前阵子跟一个朋友聊天他说自己团队兴致勃勃上了纯向量检索的 RAG结果一到生产环境召回效果就翻车了——用户问“客服电话是多少”系统检索出来的全是“客服工作时间安排”之类的段落真正写着电话号码的 FAQ 反而没进上下文。最后没辙默默把 BM25 加回来了。这个现象我在不少团队里都见过而且不是个例。今天想认真聊聊为什么大型业务系统里的 RAG检索层几乎从不“只上向量”纯向量检索到底输在哪混合检索又是怎么补救的以及在什么场景下你可以放心继续只用向量检索。1. 先搞清楚本质RAG 检索的目标从来不是“找相似”很多人对 RAG 的理解是从“语义搜索”入门的把文档切块、做 embedding用户问一句话拿这句话的向量去库里找最相近的段落然后塞给大模型。这个流程听起来顺理成章但它其实隐含了一个关键误区——把“语义相似”当成了“信息正确”。RAG 检索的真正目标不是“找到和用户问题长得像的文本”而是“找到生成回答所必需的、正确且完整的事实片段”。这中间的差别非常大。我举个例子用户问“这款手机支持 7 天无理由退货吗”假如知识库里有一条 FAQ 标题叫“退换货政策”正文写着“支持 7 天无理由退货但拆封后除外”。另一条文档叫“退货流程介绍”里面详细描述了“登录账号—选择订单—填写原因—提交申请”的步骤。从向量相似度来看“退货流程介绍”和用户问题的语义重合度非常高因为“退货”这个词、操作流程的语境都会被编码进向量里。而“退换货政策”这条 FAQ 因为标题和正文措辞相对正式向量距离反而更远。纯向量检索很容易把“退货流程介绍”排到前面而“退换货政策”掉出 Top N。结果大模型读了一堆“怎么操作”的步骤却不知道到底能不能退最后只能基于流程描述去推测产出一个含糊其辞甚至带幻觉的回答。RAG 的检索质量最终体现在三个指标上召回率、精确率、上下文利用率。召回率真正包含答案的段落有没有被检索出来。精确率检索出来的段落里有多少是真正有用的。上下文利用率大模型窗口有限塞进去的段落有多少被实际用于生成而不是占着位置当噪音。纯向量检索在“召回率”和“精确率”上都有结构性短板这是它的编码方式决定的不是调参能解决的。2. 纯向量检索的四个隐藏盲区每一个都能毁掉生成质量2.1 向量是“平均语义”精确信息被稀释Embedding 模型做的事情是把一段文本映射到一个稠密向量。问题是这个映射过程会把词与词的信息“平均化”和“融合化”。对语义理解来说这是优点但对精确信息来说这就是灾难。典型例子就是型号和数值。比如“iPhone 15 Pro Max 256GB 原色钛金属”和“iPhone 15 Pro 128GB 蓝色”这两段文本的向量距离非常近——它们在语义上确实高度相关都是某一代 iPhone 的型号描述。但如果用户问的是“256GB 原色钛金属多少钱”把蓝色 128GB 的段落召回进来就是纯粹的噪音甚至可能给出错误报价。数值型信息更麻烦。向量无法保证等式关系“退款金额为 199 元”和“退款金额为 299 元”这两句话向量距离可能非常近但答案完全不同。任何依赖精确数值、精确型号、精确规则的业务纯向量检索都天然吃亏。2.2 词项命中的价值被严重低估很多真实用户查询本质上就是精确词匹配。比如“Windows 11 更新失败错误码 0x800f0831”“对公账户开户需要什么材料”“发票抬头写错了怎么办”。这类查询里关键信息是具体的词项和短语而不是抽象语义。BM25 这类稀疏检索方法天然会对词项做加权——查询里出现了“开户”“材料”文档里“开户”这个词在标题位置出现得分就高。这是把“查字典”的优势发挥到极致。而向量检索呢它会把整个查询编码成一个整体语义然后去找语义相近的段落。词项级别的严谨匹配反而不擅长。这不是说向量模型做不到而是它建模的粒度是“整体语义”而不是“词项贡献”。2.3 垂直领域的语义错位大部分开源 embedding 模型是在通用语料上训练的其中英文语料占比还很高。到了垂直领域——比如医疗、法律、金融、工业文档——专业术语的语义分布跟通用语义差异巨大。举个例子法律文档里的“不可抗力”金融领域的“对敲”医疗文档里的“适应症”“禁忌症”。一个通用模型给出的向量可能把“不可抗力”和“自然灾害”拉得很近但在法律语境里“不可抗力”是一个有严格构成要件、需要看合同约定条款的概念它跟“自然灾害”的语义关系远不如跟“免责条款”“合同解除权”的关系重要。后果就是纯向量检索在垂直领域语料上的 top 召回里总是混入大量“表面相似但专业上不相关”的段落而真正专业的、低频的术语文档反而排在后面。2.4 上下文稀释导致幻觉加剧这一点是大厂业务系统里最致命的。大模型的上下文窗口虽然越做越大但上下文的有效利用率是有限的。你把 10 个检索段落塞进去里面只有 3 个有用、7 个是“看起来相关但其实没用”的段落那 7 个段落就会变成干扰信息。生成器在输出时会尽最大努力去“利用”上下文里的信息。当上下文里存在大量相似但不完全准确的表述时模型就可能从这些错误信息里提取要素合并出一段幻觉内容。纯向量检索由于上述几个盲区特别容易制造这种“高相似度噪音”。检索结果看着相关实则经不起推敲。3. 大厂检索链路的标准解法混合召回、融合、精排三段式既然纯向量有这么多坑那大厂是怎么做的其实很简单用混合检索兜底用重排模型纠偏。3.1 混合检索一个跑向量一个跑词项混合检索Hybrid Search就是同时跑两路召回稀疏检索路基于倒排索引的经典检索最典型的就是 BM25。它擅长精确词项匹配对专业术语、型号、代码、人名地名特别友好同时天然支持词项加权和布尔过滤。稠密检索路向量 ANN 检索刚才聊过了负责语义扩展能找回那些“说法不一样但意思一样”的段落。两路各召回 Top N然后做融合。这样做的核心收益是语义相似的段落不会被漏掉精确匹配的段落也不会因为向量距离不够近而掉出召回池两路召回的结果重叠度低互补性强整体召回率会显著攀升。3.2 融合策略RRF 才是无脑好用的方案两路检索结果拿回来以后怎么合并这里有个最常见的坑BM25 的分数和向量相似度分数完全不可比。BM25 得分受文档长度、词频影响数值上没有什么上界向量余弦相似度基本落在 -1 到 1 之间。直接把这两个分数相加等于让 BM25 主导结果向量那路形同虚设。业界最常用的融合方案是 RRFReciprocal Rank Fusion。它的思路非常简单粗暴不看分数看排名。公式是score(d) Σ 1 / (k rank(d))其中 k 一般取 60rank(d) 是文档在当前检索结果里的排名。每路检索给文档一个基于排名的得分最后累加排序。这个方案的好处是完全无视两路检索的分数尺度差异对异常分数不敏感实现起来只要几十行代码。另一种方案是加权分数融合即对 BM25 分数做归一化比如 min-max 或 z-score然后跟归一化后的向量分数加权重合并。这需要调权重而且每路检索的分数分布会随数据变化维护成本高一些。我的经验是项目早期直接上 RRF稳定靠谱留出精力去搞重排。3.3 重排把精度交给 Cross-Encoder混合召回解决了“召回率”问题但融合后的 Top 20 仍然混杂了不少噪音。这时候需要一个精排模型把真正有用的段落提到最前面。常用的做法是在召回的基础上跑一个 Cross-Encoder 重排模型。它和 Embedding 模型的区别在于Embedding 是先把查询和文档分别编码成向量再做相似度计算查询和文档没有交互Cross-Encoder 是把查询和文档拼接在一起过一个完整的 Transformer让 token 之间充分做注意力交互最后输出一个相关性分数。这种“深度交互”带来的精度提升非常可观但代价是慢。所以全量重排不现实标准做法是混合召回 Top 50 → Cross-Encoder 精排 → 取 Top 5 给大模型。这里有个大厂内部常用的取舍重排模型没必要用超大参数版本。蒸馏过的中小型模型在垂直领域微调后效果足够碾压通用大模型的排序结果而且延迟能压到几十毫秒以内。毕竟重排只需要处理 50 条左右的候选压力不大。3.4 保险丝一定要有兜底规则三段式之后还有一层兜底。比如用户查询里出现了精确的 SKU、订单号、手机号系统应该先走一次绝对匹配Term Query命中就直接置顶。这类高频强规则不依赖模型判断逻辑简单稳定性极高。大厂业务复杂宁可多一层规则也不愿意让模型在关键信息上打折扣。4. 一次真实事故复盘纯向量检索是怎么把客服系统带沟里的讲一个我接触过的案例背景是某公司的客服知识库 RAG 项目。知识库有几十万条 FAQ 和操作手册刚上线时用的是纯向量检索。内测阶段评估团队给了一个相当难看的数字首答准确率只有 61%。去翻 bad case最典型的一类是用户提问“人工客服电话是多少”知识库里有一条 FAQ“人工客服热线400-800-1234服务时间 9:00-21:00。”还有一条操作手册“如何联系人工客服——打开 App点击我的—在线客服—转人工。”纯向量检索召回了“如何联系人工客服”这篇操作手册因为“联系”“人工客服”这些词的语义编码更贴近而真正写着电话号码的 FAQ因为还有“热线”“服务时间”这些附加信息向量距离反而远了点。结果大模型没看到电话号码就开始脑补回答“您可以通过 App 内在线客服联系人工工作时间……”——愣是没给出用户真正要的那串数字。这个案例特别典型因为它清楚展示了纯向量检索的缺陷链语义相关 ≠ 信息完整信息完整 ≠ 精确命中精确命中缺失 → 生成幻觉。上线混合检索之后同样的查询BM25 路把“人工客服热线400-800-1234”这句话的原文档直接命中RRF 融合后排在第一位重排模型进一步确认最终准确率提到了 87%。所以我一直觉得在业务系统里谈 RAG 效果从来不只是“模型选得好不好”而是检索层立不立得住。5. 工程层面为什么“纯向量”在规模下更难用除了算法层面的盲区工程实现上纯向量检索也有不少硬约束。这些约束在大规模业务场景里会被不断放大。5.1 元数据过滤能力太弱业务数据几乎都需要按照权限、部门、时间、类型、状态做过滤。比如“只检索当前用户所属部门的文档”“只检索本周上架的新政策”这些过滤条件BM25 那套倒排索引配合 bitmap 过滤器处理得又快又自然。向量检索要支持过滤就得在 ANN 算法上做文章——比如 HNSW 里做过滤要么放宽搜索范围再过滤要么引入 Filtered HNSW 之类的变体性能都会有折损。很多团队最后发现向量检索的过滤时延比纯搜索还高完全背离了初衷。5.2 增量更新和删除的麻烦业务知识库每天都会有新增、修订、下架。向量索引的增量更新是个老大难HNSW 图结构在插入新点时需要维护图的连通性删除更是要打 tombstone 标记效率远不如倒排索引“删了重建某一段”来得干净。这就导致很多团队在做知识库 RAG 时发现「数据更新频率越高纯向量索引越拖后腿」。5.3 算力和内存开销向量检索的存储成本比倒排索引高一个数量级每条文本都要存一个高维向量常见 768 维到 1536 维内存里至少要保留原始向量参与距离计算。HNSW 还额外需要维护多层图结构内存开销再翻几倍。大厂的数据量动辄千万级文档切块后向量数量可能上亿。就算用量化压缩内存成本依旧可观。相比之下BM25 倒排索引用内存映射就能跑成本低得多。5.4 可解释性和调试困难召回错了纯向量检索时你很难回答“它为什么召回这个”。向量空间里两个点的距离没有直观可解释性。而 BM25 可以明确告诉你因为这三句话都出现了“退货”这个词且标题权重高。对需要持续迭代优化的生产系统来说可解释性就是调试效率。调查 bad case 时稀疏检索的错误一眼能看穿向量检索的错误则要退回去看 embedding 模型是否训练到位排查链路长得多。6. 那完蛋了纯向量检索一无是处吗——也不是写到这里如果只讲“大厂为什么不用”容易让读者误入另一个误区觉得纯向量检索是错的。其实不是。纯向量检索有它合适的应用范围。在我看来至少这几类场景可以放心用知识库体量小几百到几千条文档。检索压力不大一条条遍历向量距离都能接受。此时混合检索带来的复杂度反而划不来。查询以语义匹配为主比如头脑风暴、论文检索、相似文档推荐。用户想找的是“尽量相近的内容”而不是“精确的某一条记录”。对精确词项需求低用户问题里几乎没有型号、代码、人名、金额这类必须精确命中的信息。快速 PoC 阶段先跑一个纯向量版本验证端到端链路等数据量上来、bad case 变多再逐步加入 BM25 和重排。我个人的经验是除非你的 RAG 只是拿来自娱自乐否则一开始就把混合检索做进去后面省掉大量返工。哪怕数据量少BM25 倒排索引的成本也低得可以忽略。判断自己是否需要升级检索方案可以看两个信号检索结果里反复出现“看着相关、实际上答非所问”的段落用户开始提交精确查询订单号、型号、政策条款时正确率明显下降。出现这两个信号就该动手加一路稀疏检索了。7. 给坚持用纯向量检索的团队一句实在话这篇文章写到最后我想分享一个经验检索方案的选型不要靠信仰靠评测集说话。我每次做 RAG 项目都会先建一个小型评测集——就是人工标注三五十条“问题—正确答案所在段落”的对。先跑纯向量拿 baseline再上混合检索对比 top-5 召回率。实测下来混合检索的召回率通常能提升 10 到 20 个百分点纯向量 baseline 越高说明你的数据和查询对语义越友好baseline 惨淡就老老实实上混合。大厂不用纯向量检索不是因为向量技术不行而是因为业务系统要的不是“看起来聪明”而是“每一次都查得准”。从语义召回出发用精确匹配兜底让重排模型把握精度再辅以规则处理极端情况——这套组合拳才是能扛住生产环境复杂查询的正路。 
长河君 · 2026/10/18 22:59:54 · 阅读 1.2k 为什么大厂RAG检索不用纯向量？混合检索+BM25才是正解
前阵子跟一个朋友聊天他说自己团队兴致勃勃上了纯向量检索的 RAG结果一到生产环境召回效果就翻车了——用户问“客服电话是多少”系统检索出来的全是“客服工作时间安排”之类的段落真正写着电话号码的 FAQ 反而没进上下文。最后没辙默默把 BM25 加回来了。这个现象我在不少团队里都见过而且不是个例。今天想认真聊聊为什么大型业务系统里的 RAG检索层几乎从不“只上向量”纯向量检索到底输在哪混合检索又是怎么补救的以及在什么场景下你可以放心继续只用向量检索。1. 先搞清楚本质RAG 检索的目标从来不是“找相似”很多人对 RAG 的理解是从“语义搜索”入门的把文档切块、做 embedding用户问一句话拿这句话的向量去库里找最相近的段落然后塞给大模型。这个流程听起来顺理成章但它其实隐含了一个关键误区——把“语义相似”当成了“信息正确”。RAG 检索的真正目标不是“找到和用户问题长得像的文本”而是“找到生成回答所必需的、正确且完整的事实片段”。这中间的差别非常大。我举个例子用户问“这款手机支持 7 天无理由退货吗”假如知识库里有一条 FAQ 标题叫“退换货政策”正文写着“支持 7 天无理由退货但拆封后除外”。另一条文档叫“退货流程介绍”里面详细描述了“登录账号—选择订单—填写原因—提交申请”的步骤。从向量相似度来看“退货流程介绍”和用户问题的语义重合度非常高因为“退货”这个词、操作流程的语境都会被编码进向量里。而“退换货政策”这条 FAQ 因为标题和正文措辞相对正式向量距离反而更远。纯向量检索很容易把“退货流程介绍”排到前面而“退换货政策”掉出 Top N。结果大模型读了一堆“怎么操作”的步骤却不知道到底能不能退最后只能基于流程描述去推测产出一个含糊其辞甚至带幻觉的回答。RAG 的检索质量最终体现在三个指标上召回率、精确率、上下文利用率。召回率真正包含答案的段落有没有被检索出来。精确率检索出来的段落里有多少是真正有用的。上下文利用率大模型窗口有限塞进去的段落有多少被实际用于生成而不是占着位置当噪音。纯向量检索在“召回率”和“精确率”上都有结构性短板这是它的编码方式决定的不是调参能解决的。2. 纯向量检索的四个隐藏盲区每一个都能毁掉生成质量2.1 向量是“平均语义”精确信息被稀释Embedding 模型做的事情是把一段文本映射到一个稠密向量。问题是这个映射过程会把词与词的信息“平均化”和“融合化”。对语义理解来说这是优点但对精确信息来说这就是灾难。典型例子就是型号和数值。比如“iPhone 15 Pro Max 256GB 原色钛金属”和“iPhone 15 Pro 128GB 蓝色”这两段文本的向量距离非常近——它们在语义上确实高度相关都是某一代 iPhone 的型号描述。但如果用户问的是“256GB 原色钛金属多少钱”把蓝色 128GB 的段落召回进来就是纯粹的噪音甚至可能给出错误报价。数值型信息更麻烦。向量无法保证等式关系“退款金额为 199 元”和“退款金额为 299 元”这两句话向量距离可能非常近但答案完全不同。任何依赖精确数值、精确型号、精确规则的业务纯向量检索都天然吃亏。2.2 词项命中的价值被严重低估很多真实用户查询本质上就是精确词匹配。比如“Windows 11 更新失败错误码 0x800f0831”“对公账户开户需要什么材料”“发票抬头写错了怎么办”。这类查询里关键信息是具体的词项和短语而不是抽象语义。BM25 这类稀疏检索方法天然会对词项做加权——查询里出现了“开户”“材料”文档里“开户”这个词在标题位置出现得分就高。这是把“查字典”的优势发挥到极致。而向量检索呢它会把整个查询编码成一个整体语义然后去找语义相近的段落。词项级别的严谨匹配反而不擅长。这不是说向量模型做不到而是它建模的粒度是“整体语义”而不是“词项贡献”。2.3 垂直领域的语义错位大部分开源 embedding 模型是在通用语料上训练的其中英文语料占比还很高。到了垂直领域——比如医疗、法律、金融、工业文档——专业术语的语义分布跟通用语义差异巨大。举个例子法律文档里的“不可抗力”金融领域的“对敲”医疗文档里的“适应症”“禁忌症”。一个通用模型给出的向量可能把“不可抗力”和“自然灾害”拉得很近但在法律语境里“不可抗力”是一个有严格构成要件、需要看合同约定条款的概念它跟“自然灾害”的语义关系远不如跟“免责条款”“合同解除权”的关系重要。后果就是纯向量检索在垂直领域语料上的 top 召回里总是混入大量“表面相似但专业上不相关”的段落而真正专业的、低频的术语文档反而排在后面。2.4 上下文稀释导致幻觉加剧这一点是大厂业务系统里最致命的。大模型的上下文窗口虽然越做越大但上下文的有效利用率是有限的。你把 10 个检索段落塞进去里面只有 3 个有用、7 个是“看起来相关但其实没用”的段落那 7 个段落就会变成干扰信息。生成器在输出时会尽最大努力去“利用”上下文里的信息。当上下文里存在大量相似但不完全准确的表述时模型就可能从这些错误信息里提取要素合并出一段幻觉内容。纯向量检索由于上述几个盲区特别容易制造这种“高相似度噪音”。检索结果看着相关实则经不起推敲。3. 大厂检索链路的标准解法混合召回、融合、精排三段式既然纯向量有这么多坑那大厂是怎么做的其实很简单用混合检索兜底用重排模型纠偏。3.1 混合检索一个跑向量一个跑词项混合检索Hybrid Search就是同时跑两路召回稀疏检索路基于倒排索引的经典检索最典型的就是 BM25。它擅长精确词项匹配对专业术语、型号、代码、人名地名特别友好同时天然支持词项加权和布尔过滤。稠密检索路向量 ANN 检索刚才聊过了负责语义扩展能找回那些“说法不一样但意思一样”的段落。两路各召回 Top N然后做融合。这样做的核心收益是语义相似的段落不会被漏掉精确匹配的段落也不会因为向量距离不够近而掉出召回池两路召回的结果重叠度低互补性强整体召回率会显著攀升。3.2 融合策略RRF 才是无脑好用的方案两路检索结果拿回来以后怎么合并这里有个最常见的坑BM25 的分数和向量相似度分数完全不可比。BM25 得分受文档长度、词频影响数值上没有什么上界向量余弦相似度基本落在 -1 到 1 之间。直接把这两个分数相加等于让 BM25 主导结果向量那路形同虚设。业界最常用的融合方案是 RRFReciprocal Rank Fusion。它的思路非常简单粗暴不看分数看排名。公式是score(d) Σ 1 / (k rank(d))其中 k 一般取 60rank(d) 是文档在当前检索结果里的排名。每路检索给文档一个基于排名的得分最后累加排序。这个方案的好处是完全无视两路检索的分数尺度差异对异常分数不敏感实现起来只要几十行代码。另一种方案是加权分数融合即对 BM25 分数做归一化比如 min-max 或 z-score然后跟归一化后的向量分数加权重合并。这需要调权重而且每路检索的分数分布会随数据变化维护成本高一些。我的经验是项目早期直接上 RRF稳定靠谱留出精力去搞重排。3.3 重排把精度交给 Cross-Encoder混合召回解决了“召回率”问题但融合后的 Top 20 仍然混杂了不少噪音。这时候需要一个精排模型把真正有用的段落提到最前面。常用的做法是在召回的基础上跑一个 Cross-Encoder 重排模型。它和 Embedding 模型的区别在于Embedding 是先把查询和文档分别编码成向量再做相似度计算查询和文档没有交互Cross-Encoder 是把查询和文档拼接在一起过一个完整的 Transformer让 token 之间充分做注意力交互最后输出一个相关性分数。这种“深度交互”带来的精度提升非常可观但代价是慢。所以全量重排不现实标准做法是混合召回 Top 50 → Cross-Encoder 精排 → 取 Top 5 给大模型。这里有个大厂内部常用的取舍重排模型没必要用超大参数版本。蒸馏过的中小型模型在垂直领域微调后效果足够碾压通用大模型的排序结果而且延迟能压到几十毫秒以内。毕竟重排只需要处理 50 条左右的候选压力不大。3.4 保险丝一定要有兜底规则三段式之后还有一层兜底。比如用户查询里出现了精确的 SKU、订单号、手机号系统应该先走一次绝对匹配Term Query命中就直接置顶。这类高频强规则不依赖模型判断逻辑简单稳定性极高。大厂业务复杂宁可多一层规则也不愿意让模型在关键信息上打折扣。4. 一次真实事故复盘纯向量检索是怎么把客服系统带沟里的讲一个我接触过的案例背景是某公司的客服知识库 RAG 项目。知识库有几十万条 FAQ 和操作手册刚上线时用的是纯向量检索。内测阶段评估团队给了一个相当难看的数字首答准确率只有 61%。去翻 bad case最典型的一类是用户提问“人工客服电话是多少”知识库里有一条 FAQ“人工客服热线400-800-1234服务时间 9:00-21:00。”还有一条操作手册“如何联系人工客服——打开 App点击我的—在线客服—转人工。”纯向量检索召回了“如何联系人工客服”这篇操作手册因为“联系”“人工客服”这些词的语义编码更贴近而真正写着电话号码的 FAQ因为还有“热线”“服务时间”这些附加信息向量距离反而远了点。结果大模型没看到电话号码就开始脑补回答“您可以通过 App 内在线客服联系人工工作时间……”——愣是没给出用户真正要的那串数字。这个案例特别典型因为它清楚展示了纯向量检索的缺陷链语义相关 ≠ 信息完整信息完整 ≠ 精确命中精确命中缺失 → 生成幻觉。上线混合检索之后同样的查询BM25 路把“人工客服热线400-800-1234”这句话的原文档直接命中RRF 融合后排在第一位重排模型进一步确认最终准确率提到了 87%。所以我一直觉得在业务系统里谈 RAG 效果从来不只是“模型选得好不好”而是检索层立不立得住。5. 工程层面为什么“纯向量”在规模下更难用除了算法层面的盲区工程实现上纯向量检索也有不少硬约束。这些约束在大规模业务场景里会被不断放大。5.1 元数据过滤能力太弱业务数据几乎都需要按照权限、部门、时间、类型、状态做过滤。比如“只检索当前用户所属部门的文档”“只检索本周上架的新政策”这些过滤条件BM25 那套倒排索引配合 bitmap 过滤器处理得又快又自然。向量检索要支持过滤就得在 ANN 算法上做文章——比如 HNSW 里做过滤要么放宽搜索范围再过滤要么引入 Filtered HNSW 之类的变体性能都会有折损。很多团队最后发现向量检索的过滤时延比纯搜索还高完全背离了初衷。5.2 增量更新和删除的麻烦业务知识库每天都会有新增、修订、下架。向量索引的增量更新是个老大难HNSW 图结构在插入新点时需要维护图的连通性删除更是要打 tombstone 标记效率远不如倒排索引“删了重建某一段”来得干净。这就导致很多团队在做知识库 RAG 时发现「数据更新频率越高纯向量索引越拖后腿」。5.3 算力和内存开销向量检索的存储成本比倒排索引高一个数量级每条文本都要存一个高维向量常见 768 维到 1536 维内存里至少要保留原始向量参与距离计算。HNSW 还额外需要维护多层图结构内存开销再翻几倍。大厂的数据量动辄千万级文档切块后向量数量可能上亿。就算用量化压缩内存成本依旧可观。相比之下BM25 倒排索引用内存映射就能跑成本低得多。5.4 可解释性和调试困难召回错了纯向量检索时你很难回答“它为什么召回这个”。向量空间里两个点的距离没有直观可解释性。而 BM25 可以明确告诉你因为这三句话都出现了“退货”这个词且标题权重高。对需要持续迭代优化的生产系统来说可解释性就是调试效率。调查 bad case 时稀疏检索的错误一眼能看穿向量检索的错误则要退回去看 embedding 模型是否训练到位排查链路长得多。6. 那完蛋了纯向量检索一无是处吗——也不是写到这里如果只讲“大厂为什么不用”容易让读者误入另一个误区觉得纯向量检索是错的。其实不是。纯向量检索有它合适的应用范围。在我看来至少这几类场景可以放心用知识库体量小几百到几千条文档。检索压力不大一条条遍历向量距离都能接受。此时混合检索带来的复杂度反而划不来。查询以语义匹配为主比如头脑风暴、论文检索、相似文档推荐。用户想找的是“尽量相近的内容”而不是“精确的某一条记录”。对精确词项需求低用户问题里几乎没有型号、代码、人名、金额这类必须精确命中的信息。快速 PoC 阶段先跑一个纯向量版本验证端到端链路等数据量上来、bad case 变多再逐步加入 BM25 和重排。我个人的经验是除非你的 RAG 只是拿来自娱自乐否则一开始就把混合检索做进去后面省掉大量返工。哪怕数据量少BM25 倒排索引的成本也低得可以忽略。判断自己是否需要升级检索方案可以看两个信号检索结果里反复出现“看着相关、实际上答非所问”的段落用户开始提交精确查询订单号、型号、政策条款时正确率明显下降。出现这两个信号就该动手加一路稀疏检索了。7. 给坚持用纯向量检索的团队一句实在话这篇文章写到最后我想分享一个经验检索方案的选型不要靠信仰靠评测集说话。我每次做 RAG 项目都会先建一个小型评测集——就是人工标注三五十条“问题—正确答案所在段落”的对。先跑纯向量拿 baseline再上混合检索对比 top-5 召回率。实测下来混合检索的召回率通常能提升 10 到 20 个百分点纯向量 baseline 越高说明你的数据和查询对语义越友好baseline 惨淡就老老实实上混合。大厂不用纯向量检索不是因为向量技术不行而是因为业务系统要的不是“看起来聪明”而是“每一次都查得准”。从语义召回出发用精确匹配兜底让重排模型把握精度再辅以规则处理极端情况——这套组合拳才是能扛住生产环境复杂查询的正路。