RAG 没那么复杂：6 个检索方案，从最小到完整

原文来源：Lighthouse AI Newsletter — 六种检索增强生成方案，从最小到最复杂，教你按数据特征选型而不是一上来就堆 embedding。

现在提到 RAG，大多数人第一反应就是 embedding + 向量数据库 + 重排管道，一套组合拳打下去。但用户往往只是想找到那篇写着"如何重置密码"的文档。过度设计才是当前 RAG 的主流问题。

工程上永远是对的问题用对的工具，检索系统也一样。这篇文章给了一张"配方表"：从最简到最全共 6 种方案，从上往下选，只有当数据证明你需要更复杂的方案时再往下走。

先看决策因素

选型前，先回答这五个问题：

数据新鲜度：实时更新的内容（新闻、社交）要选容易重建索引的方案；稳定语料（月度甚至季度更新）才适合预计算 embedding；
语料特征：每日变动超过 10% 的高频变动语料，别做全量预 embedding；90% 内容没人访问的长尾分布，即时计算反而赢；
查询模式：关键词型查询从全文搜索起步；语义型、对话型查询才需要 embedding；混合型用混合方案；
规模与性能：每天不到 1000 次查询，简单方案足够；1K 到 10K 需要选择性优化；超过 10K 才值得全套优化；
团队能力：没有 ML 经验就留在全文搜索 + 查询重写；有 ML 经验再考虑混合检索；有专门团队才上高级方案。

—— 广告 ——

配方 1：MVP——纯全文搜索

就是 BM25、Elasticsearch、Postgres 全文搜索——那些"embedding 变成动词"之前就存在的东西。

适用场景：刚起步；用户写关键词式查询；精确匹配重要（比如发票号）；不想碰任何 ML 复杂度；语料里有专有术语。

优点：API 零成本、10ms 内返回、好调试（能清楚看到文档为什么匹配）、不需要 chunking 策略、不需要评估体系、没有模型弃用风险。缺点：漏同义词（"car" 和 "automobile"）、语义查询抓瞎、不理解意图。

作者的经验：纯全文搜索能解决相当大比例的真实用例。别跳过这一步——直接上 embedding 会立刻掉进"chunk 多大？512 还是 1024 token？overlap 多少？语义切块还是定长？怎么评估切块好坏？"的无底洞。

配方 2：Agentic 查询重写

用 LLM 把混乱的用户查询改写成干净的关键词查询。核心洞察：大部分"语义搜索"问题，其实是查询构造问题。

比如用户问"怎么让代码跑得更快"，文档里写的是"优化性能"，改写器把它变成"优化性能"；专有名词可以直接在 system prompt 里声明"Atlas 是我们内部的数据处理框架，永远原样保留"。

比 embedding 灵活在哪？embedding 效果不好，你得调 chunk 策略、重嵌整个语料库、跑回归测试，然后祈祷有改善；查询重写效果不好，改 system prompt 就行。成本约每次查询 0.001 美元（GPT-4o-mini 改写）。

更进一步可以做多轮 agentic 循环：改写 → 搜索 → 评估结果质量 → 质量不达标就根据反馈再改写，最多迭代三次——全程不用重嵌任何东西。

配方 3：混合搜索（BM25 候选 + embedding 重排）

BM25 先取 50 到 100 个候选，再用 embedding 重排出前 10 个。BM25 快、擅长关键词；embedding 懂语义，两者互补。

算笔成本账（按 OpenAI text-embedding-3-small 每百万 token 0.02 美元）：每次查询重排 50 篇文档（平均每篇 500 token）是 25000 token，约 0.0005 美元。每天 1000 次查询，一个月约 15 美元——其实挺便宜。但真正的代价是延迟：每次查询现算 50 个 embedding 要加 200-500ms，对用户可见的搜索来说很明显。而且 chunking 问题回来了：引入 embedding 就要决定怎么切块、块多大、重叠多少。

配方 4：即时 embedding（高频变动数据的答案）

