RAG检索模型才是地基：召回、融合到重排的调优实战

前阵子我连续接了几个RAG项目的代码评审和调优咨询，发现一个扎心的共性：大家建了知识库、接了向量数据库、也写了完整的“检索-增强-生成”链路，但回答质量就是上不去。问“报销流程”，模型一本正经地引用考勤制度；问“某版本怎么升级”，检索回来的全是接口说明。最开始几乎没有人怀疑检索，都在换大模型、调温度参数、改Prompt，折腾一圈毫无起色。

后来我逐个把链路拆开，发现问题出在最容易被忽略的环节：检索模型根本不是“建个索引、查一下相似度”那么简单，很多系统所谓的RAG，本质上只是“向量数据库+大模型”，根本没有一个真正合格的检索模型在干活。这个标题不是我故意耸人听闻——“没有检索模型构建RAGs”，在真实项目里几乎等于白做。这篇文章我想把这些踩坑、定位和调试过程完整复盘一遍，重点讲清楚：为什么检索模型才是RAG的地基、怎么判断自己的系统是不是“伪RAG”、以及一条从评估到调优的完整落地路径。

1. “伪RAG”的翻车现场：生成模型再强，也救不了一个捡不到答案的检索器

1.1 三种几乎每个RAG项目都会遇到的症状

先说我在实际项目里看到的高频症状，你对照一下就知道自己的系统有没有中招。

第一种是答非所问但看似流畅。用户问“夜班补贴的具体发放标准”，系统召回的是《差旅补贴管理办法》，大模型拿着这段不相关的内容，硬是编出一段“夜班补贴按工作日计算，每晚XX元”的答案。注意，这个答案格式规整、语气肯定，如果用户不了解业务，很容易被糊弄过去。症结很明显：召回层根本没找到“夜班补贴”这份材料，但生成层并不会说“我不知道”，它会基于错误的上下文继续自圆其说。

第二种是幻觉照旧。很多人以为RAG能解决幻觉，实际上RAG只能缓解“完全凭空编造”，但解决不了“上下文不对导致的掺杂编造”。当检索回来的5个chunk里有3个不相关，大模型依然会尽力把不相关内容也纳入回答，甚至把两个不同文档的信息拼接成一份根本不存在的标准。

第三种是定位困难。用户知道系统里肯定有答案，但它就是找不到。比如某知识库里有2000多份运维文档，用户问“Redis内存满了怎么办”，系统召回的第1名是某篇讲CPU飙高的日志分析文章，真正讲了maxmemory配置的文档排在第八。这种情况单纯调Prompt完全没用，因为问题出在“排序”和“召回范围”上。

1.2 为什么大家都察觉不到是检索的锅

这里有个非常有意思的现象：生成模型会掩盖检索模型的低质量。也就是大模型的语言组织能力太强了，它能把一堆不太相关的材料也整理成逻辑通顺的文字。只有当你追问细节、做bad-case分析时，才会发现答案的“原材料”本身就有问题。

另外，很多人在Demo阶段自欺欺人。本地测试的时候，用的都是自己精心构造的三五条query，还都是那种“和文档标题高度一致”的问题，自然百发百中。一旦上线，真实用户的问法千奇百怪——口语化表述、错别字、中英混输、指代省略——检索效果立刻崩盘。

我见过一个团队，把评估集从5条扩充到200条真实用户问题后，Recall@5从Demo时的90%掉到不足50%。这个差距不是模型能力问题，而是从一开始就没有把“检索模型”当作一个独立、需要专门设计和评估的组件。

2. 检索模型不是“建个索引”，是整条“召回-融合-排序”链路

2.1 一次合格的检索，中间要发生四件事

很多人理解的RAG是这样的：用户提一句query → 向量数据库里查相似度Top5 → 拼进Prompt → 大模型回答。如果只做这一步，那你用的只是“检索操作”，而不是“检索模型”。

我理解的完整检索链路，至少包含四件事：

用户Query → 查询理解和改写 → 多路召回（向量召回 + 关键词召回） → 结果融合（RRF或加权） → 重排序精排 → 送入LLM生成

