先别急着上 RAG：四根轴算清适用边界

同一个问题，两种问法，两种命运#

先把模式抽象出来。设用户想问的问题是 a，文档库里对应的答案是 A，问法有两种：

• a1（行话版）——用户嘴里的词和文档里的词高度重合
• a2（口语版）——用户用自己的生活语言描述同一个意图，文档原词一个没出现

a1 靠关键词检索就能命中；a2 是关键词检索的天敌。举个具体例子，某公司报销制度里写的是”探亲路费凭票报销，硬座全报、卧铺报七成”：

• 问法 a1：“探亲假火车票的报销标准是什么？”——“探亲""火车票""报销”全是文档原词，关键词检索秒中。制度全文不到一千字，命中后直接整篇读进上下文，什么都不用再建。
• 问法 a2：“我老家在外地，过年回去的高铁票能报多少？“——文档里没有”过年""回去""高铁”，关键词检索零命中。但语义上这就是探亲路费，向量检索能接住。

同一个意图，两种问法，命运完全不同。这就是检索选型的第一性原理——分界线不在数据量，不在公司规模，在用户嘴里的词和文档里的词的重合度。

四根轴，一条口诀#

口诀：塞得下加低频，全塞；塞得下加高频，检索省钱省延迟；塞不下，没得选；要精度，检索是降噪器。

把后两根轴交叉，能得到一个反直觉的结论——语义检索的真实主战场是非规范语料乘口语化提问（工单、聊天记录、会议纪要），而不是规范文档。给一万条法条建向量库，不如一个文件名匹配加全文阅读。

顺带拆掉两个常见误解：

误解一，“做个路由判断，简单问题走关键词、复杂问题走向量”。不需要，也做不好——用户下一句话会怎么措辞，事前不可知。工业界的答案是并联：两路检索同时发出，用 RRF（倒数排名融合）把两份榜单合成一份。不赌用户的嘴，让两路投票。这也不是两套系统，关键词索引可以内存直跑，向量库是同一批文档的另一个视图，同源同更新。

误解二，“检索策略要动态选”。其实产品形态在立项时就把策略定死了——用户要原文（工程师查报错），做成搜索产品，返回列表加高亮，不用接大模型；用户要人话（新人问制度），做成问答产品，检索是内部管道，用户只看到答案加引用角标。运行时零判断。

“我都 1M 上下文了，全部塞进去不行吗？”#

小语料、低频场景——行，而且这就是最优解，主流 AI 编码工具就是这么干的（不用向量库，代理自己搜索加读文件）。但账要算完四笔：

1. 成本是乘法。十万 token 语料，全塞与检索只差九万五，单次看着免费；乘上一千次查询就是每天一个亿 token 级的重复读入。且超长输入通常分档加价，缓存会在文档一改时全部失效。
2. 延迟买不掉。十万 token 的读入阶段首字延迟是秒级，五千是亚秒级。这是吞吐问题，加钱只能缓解不能消除。
3. 精度随长度衰减。大海捞针测试（一根针藏进百万 token 找出来）强模型近乎满分，但真实任务是多针加干扰项加交叉引用——塞十万 token 其中九成与本题无关，注意力被稀释，实测答案质量反而低于只塞五千精准内容。
4. 规模上限。十万篇文档是数亿 token，百万窗口塞不进百分之一，“全塞”根本不在选项里。

还有个反转认知的事实。很多人说”我用关键词把相关内容全找出来，一起塞进上下文”——这句话里的”找出来”本身就是检索。关键词匹配、按相关度排序返回前若干条，这就是检索器的召回端，只是没叫 RAG 的名字。所以真实的格局不是”RAG 对抗全塞”，而是分层共存。

检索没死，但换了角色#

强模型时代，检索的三个新定位：

• 供料阀门。再强的模型也读不见窗口里不存在的内容。检索的角色从”补模型知识短板”变成”省钱的供料阀门”——用百分之一的 token，买到九成的效果。
• 降噪器。这是长上下文给不了的能力——把无关内容挡在窗口外面。前排噪音挤占 token 预算，正确文档排太后还会被截断、被”中间遗忘”，所以精排才有价值：给上下文窗口里那几个宝贵座位挑对的乘客。
• 幻觉的缰绳。反直觉但重要——模型越强，幻觉越自信。召回不足时，强模型更敢用内部知识补漏。供料质量与模型能力是乘法关系，不是替代关系。

同时有一份贬值清单。查询改写、多轮语义扩充这类”帮模型理解差句”的优化正在贬值——现代大模型在输入时自己就会理解、联想、改写，它本身就是查询理解器，在它前面再包一层人工查询工程是浪费时间。升值的是召回准确性、精排、去重。

口诀：优化”喂什么”的永远有效，优化”帮模型理解差句”的正在贬值。

真要上，默认配方能到九十分#

基本向量库加 embedding 切块加一个精排模型，就是 90% 可用的系统，接入大模型答题能到七八十分。剩下那二十分，没有规模和评测集就不要追。

顺带把精排说透，因为它是被误解最深的一环。召回阶段用的是双塔结构——查询和文档各自独立编码成一个向量再比对距离，两者从未”见过面”，快，可以离线预计算，毫秒级扫全库。精排是另一种模型——把查询和文档拼接成一个序列一起读，词级交互，逐对打分，准但慢，只能伺候前二十到五十个候选。一个是海选简历，一个是面试当面聊。另外注意，把向量从 768 维换成 2048 维不是精排——那是换更强的召回模型，两件事正交。

那二十分怎么追？靠评测闭环，不是靠感觉。核心是先有一小份金标准评测集——二十条起步，每条是”问题加应命中的文档加标准答案”。来源三选：让大模型从文档反向生成问题（半天出几百条，但问法一股文档腔，只能冷启动用）；从真实查询日志里抽题人工标注（二十条约一小时，质量最高）；上线后收集用户点”答案不对”的反馈滚动入库（每周一两个小时，评测集随产品长大）。有了它，每次改配置都有分数可看，错误可归因——该召回的没召回改切块和混合检索，召回了排太后上精排，召回全对答案胡编改接地指令和引用标注，答案跑题改提示词或换模型。

归因口诀：用户骂”答非所问、胡编”，先查检索；用户骂”讲得绕、听不懂”，再换模型。检索决定有没有答案，模型决定答案讲得好不好。

写在最后#

回到开头的两派。“RAG 已死”派只看到了窗口变宽，没看到注意力会稀释、延迟要付钱；“无脑上 RAG”派只看到了简历潮流，没问过用户说不说行话。两者共享同一个错误——把工程选项当信仰。

下次有人问”要不要上 RAG”，先反问四个问题：语料多大、查得多不多、用户说不说行话、文档规不规范。四个答案出来，要不要上、上到哪一层、优化停在哪一分，自己就出来了。