这是个很能勾起从业者共鸣的话题。网上聊 RAG 的教程一抓一大把但绝大多数都停留在“装个向量库、调个 Embedding 接口、top-k 召回”的阶段。等你真把这套东西放到生产环境、放到百万级甚至亿级知识库上跑一遍就会意识到一个扎心的事实纯向量检索在 demo 里跑得再漂亮一上生产就原形毕露。这篇文章就把我这些年做 RAG 系统踩过的坑、以及大厂检索架构里那些“看不见的零件”一次讲清楚。1. 先说结论大厂不是不用向量检索而是不敢只用它很多人看到标题会以为大厂彻底抛弃了向量检索其实不是。真相是大厂把向量检索当成整个检索链路里的一环而不是全部。我们内部做过一个粗略统计纯向量检索在通用知识库上的端到端准确率大概在 60%~75% 之间具体数值取决于知识库的领域垂直度和 Embedding 模型的质量。这个数字看着还行但放到客服问答、法律文书、医疗知识这类场景里根本没法上线——答错一次的成本远高于召回不全的成本。RAG 的完整链路是先召回Recall再重排Rerank最后生成Generate。召回阶段负责“广撒网”从海量知识里捞出一批候选重排阶段负责“精准打击”把真正有用的内容排到前面生成阶段才轮到 LLM 对着精选后的上下文写答案。纯向量检索只在召回这一步工作而且它召回的候选集质量并不稳定。大厂真正在做的是用混合召回保证覆盖率再用重排模型保证精度。这篇文章后面会逐一拆解。我需要先把一个基础概念摆正RAG 的质量上限是由检索决定的而不是由生成决定的。LLM 再聪明喂给它的上下文里没有正确答案它也只能一本正经地胡说八道。这就是为什么大厂在检索环节砸了那么多资源——数据清洗、索引构建、召回策略、重排模型、评估体系每一层都是独立的工程没有哪一层是可以偷懒的。2. 纯向量检索的五个致命短板2.1 语义相似不等于答案正确这是纯向量检索最根本的缺陷。向量检索衡量的是 Embedding 空间里的距离距离近意味着“语义相似”但语义相似和“包含正确答案”是两回事。我举个例子。你问“公司的年假制度是什么”知识库里有两篇文档一篇是《员工手册》里关于年假的详细条款另一篇是 HR 发布的《2024 年假期安排通知》里顺带提了一句“年假申请流程保持不变详见员工手册”。从语义相似度看第二篇和问题也很接近甚至因为发布时间新、带有“2024”这个时间特征向量距离可能更近。但真正包含答案的是第一篇。纯向量检索很可能把两篇都召回来然后靠 LLM 自己从混合上下文里挑正确答案——如果两篇内容存在冲突LLM 就可能被带偏。更麻烦的情况是所谓“表面语义相似但实质无关”。比如用户问“苹果公司的总部在哪”知识库里有一篇关于“苹果公司与 FBI 的隐私纠纷案”的分析文章里面提到了库比蒂诺总部。向量检索会认为这篇文章高度相关但它并不是用户想要的直接答案。这种“伪相关”在纯向量检索里无法避免因为 Embedding 模型看到的是词共现和语义关联它不理解“用户到底想要什么”。2.2 数字、代码与 ID向量模型的天然盲区Embedding 模型的训练目标是捕捉自然语言的语义这导致它对精确值的感知非常弱。你去问“订单号 A20240615 的状态是什么”知识库里有一条记录“订单 A20240615 已于 6 月 16 日发货”。Embedding 模型对“A20240615”这个字符串的编码方式和“A20240614”“A20240616”几乎没有区分度——在向量空间里这些 ID 之间的距离远小于它们与“订单状态”这类高频词之间的距离。结果就是召回出来的候选可能包含 A20240614 的订单记录而真正要的那条反而排在后面。代码场景也一样。你检索“如何用 Python 读取 CSV 文件并按第二列排序”知识库里有几十段代码片段每段都涉及 pandas、read_csv、sort_values。纯向量检索会把这些全部召回来但无法区分哪段代码的排序逻辑是升序、哪段是降序、哪段处理了缺失值。这种场景下关键词精确匹配比向量相似度可靠得多——“sort_values(bydf.columns[1], ascendingFalse)”这个字符串本身就是最强信号。我见过一个最极端的例子某知识库里有大量产品规格文档用户问“支持 5V/2A 充电的型号有哪些”纯向量检索召回了所有提到“充电”“电源”“适配器”的文档但把“5V/2A”这个关键参数完全当成了噪音。后来我们在检索层加了正则规则和文本精确匹配这个场景的准确率才从 47% 拉到 89%。2.3 专有名词和长尾实体召回差Embedding 模型对高频概念的编码很稳定但对专有名词、缩写、行业黑话的处理远没有想象中好。这里有两个层面的问题第一分词层面。中文 Embedding 模型普遍基于 BPE 或字粒度分词一个像“图计算引擎”这样的专有名词可能被切成“图”“计算”“引擎”三个 token语义被稀释。如果知识库里的文档写的是“图计算引擎”而用户问的是“GraphScope”同一个东西的英文名向量检索基本拉不回来除非两个词在训练语料里有非常强的共现关系——而这在垂直领域很难保证。第二语义漂移层面。同一个实体在不同语境下含义不同。比如“苹果”可以是水果、是公司、是电影名。纯向量检索把 query 编码成一个点这个点是上下文无关的它没法理解“苹果发布会”里的苹果和“苹果削皮”里的苹果应该用不同的向量表示。虽然在 RAG 场景下知识库里的文档往往已经限定在某个垂直领域实体的多义性问题会被弱化但它并没有消失——跨部门、跨业务线的大知识库里这种冲突很常见。我们内部做过一次对照实验用一个通用 Embedding 模型和一个小型微调模型对 1000 条包含专有名词的 query 分别做纯向量检索。通用模型的 top-10 召回率是 68%微调后是 81%。微调用的是知识库文档里抽取的 2 万对query, 正样本数据。这个提升很可观但微调本身也需要成本标注数据、训练周期、版本管理这些都不是小事。2.4 相似文档互相干扰导致“答案淹没”知识库里的文档往往不是独立存在的。产品手册、制度文件、FAQ、历史工单它们的结构高度相似内容大量重叠。当用户问一个泛化问题时纯向量检索会召回来一堆“长得像”的文档真正的答案被淹没在大量近似内容里。举一个真实的例子。我们的知识库里有 300 多篇银行理财产品说明书每篇的章节结构几乎一样产品概述、风险提示、收益说明、赎回规则。用户问“这款产品的赎回是 T1 还是 T2”向量检索会把 300 篇说明书中包含“赎回”这个词的 200 篇全部算一遍相似度——它们的语义距离差异非常小。结果 top-5 里可能只有 2 篇是真正相关的剩下 3 篇是别的产品的说明书只是章节标题恰好包含“赎回规则”这四个字。这种问题在纯向量检索框架下是无解的因为相似度计算发生在“文档”级别而用户关心的往往是文档里的“某个段落”甚至“某个表格”。所以大厂普遍采用段落级索引 重排模型的方案召回阶段按段落切块建索引重排阶段用 cross-encoder 逐段计算 query 和段落的真实相关性。段落级检索把答案淹没的问题缩小了一个量级但仍不能完全根治。2.5 可解释性和故障定位困难这个短板很少被人提起但在生产环境里它往往才是最要命的。纯向量检索是一个“黑箱”用户问了一个问题系统返回了一批候选但你很难说清楚“为什么是这几篇而不是另外几篇”。当线上反馈说“回答质量下降了”你用纯向量检索根本没法快速定位是数据问题、模型问题还是索引问题。关键词检索就完全不同——它天然可解释。你可以直接看到“这个 query 命中了哪些词、每个词的 TF-IDF 权重是多少”线上出了任何问题按图索骥几分钟就能定位。向量检索做不到这一点你只能反复调整阈值、换模型、重新向量化像在暗房里洗照片。大厂的检索链路里可解释性不是锦上添花而是故障排查的生命线。所以我们普遍的做法是混合检索的结果里保留每一路召回的“来源标记”线上日志记录每个 query 在 BM25 路召回了多少条、在向量路召回了多少条、最终通过重排后剩了几条。一旦效果下跌先看哪一路的召回数量发生了异常再针对性排查。这个“可观测性”的建设成本往往比检索算法本身还高。3. 大厂检索架构的标配混合召回 重排3.1 为什么是 BM25 向量而不是别的组合现在业界提到混合检索默认指稀疏检索BM25 稠密检索向量。其实可选的方案还有基于词的 n-gram 检索、基于规则的检索但 BM25 是性价比最高、泛化能力最强的选择。BM25 和向量检索是互补的。BM25 擅长精确匹配专有名词、型号、ID、代码片段、日期数字只要文本里有这些 tokenBM25 就能稳定召回。向量检索擅长语义匹配同义改写、口语化表述、跨语言对应用户说“薪资发放日”而文档里写的是“工资到账日期”BM25 可能拉不回来向量能。两条路召回的候选集重叠率大概在 30%~50% 之间这个比例很理想——说明两条路各有独特贡献同时也有相当部分是一致的。如果重叠率太高说明混合检索没意义加一路纯属浪费如果重叠率太低可能说明 Embedding 模型和分词器之间存在系统性的偏差需要检查。需要强调一点BM25 不是简单的“关键词匹配”。它内部有词频TF、逆文档频率IDF和文档长度归一化三个因子。IDF 决定了“越罕见的词权重越高”——用户搜“订单 A20240615”罕见词是“A20240615”它的权重远高于“订单”。这也是为什么 BM25 在精确匹配场景下能吊打纯向量检索。3.2 重排模型把“相似候选”变成“相关候选”混合召回之后候选集可能有一两百条远超过 LLM 上下文窗口能容纳的量。从这一两百条里挑出最相关的 5~10 条就是重排模型的工作。重排模型为什么不用向量检索的相似度直接排序因为向量检索用的双塔bi-encoder结构天然有瓶颈——query 和 document 被分别编码成两个向量交互只发生在最后的余弦相似度计算那一步。这种结构丢失了 query 和 document 之间的 token 级交互信息。重排模型用的是cross-encoder把 query 和 document 拼接成一段文本喂给模型直接输出一个相关性分数。模型可以同时看到 query 里的每个词和 document 里的每个词做完整的注意力交互。用一个生活化的类比双塔模型像是相亲网站上两个人分别填资料、系统按资料匹配度打分cross-encoder 像是让两个人坐下来面对面聊五分钟再判断合不合适。后者的判断精度显然更高但代价是每对query, document都要过一次完整的模型前向计算速度慢一到两个数量级。所以合理的做法是召回阶段用轻量双塔模型快速筛出 top-100重排阶段用 cross-encoder 精排取 top-5。这个“粗筛 精排”的两段式设计是工业界所有搜索系统的基本范式本质上是拿精度换速度、再拿速度换精度的平衡。3.3 一个可落地的混合检索流水线生产环境的 RAG 检索链路我建议按照下面的分层来搭建层级组件输入输出耗时预算查询理解意图识别 查询改写用户原始 query改写后的 query50ms召回层BM25 向量检索并行改写后的 querytop-100 候选段落200ms粗筛过滤规则过滤 去重候选段落重排前候选20ms精排层Cross-encoder 重排候选段落top-5~10 段落300ms后处理上下文压缩 重排序精排结果最终上下文50ms这个链路看着复杂但每一层都有明确的职责不能省。查询改写解决“用户问得很差”的问题——口语化、省略、指代不清晰先交给一个小模型把 query 规范成知识库偏好的表达形式。规则过滤负责把明显不符合条件的候选踢掉比如候选段落来自另一个不可用的数据源。上下文压缩把每个段落的冗余内容剪掉让 LLM 能在有限窗口内看到更多有效信息。整套链路跑下来端到端延迟一般控制在 1 秒以内其中重排占了大头。如果业务对延迟敏感可以考虑把重排模型量化到 INT8或者改用蒸馏后的小模型代价是精度略微下降。这里没有一个“最优解”只有“在特定延迟预算下的最优解”。4. 工程落地的几个关键细节4.1 分数融合把两路召回的分数变成一个排名这是混合检索里最容易被忽视、也最容易翻车的环节。BM25 的分数是词频和 IDF 的加权和向量的分数是余弦相似度两者的分布完全不同。你没法直接比较 “BM25 打了 12 分” 和 “向量打了 0.82 分” 谁更相关。主流的融合策略有三种RFFReciprocal Rank Fusion按排名取倒数相加不管原始分数多少只看每个候选在各自路里的排名。公式是 score Σ 1/(k rank)k 一般取 60。RFF 的好处是鲁棒不依赖分数分布坏处是忽略了置信度信息——排名第 1 但分数很低和排名第 1 但分数很高在 RFF 里效果一样。加权归一化先把两路分数各自做 min-max 归一化或 z-score 归一化然后按权重相加。权重需要线下评估调参。这个方法理论上更精细但归一化对异常值很敏感一个极端高分就能把整个分布拉扁。学习型融合用一个小模型学习两路分数的组合权重或者直接把两路分数作为特征喂给重排模型。这是最“大厂”的做法代价是要准备标注数据。我个人的建议是如果还没到学习型融合的阶段直接用 RFF别在归一化上浪费太多时间。RFF 在大多数场景下已经能拿到超过 90% 的最优效果而且实现起来只有十几行代码。归一化方案看着精美但踩坑成本高——不同 batch 的分数分布不稳定、新增文档后 min-max 阈值要重新计算、线上和线下的计算结果可能不一致。4.2 Metadata 过滤召回正确性的隐形守护者混合检索解决的是“语义相关”但很多时候业务要求的是“条件过滤”。用户问“北京门店的营业时间”知识库里同时有上海和北京门店的营业时间文档。语义上两篇都相关但用户只要北京。这时候不做 Metadata 过滤重排模型再强也白搭——它不知道“北京”是一个过滤条件而不是一个普通关键词。正确做法是在索引构建阶段把文档的结构化属性单独存储——门店城市、发布时间、适用人群、文档版本、权限等级等。检索时先从用户 query 里抽取出过滤条件把这些条件下推到向量库和 BM25 的查询层面只在这部分文档上做相似度计算。这不仅能提升准确率还能大幅减少计算量——因为候选集从全库缩小到了符合条件的子集。从实现角度向量数据库如 Milvus、Qdrant、Elasticsearch 的 kNN 查询都支持在检索时附带过滤条件。但要注意过滤字段的索引建设尤其是多字段组合过滤的场景这决定了检索延迟是否可控。4.3 查询改写用户不会用知识库的语言提问真实用户的提问方式和知识库文档的表达方式之间存在巨大的“语言鸿沟”。用户会问“工资啥时候发”文档里写的是“薪酬发放日为每月 10 日”。纯向量检索对同义改写有一定覆盖能力但覆盖面远没有想象中大——尤其是口语化表达、行业方言、中英混用。我们的做法是加一层轻量的查询改写模型用小规模的 LLM 做三项工作补全指代用户问“它的手续费是多少”需要结合上一轮对话推断“它”指代的是哪款产品。规范化术语把口语表达映射成知识库里的标准术语“工资”改成“薪酬”“扣钱”改成“罚则”。拆分复合查询用户问“退货政策和退款流程是什么”拆成两个子查询分别检索再合并结果。查询改写本身也会引入错误——改写后的 query 丢失了原始信息。所以线上要保留原始 query 和改写后的 query 两条路同时检索最后合并候选。这样即使改写失败原始 query 的路也没丢。4.4 Embedding 版本管理与数据更新这是一个在 demo 阶段完全不会遇到的坑。知识库是持续更新的——每周新增文档、修订旧文档、删除过期内容。每次数据更新后新增的文档需要向量化并写入索引。这时候如果对全库重新向量化成本太高如果只更新增量新旧文档用的又是不同版本的 Embedding 模型向量空间不一致相似度比较就失去意义。我们的做法是每次升级 Embedding 模型时对全量数据做一次离线重向量化期间线上继续用旧模型的索引提供服务新索引构建完成后做一次平滑切换。这个“双跑”机制要纳入发布流程不能手动作业。另外索引更新和文档删除要有配套的失效机制——知识库里如果存在已下线产品的文档但索引没有同步删除用户问“XX 产品怎么申请”系统还是会把它召回然后 LLM 一本正经地给出一个早已失效的流程。5. 我踩过的坑和排查实录5.1 召回率 95% 但答案还是错的有一段时间我们的离线评估数据很好看top-10 召回率 95%重排后 top-5 准确率也到了 82%。但线上用户反馈一直说“答非所问”。排查了很久才发现问题出在评估数据的构造方式上——我们的正样本是从知识库里“和 query 有共同关键词”的文档里筛出来的不是从真实用户日志里抽的。这就相当于拿着标准答案去考一个被提前漏题的学生分数自然好看。正确的评估做法是用真实用户 query 人工标注的相关文档作为测试集而且标注标准不是“语义相似”而是“是否能直接回答这个 query”。这两个标准的差异非常大。评估集如果构造错了后面所有调优工作都是在自嗨。5.2 阈值调参的误区很多人喜欢调相似度阈值——小于 0.75 的候选全部丢弃。这个做法在纯向量检索时代勉强可以但在混合检索链路里BM25 的分数和向量的分数不在一个空间给“整体相关性”设阈值是伪命题。更合理的做法是召回阶段不设阈值只按 top-N 截断重排阶段再设定过滤线。阈值不是一个“调出来的常数”它应该基于线上反馈动态调整——比如监控 top-5 里重排分数的分布设定一个“低于这个分数就不喂给 LLM”的底线避免 LLM 基于一堆低质量上下文胡编。5.3 数据更新后效果突然下降有一次我们更新了知识库的 3000 篇文档第二天线上召回率掉了 8 个百分点。排查发现新增文档里有大量 PDF 转换出来的文本包含大量换行符和制表符。这些文档被切块后段落里全是碎片化文本向量化效果极差BM25 也匹配不上——因为 PDF 转换把原本连续的句子切成了不完整的词组。问题不在检索算法而在数据清洗。从那以后我们把“清洗质检”前置到索引构建管线里文本去重、乱码检测、空段落剔除、超长段落切割、标题层级保留。数据质量不过关检索层的任何优化都是白搭。这个教训后来影响了我对所有 RAG 项目的判断——先看数据再谈模型。5.4 常见问题速查表现象可能原因排查方向召回结果全是“长得像但不相关”的文档段落实的切块太粗语义被稀释检查切块策略按语义边界切专有名词检索效果差Embedding 模型对长尾实体不敏感加 BM25 精确匹配权重或微调模型检索延迟突然变高候选集太大重排模型逐条过慢压缩召回 top-N或重排模型量化答案内容过期索引里存在已失效文档检查文档下线逻辑是否同步删索引同一 query 不同时间效果不同数据更新后未重新向量化检查索引版本一致性6. 从零搭一套混合检索 RAG 的最低可行方案6.1 最小配置清单如果你正在做一个新的 RAG 项目且预算和人力有限我建议从以下配置起步索引组件直接选支持 BM25 kNN 混合查询的搜索引擎Elasticsearch 或 OpenSearch避免同时维护两个系统。向量数据库虽然检索性能更强但你要额外解决 BM25 的问题等于维护两套基础设施。Embedding 模型先用通用的中文 Embedding 模型起步不建议一上来就微调。先跑通链路用评估数据证明“确实有提升空间”再考虑微调微调不是第一优先级。重排模型选一个 cross-encoder 类型的重排模型。这一步不要省混合召回 重排带来的提升比单纯换更贵的 Embedding 模型大得多。评估集从第 1 天就开始收集真实用户 query 和人工标注的相关文档哪怕只有几百条都比没有强。6.2 评估方法论评估 RAG 系统不能只看一个数字。我推荐至少关注四个指标召回率正确答案是否出现在召回候选里。重排后准确率top-5 里有多少条是真正相关的。答案利用率生成答案是否真的用到了重排后的内容还是全靠模型参记忆硬编。线上 Bad Case 率用户反馈里“答非所问”“答错”的比例。前两个指标离线可以测后两个必须上线上日志才能评估。很多团队只盯前两个导致离线指标和线上体验严重脱节。如果资源允许还要做 A/B 测试——检索链路是黑盒还是白盒对最终答案的影响只有对照实验能说清楚。6.3 后续可以往哪些方向扩展这套最小可行方案跑起来之后如果你还有余力建议依次做三件事第一沉淀 Bad Case 库。每一条线上反馈的“答错了”都值得记录原始 query、召回候选、重排结果、LLM 最终输出、人工标注的正确文档。这个库是后续所有优化的基石。第二做查询理解和改写增强。把用户 query 的意图分类、实体抽取、指代消解逐步加进去——这部分对准确率的提升往往比换模型更立竿见影。第三探索文档级和段落级的两级召回。先用文档级检索快速定位候选文档再在候选文档内部做段落级检索。两级结构在处理超长文档时能大幅提高效率。最后说几句实在话做 RAG 检索这几年我最大的感受是这个领域真正的难点不在算法而在工程。纯向量检索在学术论文里表现优秀但生产环境的脏数据、长尾实体、专有名词、权限过滤、版本管理每一个细节都能让一个“优秀算法”变得一文不值。大厂之所以不用纯向量检索是因为它们比谁都清楚检索的终极目标不是相似而是有用。如果你正在搭自己的 RAG 系统我的建议非常简单先跑通 BM25 向量 重排的最小链路然后用真实用户数据持续评估按 Bad Case 驱动迭代。别一开始就追求“最先进的模型”“最复杂的架构”先让系统在真实场景里站稳再逐步加码。这个过程没有捷径但每一步踩下去都是实打实的积累。