这四件事，每一件都在解决不同层面的问题：

• 查询理解/改写解决的是“用户没说清”的问题，比如“上次那个流程怎么走”需要被解释成“XX审批流程怎么走”。
• 多路召回解决的是“单一匹配方式会漏”的问题，向量找语义、布尔/关键词找精确匹配。
• 结果融合解决的是“不同召回方式结果怎么合并”的问题。
• 重排序解决的是“粗选Top50里谁才是真正该进上下文”的问题。

缺了其中任何一环，整个系统都算不上“有检索模型”。注意我的用词：这里说的“模型”，不是单指某个Embedding模型或者Reranker模型，而是指一套有召回策略、有排序逻辑、能回答‘哪些材料值得进上下文’的完整机制。

2.2 向量检索只是其中一环，它救不了专有名词和精确编号

先声明一下，Embedding模型是检索模型的“地基”，这一点没有争议。但如果你觉得“向量相似度”能解决所有召回问题，就大错特错了。

我拿一个真实场景举例。用户问“V1.3.2版本的升级步骤”。在向量语义空间里，V1.3.2的向量和V1.3.0、V1.3.1的向量可能非常接近，物理上它们都是“版本升级说明”，语义高度相似。但业务上，用户要的就是那个精确的V1.3.2，不是你推给它一个V1.2.8的升级指南。这种场景下，精确关键词匹配（BM25/Lexical Search）比语义匹配可靠得多。

还有一个常见坑：很多Embedding模型对拼写错误、缩写、代码片段、型号的敏感度很低。你让它区分“TCP”和“UDP”，如果文档里没出现明确的指代关系，向量可能就把两者视为高度相关了。所以，成熟RAG系统的标配是“混合检索”：

• 稀疏检索（BM25/关键词）：负责精确匹配、专有名词、编号、代码片段。
• 稠密检索（向量）：负责语义泛化、同义改写、跨语言理解。
• 两者按策略融合，而不是只用其中一种。

如果你现在还在“只用向量数据库的相似度检索”，那这个RAG离“没有检索模型”确实只差一步了。

2.3 重排序为什么是“能否用对材料”的分水岭

混合召回之后，通常会得到一批候选，少则20条，多则50条。问题来了：直接把50条全部塞给大模型，一方面浪费token、增加延迟，另一方面信息太多反而会干扰生成。大模型在长上下文里同样存在“注意力漂移”，塞进去10个chunk往往比塞3个高质量的chunk效果更差。

重排序（Rerank）就是解决这个问题的。典型的做法是用Cross-Encoder结构，把(query, passage)同时输入模型，计算出两者之间的精细匹配分，而不是像向量检索那样把query和passage分别编码再算余弦相似度。Cross-Encoder能捕捉到“query里的这个词在passage里有没有出现”“这句话是不是真正回应了问题意图”这类细粒度信号，排序准确率通常远高于双塔向量模型。

实操上常见的策略是：

向量召回Top50 + BM25召回Top50 → RRF融合去重 → Rerank取Top3-5 → 进LLM

我常说一句话：召回决定有没有，重排决定用不用得对。如果你的系统把重排省了，就算前面Recall再高，最终喂给LLM的那几个chunk未必是真正对的那几个，这其实就是一种很隐蔽的“没有检索模型”。

3. 可信度自检：在你说“检索还行”之前，先做一次离线评估

3.1 为什么评估必须排在所有调优前面

做RAG调优，最忌讳的就是“凭感觉”。一会儿觉得这个Embedding模型更牛，换了；一会儿觉得chunk切到512肯定好，改了；然后看几条Demo觉得不错，就算验收了。这是错误的。

原因很简单：没有量化指标，你根本不知道改动是正向还是负向的。有些Embedding模型在三条例子上表现很好，但在一百条真实问题上可能平均分反而下降。所以我的习惯是：任何RAG系统，第一周只干一件事——搭评估集、跑基线、把指标记录下来。所有后续优化都围绕指标做AB对比。

