RAG Is Simpler Than You Think

RAG 比你想象的更简单

Six approaches to retrieval-based AI, from minimal to elaborate 六种检索增强 AI 的实现路径，从极简到复杂

Nowadays, most people seem to over-engineer their RAG stack. They jump straight to embeddings, vector databases, and reranking pipelines. Meanwhile, their users just want to find the doc that says “How to reset my password.” 如今，大多数人似乎在过度设计他们的 RAG（检索增强生成）技术栈。他们直接跳到嵌入（embeddings）、向量数据库和重排序（reranking）流水线。然而，用户其实只是想找到那篇写着“如何重置密码”的文档。

In engineering, there’s always the right tool for the right problem. In AI Retrieval Systems it’s not different. 在工程领域，针对特定问题总有最合适的工具。AI 检索系统也不例外。

Decision Factors

决策因素

Before we dive into recipes, let’s establish when you should use each approach. The key factors are: 在深入探讨具体方案之前，我们先确定何时应该使用哪种方法。关键因素如下：

Data Freshness Requirements - Real-time updates (news, social media) favor approaches with easy re-indexing. Daily or weekly updates work well with hybrid approaches. A stable corpus (monthly or quarterly updates) makes pre-embedding sensible.
数据时效性要求 - 实时更新（新闻、社交媒体）倾向于易于重新索引的方法。每日或每周更新适合混合检索方法。稳定的语料库（按月或按季度更新）则适合预嵌入（pre-embedding）。
Corpus Characteristics - High churn (more than 10% changes daily) means you should avoid full pre-embedding. Stable documents work fine with pre-embedding. Long-tail distribution (90% never accessed) means on-the-fly wins.
语料库特征 - 高频变动（每日变动超过 10%）意味着应避免全量预嵌入。稳定的文档适合预嵌入。长尾分布（90% 的内容从未被访问）意味着即时检索（on-the-fly）更胜一筹。
Query Patterns - Keyword-heavy queries should start with full-text search. Semantic or conversational queries benefit from embeddings. Mixed patterns need hybrid approaches.
查询模式 - 关键词密集的查询应从全文检索开始。语义或对话式查询则受益于嵌入技术。混合模式则需要混合检索方法。
Scale & Performance - Less than 1000 queries per day means simple approaches are sufficient. 1K to 10K queries per day requires selective optimization. More than 10K queries per day justifies full optimization.
规模与性能 - 每日少于 1000 次查询，简单的方案足矣。每日 1000 到 10000 次查询需要选择性优化。每日超过 10000 次查询则值得进行全面优化。
Team Capabilities - No ML expertise means stay with full-text plus query rewriting. Some ML experience makes hybrid search manageable. Having an ML team available makes advanced approaches viable.
团队能力 - 没有机器学习经验，建议保持“全文检索 + 查询重写”。具备一定机器学习经验，混合检索是可控的。拥有专门的机器学习团队，则可以尝试高级方案。

Now, let’s look at the recipe book. Start at the top. Move down only when you have data proving you need to. 现在，让我们看看这份“食谱”。从最顶端开始，只有当你拥有数据证明确实需要时，再向下尝试。

Recipe 1: The MVP – Full-Text Search Only

方案 1：MVP（最小可行性产品）—— 仅使用全文检索

What it is Good old BM25. Elasticsearch. Postgres full-text search. The stuff that existed before “embedding” became a verb. 它是什么 经典的 BM25 算法、Elasticsearch、Postgres 全文检索。这些都是在“嵌入（embedding）”成为动词之前就已存在的技术。

When to use You’re just starting out. Your users write keyword-style queries (”pandas merge dataframe”). Exact matches matter (”invoice #12345”). You want zero ML complexity. Your corpus has proprietary terminology. 何时使用 刚起步时；用户使用关键词风格查询（如“pandas 合并数据框”）；精确匹配很重要（如“发票 #12345”）；你希望零机器学习复杂度；或者你的语料库包含专有术语。

Pros Zero API costs. Fast (under 10ms). Easy to debug. Surprisingly effective. No chunking strategy needed. No evaluation complexity. No model deprecation risk. 优点零 API 成本；速度快（低于 10ms）；易于调试；效果出奇地好；无需分块（chunking）策略；无评估复杂度；无模型弃用风险。

Cons Misses synonyms (”car” vs “automobile”). Fails on semantic queries (”How do I…?”). Can’t understand intent beyond keywords. 缺点无法处理同义词（如“汽车”与“轿车”）；语义查询（如“我该如何……”）效果差；无法理解关键词之外的意图。

Recipe 2: Agentic Query Rewriting

方案 2：智能体查询重写（Agentic Query Rewriting）

What it is Use an LLM to transform messy user queries into clean keyword searches. 它是什么 利用大语言模型（LLM）将混乱的用户查询转换为整洁的关键词搜索。

The insight Most “semantic search” problems are actually query formulation problems. 核心洞察 大多数“语义搜索”问题，本质上其实是查询表述问题。

When to use Users ask questions conversationally. Vocabulary mismatch (users say “fix bugs”, docs say “debugging”). You have internal jargon. You want flexibility to iterate quickly. 何时使用 用户以对话方式提问；存在词汇不匹配（用户说“修 bug”，文档写“调试”）；有内部术语；希望能够快速迭代。

The magic An LLM can remove stopwords, add synonyms, translate domain terms, decompose complex queries, and learn from your glossary. 魔法所在 LLM 可以去除停用词、添加同义词、翻译领域术语、分解复杂查询，并根据你的术语表进行学习。

Why this is more flexible than embeddings With embeddings, if results aren’t good, you need to adjust chunking, re-embed, and run regression tests. With query rewriting, you just adjust the system prompt. That’s it. 为什么这比嵌入更灵活 使用嵌入时，如果结果不好，你需要调整分块策略、重新嵌入整个语料库并运行回归测试。而使用查询重写，你只需调整系统提示词（System Prompt），仅此而已。

Multi-turn agentic rewriting Even better, you can create a loop where the agent searches, evaluates quality, and refines the query based on feedback – all without re-embedding anything. 多轮智能体重写 更棒的是，你可以创建一个循环：智能体进行搜索、评估质量，并根据反馈优化查询——这一切都无需重新嵌入任何数据。