1. 从一次召回翻车说起纯向量检索到底哪里不够用去年帮一个做企业知识库的团队做检索链路复盘他们的场景很典型几万份内部技术文档、产品手册、会议纪要用了一套开箱即用的向量数据库embedding 模型选的是当时榜单上排名很靠前的一个。上线第一周产品经理搜报销流程返回的第一条是《差旅费用标准》第二条是《员工福利政策》真正讲报销步骤的那份文档排在第七位。更离谱的是搜一个具体的错误码向量检索返回了一堆语义相近但完全不相关的故障描述而那份精确记录该错误码的运维手册压根没进前二十。这不是个例。我后来陆续接触了七八个 RAG 项目几乎每一个在纯向量检索这条路上都踩过类似的坑。问题不在于向量检索本身不好而在于它被当成了万能钥匙。向量检索擅长的是语义相似但真实业务里的查询需求远比语义相似复杂——有时候用户要的是精确匹配有时候要的是关键词命中有时候要的是时间范围过滤还有时候要的是多个条件的组合。纯向量检索只能覆盖其中一部分。这篇文章想聊的就是这件事为什么那些真正在生产环境跑 RAG 的团队几乎没有人只用纯向量检索他们到底在向量检索之外加了什么这些补充手段各自解决什么问题、在什么场景下生效、怎么组合起来用我会从检索链路的底层逻辑讲起把混合检索、重排序、查询改写、元数据过滤这些手段拆开揉碎配上可落地的参数建议和实操中踩过的坑。不管你是刚接触 RAG 的新手还是已经在调优检索效果的老手应该都能从中找到能直接抄作业的东西。2. 向量检索的能力边界它擅长什么、不擅长什么2.1 向量检索的本质是语义空间里的距离计算要理解向量检索为什么不够用得先搞清楚它到底在做什么。简单说embedding 模型把一段文本映射成一个高维空间里的点语义越接近的文本它们的点在空间里的距离越近。检索的时候把查询也映射成同一个空间里的点然后找离它最近的几个点对应的文本。这个机制决定了向量检索的核心能力它能理解意思相近但用词不同的查询。比如用户搜怎么请年假一份标题是《休假申请指南》的文档虽然字面上没有年假两个字但语义上很接近向量检索能把它找出来。这是传统关键词检索做不到的也是向量检索最大的价值。但反过来这个机制也决定了它的盲区。向量是一个有损压缩的结果一段几百字的文本被压成一个固定维度的向量常见的是 768 维、1024 维、1536 维压缩过程中必然会丢失信息。丢失的是什么是精确的词汇、数字、代码、专有名词、否定词、逻辑关系。这些东西在语义空间里往往被平滑掉了。2.2 四类纯向量检索必然翻车的场景我在实际项目里总结下来纯向量检索至少在四类场景下会出问题。第一类是精确匹配需求。用户搜一个错误码ERR_0x80070005、一个订单号、一个 API 名称、一个函数名向量检索会把这类查询和语义相近的文本匹配但精确包含这个字符串的文档未必排在最前面。因为 embedding 模型在训练时见到的这类 token 很少它对这个字符串的表示能力很弱。第二类是关键词权重需求。有些查询里某个词是绝对核心比如Redis 持久化 RDB 和 AOF 的区别RDB和AOF这两个词必须命中但向量检索可能返回一篇讲数据库持久化通用原理的文档因为它整体语义更接近但恰恰没有讲 RDB 和 AOF。第三类是结构化过滤需求。用户想搜2024 年第三季度的销售数据这里2024 年第三季度是一个硬性过滤条件向量检索没法保证返回的文档都在这个时间范围内。它只能找语义上像销售数据的文档时间范围得靠额外的元数据过滤来做。第四类是否定和排除需求。用户搜不包含测试环境的部署文档向量检索对不包含这种否定语义的处理很弱它很可能返回一堆测试环境的部署文档因为部署文档这个语义太强了。下面这张表是我在实际项目里整理的对比能直观看出向量检索和关键词检索各自的强项查询类型纯向量检索表现关键词检索表现典型例子语义相近、用词不同强弱怎么请假匹配《休假申请指南》精确字符串匹配弱强错误码、订单号、API 名核心关键词必须命中中强RDB 和 AOF 的区别结构化条件过滤不支持不支持时间范围、部门、文档类型否定语义弱中不包含测试环境长尾专有名词弱强内部项目代号、产品型号这张表说明一个核心结论向量检索和关键词检索是互补的不是替代关系。大厂的 RAG 系统之所以不用纯向量检索第一个原因就是他们需要关键词检索来补上精确匹配和核心词命中的短板。2.3 一个容易被忽略的点embedding 模型的领域漂移还有一个坑很多人没意识到。公开的 embedding 模型大多是在通用语料上训练的对通用领域的语义理解很好但一到垂直领域就拉胯。比如医疗、法律、金融、工业制造这些领域大量专有术语在通用语料里出现频率极低模型对它们的表示很不准确。我见过一个做工业设备手册检索的项目用户搜液压泵异响纯向量检索返回的是发动机噪音处理因为模型在通用语料里学到的异响和噪音很近但它不知道在工业语境下液压泵异响是一个特定的故障类型对应的是完全不同的处理流程。这种领域漂移问题靠换更大的模型只能缓解不能根治最终还是得靠关键词检索兜底。3. 混合检索把向量和关键词拧成一股绳3.1 混合检索的基本架构既然向量检索和关键词检索互补最直接的想法就是把两者结合起来这就是混合检索Hybrid Search。基本架构是同一份文档既建向量索引也建关键词索引通常是倒排索引查询的时候两路并行检索各自返回一批候选然后融合成一个最终结果。关键词检索这一路现在主流用的是 BM25 算法。BM25 是 TF-IDF 的改进版核心思想是一个词在文档里出现次数越多、在所有文档里出现越少这个词对这篇文档的重要性就越高。同时它做了长度归一化避免长文档因为词多而占便宜。BM25 对精确匹配和核心词命中的效果非常好而且计算速度快是工业界用了十几年的成熟方案。融合两路结果的方法最常见的是RRFReciprocal Rank Fusion倒数排名融合。它的公式很简单RRF_score(d) Σ 1 / (k rank_i(d))其中rank_i(d)是文档 d 在第 i 路检索结果里的排名k是一个平滑常数通常取 60。这个公式的好处是不需要关心两路检索的分数尺度是否一致向量检索返回的是余弦相似度BM25 返回的是另一个量纲的分数直接加权求和会有问题只看排名天然公平。3.2 RRF 融合的实操参数与踩坑RRF 看起来简单但实操里有几个细节要注意。k 值的选择。公式里的 k 取 60 是原论文的推荐值它的作用是削弱排名靠前文档的绝对优势让排名靠后的文档也有机会。k 越小头部文档的优势越大k 越大各排名之间的差距越小。我在实际项目里试过 10、30、60、100 几个值发现对于候选集在 50 到 100 条的场景k 取 60 确实比较稳。但如果你的候选集很小比如只取 top 10k 可以适当调小到 20 到 30让头部更突出。两路各取多少候选。这是个需要权衡的点。取太少融合的素材不够可能漏掉好文档取太多融合后的噪声变大而且增加后续重排序的负担。我的经验是如果最终要给重排序模型喂 20 条那两路各取 30 到 50 条比较合适融合后取 top 20 到 30 条进入重排序。这个比例不是死的得根据你的文档库规模和查询特点调。权重问题。标准 RRF 是两路等权的但实际场景里往往需要调权。比如一个技术文档库用户查询里精确术语很多那 BM25 这一路应该给更高权重如果是一个客服问答库用户查询很口语化那向量这一路应该更重。加权 RRF 的公式变成RRF_score(d) Σ w_i / (k rank_i(d))w_i是第 i 路的权重。调权的方法没有理论最优解只能靠标注一批查询-文档对然后网格搜索。我一般会先固定 k60然后在 w_vector 从 0.3 到 0.7 之间以 0.1 为步长试看哪个组合在评测集上的 recall20 最高。提示调权之前一定要先有一批标注数据哪怕只有几十条。凭感觉调权很容易过拟合到某几个查询上上线后效果反而更差。3.3 关键词检索这一路的工程细节BM25 这一路虽然成熟但工程上也有几个坑。分词。中文场景下BM25 依赖分词质量。用通用的分词器比如基于词典的在垂直领域经常分错比如把液压泵分成液压和泵把产品型号XJ-2000分得乱七八糟。我的做法是维护一个领域词典把专有名词、产品型号、错误码都加进去强制分词器不切分它们。这个词典的维护成本不高但效果提升很明显。停用词。通用停用词表在垂直领域不一定适用。比如在医疗领域患者这个词可能到处都是但它未必是停用词因为患者和医生的查询意图完全不同。停用词表最好根据实际语料统计词频来定而不是直接用网上的通用表。字段权重。如果文档有标题、正文、标签等多个字段BM25 可以对不同字段给不同权重。标题命中的权重通常应该高于正文命中。Elasticsearch 和 OpenSearch 都支持字段级 boost比如title^3 content^1表示标题权重是正文的三倍。这个设置对提升精确匹配效果很有帮助。4. 重排序把粗排的噪声压下去4.1 为什么混合检索之后还需要重排序混合检索解决了召回的问题把可能相关的文档都捞出来了但捞出来的这批文档里排序未必准。原因有两个一是 RRF 只看排名不看内容它没法判断一篇文档到底和查询有多相关二是向量检索和 BM25 都是粗排模型它们的计算复杂度低但精度也有限。重排序Rerank就是来解决这个问题的。它的思路是对粗排返回的 top N 条文档用更精细的模型逐条计算它和查询的相关性分数然后重新排序。这个精细模型通常是Cross-Encoder它把查询和文档拼在一起输入模型让模型同时看到两者做充分的交叉注意力计算。相比之下向量检索用的 Bi-Encoder 是分别编码查询和文档两者之间没有交互精度自然差一截。Cross-Encoder 的代价是计算量大。Bi-Encoder 可以预先算好所有文档的向量查询时只算一次查询向量然后做向量检索Cross-Encoder 必须对每个查询-文档对都跑一次模型没法预计算。所以它只能用在 top N 这个很小的候选集上N 通常是 20 到 100。4.2 重排序模型的选型与实测对比重排序模型的选择我实测过几个主流方案各有特点。基于 BERT 的 Cross-Encoder。这是最经典的方案把查询和文档拼接后输入 BERT取 [CLS] 位置的输出做二分类相关/不相关。效果稳定但推理速度一般尤其是文档较长的时候。适合对延迟不敏感的场景。基于轻量级模型的 Cross-Encoder。比如用蒸馏过的小模型推理速度快很多效果略降但通常可接受。适合高并发场景。基于 LLM 的重排序。用大模型对候选文档逐条打分或排序。效果通常最好因为大模型的语义理解能力最强但成本和延迟也最高。我一般只在候选集很小比如 top 10且对精度要求极高的场景用。下面这张表是我在一个技术文档检索项目上的实测数据评测集是 200 条人工标注的查询指标是 nDCG10方案nDCG10单次查询延迟top 20 重排纯向量检索0.5230ms混合检索RRF0.6160ms混合检索 BERT Cross-Encoder0.74280ms混合检索 轻量 Cross-Encoder0.70120ms混合检索 LLM 重排序0.781500ms这组数据很能说明问题混合检索相比纯向量检索提升了 0.09重排序又在混合检索基础上提升了 0.13。重排序的增益甚至比混合检索还大。这就是为什么大厂的 RAG 链路里重排序几乎是标配。4.3 重排序的工程注意事项重排序虽然效果好但工程上有几个点要注意。候选集大小。重排序的候选集不能太大否则延迟扛不住也不能太小否则粗排漏掉的好文档没机会被救回来。我的经验是 20 到 50 条比较合适。如果延迟预算充足可以放到 100 条。批处理。Cross-Encoder 逐条推理很慢一定要做批处理。把 top N 条文档拼成一个 batch 一次性送进模型能显著提升吞吐。batch size 根据显存和延迟要求调一般 8 到 32 之间。截断长度。文档太长会拖慢推理而且 Cross-Encoder 对超长文档的效果也会下降。通常把文档截断到 512 个 token 左右只保留和查询最相关的部分。如果文档本身很长可以先做段落切分对每个段落单独重排序。缓存。如果某些查询是高频的可以把重排序结果缓存起来。缓存 key 用查询的哈希value 是排序后的文档 ID 列表。这个优化在客服问答这类场景效果很明显。5. 查询改写与扩展让检索更懂用户5.1 用户查询和文档之间的表达鸿沟前面讲的混合检索和重排序都是在查询已经确定的前提下优化。但实际场景里用户的原始查询往往质量很差太短、太口语、有错别字、指代不明、缺少上下文。比如用户搜那个报错怎么办这个查询里没有任何有效信息向量检索和 BM25 都无能为力。查询改写Query Rewriting和查询扩展Query Expansion就是来解决这个问题的。核心思路是在检索之前先把用户的原始查询加工一下让它更容易匹配到相关文档。5.2 几种常见的查询改写策略基于 LLM 的查询改写。这是现在最主流的做法。把用户查询和对话历史一起喂给 LLM让它输出一个更完整、更明确的查询。比如用户在多轮对话里先问Redis 怎么持久化再问那 AOF 呢LLM 可以把第二个查询改写成Redis AOF 持久化的原理和配置。这个改写补全了上下文检索效果会好很多。查询扩展。在原始查询基础上加同义词、相关词。比如请假扩展成请假 休假 年假 调休。扩展词可以来自同义词词典也可以让 LLM 生成。扩展的好处是提升召回坏处是可能引入噪声所以扩展词要控制数量一般加 2 到 5 个就够。HyDEHypothetical Document Embeddings。这个思路比较巧妙让 LLM 先根据查询生成一个假想的答案文档然后用这个假想文档的向量去检索。因为假想文档和真实文档在表达上更接近都是陈述句、都是完整段落比原始查询往往是疑问句、短语更容易匹配。HyDE 在查询很短、很口语的场景下效果提升明显。查询分解。对于复杂的多跳查询比如对比 Redis 和 Memcached 在持久化上的区别可以拆成Redis 持久化和Memcached 持久化两个子查询分别检索后再合并。这个策略适合需要综合多个信息源的场景。5.3 查询改写的成本与收益权衡查询改写不是免费的。每次改写都要调一次 LLM增加延迟和成本。而且改写本身可能出错把原本正确的查询改歪了。所以我的建议是对于短查询少于 5 个词和指代不明的查询做改写收益大。对于已经很长、很明确的查询不做改写避免画蛇添足。改写结果和原始查询可以并行检索两路结果一起融合这样即使改写出错原始查询还能兜底。注意查询改写和查询扩展都会增加检索的候选集进而增加重排序的负担。如果延迟预算紧张要控制扩展的规模或者只对部分查询做改写。6. 元数据过滤结构化条件的硬约束6.1 向量检索处理不了结构化条件前面提到过向量检索对结构化条件无能为力。用户搜2024 年第三季度的销售数据向量检索只能找语义上像销售数据的文档没法保证时间范围。这类需求必须靠元数据过滤Metadata Filtering来解决。元数据过滤的思路是给每篇文档打上结构化标签比如创建时间、文档类型、所属部门、产品线、版本号等。检索的时候先按这些标签做过滤缩小候选集再在候选集里做向量检索或关键词检索。6.2 过滤和检索的执行顺序这里有个工程上的关键决策先过滤再检索还是先检索再过滤先过滤再检索候选集小检索快但如果过滤条件太严可能把相关文档都过滤掉了导致召回不足。先检索再过滤召回有保障但如果过滤条件筛掉大部分结果可能返回的结果很少而且检索时浪费了算力在会被过滤掉的文档上。我的经验是过滤条件的选择性selectivity决定顺序。如果过滤条件能筛掉 90% 以上的文档高选择性就先过滤再检索如果过滤条件只能筛掉一小部分低选择性就先检索再过滤。实际系统里很多向量数据库支持在检索时带过滤条件底层会自动选择执行计划但了解这个原理有助于你写出更高效的查询。6.3 元数据设计的最佳实践元数据设计有几个原则标签要覆盖高频过滤需求。先统计用户查询里常见的过滤条件比如时间、类型、部门然后针对性地打标签。不要为了全面打一堆用不上的标签浪费存储和维护成本。标签值要规范化。比如时间统一用 ISO 格式部门统一用标准名称避免技术部和技术部门这种不一致。支持多值标签。一篇文档可能属于多个产品线标签要支持数组形式。标签要可更新。文档的元数据可能变化比如文档更新了版本号要支持增量更新而不是重建整个索引。下面这张表是我在一个企业知识库项目里用的元数据 schema供参考字段名类型说明是否可过滤doc_idstring文档唯一标识否titlestring文档标题否doc_typeenum文档类型手册/纪要/规范是departmentstring所属部门是product_linearray产品线可多值是created_atdatetime创建时间是updated_atdatetime更新时间是versionstring版本号是tagsarray自定义标签是7. 一套可落地的 RAG 检索链路长什么样7.1 完整链路的六个环节把前面讲的东西串起来一套生产可用的 RAG 检索链路大概是这样的查询预处理判断查询是否需要改写。短查询、指代不明的查询走改写分支长查询直接进入下一步。查询改写/扩展用 LLM 改写查询或加同义词扩展。改写结果和原始查询并行保留。元数据过滤根据查询里识别出的结构化条件时间、类型等生成过滤表达式。混合检索向量检索和 BM25 并行执行各自返回 top K用 RRF 融合。重排序对融合后的 top N 用 Cross-Encoder 重排。结果组装取重排后的 top M 条拼成上下文喂给生成模型。这个链路里每一步都有开关。不是所有查询都需要走全流程。比如一个很明确的查询可以跳过改写一个对延迟极敏感的场景可以跳过重排序。链路要可配置根据查询特征动态选择走哪些环节。7.2 各环节的参数配置建议下面这张表是我在多个项目里总结的参数起点可以直接作为调优的初始值环节参数建议值说明向量检索top_k30-50根据文档库规模调BM25top_k30-50和向量检索对齐RRFk60候选集小时可降到 20-30RRF权重向量 0.5 / BM25 0.5根据查询特点调重排序候选集20-50延迟和精度的平衡点重排序batch_size8-32根据显存调重排序截断长度512 token超长文档先切分最终上下文top_m3-8根据生成模型上下文窗口调这些值不是金科玉律但作为起点能帮你少走弯路。调优的时候一次只动一个参数观察评测指标的变化避免多个参数一起动导致无法归因。7.3 评测没有评测就没有调优最后强调一个很多人忽略的点RAG 检索链路的调优必须建立在评测之上。没有评测集你改任何参数都是盲调改好了不知道为什么好改坏了也不知道为什么坏。评测集不需要很大几十到几百条查询就够。每条查询标注出真正相关的文档 ID。指标用 recallk召回率和 nDCGk排序质量。recall 衡量相关文档有没有被召回nDCG 衡量相关文档排得够不够靠前。两个指标要一起看只看一个容易偏。我一般会维护两个评测集一个核心集覆盖高频查询用来防止调优把常见场景调坏一个挑战集覆盖长尾、难例用来推动效果上限。每次改动链路两个集都跑一遍确保没有回退。8. 我在实际项目里踩过的几个坑聊了这么多方法论最后分享几个实操中踩过的坑都是文档里不会写但实际会遇到的。第一个坑重排序模型和 embedding 模型不匹配。有一次我换了一个新的 embedding 模型检索召回率上去了但重排序后的最终效果反而下降了。排查后发现新的 embedding 模型返回的 top 20 里相关文档的排名分布和旧模型不一样而重排序模型是在旧模型的候选分布上调的阈值换模型后阈值就不适用了。教训是换任何一个环节的模型都要重新跑评测不能想当然认为其他环节不用动。第二个坑BM25 的字段权重设反了。有个项目里文档的正文里经常引用标题导致标题词在正文里也高频出现BM25 的字段权重设了title^3 content^1后效果反而变差因为正文里的标题词被重复计权了。后来改成先去掉正文里的标题重复再设权重才恢复正常。这个坑提醒我字段权重不是设了就有效得看实际语料的特点。第三个坑元数据过滤把召回杀死了。有个场景用户查询里经常带时间我一开始把时间过滤设得很严结果很多相关文档因为时间标签不准被过滤掉了。后来改成时间过滤只作为软条件在重排序阶段给符合时间范围的文档加分而不是硬过滤效果好了很多。硬过滤适合标签准确的场景标签不准的时候要用软条件。第四个坑查询改写引入幻觉。用 LLM 改写查询时模型有时会脑补出用户没问的信息。比如用户搜部署流程模型改写成Kubernetes 集群部署流程但用户其实想问的是传统虚拟机的部署。这种幻觉改写会把检索带偏。解决办法是在改写 prompt 里明确要求只补全上下文不添加用户未提及的信息并且保留原始查询并行检索。第五个坑忽略冷启动。新文档入库后向量索引和 BM25 索引都需要时间更新这期间新文档检索不到。如果业务对时效性要求高要用支持实时更新的索引方案或者对新文档做特殊处理比如临时提升权重。这些坑的共同点是它们都不是算法问题而是工程问题。RAG 检索链路的调优算法占三成工程占七成。把工程细节做扎实比换更先进的模型往往更有效。9. 关于大厂为什么不用纯向量检索的几句实在话回到标题的问题。大厂的 RAG 不用纯向量检索不是因为向量检索不好而是因为真实业务的查询需求是多样的没有任何单一检索方式能覆盖所有需求。向量检索解决语义匹配BM25 解决精确匹配重排序解决精度查询改写解决表达鸿沟元数据过滤解决结构化条件。这些手段各司其职组合起来才能覆盖真实场景。而且大厂的场景往往更复杂文档量大、查询类型多、延迟要求严、成本敏感。这些约束逼着他们必须把每个环节都做精细不能指望一个向量检索包打天下。小团队虽然场景简单些但道理是一样的——只要你开始遇到某些查询搜不准的问题就该考虑在纯向量检索之外加东西了。我个人的建议是不要一上来就搭全套链路那样复杂度和维护成本都太高。先从纯向量检索开始遇到具体问题再加对应的手段。搜不准精确词加 BM25排序不准加重排序查询太短加改写有结构化条件加元数据过滤。每一步都解决一个具体问题每一步都有评测支撑。这样搭出来的链路才是真正适合你场景的而不是照搬别人的架构。