RAG 比你想的更简单：六种检索方案从简到繁
RAG 比你想的更简单
做 RAG 的同学必看，这篇把检索方案从简到繁拆成六档，还给了决策因素和成本测算，直接照着选型就能落地，赶紧收藏。
Under the Hood
引擎盖之下
RAG Is Simpler Than You Think
RAG比你想象的更简单
Six approaches to retrieval-based AI, from minimal to elaborate
从最小化到精细化的六种检索式AI方法
Rafael Pierre
拉斐尔·皮埃尔
Jun 10, 2026
2026年6月10日
12
12
5
5
Share
分享
Hello, Rafael here - every week I cover interesting challenges and developments that I’ve come across recently through the lens of an engineer building AI systems.
你好，我是拉斐尔——每周我都会从构建AI系统的工程师视角，分享最近遇到的有趣挑战和发展。
Subscribe and get my weekly takes 👇
订阅并获取我的每周见解👇
Subscribe
订阅
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技术栈。他们直接跳到嵌入、向量数据库和重排序管道。而与此同时，他们的用户只想找到那份写着“如何重置我的密码”的文档。
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:
在我们深入具体方法之前，先确定何时使用每种方法。关键因素包括：
1. 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.
1. 数据新鲜度要求 - 实时更新（新闻、社交媒体）倾向于易于重新索引的方法。每日或每周更新适合混合方法。稳定的语料库（每月或每季度更新）使得预嵌入变得合理。
2. 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.
2. 语料库特征 - 高变动率（每日超过10%的变化）意味着应避免完全预嵌入。稳定的文档适合预嵌入。长尾分布（90%从未被访问）意味着即时处理胜出。
3. Query Patterns - Keyword-heavy queries should start with full-text search. Semantic or conversational queries benefit from embeddings. Mixed patterns need hybrid approaches.
3. 查询模式 - 关键词密集型查询应从全文搜索开始。语义或对话式查询受益于嵌入。混合模式需要混合方法。
4. 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.
4. 规模与性能 - 每日少于1000次查询意味着简单方法就足够了。每日1K到10K次查询需要选择性优化。每日超过10K次查询则值得进行全面优化。
5. 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.
5. 团队能力 - 没有机器学习专业知识意味着坚持使用全文搜索加查询重写。有一些机器学习经验可以使混合搜索变得可管理。拥有机器学习团队则使高级方法可行。
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全文搜索。这些在“嵌入”成为动词之前就已存在的东西。
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 (more on this later).
你刚开始。你的用户编写关键词式查询（“pandas合并数据框”）。精确匹配很重要（“发票#12345”）。你希望零机器学习复杂性。你的语料库包含专有术语（稍后详述）。
Pros
优点
Zero API costs. Fast (under 10ms). Easy to debug (you can see exactly why a document matched). Surprisingly effective (handles many use cases). No chunking strategy needed – works with full documents. No evaluation complexity – easy to test and validate. No model deprecation risk (BM25 doesn’t change).
零API成本。速度快（低于10毫秒）。易于调试（你可以确切看到文档为何匹配）。出乎意料地有效（处理许多用例）。无需分块策略——适用于完整文档。无评估复杂性——易于测试和验证。无模型弃用风险（BM25不会改变）。
Cons
缺点
Misses synonyms (”car” vs “automobile”). Fails on semantic queries (”How do I...?”). Can’t understand intent beyond keywords.
无法识别同义词（“汽车”与“机动车”）。在语义查询（“我如何...？”）上失败。无法理解关键词之外的意图。
In my experience, this handles a significant portion of use cases. Don’t skip this step. You might be surprised how far you can get.
根据我的经验，这处理了相当一部分用例。不要跳过这一步。你可能会惊讶于它能走多远。
When you jump straight to embeddings, you immediately face questions like: What chunk size? (512 tokens? 1024?) What overlap? (50 tokens? 100?) Semantic chunking or fixed-size? How do I evaluate if my chunking is good?
当你直接跳到嵌入时，你立即面临这样的问题：块大小是多少？（512个令牌？1024个？）重叠多少？（50个令牌？100个？）语义分块还是固定大小？我如何评估我的分块是否好？
With full-text search, you skip all of this. Your documents are your documents. Search just works.
使用全文搜索，你跳过所有这些。你的文档就是你的文档。搜索就是有效。
Thanks for reading Lighthouse AI! This post is public so feel free to share it.
感谢阅读Lighthouse AI！这篇文章是公开的，所以欢迎分享。
Share
分享
Recipe 2: Agentic Query Rewriting
配方2：代理式查询重写
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 (your framework called “Atlas”). You want flexibility to iterate quickly on query strategies.
用户以对话方式提问。词汇不匹配（用户说“修复错误”，文档说“调试”）。你有内部术语（你的框架称为“Atlas”）。你希望灵活地快速迭代查询策略。
Cost
成本
~$0.001 per query (using GPT-4o-mini for query rewriting)
每次查询约$0.001（使用GPT-4o-mini进行查询重写）
The magic
神奇之处
An LLM can remove stopwords (”how do I” becomes nothing). It can add synonyms (”car” becomes “car automobile vehicle”). It can translate domain terms (”speed up code” becomes “optimize performance”). It can decompose complex queries (”read CSV and plot” becomes [”read CSV”, “plot data”]). It can learn from your glossary (via system prompt).
LLM可以移除停用词（“我如何”变成无）。它可以添加同义词（“汽车”变成“汽车 机动车 车辆”）。它可以翻译领域术语（“加速代码”变成“优化性能”）。它可以分解复杂查询（“读取CSV并绘图”变成[“读取CSV”，“绘图数据”]）。它可以从你的词汇表中学习（通过系统提示）。
Why this is more flexible than embeddings
为什么这比嵌入更灵活
With embeddings, if results aren’t good, you need to adjust chunking strategy, re-embed entire corpus, run regression tests on your eval set, and hope it improved.
使用嵌入，如果结果不佳，你需要调整分块策略，重新嵌入整个语料库，在评估集上运行回归测试，并希望它有所改进。
With query rewriting, if results aren’t good, you adjust the system prompt. That’s it. Test immediately.
使用查询重写，如果结果不佳，你调整系统提示。就这样。立即测试。
Multi-turn agentic rewriting
多轮代理式重写
Even better, you can create a loop:
更妙的是，你可以创建一个循环：
def agentic_search(query, max_iterations=3):
for i in range(max_iterations):
# Rewrite query
optimized = query_rewriter.rewrite(query, iteration=i)
# Search
results = bm25_search(optimized)
# Evaluate quality
quality = evaluate_results(results, query)
if quality > threshold:
return results
# Agent learns and tries again
query = refine_based_on_feedback(query, results, quality)
return resultsdef agentic_search(query, max_iterations=3):
for i in range(max_iterations):
# Rewrite query
optimized = query_rewriter.rewrite(query, iteration=i)
# Search
results = bm25_search(optimized)
# Evaluate quality
quality = evaluate_results(results, query)
if quality > threshold:
return results
# Agent learns and tries again
query = refine_based_on_feedback(query, results, quality)
return resultsThe agent can iterate, learn, and adapt – all without re-embedding anything.
代理可以迭代、学习和适应——全程无需重新嵌入任何内容。
Example: The Proprietary Terminology Problem
示例：专有术语问题
Say your company has a Python framework called “Atlas.” If you use general-purpose embeddings:
假设你的公司有一个名为“Atlas”的Python框架。如果你使用通用嵌入：
General embedding model (trained on internet):
“Atlas” = [vectors pointing toward: Greek mythology, maps, geography]
Your actual Atlas docs = [vectors about data processing]
Similarity score: 0.15 (terrible!)General embedding model (trained on internet):
“Atlas” = [vectors pointing toward: Greek mythology, maps, geography]
Your actual Atlas docs = [vectors about data processing]
Similarity score: 0.15 (terrible!)The model has no idea your “Atlas” exists. It falls back to what it learned in training. But with query rewriting:
模型不知道你的“Atlas”存在。它会退回到训练中学到的内容。但通过查询重写：
system_prompt = """
Domain-specific terms (NEVER modify these, use as exact keywords):
- Atlas: our internal data processing framework
- Mercury: our messaging system
- Zeus: our auth service
Preserve these terms exactly and optimize the rest of the query.
"""
# User: "How do I use Atlas for batch jobs?"
# Agent: "Atlas batch jobs data processing pipeline"
# BM25: Perfect match on "Atlas" ✓system_prompt = """
Domain-specific terms (NEVER modify these, use as exact keywords):
- Atlas: our internal data processing framework
- Mercury: our messaging system
- Zeus: our auth service
Preserve these terms exactly and optimize the rest of the query.
"""
# User: "How do I use Atlas for batch jobs?"
# Agent: "Atlas batch jobs data processing pipeline"
# BM25: Perfect match on "Atlas" ✓For proprietary terms, exact keyword matching beats semantic understanding.
对于专有术语，精确的关键词匹配胜过语义理解。
Thanks for reading Lighthouse AI! Subscribe for free to receive new posts and support my work.
感谢阅读Lighthouse AI！免费订阅以获取新文章并支持我的工作。
Subscribe
订阅
Recipe 3: Hybrid Search (Sparse + Dense Reranking)
配方3：混合搜索（稀疏+密集重排序）
What it is
这是什么
Use BM25 to get candidates (top 50-100), then rerank with embeddings (top 10).
使用BM25获取候选（前50-100个），然后用嵌入重排序（前10个）。
Why this works
为什么有效
BM25 is fast and great at keyword matching. Embeddings are good at semantic understanding. Together, they cover each other’s weaknesses.
BM25速度快，擅长关键词匹配。嵌入擅长语义理解。两者结合，互补短板。
When to use
何时使用
Users ask semantic questions (”find alternatives to X”). BM25 plus query rewriting alone isn’t cutting it (you have data proving this). You can tolerate 100-500ms latency. Your corpus is relatively stable (not changing every minute).
用户提出语义问题（“寻找X的替代品”）。仅靠BM25加查询重写不够（你有数据证明这一点）。你能容忍100-500毫秒的延迟。你的语料库相对稳定（不是每分钟都在变化）。
The pipeline
流程
Cost considerations
成本考量
Let’s do the math with current pricing (OpenAI text-embedding-3-small at $0.02 per 1M tokens):
我们用当前价格算一下（OpenAI text-embedding-3-small，每百万token $0.02）：
- Embedding 50 docs per query (avg 500 tokens each) means 50 docs × 500 tokens = 25,000 tokens
- Cost: 25,000 × $0.00002 = ~$0.0005 per query. At 1,000 queries per day × 30 days = ~$15 per month.
- 每次查询嵌入50个文档（平均每个500 token）意味着50个文档 × 500 token = 25,000 token
- 成本：25,000 × $0.00002 = 每次查询约$0.0005。每天1,000次查询 × 30天 = 每月约$15。
Actually pretty reasonable. But there’s a catch: latency.
实际上相当合理。但有一个问题：延迟。
Embedding 50 documents on-the-fly adds 200-500ms per query. For user-facing search, that’s noticeable. This is where the real trade-off lives – not cost, but speed.
每次查询即时嵌入50个文档会增加200-500毫秒延迟。对于面向用户的搜索，这是明显的。真正的权衡在这里——不是成本，而是速度。
Important consideration: The chunking problem returns
重要考虑：分块问题回归
When you introduce embeddings, you need to decide how to chunk your documents (fixed-size? semantic? by section?). You need to determine what chunk size and overlap to use. You need to handle chunks that span important context.
当你引入嵌入时，需要决定如何分块文档（固定大小？语义？按章节？）。你需要确定使用什么块大小和重叠。你需要处理跨越重要上下文的块。
This adds complexity that pure full-text search avoids.
这增加了纯全文搜索所避免的复杂性。
Recipe 4: On-The-Fly Embedding (The Fresh Data Play)
配方4：即时嵌入（新鲜数据玩法）
The insight
洞见
If your data changes frequently, why pay to re-embed everything?
如果你的数据频繁变化，为什么要为重新嵌入所有内容付费？
What it is
它是什么
When to use
何时使用
更进一步：量化金融体系
看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力