1. 先复盘一次线上事故纯向量检索是怎么“翻车”的大概一年前我接手了一个电商售后知识库的 RAG 项目。当时团队里没有专职做 NLP 的人大家一听说“语义检索”第一反应就是把所有文档切成块、做 embedding、塞进向量库然后用户一问就向量相似度 top-k 召回再丢给大模型生成答案。这个方案跑 Demo 的时候效果惊艳老板看了都说好——直到真正上线。第一次被打脸是在一个很普通的用户提问上“耳机充不进电怎么办”。知识库里其实有一篇很详细的文档标题是“蓝牙耳机电池维护与充电异常排查”内容里写了“如果充电无反应请检查充电线和充电口”。但最终线上系统召回的结果里这篇文档压根没出现反而召回了七八篇“耳机怎么连接手机”“耳机怎么配对”之类的文章。用户最后拿到的是一个又长又没用的大模型摘要。当时我第一反应是 embedding 模型的问题换了一个更大的模型重跑效果有改善但不彻底。后来我把这篇文档翻出来发现它内部的表述是“充电无反应”“充不进电”和用户问的“充不进电”在字面上其实就是一回事但向量表达出来之后相似度变成了 0.82低于我们设的 0.85 召回阈值。问题不在模型烂而在我们只依赖向量相似度这一条路。这件事之后我开始系统性地去查业界那些真正把 RAG 跑在大规模生产环境里的团队到底怎么做。结论让我很意外几乎所有跑得稳的系统都不是“纯向量检索”而是混合检索——稀疏检索关键词、稠密向量、甚至还有规则召回多路并行再做重排。我自己的项目也从“全向量”改成了“向量BM25 混合”上线后检索命中率直接从 73% 提高到 91%。所以这篇博文就围绕一个我们绕不开的问题来展开为什么大厂 RAG 从不用纯向量检索。我会把我在项目里踩过的坑、查过的资料、改过的架构以及最终验证有效的混合检索方案完整分享出来。2. 纯向量检索的四个结构性短板不是“调参”能解决的很多从没上过生产环境的人理解不了向量检索不是号称“语义匹配”吗为什么文字一模一样反倒搜不到这就要从向量检索的几个结构性短板说起。这四个问题互相叠加不是换个大模型或者调低阈值能解决的。2.1 处理精确匹配场景时向量会主动“丢信息”embedding 模型在训练时目标是把语义相近的文本映射到相近的空间位置。这带来一个副作用它天然会把“字面上不同但语义相同”的句子拉近但也因此主动丢弃了大量字面信息。比如“iPhone 15 可以防水吗”和“iPhone 15 的防水等级是什么”在向量空间里距离非常近。这是好事。但反过来说如果两个文本只是共享同一批关键词但语义完全不同比如“苹果好吃”和“苹果发布了新品”向量模型会把它们拉得更远——这也没问题。问题出在那些用户体感上是“精确要命”的场景型号、编号、报错码、身份证号、邮箱、价格区间、时间范围。我见过最典型的一个例子用户问“A3000 显卡支持吗”知识库里有一篇明确写“不支持 A3000”的文档结果向量检索因为“A3000 显卡”和“支持的显卡列表”语义相似度高把另一篇“支持的显卡列表”排在前面。字面匹配在这里完全输给了“语义相关”。原因其实很朴素embedding 本质上是对文本做有损压缩。模型要把一整句话塞进一个 1024 或 1536 维的向量里它必然优先保留“大意”牺牲“细节”。而“大意”在大多数 RAG 场景里恰恰不够用——用户问的是细节答案差一个型号就是错。2.2 对用户 query 的理解本身就可能跑偏上面说的是“文档侧”的信息丢失这第二短板出现在“用户提问侧”。用户不会像写文档的人那样用规范术语提问。在售后场景里同一个问题我能收集到十几种说法“充电口坏了”“插上没反应”“开不了机”“砖了”“充电没指示灯”。如果知识库文档写的是规范表述用户 query 用的是大白话两者在语义上能被多数 embedding 模型拉近但如果用户用了缩写、中英混排、错别字效果立刻崩。我做过一次测试同一批 200 条真实用户提问跑纯向量检索其中包含错别字、口语缩写、缺失主语的问题命中率比规范表述的问题低 27%。为什么向量模型训练时“见过”的错别字远少于规范输入它会把“充电没反应”和“冲电没反应”放在不同的语义簇里。用户体感就是同一句话换个说法答案质量天差地别。纯向量检索对 query 的容错能力我们往往会高估。或者说它只对“语义丰富、表述完整”的 query 是友好的对真实世界里又短、又碎、又带错的提问效果打折是常态。2.3 ANN 检索的“近似”属性本身就埋了雷大多数生产环境用的向量库比如各种支持 embedding 搜索的数据库底层都是 ANN近似最近邻索引不是暴力精确计算。ANN 的核心是“用召回率换速度”它通过 HNSW、IVF 这类算法把向量空间分区或者建图搜索的时候只遍历一部分候选节点而不是全部比较。这个“近似”带来两个隐性问题。第一阈值不可信。你以为设的 0.85 相似度很稳但 ANN 搜索出来的 top-k 只是一个近似结果它可能只在某一层子图里找到局部最近的向量真实的全局最近向量可能根本没进候选集。结果就是你调高阈值误杀变多你调低阈值噪声灌进来。第二索引参数极其敏感。HNSW 的M每个节点的最大连接数和efConstruction建图时的搜索广度直接决定了召回率和内存占用之间的平衡。参数设小了索引快但召回率明显下降设大了索引构建慢线上查询也慢。很多团队上线后从来没调过这两个参数用的默认配置召回率莫名低了一大截都不知道为什么。2.4 “相似但不相关”是纯向量的慢性毒药这是最让我头疼的一点语义相似和事实相关是两回事。用户问“保修期多久”知识库里有篇文章讲“延长保修服务的购买方式”里面出现了“保修期”三个字向量相似度不会低但它根本没回答用户的问题。这类“字面相关、语义跑偏”的文档在纯向量检索里会不断混进来污染上下文导致大模型生成看起来合理、实际上答非所问的内容——这是 RAG 最经典的“幻觉”来源之一。进一步拆解embedding 模型擅长“找相关段落”不擅长“判断是否有答案”。大厂的做法通常是再加一道“判断题”用专门的 rerank 模型或者分类器把真正包含答案的段落挑出来。这本质上是在给“纯向量”这个粗糙的筛子再加一道精密的过滤网。3. 大厂 RAG 检索层的真实面目多路召回 精排而不是“向量打天下”我扒过不少公开的技术分享和论文也和一些在头部公司做搜索/推荐的朋友交流过发现他们内部跑得稳的 RAG 架构基本收敛到同一个套路召回阶段多路并行融合阶段做精排。这个思想和传统的搜推广系统一脉相承只不过把“倒排索引”换成了“混合召回”。3.1 多路召回BM25、向量、还有你看不见的规则路大厂的召回层通常是三路起步第一路是稀疏检索也就是我们常说的 BM25 或者它的改良版。它管的事很简单文本命中。你要查“充电没反应”它就老实去匹配“充电”“没反应”这些词命中了就高分不关心语义。这一路对精确匹配、型号、错别字部分场景非常有效尤其适合用户提问里包含明确实体词的时候。第二路是稠密向量检索就是我们一直在说的 embedding 检索。它管的事是“语义相近”适配模糊表达、口语化描述、同义改写。比如用户问“耳机充不进电”它能匹配上“充电无反应”“无法充电”这些表述。第三路是规则/元数据召回很多团队容易忽略。比如通过实体识别抽取出文档中的产品型号、类目、发布时间然后做过滤或者通过用户画像和上下文信息把检索范围限制在特定类目下。这一路不产生新召回但它能限制候选集相当于给前两路“画了个框”。三路召回并行执行之后进入融合模块。3.2 RRF 融合不是随便平均选型有讲究多路召回的结果怎么合并业界最常见的方案是 RRFReciprocal Rank Fusion。它的核心思路很简单每一路都给一个排名然后按倒数排名加权求和。比如某篇文档在向量路排第 3在 BM25 路排第 5那它的融合分就是1/3 1/5 0.533。不用纠结各路打分尺度不同的问题因为它用的不是原始分数而是排名倒数。RRF 的好处是鲁棒、不需要训练、对每一路的分数分布不敏感。但注意它有一个隐含假设每一路的排序质量是接近的。如果某一路召回质量太差它会给很多无关文档很高的 RRF 分反而污染结果。所以生产环境里RRF 通常配合一个“保底过滤”——先把相关性低于阈值的文档直接扔了再进融合。还有一些团队内部用了 LTRLearning to Rank模型来做融合把各路分数、文本命中数、文档长度、点击数据作为特征训练出一个排序模型。这是更高级的做法但需要大量标注数据普通团队没必要一上来就上这套。先 RRF等数据积累够了再考虑升级。3.3 Rerank 是第二道闸门千万别省多路召回之后候选集里通常还有几十篇文档直接塞给大模型既浪费 token又容易干扰生成。所以大厂会再上一道精排模型业界最常用的是 cross-encoder 类型的 rerank 模型。它不像 embedding 模型那样把文本单独编码而是把“用户 query”和“候选文档”拼接在一起让模型直接判断两者之间的“相关程度”。这一脚有多关键看个数据embedding 召回的 top-20 文档经过 rerank 之后前 5 篇的准确率能提升 30% 以上。cross-encoder 因为能看到完整交互信息对事实相关性的判断远好于双塔结构的向量模型。代价是速度慢所以它只对 top-20 或者 top-50 精排不做全库粗排。我在项目里把 rerank 加上之后靠它拦下了一大半“相似但不相关”的文档。原先大模型偶尔会一本正经地用“相似文档”编出一个错误答案现在这种情况少了很多。3.4 面向搜索优化的索引分片和缓存被忽略的工程细节最后说一个纯工程层面的点。大厂的检索层不只是“算法”问题还有“架构”问题。比如数据量大了之后索引不能放在一个节点上要做分片。分片的维度可以是时间、类目、地域选错了分片键你会在某些分片上积压大量查询另外的却空转。还有一个很容易被忽略的点缓存。用户提问有着极强的重复性——售后场景里“充不进电”“连不上蓝牙”这类问题每天被问几千次。对真实生产系统来说没必要每次都用模型重新算一遍 embedding 和 rerank。做一层 query 归一化 结果缓存能省掉至少 30% 的检索计算量。我见过不少团队因为没做缓存线上检索延迟动不动飙到 2 秒以上用户体验很糟糕。4. 从纯向量到混合检索我的实操改造记录理论说完了接下来是我的项目从纯向量检索改造成混合检索的完整过程。这部分偏工程实操每一项我都标了具体参数和当时踩坑的记录方便你直接对号入座。4.1 第一步先给文档打“元数据标签”让过滤条件有机会介入改造之前我做的第一件事不是换检索算法而是给已有的 3 万篇知识库文档补元数据。每篇文档打上产品线、文档类型说明书/FAQ/故障排查/政策、适用版本、更新时间、关键词列表。这个步骤看起来很简单但对后续检索的影响是决定性的。原因在于多路召回的目标是“把真正有答案的文档排在前面”但如果没有过滤条件召回结果会被非目标产品线的文档严重干扰。电子产品用户问的几乎都带产品上下文没有元数据过滤向量检索很容易从别的产品线拉一堆“看起来相关”的资料进来。打元数据的方式我用了混合方案对历史文档使用大模型批量抽取对新增文档走审核流程人工维护。批量抽取那一步我用了一个常规的 few-shot prompt让大模型输出产品的型号、类目、适用人群效果能达到 94% 的准确率剩下的 6% 人工复核一下就行。4.2 第二步接 BM25别用默认的 analyzer选 BM25 实现的时候我先试了 Python 生态里常见的全文检索库发现两个坑。第一默认分词器对中文就是一个字一个字切效果很差必须用中文分词插件把“无线耳机”切成“无线”“耳机”而不是“无”“线”“耳”“机”。第二BM25 的参数k1和b要调。k1控制词频对分数的影响程度默认 1.2 左右没问题b控制文档长度归一化默认 0.75 也差不多但如果你文档长度差异特别大比如既有 200 字的小 FAQ 又有 2 万字的说明书b要适当调低一点避免长文档被过度惩罚。我用了同一个中文分词器和向量检索对比过一次在 top-10 召回里BM25 单独跑的正确率是 61%纯向量是 68%。但如果把两者做 RRF 融合正确率直接跳到 84%。这已经验证了多路召回的价值——无脑把两路结果平均一下都比任何单一手段强。4.3 第三步调 ANN 索引参数召回率还能再捞几个点向量库我用的是支持 HNSW 索引的方案之前一直用默认参数。趁这次改造我把索引重建了一遍参数改成M32、efConstruction200线上查询时ef100。在同样的测试集上召回率从 81% 提到 85%。代价是索引构建时间长了 40%内存占用多了 20%——但换来 4 个点的召回率这对一个线上 RAG 系统来说完全值得。我额外做了一件事对索引做“分段召回”。每次查询不只在一个全库索引上搜索而是先按产品线元数据过滤在对应类目的子索引里搜索。这样等于把 ANN 的搜索范围直接缩小了 70%查询延迟也降下来了。4.4 第四步加 rerank 模型并且只对 top-20 做精排精排这一步我用了一个 small 版本的 cross-encoder 模型参数不到 200M单次推理大概在 30 毫秒到 80 毫秒之间在可以接受的范围。我把多路召回融合后的 top-20 喂给 rerank重新排序后取前 5 作为最终上下文。这个步骤带来的提升是肉眼可见的用户在“充不进电”场景下的回答准确率从混合召回后的 84% 提升到了 92%。我统计了 500 条线上提问发现 rerank 主要拦掉的是“包含关键词但无答案”的文档——这类问题在纯向量阶段占比能达到 20% 上下。4.5 第五步全链路评估指标要看“答案正确率”而不是“向量相似度”改造完之后我搭了一个简单的评估 pipeline500 条带标准答案的真实用户提问逐一跑完整链路人工核对最终回答里是否包含标准答案的关键信息。我强烈建议你也这么做——不看这个指标你根本不知道自己系统真实水平。改造前后的数据大概是这样的方案top-5 检索命中率最终回答正确率单条平均延迟纯向量检索73%61%450ms向量 BM25RRF84%76%480ms混合检索 rerank—92%540ms注意看检索命中率和最终回答正确率之间永远有一段落差。因为就算检索到的文档包含答案大模型也可能没正确引用就算检索到的文档不包含答案大模型也可能编一个。评估的时候不要只看检索指标最终回答的准确率才是用户体感。5. 中小团队落地的务实建议先别急着上多路按这个顺序来很多人看完上面的架构会焦虑大厂那套是不是太复杂了我们团队就三五个人能搞吗我的答案是——能但要分阶段来不要一上来就埋头做多路召回。以下是我推荐的落地顺序每一步都能带来可感知的提升且互相独立。5.1 阶段一先把“文本命中”找回来如果你是纯向量方案第一步不是上 BM25 或者 rerank而是先把你业务里最高频的“精确命中”场景找出来。例如售后场景最常见的提问是“某某型号怎么用”“某某报错码是什么”。这种 query 里含实体词纯向量很容易翻车。最务实的做法在向量检索基础上加一层轻量全文检索只把 BM25 命中的 top-10 和向量召回做交集合并用 RRF 融合。这一步只改 200 行代码不需要额外的模型部署。我实测过单靠这一步就能覆盖七八成的问题。5.2 阶段二把检索结果接入“规则约束”第二步给文档补元数据让检索过程能接受过滤条件。举一个最简单的例子你提前知道当前用户问的产品线那就直接在检索 API 里加一个 filter 参数让检索只在对应产品线内进行。这一步提高的是“候选集质量”效果常常比换 embedding 模型来得更猛。我见过一个团队什么算法都没换只加了产品线过滤回答正确率直接上涨 8 个点。原因是原来 8 个产品线打架现在只在一个产品线里找答案干扰项成倍减少。5.3 阶段三上 re-rank但用最小可用的模型到了这一步你的 RAG 系统大概已经有 85% 左右的原始答案覆盖能力短板在于“检索结果排序质量”塞给大模型的 top-5 里可能有 1-2 篇干扰文档。这时候上一个小的 rerank 模型就够了。选模型有一个小技巧不要一上来就看大模型榜单先看延迟是否在你的 SLA 内。我自己选型时会列出候选模型分别测“top-5 正确率”和“单条推理延迟”挑一个平衡点。规模上和效果上的最优解不一定一致比如有些轻量模型在长文本上表现并不差延迟还更低。5.4 阶段四以上都做完了再考虑卷大参数和复杂融合如果走到这一步你的 RAG 系统已经超过大部分中小团队了。这时候再考虑要不要上 LTR 排序、要不要用更大的 rerank 模型、要不要做多路扩展。但说实话对大部分业务来说前三个阶段已经能解决 90% 的质量问题剩下的提升空间有限投入产出比大幅下降。我的建议是系统上线之后多花时间在数据质量上——把知识库里过时文档删掉把重复内容合并把缺失的答案补上这些对最终效果的提升常常比折腾算法更明显。我自己吃过一次亏重构了检索链路花了三周效果只涨了 3 个点后来花两天清理了一批陈旧文档效果直接涨了 6 个点。数据质量才是 RAG 的天花板。6. 最后再分享一下我在这个项目里最深的几个体会改造完这套系统之后我复盘了整个过程有几个认知层面的变化值得单独拿出来说。第一检索的本质是“召回候选集”不是“给答案”。很多人做 RAG 时把检索想象成“直接找答案”于是追求向量检索的精准度这是方向错了。检索层的作用是“给大模型看到足够多足够相关的候选材料”而判断“用哪篇、不用哪篇”应该交给 rerank 和生成模型。纯向量检索的问题恰恰在于它试图用一个粗糙的语义匹配来完成“精准筛选”这件事天生力不从心。第二embedding 模型和 rerank 模型是不同物种不要混为一谈。embedding 是双塔模型query 和 doc 分别编码看不到彼此rerank 是 cross-encoder直接拼接文本能看见完整交互。向量检索负责“海选”rerank 负责“决赛”这个分工意味着向量检索可以稍微宽松一点保证召回排序交给 rerank保证精准。我之前有一个误区是拼命调 embedding 模型想让它“更精”后来发现这是在用最贵的方案做最简单的事情。第三工程细节比算法选择更能拉开差距。同样的检索方案A 团队和 B 团队跑出来的效果可能差 10 个百分点原因往往不在算法上而在有没有好的元数据、有没有调 ANN 参数、有没有做缓存、有没有用对分词器。算法是骨架工程细节才是血肉。第四评估数据要贴近真实用户。我自己最早的评价集是从标准文档里抽出来的“规范问题”后来换成真实用户提问集才发现系统在真实输入面前那么脆弱。强烈建议从第一天开始就用真实业务日志里的 query 建评估集哪怕只有 200 条也好过 5000 条“自欺欺人”的规范样本。如果你现在正被 RAG 的检索质量问题折磨我最后的建议是先动手加一路 BM25再补元数据然后接一个小的 rerank按这个顺序来。每走一步都做一次带真实 query 的评估看到数据涨了再进行下一步。这条路我走过稳得很。 
长河君 · 2026/10/14 7:49:59 · 阅读 1.2k RAG检索实战：为什么纯向量检索会翻车？混合检索才是答案
1. 先复盘一次线上事故纯向量检索是怎么“翻车”的大概一年前我接手了一个电商售后知识库的 RAG 项目。当时团队里没有专职做 NLP 的人大家一听说“语义检索”第一反应就是把所有文档切成块、做 embedding、塞进向量库然后用户一问就向量相似度 top-k 召回再丢给大模型生成答案。这个方案跑 Demo 的时候效果惊艳老板看了都说好——直到真正上线。第一次被打脸是在一个很普通的用户提问上“耳机充不进电怎么办”。知识库里其实有一篇很详细的文档标题是“蓝牙耳机电池维护与充电异常排查”内容里写了“如果充电无反应请检查充电线和充电口”。但最终线上系统召回的结果里这篇文档压根没出现反而召回了七八篇“耳机怎么连接手机”“耳机怎么配对”之类的文章。用户最后拿到的是一个又长又没用的大模型摘要。当时我第一反应是 embedding 模型的问题换了一个更大的模型重跑效果有改善但不彻底。后来我把这篇文档翻出来发现它内部的表述是“充电无反应”“充不进电”和用户问的“充不进电”在字面上其实就是一回事但向量表达出来之后相似度变成了 0.82低于我们设的 0.85 召回阈值。问题不在模型烂而在我们只依赖向量相似度这一条路。这件事之后我开始系统性地去查业界那些真正把 RAG 跑在大规模生产环境里的团队到底怎么做。结论让我很意外几乎所有跑得稳的系统都不是“纯向量检索”而是混合检索——稀疏检索关键词、稠密向量、甚至还有规则召回多路并行再做重排。我自己的项目也从“全向量”改成了“向量BM25 混合”上线后检索命中率直接从 73% 提高到 91%。所以这篇博文就围绕一个我们绕不开的问题来展开为什么大厂 RAG 从不用纯向量检索。我会把我在项目里踩过的坑、查过的资料、改过的架构以及最终验证有效的混合检索方案完整分享出来。2. 纯向量检索的四个结构性短板不是“调参”能解决的很多从没上过生产环境的人理解不了向量检索不是号称“语义匹配”吗为什么文字一模一样反倒搜不到这就要从向量检索的几个结构性短板说起。这四个问题互相叠加不是换个大模型或者调低阈值能解决的。2.1 处理精确匹配场景时向量会主动“丢信息”embedding 模型在训练时目标是把语义相近的文本映射到相近的空间位置。这带来一个副作用它天然会把“字面上不同但语义相同”的句子拉近但也因此主动丢弃了大量字面信息。比如“iPhone 15 可以防水吗”和“iPhone 15 的防水等级是什么”在向量空间里距离非常近。这是好事。但反过来说如果两个文本只是共享同一批关键词但语义完全不同比如“苹果好吃”和“苹果发布了新品”向量模型会把它们拉得更远——这也没问题。问题出在那些用户体感上是“精确要命”的场景型号、编号、报错码、身份证号、邮箱、价格区间、时间范围。我见过最典型的一个例子用户问“A3000 显卡支持吗”知识库里有一篇明确写“不支持 A3000”的文档结果向量检索因为“A3000 显卡”和“支持的显卡列表”语义相似度高把另一篇“支持的显卡列表”排在前面。字面匹配在这里完全输给了“语义相关”。原因其实很朴素embedding 本质上是对文本做有损压缩。模型要把一整句话塞进一个 1024 或 1536 维的向量里它必然优先保留“大意”牺牲“细节”。而“大意”在大多数 RAG 场景里恰恰不够用——用户问的是细节答案差一个型号就是错。2.2 对用户 query 的理解本身就可能跑偏上面说的是“文档侧”的信息丢失这第二短板出现在“用户提问侧”。用户不会像写文档的人那样用规范术语提问。在售后场景里同一个问题我能收集到十几种说法“充电口坏了”“插上没反应”“开不了机”“砖了”“充电没指示灯”。如果知识库文档写的是规范表述用户 query 用的是大白话两者在语义上能被多数 embedding 模型拉近但如果用户用了缩写、中英混排、错别字效果立刻崩。我做过一次测试同一批 200 条真实用户提问跑纯向量检索其中包含错别字、口语缩写、缺失主语的问题命中率比规范表述的问题低 27%。为什么向量模型训练时“见过”的错别字远少于规范输入它会把“充电没反应”和“冲电没反应”放在不同的语义簇里。用户体感就是同一句话换个说法答案质量天差地别。纯向量检索对 query 的容错能力我们往往会高估。或者说它只对“语义丰富、表述完整”的 query 是友好的对真实世界里又短、又碎、又带错的提问效果打折是常态。2.3 ANN 检索的“近似”属性本身就埋了雷大多数生产环境用的向量库比如各种支持 embedding 搜索的数据库底层都是 ANN近似最近邻索引不是暴力精确计算。ANN 的核心是“用召回率换速度”它通过 HNSW、IVF 这类算法把向量空间分区或者建图搜索的时候只遍历一部分候选节点而不是全部比较。这个“近似”带来两个隐性问题。第一阈值不可信。你以为设的 0.85 相似度很稳但 ANN 搜索出来的 top-k 只是一个近似结果它可能只在某一层子图里找到局部最近的向量真实的全局最近向量可能根本没进候选集。结果就是你调高阈值误杀变多你调低阈值噪声灌进来。第二索引参数极其敏感。HNSW 的M每个节点的最大连接数和efConstruction建图时的搜索广度直接决定了召回率和内存占用之间的平衡。参数设小了索引快但召回率明显下降设大了索引构建慢线上查询也慢。很多团队上线后从来没调过这两个参数用的默认配置召回率莫名低了一大截都不知道为什么。2.4 “相似但不相关”是纯向量的慢性毒药这是最让我头疼的一点语义相似和事实相关是两回事。用户问“保修期多久”知识库里有篇文章讲“延长保修服务的购买方式”里面出现了“保修期”三个字向量相似度不会低但它根本没回答用户的问题。这类“字面相关、语义跑偏”的文档在纯向量检索里会不断混进来污染上下文导致大模型生成看起来合理、实际上答非所问的内容——这是 RAG 最经典的“幻觉”来源之一。进一步拆解embedding 模型擅长“找相关段落”不擅长“判断是否有答案”。大厂的做法通常是再加一道“判断题”用专门的 rerank 模型或者分类器把真正包含答案的段落挑出来。这本质上是在给“纯向量”这个粗糙的筛子再加一道精密的过滤网。3. 大厂 RAG 检索层的真实面目多路召回 精排而不是“向量打天下”我扒过不少公开的技术分享和论文也和一些在头部公司做搜索/推荐的朋友交流过发现他们内部跑得稳的 RAG 架构基本收敛到同一个套路召回阶段多路并行融合阶段做精排。这个思想和传统的搜推广系统一脉相承只不过把“倒排索引”换成了“混合召回”。3.1 多路召回BM25、向量、还有你看不见的规则路大厂的召回层通常是三路起步第一路是稀疏检索也就是我们常说的 BM25 或者它的改良版。它管的事很简单文本命中。你要查“充电没反应”它就老实去匹配“充电”“没反应”这些词命中了就高分不关心语义。这一路对精确匹配、型号、错别字部分场景非常有效尤其适合用户提问里包含明确实体词的时候。第二路是稠密向量检索就是我们一直在说的 embedding 检索。它管的事是“语义相近”适配模糊表达、口语化描述、同义改写。比如用户问“耳机充不进电”它能匹配上“充电无反应”“无法充电”这些表述。第三路是规则/元数据召回很多团队容易忽略。比如通过实体识别抽取出文档中的产品型号、类目、发布时间然后做过滤或者通过用户画像和上下文信息把检索范围限制在特定类目下。这一路不产生新召回但它能限制候选集相当于给前两路“画了个框”。三路召回并行执行之后进入融合模块。3.2 RRF 融合不是随便平均选型有讲究多路召回的结果怎么合并业界最常见的方案是 RRFReciprocal Rank Fusion。它的核心思路很简单每一路都给一个排名然后按倒数排名加权求和。比如某篇文档在向量路排第 3在 BM25 路排第 5那它的融合分就是1/3 1/5 0.533。不用纠结各路打分尺度不同的问题因为它用的不是原始分数而是排名倒数。RRF 的好处是鲁棒、不需要训练、对每一路的分数分布不敏感。但注意它有一个隐含假设每一路的排序质量是接近的。如果某一路召回质量太差它会给很多无关文档很高的 RRF 分反而污染结果。所以生产环境里RRF 通常配合一个“保底过滤”——先把相关性低于阈值的文档直接扔了再进融合。还有一些团队内部用了 LTRLearning to Rank模型来做融合把各路分数、文本命中数、文档长度、点击数据作为特征训练出一个排序模型。这是更高级的做法但需要大量标注数据普通团队没必要一上来就上这套。先 RRF等数据积累够了再考虑升级。3.3 Rerank 是第二道闸门千万别省多路召回之后候选集里通常还有几十篇文档直接塞给大模型既浪费 token又容易干扰生成。所以大厂会再上一道精排模型业界最常用的是 cross-encoder 类型的 rerank 模型。它不像 embedding 模型那样把文本单独编码而是把“用户 query”和“候选文档”拼接在一起让模型直接判断两者之间的“相关程度”。这一脚有多关键看个数据embedding 召回的 top-20 文档经过 rerank 之后前 5 篇的准确率能提升 30% 以上。cross-encoder 因为能看到完整交互信息对事实相关性的判断远好于双塔结构的向量模型。代价是速度慢所以它只对 top-20 或者 top-50 精排不做全库粗排。我在项目里把 rerank 加上之后靠它拦下了一大半“相似但不相关”的文档。原先大模型偶尔会一本正经地用“相似文档”编出一个错误答案现在这种情况少了很多。3.4 面向搜索优化的索引分片和缓存被忽略的工程细节最后说一个纯工程层面的点。大厂的检索层不只是“算法”问题还有“架构”问题。比如数据量大了之后索引不能放在一个节点上要做分片。分片的维度可以是时间、类目、地域选错了分片键你会在某些分片上积压大量查询另外的却空转。还有一个很容易被忽略的点缓存。用户提问有着极强的重复性——售后场景里“充不进电”“连不上蓝牙”这类问题每天被问几千次。对真实生产系统来说没必要每次都用模型重新算一遍 embedding 和 rerank。做一层 query 归一化 结果缓存能省掉至少 30% 的检索计算量。我见过不少团队因为没做缓存线上检索延迟动不动飙到 2 秒以上用户体验很糟糕。4. 从纯向量到混合检索我的实操改造记录理论说完了接下来是我的项目从纯向量检索改造成混合检索的完整过程。这部分偏工程实操每一项我都标了具体参数和当时踩坑的记录方便你直接对号入座。4.1 第一步先给文档打“元数据标签”让过滤条件有机会介入改造之前我做的第一件事不是换检索算法而是给已有的 3 万篇知识库文档补元数据。每篇文档打上产品线、文档类型说明书/FAQ/故障排查/政策、适用版本、更新时间、关键词列表。这个步骤看起来很简单但对后续检索的影响是决定性的。原因在于多路召回的目标是“把真正有答案的文档排在前面”但如果没有过滤条件召回结果会被非目标产品线的文档严重干扰。电子产品用户问的几乎都带产品上下文没有元数据过滤向量检索很容易从别的产品线拉一堆“看起来相关”的资料进来。打元数据的方式我用了混合方案对历史文档使用大模型批量抽取对新增文档走审核流程人工维护。批量抽取那一步我用了一个常规的 few-shot prompt让大模型输出产品的型号、类目、适用人群效果能达到 94% 的准确率剩下的 6% 人工复核一下就行。4.2 第二步接 BM25别用默认的 analyzer选 BM25 实现的时候我先试了 Python 生态里常见的全文检索库发现两个坑。第一默认分词器对中文就是一个字一个字切效果很差必须用中文分词插件把“无线耳机”切成“无线”“耳机”而不是“无”“线”“耳”“机”。第二BM25 的参数k1和b要调。k1控制词频对分数的影响程度默认 1.2 左右没问题b控制文档长度归一化默认 0.75 也差不多但如果你文档长度差异特别大比如既有 200 字的小 FAQ 又有 2 万字的说明书b要适当调低一点避免长文档被过度惩罚。我用了同一个中文分词器和向量检索对比过一次在 top-10 召回里BM25 单独跑的正确率是 61%纯向量是 68%。但如果把两者做 RRF 融合正确率直接跳到 84%。这已经验证了多路召回的价值——无脑把两路结果平均一下都比任何单一手段强。4.3 第三步调 ANN 索引参数召回率还能再捞几个点向量库我用的是支持 HNSW 索引的方案之前一直用默认参数。趁这次改造我把索引重建了一遍参数改成M32、efConstruction200线上查询时ef100。在同样的测试集上召回率从 81% 提到 85%。代价是索引构建时间长了 40%内存占用多了 20%——但换来 4 个点的召回率这对一个线上 RAG 系统来说完全值得。我额外做了一件事对索引做“分段召回”。每次查询不只在一个全库索引上搜索而是先按产品线元数据过滤在对应类目的子索引里搜索。这样等于把 ANN 的搜索范围直接缩小了 70%查询延迟也降下来了。4.4 第四步加 rerank 模型并且只对 top-20 做精排精排这一步我用了一个 small 版本的 cross-encoder 模型参数不到 200M单次推理大概在 30 毫秒到 80 毫秒之间在可以接受的范围。我把多路召回融合后的 top-20 喂给 rerank重新排序后取前 5 作为最终上下文。这个步骤带来的提升是肉眼可见的用户在“充不进电”场景下的回答准确率从混合召回后的 84% 提升到了 92%。我统计了 500 条线上提问发现 rerank 主要拦掉的是“包含关键词但无答案”的文档——这类问题在纯向量阶段占比能达到 20% 上下。4.5 第五步全链路评估指标要看“答案正确率”而不是“向量相似度”改造完之后我搭了一个简单的评估 pipeline500 条带标准答案的真实用户提问逐一跑完整链路人工核对最终回答里是否包含标准答案的关键信息。我强烈建议你也这么做——不看这个指标你根本不知道自己系统真实水平。改造前后的数据大概是这样的方案top-5 检索命中率最终回答正确率单条平均延迟纯向量检索73%61%450ms向量 BM25RRF84%76%480ms混合检索 rerank—92%540ms注意看检索命中率和最终回答正确率之间永远有一段落差。因为就算检索到的文档包含答案大模型也可能没正确引用就算检索到的文档不包含答案大模型也可能编一个。评估的时候不要只看检索指标最终回答的准确率才是用户体感。5. 中小团队落地的务实建议先别急着上多路按这个顺序来很多人看完上面的架构会焦虑大厂那套是不是太复杂了我们团队就三五个人能搞吗我的答案是——能但要分阶段来不要一上来就埋头做多路召回。以下是我推荐的落地顺序每一步都能带来可感知的提升且互相独立。5.1 阶段一先把“文本命中”找回来如果你是纯向量方案第一步不是上 BM25 或者 rerank而是先把你业务里最高频的“精确命中”场景找出来。例如售后场景最常见的提问是“某某型号怎么用”“某某报错码是什么”。这种 query 里含实体词纯向量很容易翻车。最务实的做法在向量检索基础上加一层轻量全文检索只把 BM25 命中的 top-10 和向量召回做交集合并用 RRF 融合。这一步只改 200 行代码不需要额外的模型部署。我实测过单靠这一步就能覆盖七八成的问题。5.2 阶段二把检索结果接入“规则约束”第二步给文档补元数据让检索过程能接受过滤条件。举一个最简单的例子你提前知道当前用户问的产品线那就直接在检索 API 里加一个 filter 参数让检索只在对应产品线内进行。这一步提高的是“候选集质量”效果常常比换 embedding 模型来得更猛。我见过一个团队什么算法都没换只加了产品线过滤回答正确率直接上涨 8 个点。原因是原来 8 个产品线打架现在只在一个产品线里找答案干扰项成倍减少。5.3 阶段三上 re-rank但用最小可用的模型到了这一步你的 RAG 系统大概已经有 85% 左右的原始答案覆盖能力短板在于“检索结果排序质量”塞给大模型的 top-5 里可能有 1-2 篇干扰文档。这时候上一个小的 rerank 模型就够了。选模型有一个小技巧不要一上来就看大模型榜单先看延迟是否在你的 SLA 内。我自己选型时会列出候选模型分别测“top-5 正确率”和“单条推理延迟”挑一个平衡点。规模上和效果上的最优解不一定一致比如有些轻量模型在长文本上表现并不差延迟还更低。5.4 阶段四以上都做完了再考虑卷大参数和复杂融合如果走到这一步你的 RAG 系统已经超过大部分中小团队了。这时候再考虑要不要上 LTR 排序、要不要用更大的 rerank 模型、要不要做多路扩展。但说实话对大部分业务来说前三个阶段已经能解决 90% 的质量问题剩下的提升空间有限投入产出比大幅下降。我的建议是系统上线之后多花时间在数据质量上——把知识库里过时文档删掉把重复内容合并把缺失的答案补上这些对最终效果的提升常常比折腾算法更明显。我自己吃过一次亏重构了检索链路花了三周效果只涨了 3 个点后来花两天清理了一批陈旧文档效果直接涨了 6 个点。数据质量才是 RAG 的天花板。6. 最后再分享一下我在这个项目里最深的几个体会改造完这套系统之后我复盘了整个过程有几个认知层面的变化值得单独拿出来说。第一检索的本质是“召回候选集”不是“给答案”。很多人做 RAG 时把检索想象成“直接找答案”于是追求向量检索的精准度这是方向错了。检索层的作用是“给大模型看到足够多足够相关的候选材料”而判断“用哪篇、不用哪篇”应该交给 rerank 和生成模型。纯向量检索的问题恰恰在于它试图用一个粗糙的语义匹配来完成“精准筛选”这件事天生力不从心。第二embedding 模型和 rerank 模型是不同物种不要混为一谈。embedding 是双塔模型query 和 doc 分别编码看不到彼此rerank 是 cross-encoder直接拼接文本能看见完整交互。向量检索负责“海选”rerank 负责“决赛”这个分工意味着向量检索可以稍微宽松一点保证召回排序交给 rerank保证精准。我之前有一个误区是拼命调 embedding 模型想让它“更精”后来发现这是在用最贵的方案做最简单的事情。第三工程细节比算法选择更能拉开差距。同样的检索方案A 团队和 B 团队跑出来的效果可能差 10 个百分点原因往往不在算法上而在有没有好的元数据、有没有调 ANN 参数、有没有做缓存、有没有用对分词器。算法是骨架工程细节才是血肉。第四评估数据要贴近真实用户。我自己最早的评价集是从标准文档里抽出来的“规范问题”后来换成真实用户提问集才发现系统在真实输入面前那么脆弱。强烈建议从第一天开始就用真实业务日志里的 query 建评估集哪怕只有 200 条也好过 5000 条“自欺欺人”的规范样本。如果你现在正被 RAG 的检索质量问题折磨我最后的建议是先动手加一路 BM25再补元数据然后接一个小的 rerank按这个顺序来。每走一步都做一次带真实 query 的评估看到数据涨了再进行下一步。这条路我走过稳得很。