1. 从一个被问烂了的问题说起如果你最近半年在搞大模型应用大概率绕不开 RAG 这个词。招聘 JD 上写着“熟悉 RAG 检索增强生成”技术群里天天有人讨论 chunk size 设多少、embedding 模型选哪个、向量库用哪家。但我发现一个很有意思的现象真正把 RAG 做到线上稳定跑的大厂团队几乎没有人用纯向量检索。这话不是拍脑袋。我前后参与过三个不同规模的 RAG 项目从内部知识库问答到面向用户的智能客服踩过的坑足够写一本小册子。最开始我也是“向量检索一把梭”的信徒——文本切块、embedding、存向量库、余弦相似度召回流程干净利落Demo 效果惊艳。但一上真实流量问题就来了用户问“上个月的报销标准改了吗”纯向量检索给我召回一堆“报销流程说明”“差旅费管理规定”就是找不到那条“2024年3月修订”的具体条款。用户问一个精确的产品型号向量检索返回的是语义相近但型号完全不同的文档。这就是纯向量检索的命门它擅长“意思差不多”但搞不定“必须是这个”。所以这篇内容我想把这件事彻底讲透。为什么大厂 RAG 从不用纯向量检索不是因为向量检索不好而是因为单一检索范式有结构性缺陷。我会从检索原理、混合检索架构、重排序、查询改写、工程落地几个层面拆开讲每个环节都配上我实际用过的参数和踩过的坑。适合正在做 RAG 落地的工程师、正在选型的技术负责人以及那些 Demo 跑得挺好但一上线就翻车的同行。看完你至少能明白你的 RAG 该在哪个环节加什么而不是盲目堆向量库。2. 纯向量检索到底强在哪、又死在哪2.1 向量检索的本质语义空间的近似匹配先把原理说清楚。向量检索的核心是把文本通过 embedding 模型映射到一个高维空间语义相近的文本在这个空间里距离更近。你查“如何申请年假”它能把“年休假申请流程”召回来哪怕这两个字符串一个字都不重叠。这是传统关键词检索做不到的也是向量检索最大的价值。我用过一个内部技术文档库大概两万多个 chunk用某开源 embedding 模型做向量化top-5 召回在语义类问题上的准确率能到 80% 左右。这个数字在 Demo 阶段非常好看。但注意这是“语义类问题”一旦问题类型变了表现就断崖式下跌。向量检索的相似度计算无论用余弦相似度还是内积本质都是在算两个向量在高维空间里的“方向接近程度”。这个机制决定了它对语义漂移很敏感。什么叫语义漂移就是两段文本在字面上高度相关但在向量空间里被拉远了或者反过来字面无关但语义相近的被拉近了。embedding 模型不是万能的它的训练目标决定了它更关注“主题相似”而非“事实精确”。2.2 三个让纯向量检索翻车的真实场景我整理了三类最典型的翻车场景都是实际遇到过的。第一类精确匹配需求。用户问“X2000 型号的额定功率是多少”。向量检索会把“X2000 产品手册”“X2000 系列介绍”“功率参数说明”都召回来但很可能把“X3000 的功率”也带进来因为这两个型号在语义空间里太近了。用户要的是一个精确的数字你给他一堆相关文档他得自己翻。这种场景下关键词检索比如 BM25反而能精准命中“X2000”这个 token。第二类否定和条件查询。用户问“哪些情况不能申请退款”。向量检索对“不能”这种否定词的处理很弱因为 embedding 模型在训练时否定句和肯定句的向量距离往往很近。“可以申请退款”和“不能申请退款”在语义空间里可能就隔了一点点。结果就是召回一堆“退款条件”的文档但分不清哪些是允许哪些是禁止。第三类时效性和版本敏感。用户问“最新的差旅标准”。向量检索没有时间概念它不知道哪个 chunk 是“最新”的。如果知识库里有 2022、2023、2024 三个版本的标准它可能把三个都召回来而且排序还不一定对。这时候你需要的是元数据过滤加关键词匹配而不是纯语义。我把这三类问题整理成了一张对照表方便你判断自己的场景问题类型纯向量检索表现根因更适合的检索方式语义相近但事实不同容易混淆向量空间主题聚类关键词精确匹配否定/条件查询经常失效否定词向量距离近关键词规则时效/版本敏感无法区分无时间元数据感知元数据过滤关键词专有名词/型号召回噪声大token 级信息丢失BM25/倒排索引长尾低频词召回率低训练语料覆盖不足关键词兜底这张表是我踩了无数次坑之后总结的。你会发现纯向量检索的短板集中在“精确性”和“可控性”上而这恰恰是企业级应用最看重的。2.3 一个容易被忽略的数学细节再说一个很多人没注意到的点向量相似度的分数分布。余弦相似度的值域是 [-1, 1]但实际文本 embedding 的相似度往往集中在 0.6 到 0.95 之间。这意味着什么意味着 top-1 和 top-5 的分数差距可能只有 0.02。你设一个阈值 0.8 来过滤结果要么全过要么全不过阈值根本卡不住。我实测过一个场景同一个 query 下正确文档的相似度是 0.847错误文档是 0.831。差了 0.016。你靠这个分数做排序基本等于抛硬币。这就是为什么大厂要在向量召回之后加一个重排序rerank阶段用交叉编码器cross-encoder重新算相关性。向量检索负责“广撒网”rerank 负责“精挑拣”这个组合才是标配。3. 大厂真正在用的混合检索架构3.1 混合检索的核心思想让不同的检索器各司其职混合检索Hybrid Retrieval这个词听起来高大上说白了就是别指望一个检索器解决所有问题让关键词检索和向量检索各干各擅长的活然后把结果融合。关键词检索通常是 BM25 或其变体擅长什么精确 token 匹配、低频词、专有名词、否定词。它的打分基于词频和逆文档频率一个词在文档里出现得越多、在整个语料里出现得越少得分越高。这个机制天然适合“X2000”“2024年3月”“不能”这类查询。向量检索擅长什么语义泛化、同义替换、跨语言、模糊意图。用户说“我想请个假”它能召回“休假申请流程”哪怕字面不重叠。把两者结合召回率能提升一大截。我做过对比测试同一个知识库纯向量 top-10 召回率 72%纯 BM25 top-10 召回率 65%混合检索 top-10 召回率能到 89%。这个提升在真实业务里就是“能用”和“不能用”的区别。3.2 融合策略RRF 为什么成了事实标准混合检索的关键问题是两路召回的结果怎么合并最简单的做法是加权求和但权重很难调而且两路分数的量纲不一样BM25 分数可能是 12.3余弦相似度是 0.85直接加权没有意义。目前业界最常用的融合算法是RRFReciprocal Rank Fusion倒数排名融合。它的公式很简单RRF_score(d) Σ 1 / (k rank_i(d))其中rank_i(d)是文档 d 在第 i 路召回中的排名k是一个平滑常数通常取 60。这个公式的妙处在于它只看排名不看原始分数天然解决了量纲不一致的问题。而且排名靠前的文档会被显著加权排名靠后的影响很小。我实际用下来k 取 60 是个比较稳的默认值。k 太小比如 10头部文档权重过高容易受单路召回噪声影响k 太大比如 100排名差异被抹平融合效果变差。你可以从 60 开始调根据业务反馈微调。用 Python 实现 RRF 大概长这样def rrf_fusion(vector_results, bm25_results, k60): scores {} for rank, doc_id in enumerate(vector_results): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank 1) for rank, doc_id in enumerate(bm25_results): scores[doc_id] scores.get(doc_id, 0) 1 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)这段代码我用了很多次简单可靠。注意rank 1是因为排名从 0 开始而 RRF 公式里 rank 通常从 1 开始。3.3 检索器选型BM25 不是唯一选择关键词检索这一路BM25 是最经典的但也不是唯一。我见过几种不同的做法BM25Elasticsearch/Lucene 内置最成熟工程上最稳支持中文分词需要配 IK 分词器或类似方案。适合大多数场景。Splade 等学习型稀疏检索用模型生成稀疏向量兼顾关键词精确性和语义泛化。效果比 BM25 好但工程复杂度高推理成本也高。n-gram 匹配对短查询和专有名词特别有效实现简单可以作为 BM25 的补充。我的建议是如果没有特殊需求BM25 起步就够了。别一上来就上学习型稀疏检索那个调优成本很高而且收益在多数场景下没有想象中大。先把混合检索的框架搭起来跑通再优化。3.4 一个完整的混合检索流程我把实际用的流程画成文字版方便你对照实现用户 query 进来先做查询改写后面会细讲生成 1-3 个变体。每个变体分别走向量检索和BM25 检索各取 top-20。用RRF 融合两路结果得到 top-20 的候选集。用rerank 模型对候选集重新打分取 top-5。把 top-5 的 chunk 拼进 prompt送给大模型生成答案。这个流程里向量检索和 BM25 是并行的RRF 是轻量级的rerank 是重头戏。整个链路延迟大概在 200-500ms取决于 rerank 模型大小和候选集数量线上完全可接受。4. 重排序被低估的 RAG 质量杠杆4.1 为什么召回之后必须 rerank前面说了向量相似度的分数区分度很低top-1 和 top-5 可能只差 0.02。这意味着召回阶段给你的排序基本不可靠。rerank 的作用就是用更精细的模型重新算相关性。召回阶段用的模型双编码器bi-encoder是把 query 和 document 分别编码成向量然后算相似度。这个架构快但精度有限因为 query 和 document 在编码时没有交互。rerank 阶段用的模型交叉编码器cross-encoder是把 query 和 document 拼在一起送进模型让它们充分交互精度高很多但速度慢所以只能用在少量候选上。这个“先粗后精”的思路和推荐系统里的“召回-排序”两阶段是一模一样的。大厂做推荐做了十几年这套架构早就验证过了。RAG 本质上也是一个检索排序问题自然沿用同样的思路。4.2 rerank 模型怎么选目前主流的 rerank 方案有几类开源交叉编码器比如 BGE-reranker 系列、Cohere rerank 的开源替代。效果不错可以本地部署成本可控。商业 rerank API按调用量计费省事但长期成本高而且数据要出域很多企业不接受。LLM 做 rerank直接用大模型给候选文档打分。效果最好但延迟和成本都高适合对质量要求极高的场景。我实测下来BGE-reranker-base 在中文场景下的效果已经相当能打推理延迟在 50ms 左右batch size 20GPU 推理。如果你的场景对延迟不敏感可以上 large 版本效果更好。这里有个经验rerank 的候选集不要太大20-30 个就够了。候选集太大延迟线性增长而且收益递减。我试过把候选集从 20 加到 50最终 top-5 的准确率只提升了 2%但延迟翻了一倍多。不划算。4.3 rerank 的阈值策略rerank 之后你需要决定哪些文档真正送进 prompt。这里有个坑不要把所有 top-k 都塞进去。如果 rerank 分数普遍很低说明这批文档都不相关硬塞进去只会让大模型产生幻觉。我的做法是设一个动态阈值取 rerank 最高分然后保留分数在最高分 85% 以上的文档最多 5 个。这样既能保证相关性又能避免噪声。如果最高分本身就很低比如低于某个绝对阈值那就直接返回“没有找到相关信息”而不是硬答。这个策略在客服场景特别重要。用户问一个知识库里根本没有的问题纯向量检索会召回一堆“看起来相关”的文档大模型基于这些文档编一个答案用户信以为真。加了 rerank 和阈值之后这种情况能减少 70% 以上。5. 查询改写让检索器听懂人话5.1 用户 query 和文档语言之间的鸿沟用户提问的方式和文档写作的方式往往不一样。用户问“这个月工资怎么还没到”文档写的是“薪资发放时间及异常处理流程”。向量检索能处理一部分这种差异但不够。查询改写Query Rewriting就是在这中间搭桥。查询改写有几个层次同义扩展把“工资”扩展成“薪资、薪酬、薪水”。意图澄清把模糊 query 改写成明确的检索 query。多查询生成生成多个不同角度的 query分别检索后融合。对话历史融合多轮对话里把历史上下文融进当前 query。5.2 多查询生成的实际效果我重点说说多查询生成Multi-Query这是我觉得性价比最高的改写策略。做法很简单用一个小模型或者大模型的一次调用把用户 query 改写成 3 个不同表述的 query分别检索然后 RRF 融合。比如用户问“报销要多久到账”生成的三个 query 可能是“报销到账时间”“费用报销处理周期”“报销款项发放时效”这三个 query 分别检索能覆盖到不同表述的文档。实测下来多查询生成能把召回率再提升 10-15 个百分点。代价是检索次数变成 3 倍延迟增加但如果你用并行检索延迟增加其实很有限。代码上大概是这样def generate_queries(original_query, llm_client): prompt f请将以下问题改写成3个不同表述的检索查询每行一个 问题{original_query} 查询 response llm_client.generate(prompt) queries [q.strip() for q in response.split(\n) if q.strip()] return [original_query] queries[:3]注意改写用的模型不需要太大7B 级别的模型就够用。我用过一个 3B 的模型做改写效果和 70B 的差别不大但延迟低了一个数量级。5.3 查询改写的注意事项有几个坑要避开别改得偏离原意。改写模型有时候会“过度发挥”把“退款”改成“退货”这就跑偏了。建议在 prompt 里强调“保持原意”。别生成太多 query。3-5 个就够了再多收益递减延迟线性增长。保留原始 query。改写后的 query 是补充不是替代。原始 query 一定要参与检索否则可能丢掉最直接的匹配。6. 工程落地从 Demo 到线上的那些坑6.1 分块策略比 embedding 模型更重要很多人花大量时间选 embedding 模型却忽略了分块chunking策略。我的经验是分块策略对最终效果的影响比 embedding 模型选型大得多。固定长度分块比如 512 token是最简单的但会切断语义单元。一个完整的条款被切成两半检索到一半也没用。更好的做法是按语义边界分块按段落、按标题、按列表项。如果文档有结构Markdown、HTML优先按结构分。我实际用的策略是先按标题层级切分如果某个 section 超过 800 token再按段落切如果段落还超才按固定长度切。每个 chunk 前面加上所属标题的路径比如“差旅管理 报销标准 国内差旅”。这个路径信息在检索时很有用能提供额外的上下文。另外chunk 之间要有重叠。我一般设 10-15% 的重叠防止关键信息正好落在边界上被切断。6.2 元数据过滤被低估的精确性武器前面提到时效性和版本敏感的问题解法就是元数据过滤。每个 chunk 存的时候带上时间、版本、部门、文档类型等元数据。检索时先按元数据过滤再做向量和关键词检索。比如用户问“最新的差旅标准”你可以先过滤出version latest的 chunk再在里面检索。这样就不会召回旧版本了。元数据过滤在 Elasticsearch 里就是 filter 查询在向量库里通常也支持。关键是在检索前过滤而不是检索后过滤。检索后过滤会导致召回数量不足因为过滤掉的文档已经占用了 top-k 名额。6.3 缓存和降级线上稳定的保障线上系统必须考虑缓存和降级。RAG 的链路很长任何一环出问题都会导致整个请求失败。查询缓存相同的 query 直接返回缓存结果命中率在客服场景能到 30% 以上。检索结果缓存query 改写后的检索结果可以缓存因为改写是确定性的。降级策略如果 rerank 服务挂了直接跳过 rerank用 RRF 融合结果如果向量库挂了降级到纯 BM25。保证系统始终能返回结果哪怕质量下降。我踩过最大的坑就是没做降级。有一次向量库集群扩容短暂不可用整个问答系统直接 500。后来加了降级逻辑向量库挂了自动切 BM25用户基本无感知。6.4 评估没有评估就没有优化最后说评估。RAG 系统最怕的就是“感觉还行”没有量化指标就没法优化。我建议至少跟踪这几个指标指标含义目标值召回率ktop-k 里包含正确文档的比例85%精确率ktop-k 里相关文档的比例60%MRR正确文档的平均倒数排名0.7答案准确率人工评估答案正确的比例80%拒答率正确拒答无相关信息时的比例90%评估集要覆盖各种问题类型语义类、精确类、否定类、时效类。每类至少 50 条。每次改动检索策略都跑一遍评估集看指标变化。别凭感觉调参。7. 几个常见问题的排查思路7.1 召回不准怎么办先定位是召回问题还是排序问题。把 top-20 的召回结果打出来看如果正确文档根本不在里面是召回问题如果在里面但排名靠后是排序问题。召回问题检查分块策略、embedding 模型、查询改写。排序问题加 rerank调 RRF 的 k 值。7.2 大模型幻觉严重怎么办幻觉通常是因为 prompt 里塞了不相关的文档。检查 rerank 阈值把低分文档过滤掉。另外在 prompt 里明确要求“只基于提供的文档回答不知道就说不知道”。7.3 延迟太高怎么办先测各阶段耗时。通常是 rerank 和 LLM 生成占大头。rerank 可以换小模型、减候选集LLM 生成可以换小模型、流式输出。检索阶段一般不是瓶颈。7.4 多轮对话效果差怎么办多轮对话的关键是 query 改写把历史上下文融进当前 query。比如用户先问“差旅标准”再问“那住宿呢”第二个 query 要改写成“差旅住宿标准”。这个用 LLM 做很简单但一定要做。8. 我个人在实际操作中的体会说了这么多最后分享几点个人体会。第一别迷信单一技术。向量检索、BM25、rerank、查询改写每个都有它的位置。大厂的 RAG 不是用了什么黑科技而是把每个环节都做扎实了组合起来效果就好。第二工程细节决定成败。分块策略、元数据设计、缓存降级这些看起来不“AI”的东西恰恰是线上稳定的关键。我见过太多团队模型选得很 fancy但分块一塌糊涂效果还不如老老实实做 BM25。第三评估要趁早。别等系统上线了才想起来做评估。从第一天就建评估集每次改动都跑一遍。这样你才知道自己的优化到底有没有用。第四从简单开始。如果你刚开始做 RAG别一上来就搞多查询生成加 rerank 加混合检索。先用 BM25 加向量做混合检索跑通再说。效果不够再加 rerank还不够再加查询改写。每一步都验证收益别盲目堆组件。这个领域变化很快新的 embedding 模型、新的 rerank 方案、新的检索架构层出不穷。但底层的检索原理和工程思路是相对稳定的。把原理搞透把工程做扎实比追新更重要。