3.2 如何用一个“最小可用评估集”撑起整个调优周期

构建评估集不一定非要豪横到标注几千条。对绝大多数中小项目来说，50到100条高质量的真实问题已经能提供非常有价值的信号。

评估集的构建办法我推荐这样：

1. 从已有用户日志里抽样，如果系统还没上线，就让团队里真正的业务方（不是开发自己）每人提10到20个真实工作问题。
2. 针对每个问题，人工标注1到3条“golden passage”，也就是“如果让我手找文档，我会优先看哪几段”。
3. 如果实在没有标注人力，可以借助“LLM生成候选问题+人工过滤”的方式提效。让大模型基于每个文档段落生成问题，然后人工删掉质量差的，等于半自动造了一批评估数据。

注意，评估集里的query一定要“像真实用户”，口语化、不完整、有歧义都没关系。我经常看到团队用“与文档标题完全一致的query”做评估，那等于开卷考试，数据再好也没有参考价值。

3.3 检索指标与生成指标，先看哪个？

我习惯把评估指标分成两层，两层都要看，但顺序不能反。

调试顺序上，我强烈建议先盯Recall@K和Hit Rate，再盯MRR，最后关注Rerank之后的效果。这就好比打猎：如果弓箭射程内根本没有猎物（Recall差），你瞄得再准（排序好）也没用。只有当“答案已经在Top50里”了，重排才有意义。

真实案例：某系统基线Recall@5只有57%，但Hit@1很低，因为正确材料每次都能被召回但不排在前三。这时候该做的就不是换Embedding了，而是加一停用词过滤、加元数据过滤，让它往前提。层级搞错，优化会南辕北辙。

4. 分块、查询改写与元数据过滤：真正拉高检索天花板的三个关键点

4.1 分块策略：小chunk高精准，大chunk有上下文，别二选一

分块是检索模型里最“编程简单但业务影响最大”的环节。固定长度512字、重叠64字方便省事，但代价是语义被拦腰截断。我试过一份合同文档，第400字正好卡在“甲方应于____前支付”中间，后半句整段被切断，检索到这个chunk时，鸡蛋里的骨头全丢了。

比较实用的做法是父子分块（Parent-Child Chunking）或者段落边界感知分块：

• 把文档按自然段落/标题结构切分成“父块”，父块通常是完整语义单元。
• 在父块内部再切成更细的“子块”，子块负责检索。
• 命中子块后，用父块的完整内容喂给LLM。

这样做的逻辑是：子块小、语义聚焦、召回精准度高；父块大、上下文完整、信息量足。两者配合，可以兼顾“找得到”和“够完整”。

如果不想上父子分块，至少做到“分段切+小重叠”，避免把段落切碎。很多人在这一步图省事，后面在重排环节省再多力都补不回来。

4.2 查询改写：别让用户的原话直接进检索器

真实用户很少用“关键词+完整名词”提问，他们说话更像“上次那个表填错了怎么办”这种依赖上下文的表达。如果原样拿这句话去做向量检索，效果可想而知。

所以，查询经过一次LLM改写/扩展是非常值得的。改写方向有两种：

• 意图补全：把“上次那个表”改写成“XX月数据统计表填写的错误处理流程”。
• 子查询拆分：用户问“报销流程和标准是什么？”，拆成“报销流程”“报销标准”两条子查询分别检索，再合并结果。

这里要提醒一下，不是每个query都要调用LLM去改写。成本高、延迟高。我在项目里一般先用“高频query缓存+规则识别”：完全匹配的可以用历史缓存结果；明显是短query、口语化query的才触发LLM改写；关键词足够精确的直接走原句检索。

还有一个经常被拿来主义但需要慎用的招叫HyDE（假设文档嵌入）：先让大模型基于query写一个“假想答案”，再用这个假想答案去检索。效果在部分场景确实能提升召回，但它会引入“编造出来的词汇”，如果假想答案和真实文档语言风格差异很大，检索质量反而下降。真想用，就得先在评估集上小范围验证，别一把梭全量上。

