★ FEATURED ARTICLE 这几年大大小小做了十几个 RAG 项目从内部知识库到客服问答再到文档助手几乎每次评审都会被问到同一个问题为什么检索层不直接用向量数据库一把梭说实话我最早也这么干过纯向量检索简单、快、部署成本低demo 跑起来效果还挺唬人。但一旦接上真实业务问题马上像气泡一样冒出来用户问“怎么退换货”向量召回把“退货政策”和“退款流程”的文档都拉出来了偏偏把一篇标题里带“退换”两个字的 FAQ 漏掉了用户报一串订单号向量检索把数值当成语义处理结果完全对不上。后来我逐渐意识到纯向量检索从来不是“够用”的方案它只是整条 RAG 链路里一个基础的召回手段。大厂几乎不用纯向量检索根本原因不是技术审美而是召回精度不够、可解释性差、线上无法兜底。这篇文章我就把这条链路里每一环为什么不能省以及我自己踩坑调优的过程一次说清楚。1. 为什么纯向量检索在真实业务里经常“失灵”1.1 语义相似不等于答案正确一次印象深刻的误召回先讲一个我实际遇到的案例。当时做一个企业内部文档问答库里有几百篇产品 FAQ标题和正文都处理得很干净。第一次上线时为了快速验证直接在向量数据库里做 top-10 召回向量模型用的开源中文模型分块 500 字左右。结果用户问“发票抬头写错了怎么改”系统召回的十条里三条是“发票开具流程”两条是“发票查验”真正讲“冲红重开”的那篇文档排到了第十二名。语义上“改发票”和“发票流程”确实相近但用户要的是“怎么改”不是“怎么开”。这类例子做多了你会发现一个事实向量检索衡量的是语义距离不是信息需求是否被满足。这背后是向量模型本身的特性。双塔式的向量模型会把整段文本压缩成一个高维向量这个过程天然丢信息句式、否定词、数值、专有名词的精确含义很多细节在向量空间里被拉平了。“不开发票”和“开发票”在某些模型里距离极近因为它们的上下文高度重合。你可以在离线评测里把这两条加进难负样本堵住一部分漏洞但每堵住一个总有下一个冒出来。真实业务里的 query 千奇百怪靠纯向量一网打尽本质上是在赌向量模型的语义泛化能力。1.2 精确匹配场景代码、型号、人名与数字检索的灾难第二个失灵场景更致命精确匹配。客服场景里用户会直接报“订单号 20240518xxx”知识库里对应文档的标题是“关于订单 20240518xxx 的异常处理说明”。按纯向量检索这个订单号作为 token 被切碎、被向量化只要文档里数字出现的位置稍微不同或者用户把中间两位记错语义检索照样给你返回一堆“看起来差不多”的文档。可业务要的是唯一命中不是差不多。代码、型号、身份证号、合同编号、金额范围这些内容都有一个共同点它们的正确性依赖字符级精确匹配而不是语义近似。向量检索天生不擅长这类匹配因为向量模型在训练时根本不会专门为“连续数字串的完全一致”建模。那怎么办只能靠额外一路精确检索兜住比如分词后走 BM25 的 term 匹配或者直接在倒排索引上查原始字段。我在多个项目里验证过纯向量检索在这类 query 上的准确率通常只有五六成加上精确匹配这一路之后能拉到九成以上。1.3 阈值与召回的“跷跷板”精度上不去成本下不来纯向量检索还有一个绕不开的工程问题阈值怎么定。定低了召回一堆无关文档生成阶段不仅浪费 token还把正确答案淹没在噪声里模型更容易被误导定高了真正相关的文档因为向量距离不够近被过滤掉直接丢召回。我见过不少团队在相似度阈值上调来调去最后发现它跟数据分布强相关文档长度、领域术语密度、向量模型版本任何一样变了阈值就得重新调。纯向量方案没有局部可控的能力只能全局调一个数这在大规模多类目语料上是很难用的。更麻烦的是可解释性。用户问为什么搜不到纯向量方案只能回答“语义距离没到阈值”既拿不出命中的关键词也做不了词级别的归因。做一个面向内部业务的 RAG检索链路出了问题是要能向业务方解释的纯向量这一层解释不了任何东西。这一点虽然不算硬性指标但在真实项目里往往决定了方案能不能推广开。2. 先看全貌大厂 RAG 检索链路到底由哪些环节组成2.1 检索只是中间层不是终点现在做 RAG 的人很多但不少人把检索等同于向量搜索这其实是个误区。检索的目标是“从海量候选里捞出一小撮有用的”而 RAG 真正要的是把对的那几篇文档送进生成模型。从“有用的”到“对的”中间还隔着海选、精排、后处理好几道工序。打个比方这就像招聘。向量检索相当于你在一万份简历里用关键词初筛出五十份但你不能直接让面试官面对五十个人精谈你得先有 HR 专员按岗位匹配度排个序再让业务负责人挑出最像样的五个人最后还要核对简历真伪、排除重复投递。检索链路里的每一层干的都是这类逐步收窄、逐步校验的活。任何一个环节缺失都会让最终进到 LLM 的上下文质量下降进而影响回答的准确性和稳定性。2.2 一条标准流水线的六个环节我后来在项目里沉淀下来的一套标准链路基本可以拆成六个环节Query 理解改写、扩写、意图识别、抽取结构化条件。多路召回向量召回、关键词召回、结构化查询各跑各的。融合把多路结果做归一化、去重、合并。精排用更强的模型对 Top-N 做细粒度打分。后处理去重、过滤、硬截断、按上下文窗口裁剪。兜底策略命中率不足时的提示改写、追问澄清或默认回答。每一步看起来都简单但每一步都在解决一个真实问题Query 理解解决“用户没说清”多路召回解决“单一信号不可靠”融合解决“各路分数不可比”精排解决“粗召回精度不够”后处理解决“模型输出边界”兜底策略解决“链路整体失灵时的表现”。把这些环节串起来才算一条能上生产的检索链路。2.3 为什么“纯向量”在链路中只能当一个零件把这六个环节放在一起看就很容易理解大厂为什么不做纯向量了。纯向量检索只覆盖了第二个环节里的一路召回它既没有处理 query 的表达问题也没有处理候选质量的校验问题。你可以换一个更好的向量模型把召回率从 80 拉到 85但剩下的 15 个点靠的是精排、改写、关键词召回这些环节补上来的。这不是“要不要用向量”的问题而是“向量只是其中一个信号”的问题。所以每次有人问“你们为什么不用纯向量”我的回答通常是不是不用向量而是不能只用向量。向量检索在链路里承担的是“语义召回兜底”的角色它负责把那些用词不同但意思相关的文档捞回来至于精确匹配、强约束条件、排序优化这些都交给别的环节。哪个环节省掉哪个环节的坑就会在线上爆发这不是危言耸听是我反复验证过的经验。3. Query 理解检索之前先把用户的话“翻译”明白3.1 查询改写一词之差结果天差地别真实用户问问题很少会按文档的表述方式来说。用户说“电脑开不了机怎么办”文档里写的是“设备无法启动时的排查步骤”两者在字面上几乎不重叠纯向量模型有时候能靠语义拉近但遇到更隐蔽的说法就会失效。比如用户问“工资条在哪看”文档里写的是“薪酬明细查询路径”语义相近但检索模型未必稳定命中。所以线上系统一般会加一层 query 改写。常见做法是用 LLM 把用户问题改写成几个候选检索式比如拆解成子问题、提取关键词、补充同义词。这个环节我实测下来收益非常大尤其是对短 query 和口语化 query。改写本身也不复杂给 LLM 一个 prompt让它输出 2 到 3 个检索用 query再对这些 query 分别召回最后合并结果。成本是每次多几次 LLM 调用换来的是召回质量的明显提升。要注意的是改写 prompt 里的约束要写清楚不要太发散不要添加原文没有的信息。否则模型会把“退换货”扩写成“七天无理由”“售后政策”“退款流程”反而把结果带偏。改写的目标不是“生成更多花样”而是“提高检索命中率”这两者有本质区别。3.2 意图路由先分类再检索第二个常见手段是意图路由。很多知识库天然分域售后服务、技术文档、政策法规、数据报表各自用的术语和文档结构完全不同。如果所有 query 都进同一个检索池模型容易在不同域的文档之间反复横跳。做法是先让一个轻量分类器判断用户 query 属于哪个域然后只在这个域的索引里做召回。比如金融客服场景“信用卡账单怎么查”和“贷款利息怎么算”应该走两套不同的知识索引。路由这个动作还能带来额外好处每套索引可以单独调参、单独优化某个域的文档更新也不影响其他域。实际项目里路由本身的准确率很容易做到 95% 以上成本很低性价比极高。3.3 元数据过滤把搜索空间先缩小一半还有一种不依赖模型的优化就是元数据过滤。知识库里的文档通常都带字段发布时间、适用版本、文档类型、关联产品。如果能在检索前把这些条件过滤掉向量搜索的候选空间会小很多精度和延迟都会改善。举个例子。做设备说明书问答时用户会问“XX 型号的蓝牙配对步骤”那就可以先用实体识别把型号抽出来作为过滤条件直接限定索引范围检索只在对应型号的文档子集里做。这样既避免了跨型号的相似文档干扰召回又能让向量检索在更聚焦的候选集里找到正确答案。元数据过滤和向量检索是叠加关系不是替代关系先过滤再检索往往比单纯加大向量召回数量更有效。4. 混合召回为什么 BM25 到现在还没被淘汰4.1 词汇匹配和语义匹配是互补关系混合召回这个词大家可能都听腻了但真正理解它为什么有效的没多少。纯语义召回面临的困境我在前面说了对精确匹配不敏感、对长尾 query 不稳。而 BM25 这类词汇匹配方法恰好擅长这些它不关心词的意思只关心词在文档里有没有出现、出现得多不多。用户报订单号、报型号、报人名BM25 能稳稳命中。反过来BM25 对同义词、口语化表达无能为力而向量检索恰好擅长泛化。这俩不是竞争关系而是互补关系。实际项目里我会把两路召回合并一路向量召回提高语义覆盖一路 BM25 保证精确命中最后再让精排环节对两路候选统一打分。多路召回不一定两路就够有些场景还会加第三路、第四路比如后缀树匹配、正则匹配、知识图谱查询全看业务需求。4.2 三种分数融合方案与我的实测感受多路召回之后必然面临一个问题各路分数不在一个量纲上怎么合并排序。我实际用过的融合方式有三种。第一种是加权分数和。给向量相似度和 BM25 分数各自乘一个权重再相加。问题是要先做分数归一化而且权重对效果很敏感换一版数据就要重新调。第二种是 RRF按名次而不是分数来融合对每路结果的排名取倒数求和。它不依赖分数分布鲁棒性很好实测下来效果稳定适合作为默认方案。第三种是让精排模型直接吃多路候选融合和精排一起做跳过显式融合。这个效果上限最高但工程上复杂一些。我的经验是如果团队刚起步先上 RRF简单可靠等数据多了以后再换端到端精排。调权重这种事看起来精细实际上很容易过拟合到某一批数据上得不偿失。4.3 多路召回不是终点还有结构化数据这条路再往深了说有些问题本质上不是“文本检索”问题而是“结构化查询”问题。用户问“上个月退货率最高的三个品类分别是什么”这要求系统去查报表数据而不是翻文档。纯文本检索链路对这类 query 无能为力但真实大厂的 RAG 系统会把文本召回、结构化数据查询、知识图谱推理都纳入进来按 query 类型选择不同的数据通道。这也是大厂不用纯向量检索的另一个深层原因业务场景里需要回答的问题类型太多样了没有一种检索方式能覆盖全部。文本向量解决语义相近的文档召回知识图谱解决多跳关系查询结构化接口解决数值统计各管一摊再由上层的路由和精排统一调度。5. Rerank 重排召回质量不够精排来兜底5.1 用小模型召回、大模型精排的分工逻辑检索链路里我花时间最多、收益也最大的一环是精排。召回阶段为了追求高召回通常会故意放松标准向量召回 top-50、关键词召回 top-30让候选数量充足一些。但这些候选里真正有用的可能只有三五个。如果直接全塞给生成模型上下文会被大量无关文档挤占不仅浪费 token还会引入噪声让回答质量下降。精排的作用就是把粗召回的 Top-N 用更强的模型重新打分只保留最相关的 Top-K 进入上下文。为什么不在召回阶段直接用一个很强的模型因为成本。精排模型通常是 cross-encoder 结构把 query 和每条文档拼在一起过一遍 Transformer计算量远大于召回阶段的双塔向量模型。用它在百万级文档里打分不现实但在几十条候选上跑完全没问题。这就是“粗召回 精排”的分工逻辑粗召回负责广撒网精排负责优中选优。5.2 精排模型怎么选、怎么部署精排模型我通常会选开源的中文 cross-encoder 模型它们在常见 RAG 场景下的效果已经够用。部署上要注意两点一是要把模型和向量检索服务解耦这样精排升级不需要重建全部向量索引二是要控制 batch精排是纯计算密集型环节延迟和吞吐要单独压测避免它成为整条链路的瓶颈。还有一个容易被忽略的点精排模型的输入长度是有限的文档太长会被截断。所以我一般在分块切分时就把长文档拆成段落级块精排直接对 query 加段落打分最后再按文档维度聚合。这样既避免了截断丢信息又能让精排在更细粒度上做判断。实测下来段落级精排比文档级精排在准确率上能高出不少。5.3 重排之后的后处理去重、过滤与截断精排之后不是直接结束还有一层容易被忽略的后处理。第一是去重多路召回里同一篇文档可能以不同版本反复出现精排前通常已经做了一次合并精排后再做一次确认避免重复内容占据上下文。第二是过滤把包含固定模板、无实质信息、或者不符合当前场景的段落剥掉这一步很多团队不做但线上出过问题之后就会知道它有多重要。第三是截断根据 LLM 的上下文窗口和 token 预算把精排后的文档裁剪拼接确保不超限。后处理看起来琐碎但它是决定生成质量的重要一环。我见过不少项目检索和精排效果都很好最后因为上下文拼得太满关键信息被挤出窗口导致回答质量直线下降。这类问题排查起来又隐蔽又费时间不如在一开始就把后处理规则定好。6. 实操复盘一套可落地的混合检索方案是怎么调出来的6.1 从零到一场景分析与方案设计说点具体的。我拿最近的一个项目完整走一遍场景是某公司的售后知识库文档大概一万篇包含产品说明书、FAQ、政策公告用户 query 以口语化提问为主来源是客服对话和员工咨询。前期分析时我先列了三类典型问题语义泛化型比如“电脑卡顿怎么办”精确匹配型比如“订单号 xxx 的状态”混合型比如“XX 型号怎么连蓝牙连不上怎么办”。这三类问题决定了检索方案不能是单一通道。方案上我定了四层query 改写、双路召回向量加 BM25、RRF 融合、cross-encoder 精排。向量索引按领域切了两套子索引售后类和技术类分开BM25 走倒排索引同时保留元数据过滤字段。精排模型单独部署了一个 GPU 服务和向量召回服务解耦。这个方案看起来不复杂但每一步都有明确的针对性改写解决口语化双路解决语义和精度的互补RRF 解决分数融合精排解决最终质量。6.2 关键参数调优记录与效果对比调参过程中我重点盯几个参数。第一是分块大小。最初按 500 字切块结果很多包含完整答案的段落被切成两半召回时只命中一半精排打分也受影响。后来改成按段落切过长段落再按句切召回命中率立刻上来了。第二是召回数量。向量召回 top-50、BM25 top-30融合后精排输入 top-30最后保留 top-5。这个比例是在延迟和效果之间反复试出来的top-5 是生成效果不下降的最大值。第三是精排阈值。我不用固定的相似度阈值而是固定保留条数因为精排模型输出的是相对分数固定条数比固定阈值稳定得多。效果对比上纯向量方案的命中率大概是七成左右加 BM25 双路后到了八成五再加精排后到了九成五以上。延迟方面整条链路增加了改写和精排两步单次问答从 200 毫秒涨到 800 毫秒但在客服场景里完全可以接受。这个对比也印证了前面的判断向量模型升级能带来几个点的提升但大头的提升来自链路补全。6.3 离线评估指标别只用 Recallk 骗自己最后说评估。很多人做 RAG 只报一个指标比如 Recall5但这会骗人。Recall5 只告诉你正确答案在不在前五不告诉你排序是否合理也不告诉你生成质量是否受益。我建议至少看四类指标召回率正确答案是否进入候选命中位置正确答案排第几生成质量人工打分或者用大模型打分端到端成功率用户问题是否被完整解决。另外评估集一定要贴近真实分布。我从线上日志里抽了 200 条真实 query再人工标注正确答案文档构建了一套评测集。这套评测集后来帮我挡住了很多“看起来很美”的方案。比如某个新向量模型在公开数据集上的指标很漂亮但在我的评测集上精确匹配类 query 反而退步了就是因为公开数据集缺少这类样本。用真实数据评估才能避免被公开指标误导。7. 常见问题排查与避坑实录7.1 典型问题速查表现象可能原因排查思路精确信息搜不到只有向量一路召回加 BM25 或精确匹配路答案正确但排序靠后缺少精排加 cross-encoder 重排改一个词就召回失败query 改写不充分增加改写候选、补充同义词结果在不同文档间跳来跳去缺少意图路由按域切索引、前置路由生成结果被无关文档带偏上下文混入噪声提高精排阈值、减少 Top-K同一文档重复出现多路合并去重没做好在融合阶段按文档 ID 去重线上效果和离线差距大评测集分布不真实用线上日志构建评测集这张表是我排查问题时的第一参照大多数线上问题往里一套基本就有方向了。7.2 我踩过最深的三个坑第一个坑是权重调参上瘾。早期我做混合检索花了整整两周调向量和 BM25 的融合权重每天都有小提升但评测集一换就崩。后来用 RRF 替代加权融合效果反而稳定了省下来的时间都去做数据清洗。这个教训是融合策略优先选鲁棒的别在过拟合边缘反复横跳。第二个坑是忽略索引更新。知识库不是静态的每周都有文档更新。纯向量索引的增量更新和删除一直是个麻烦事我踩过文档删了但向量没删、导致召回一堆过期内容的坑。后来我在检索结果上加了文档级的时间戳校验过期文档在融合阶段直接滤掉才算彻底解决。第三个坑是“精排万能论”。有一阵我觉得精排能解决一切于是放松了对召回的要求结果精排质量再好也救不回来。精排只能排“被召回的内容”它不能无中生有。正确的做法是把精排定位成最后一道质检召回环节该做的多路、改写、过滤一样都不能省。7.3 RAG 检索链路后续还能怎么扩展这套链路搭起来之后后续扩展的方向其实很清晰。一是把精排模型升级成能感知用户反馈的版本把线上用户的点赞和点踩信号变成训练样本让模型不断进化。二是引入长期记忆把高频问题和对应的正确答案沉淀成缓存命中缓存时直接回答绕开整条检索链路延迟能从几百毫秒降到几十毫秒。三是建立检索结果反馈闭环把生成回答的引用来源记录下来用户如果反馈“答案不对”可以反查是哪条文档误导了模型再针对性地优化数据。我在实际项目里已经开始做前两步了效果都比较直接。长期记忆缓存带来的延迟下降是最明显的用户感知立刻就不一样反馈闭环虽然难做但它是让 RAG 系统持续变好的关键一环。这个领域变化很快但底层逻辑没变检索质量决定 RAG 的天花板而检索质量从来不是靠某一个模型、某一种检索方式撑起来的是靠一条完整的、每一环都能兜底的链路撑起来的。别迷信纯向量也别一股脑上全套方案先搞清楚你的数据长什么样、用户怎么提问再决定每一环怎么搭这才是最靠谱的路径。
阅读完成 · 觉得有帮助？
