混合检索怎么配：向量加关键词不是简单相加
数据截至 2026-07，规范与各项目能力以官方文档当前版本为准。
混合检索能不能起作用，关键不在于你有没有同时开向量和关键词两路，而在于两路结果用什么规则合成一份榜单。把两个分数直接相加是最常见也最容易失败的做法——两路分数的量纲、分布、稳定性完全不同，直接相加等于让其中一路悄悄主导了全部排序，而你从配置文件上看还以为它们各占一半。
有个误解流传得很广：混合检索被当成一个”打开就变好”的开关，只要在配置里把 hybrid 设成 true，效果就应该比纯向量强。实际跑下来经常不是这样，很多团队打开混合后指标反而掉了，然后得出”混合检索没用”的结论。真实原因通常是融合方式没配对，或者关键词那一路的分词、字段权重根本没调过，等于往榜单里注入了噪声。这篇就把中间这几个环节拆开讲。
两种检索各自在什么地方失手
要配好混合，先得知道你在拿两个什么东西互相补。
向量检索（稠密检索）比的是语义相近。用户问”报销超期了还能交吗”，文档里写的是”逾期费用申请的处理办法”，字面几乎没有重合，向量检索能捞回来，这是它的价值所在。它的失手场景也很固定：一是精确标识符，比如产品型号、合同编号、错误码、API 参数名，这类字符串对嵌入模型来说信息密度极低，“ERR-4021” 和 “ERR-4012” 在向量空间里几乎贴在一起；二是低频专有名词，公司内部的项目代号、自造缩写，嵌入模型训练时没见过，编码结果基本是随机方向；三是否定和限定词，“不适用于试用期员工”和”适用于试用期员工”的向量距离往往小得离谱。
关键词检索（稀疏检索，常见实现是 BM25 一类的词频算法）比的是字面命中。它对上面那三类场景恰好很稳：型号、编号、缩写只要拼对了就能精确命中，而且命中理由可解释，出问题时你能一眼看出是哪个词匹上了。它的失手场景同样固定：同义换说法就废，用户说”离职”文档写”解除劳动合同”，一个词都对不上；中文分词是隐性风险，分词器把”数字员工”切成”数字/员工”还是当成一个词，直接决定这条查询能不能命中，而这一层通常藏在检索引擎默认配置里，很少有人去看。
所以混合检索真正在做的事情是：用关键词兜住向量的精确性短板，用向量兜住关键词的表达多样性短板。这两路是互补关系，不是加强关系——指望两个都对的时候分数更高，收益远小于指望其中一个把另一个漏掉的结果捞回来。这个认知会直接影响下面的融合方式选择。
融合方式：分数加权和排名融合，选哪个
把两路结果合成一份榜单，主流做法有两种，差别比想象中大。
第一种是分数加权。先把两路的原始分各自归一化到同一区间，再按权重加权求和。这种做法的前提是分数可比，而这恰恰是最难保证的一点。向量检索给出的余弦相似度在多数语料上分布很挤，前十条可能都在一个很窄的区间里；关键词的相关性分数则没有天然上界，一条文档因为某个稀有词重复出现就可能拿到远高于其他条目的分。如果你只是按每次查询的最大最小值做归一化，那么当某一路这次召回质量特别差时，它最差的那批结果照样会被拉伸到接近满分，混进最终榜单。分数加权不是不能用，但它要求你对分数分布心里有数，并且愿意为不同类型的查询做区分处理。
第二种是倒数排名融合（Reciprocal Rank Fusion，常缩写为 RRF）。它干脆不看分数，只看名次：每一路给它的第 n 名贡献一个 1/(k+n) 形式的分值，k 是个平滑常数，各家库的默认取值不一样，以你所用库的官方文档为准。所有路的贡献相加，得出最终排序。它的好处很直接——彻底回避了量纲问题，两路分数再怎么不可比也不影响结果，并且天然抑制了极端高分的影响，因为第一名和第二名的贡献差距是有限的。代价是它丢掉了分数里的置信度信息：一条被向量检索以极高相似度命中的文档，和一条勉强排到第一的文档，在 RRF 眼里是同一个待遇。
实践中的建议是：如果你还没有一套可靠的评估集，先用倒数排名融合。它的鲁棒性更好，配错了也不容易出灾难性结果，适合作为默认起点。等你有了评估集、能量化每次改动的收益之后，再考虑切到分数加权去榨那最后几个点——那时候你至少能看出改动是变好还是变坏。评估集怎么建、看哪些指标，可以参考 RAG 怎么评估？凭感觉调是调不出来的。
权重和候选数：两个最该动手调的旋钮
配混合检索时真正需要你做决定的参数不多，主要是下面这几个。
两路的权重比例。默认各占一半是个合理起点，但它几乎肯定不是你场景的最优值。判断方向的办法很朴素：翻一遍你的真实查询日志，看里面有多大比例含有型号、编号、错误码、专有缩写这类精确标识。这类查询占比高（比如售后知识库、设备手册问答），关键词那一路该加权；反过来如果用户提问基本是口语化的长句描述（比如政策制度咨询），向量那一路该占大头。不要靠感觉调，每次改完权重都用同一批评估问题跑一遍，把数字记下来。
每路的召回数量。融合之前，每一路各取多少条候选，这个数直接决定了”正确答案有没有进入候选池”。取得太少，某一路本来能在第 30 名捞到的正确答案根本没机会进入融合；取得太多，噪声变大，也会拖慢后面的重排。常见做法是每路取的数量明显大于最终要送进上下文的条数，融合去重后再交给重排模型收敛到最终几条。这里要注意去重逻辑：两路很可能召回同一个分块，如果去重时把它当成两条独立结果各自计分，那么”两路都命中”的文档会被重复加权，这有时是你想要的、有时不是，得看清楚你用的库是怎么实现的。
元数据过滤要放在哪一步。按部门、时间、文档类型做过滤，是放在检索之前（先缩小范围再检索）还是之后（检索完再筛）？这两种在多数向量库里性能差别明显。像 Qdrant 这类向量库提供了过滤与 payload 索引能力，还支持量化；有第三方测评称其在百万级以上向量规模下可以做到 50 毫秒以内的检索延迟——这是第三方口径而非官方指标，你自己的语料、硬件、过滤条件都会改变实际结果，只能拿来当”这条路走得通”的参考，不能当验收标准。
重排要不要加。混合检索解决的是召回问题，重排解决的是排序问题，两者不互相替代。如果你的现象是”正确答案根本没出现在候选里”，那是召回问题，该调混合；如果是”正确答案在候选第 15 名”，那是排序问题，该上重排。这两段的完整取舍顺序在 RAG 检索调优：嵌入、混合检索与重排的取舍 里讲得更细。
这些情况其实不用上混合检索
诚实地说，混合检索不是每个 RAG 系统都需要的，它带来的复杂度是实打实的：多一套索引、多一层融合逻辑、多几个要调的参数、排查问题时多一个变量。下面几种情况可以先不上：
- 语料里几乎没有精确标识符。纯叙述性的政策文档、培训材料、会议纪要，关键词那一路能补上的东西很有限。
- 查询高度同质。如果用户问法就那么十几种，与其配混合，不如直接做查询改写或者建一层常见问题的直答。
- 你的瓶颈根本不在检索段。这是最常见的误诊。如果你的 PDF 是扫描件、表格被解析成一团乱码、分块把一张表拦腰截断，那么无论怎么配检索，喂进去的内容本身就是错的。这种情况该回头解决解析问题，可以看 RAG 效果差？先确认瓶颈是不是在解析这一步。按瓶颈选工具而不是按名气选，这一点在 RAG 框架怎么选 里有更系统的说法。
反过来，明确该上混合检索的信号是：你能举出具体的失败案例，且这些案例里用户搜的是一个确定的字符串，而系统返回了一堆语义上”差不多”的东西。有这种案例在手，改动效果一试就知道。
落地顺序：一套不容易翻车的推进方式
给一个可执行的起点，四步：
- 先建评估集，再动配置。哪怕只有三五十条真实问题配上期望命中的文档，也比没有强。没有这一步，后面所有调整都说不清是变好还是运气。
- 纯向量跑一遍基线，把数字记下来。这是你后面所有对比的锚点。跳过基线直接上混合，等于放弃了判断收益的能力。
- 加上关键词那一路，用倒数排名融合，权重先各占一半。这一步先不动其他任何参数，单独看融合本身带来的变化。如果指标不升反降，先去查关键词那一路的分词和字段配置，而不是急着换融合方式。
- 再逐个调权重和候选数，每次只改一个。同时改两个参数、指标动了，你没法归因。这条听起来啰嗦，但它是混合检索调优里最容易被跳过、也最容易导致返工的一步。
关于工具选择：如果你的瓶颈明确在检索这一段，可调的旋钮多少就很重要。LangChain、Haystack、Cognita 这类框架在嵌入、混合检索、重排上暴露的可调项相对更多；如果瓶颈是版式复杂的 PDF、财报、法律文书这类解析难题，RAGFlow 在深度文档理解方向更对口；语料本身是有链接的结构化内容，图检索是另一条路。需要提醒的是，GitHub 上的关注度不代表适用性——截至 2026 年 1 月的第三方统计里，LangChain 约 12.5 万 star、RAGFlow 约 7 万、LlamaIndex 约 4.65 万、Haystack 约 2.4 万，这些数字反映的是社区活跃度，跟你这个场景合不合适是两回事。各项目的实际能力以官方文档当前版本为准。
还有一个容易被忽略的成本项：查询侧的处理会加延迟。有第三方基准指出，用 LangChain 的 LCEL 做复杂查询重写，相比直接检索会多出约 15% 到 20% 的延迟开销——这是第三方测得的数字、不是官方指标，量级上可以当作”查询改写不是免费的”这个判断的旁证。如果你的场景对首字延迟敏感，混合检索加查询改写加重排三层叠上去，总延迟要提前算清楚。
局限：混合检索解决不了的事
说几句它做不到的，免得期望放错地方。
混合检索不能修复错误的分块。如果一段答案被切分到了两个块里，两路检索谁也捞不出完整答案，融合再精巧也没用。
它不能替代查询理解。用户问了一个含混的问题，或者一句话里塞了三个问题，两路检索都会被带偏。这类问题要靠查询改写、拆分子问题来处理，属于检索的上游。
它会让排查变难。单路检索出问题时，你看一眼召回列表基本能判断原因；混合之后，一条不该出现的文档进了前三，你得先拆开看它在哪一路排第几、融合时拿了多少分。所以建议在日志里把每一路的原始名次都留下来，出问题时能直接翻。
最后，它不保证一定变好。有相当比例的场景在正确配置下混合检索的收益也就是几个百分点，未必值得那份复杂度。这个判断只能靠你自己的评估集给答案，别人的经验数字帮不上忙。
小结
向量和关键词是互补关系，混合检索的价值主要在于一路把另一路漏掉的结果捞回来，而不是两路都对时分更高。融合方式比是否开启混合更关键，没有评估集之前优先用倒数排名融合，它对分数量纲不敏感、配错了也不容易崩。权重和每路候选数是最值得动手的两个旋钮，但都必须在固定评估集上逐个验证，一次只改一个。语料里没有精确标识符、瓶颈其实在解析段的情况，先别急着上混合，那是另一个问题。所有参数与项目能力，以你所用工具的官方文档当前版本为准。