4.3 元数据过滤：最容易赚到的检索分，别忽略

很多项目把所有文档一股脑塞进一个集合，没有任何元数据标签，检索时所有的老版本、作废文档、不同部门材料全部平等竞争。这是检索质量上不去的隐形原因。

我强烈建议在文档入库时就带上结构化字段：部门、文档类型、生效时间、产品线、状态（有效/已废弃）。检索时先做前过滤（Pre-filter），比如“只查财务类、最近两年、有效状态”的文档，再执行向量/关键词检索。

有次我调某个知识库，只加了一个“排除已废弃文档”的前过滤，Hit@1直接从38%跳到52%。因为原来的Top结果常年被几个过时版本挤占，向量模型根本分辨不了“新旧版本哪个是答案”，但一个简单的元数据条件就能搞定。

5. 从52%到89%的检索调优复盘：每步都有数据，不看运气

5.1 一个典型的基线状态

前面讲了这么多原理，最后我拿一个模拟项目的调试过程复盘一下，方便你对照自己的系统一步步来。

假设某团队做一个内部知识库问答RAG系统，文档量3000多份，包含制度、操作手册、FAQ、故障复盘等。上线前评估集有80条真实业务问题。初始基线如下：

这个基线很典型：看起来能用，实际体验很差。用户问10个问题，差不多一半系统连正确材料都捞不回来，更别说答案质量了。

5.2 一步一步改，别一次上五个方案

当时的优化是按顺序做的，每步都重新跑同一份评估集：

注意这里的变化趋势，不是每个改动都能带来奇迹。V4那一步Recall@5只涨了3%，但MRR从0.49涨到0.55，这说明召回宽度已经够，重排开始把正确材料往前推。而V5那步，最大的受益者是那种“用户没把名词说全”的坏query，经过LLM改写后，直接回到正确召回区间。

关于RRF公式，也顺便说一下，免得你看到“融合”就发怵。RRF不依赖各召回源的分数大小（向量距离和BM25分数本来就不在一个量级），只看排名：

RRF(d) = Σ 1/(k + rank_i(d))

k通常取60左右。某条文档在BM25里排第2、在向量里排第5，那它的融合分就是 1/62 + 1/65，两者排名越靠前，融合分越高。这个公式的好处是鲁棒，不需要调权，非常适合两种异构召回结果合并的场景。

5.3 这次复盘里最重要的三条经验

第一，换Embedding模型是“最后的手段”，不是第一手段。很多人一觉得RAG效果差就嚷着“换个更牛的Embedding”，结果V2环节只带来7个百分点的提升，而V3混合召回和V5查询改写分别带来6和12个百分点的提升。在一套没有混合检索、没有改写的系统里，换Embedding相当于给一辆破车换好轮胎，跑不快还是跑不快。

第二，生成的指标也要盯，但要在检索指标稳住之后。上面的V4版本做完后，忠实度已经稳定在90%以上，因为它们拿到的大多是对的材料。如果忠实度还低，先回头查检索；只有检索Top1基本稳定命中后，生成侧优化才有意义。

第三，每一步都要留bad case记录，不要只看平均数。我们当时把每条评估query按“编号类、步骤类、制度类、口语类”打标签，统计发现V5的收益几乎全来自“口语类”，“编号类”query甚至略有下降。于是保留改写策略的同时，规定编号/版本号类query一律跳过改写，直接走BM25精确匹配。这个微调，让最终Hit@1又涨了4个点。

最后说点个人体会。RAG调优做久了，你会发现它其实是一个“检索工程”问题，不是一个“大模型调度”问题。评估集就像一面照妖镜，你的检索器到底行不行，跑一把数据全知道。如果你现在正在搭RAG系统，我建议把“先搭评估集、再调检索链路”这件事排在所有技术选型前面——哪怕一开始只是50条问题，也比没有强。还有一个小技巧：从第一天就把线上的真实用户query全部匿名收集起来，三个月后回头一看，你手里已经有了一份比任何人工标注都值钱的评估资产。