向量检索找不到那个型号，混合检索和重排怎么搭

向量检索找不到那个型号，混合检索和重排怎么搭

用户问 SG-2048A 的替换型号是什么。知识库里明明有这份文档，向量检索返回的却是几篇讲产品线的综述。翻回去看，那份文档的标题里就有 SG-2048A，只是正文很短，讲得也不深。

这类漏检在业务知识库里天天发生，重灾区是型号、编号、人名、专有名词。语义向量擅长抓意思相近，对精确字串反而迟钝，因为 SG-2048A 和 SG-2048B 在向量空间里几乎是同一个点。

两路召回一起上

关键词检索补的正是这个短板。文档切块之后，除了建向量索引，也建一份倒排索引，用 BM25 这类算法做字面匹配。查询进来两路一起跑，一路按语义，一路按关键词，各自出一份候选列表。

两路的分数量纲不一样，不能直接相加。常用做法是倒数排名融合，不看分数看名次，某一路排第一的得分高，两路都排前面的累计更高。这个办法不用调权重，落地成本低，效果稳定。

权重还是想调的话，按查询类型分。用户输入里带型号、编号、引号，关键词那路权重提上去。输入是自然语言问句，语义那路为主。判断查询类型的规则可以写死几条，够用。

召回之后必须重排

两路召回各取二十条，合起来几十条，直接塞给模型太浪费。中间加一层重排，用一个更贵的模型对候选逐条打分，取前五。

重排模型的选择看预算。专门的交叉编码器精度好延迟低，适合量大；用大模型做重排，一条一条读，效果好但慢且贵，适合低并发高价值的场景。

重排的价值在长文档场景尤其明显。召回阶段为了不漏，切块切得碎，块和查询的语义相似度都差不多，谁更相关得看完整语义，这正是重排擅长的。

过滤要放在检索之前

时间范围、文档类型、权限归属这些条件，必须在检索前作为过滤条件下推，别检索完再筛。检索完再筛的问题是，前二十条里可能十九条都不满足条件，筛完只剩一条。

权限这点尤其要注意，不同用户能看的文档不同。过滤条件里必须带租户和权限范围，让检索层自己保证召回的都是有权限的内容，别指望后面再拦。

召回不足怎么办

检索结果的相关性分数都不高，说明知识库里可能真没有。这时候硬答最危险。

两种补救。一是查询改写，把用户的口语问题换成更适合检索的表述，或者拆成几个子问题分别检索。二是明确告知没找到，请用户补充信息。

任何时候都别让模型拿低相关度的内容硬编答案。宁可说没查到，也别给出一个看起来很像的错误结论。

调优看什么指标

召回率比准确率更值得盯。召回阶段的目标是不漏，反正后面有重排来筛。每次改动检索策略，用一批标注过的问题跑一遍，看目标文档有没有进前二十。

还有一个便宜的信号，用户点了重新生成或者追问换个说法，往往意味着这次检索没命中。把这个行为埋点统计，能找到一批需要补的文档。

结合系列

RAG 两篇讲的是整体流程和检索链路，这篇补上混合召回与重排这一层。上下文压缩篇的原则在这里同样适用，少而准的上下文比多而杂的更好，进去五条高相关的胜过二十条一般的。可观测性篇的 trace 要记录召回了哪些块、重排后留了哪些，否则调检索就是盲调。数据脱敏篇落到的那个出口，在这里也有对应，进模型的文档片段同样要过脱敏。