数据天天变，为什么还要定期重嵌整个语料？每次查询时对候选文档现算 embedding 就好。

适用场景：每日超过 10% 文档更新的语料；实时内容；想实验不同 embedding 模型（切换零成本）；K 值小（重排 20-50 篇）。

模型弃用是它的高光时刻：OpenAI 弃用过 text-embedding-ada-002。如果你预嵌了 1000 万篇文档，换模型 = 重嵌 1000 万篇 + 更新向量库 + 回归测试 + 切换期；即时 embedding 方案改一行代码就完事。

代价是延迟：每次查询都在做 embedding，200-500ms。只有能接受这个延迟、且新鲜度优先的场景才适合。

配方 5：预 embedding + 冷热分层

访问模式符合帕累托分布：20% 的文档吃掉 80% 的流量。那就把高频文档（热层）预计算 embedding，低频文档（冷层）按需现算。

code

# 热文档走预计算向量（快），冷文档即时 embedding（慢但罕见）
hot_scores = vector_db.similarity_search(query_emb, hot_docs)
cold_scores = embed_and_score(cold_docs, query_emb)

模型更新时的账：全量预嵌 100 万文档换模型要 1 万美元 + 停机；冷热分层只重嵌热层 20 万篇，2000 美元 + 极少停机；即时 embedding 改一行代码，0 美元 0 停机。

适用场景：访问模式有明显冷热、语料中等偏大（10 万+）、混合稳定与变动内容、需要常见查询低延迟、想最小化模型更新成本。

配方 6：全量预 embedding（规模玩家的玩法）

把所有内容提前嵌入向量数据库，用 ANN（近似最近邻）搜索。

适用条件很苛刻：每天 10K+ 查询、需要 50ms 内延迟、语料非常稳定（每月变动低于 5%）、访问模式无长尾、有 ML 团队维护基础设施。

成本：预嵌 100 万文档一次性约 10 美元（embedding 本身不贵），存储 100 万 × 1536 维 × 4 字节 ≈ 6GB，每月 10-30 美元。真正痛的是模型弃用：换模型 = 停机 + 重嵌百万文档 + 全量回归测试 + chunk 策略重估 + 领域效果变差的风险。

作者原话："我见过团队花几个月优化向量数据库，而查询重写能解决他们 90% 的问题。"全量预 embedding 对大多数系统都是过度设计——除非你是 Pinterest、Shopify 那个量级。

多意图查询：Perplexity 的玩法

前面都在讲单意图查询。真实用户会问"怎么读 CSV、清洗缺失数据、然后画图"——这是三个独立意图，当成一个查询搜，就像找一家同时卖披萨、寿司和墨西哥卷的餐厅。

现代 agentic RAG（Perplexity、ChatGPT search）的处理方式：

查询理解：agent 把查询拆成子查询，标出依赖关系（读 > 清洗 > 画图）；
并行自适应处理：简单子查询（"pandas read csv"）走停用词 + 词形还原 + BM25，零成本、15ms；中等子查询加同义词扩展；复杂子查询才走 LLM 改写 + 多路搜索，0.001 美元、250ms；
合成：按依赖顺序合并结果，给出带代码示例的完整回答。

算账对比：不拆解的话，LLM 改写整个复杂查询 0.005 美元 + 嵌 50 篇文档 0.025 美元 = 0.03 美元/次；拆解后简单子查询免费，总计 0.002 美元——便宜 15 倍，质量还更好。每个子查询聚焦精确，并行执行让延迟取最大值而非总和，agent 可以智能决定哪些子查询值得花贵钱、哪些用便宜方案打发。

选型决策树

如果只想要一句话的答案：你有搜索功能吗？没有就先做纯全文搜索。 全文搜索不够再考虑查询重写；还不够、且能接受 200-500ms 延迟再上混合检索；数据天天变就做即时 embedding；规模大了再考虑冷热分层，最后才轮到全量预 embedding。每一步都是被数据推着走的，不是被流行词拉着走的。