混合检索值不值——值，但条件很具体。最亏的做法我见过一次：知识库里一半是产品型号和工单编号，先上纯向量，召回一直不对，回头再补 BM25，索引重建了两遍。反过来也有——几千条 FAQ 的库硬上混合，两套索引两套调参，收益几乎看不见。分界线不在库的大小，在语料里有多少"必须字面命中"的词。
这周没检索的新料，只有一篇沾边
ArXiv 这周基本被 agent 安全、监控、评测占满，HN 首页也差不多，跟检索不搭。唯一能接上的是 Accurate but Not Humble：检索到的证据和模型先验冲突时，模型会不会改口。答案不太好——经常不改。
这篇讲的是模型行为，但顺手戳了一件事：检索回来的东西，模型分不清它是证据还是"读起来像"。关键词命中的价值就在这儿。BM25 命中一个型号，那是硬事实，文档里确实有这串字符。向量召回给的是相似度，两个分数挨得很近，为什么这个排前面那个排后面，谁也解释不了。
向量对没见过的词，基本无能为力
Embedding 是把 token 映射到语义空间。模型训练时见过多少次某个词，直接决定它在空间里的位置稳不稳。产品型号、料号、订单号、罕见人名、内部缩写——这些在预训练语料里出现次数极少，向量位置就飘。更麻烦的是，"X200-PRO"和"X200-PLUS"这种只差一个后缀的，向量空间里几乎重合，但业务上完全是两个东西，退货地址都能不一样。
BM25 的机制正好相反。它不看语义，只看词频和逆文档频率。罕见词恰恰是 IDF 最高的那批，也就是它最擅长捞的那批。这不是谁强谁弱，是两套机制覆盖的词类不一样。拿向量去查型号，等于让一个只读散文的人去对账。
反面意见我认真想过：小库纯向量确实够
几千条的库，专有名词的候选集本来就小。top-k 一拉，相关段落基本都进来了，混淆的机会少，向量那点模糊性被候选集规模兜住了。这时候硬上混合，多出来的是一整套运维：两路索引、两套分词、两套重建流程、分数融合还得调。
中文还有个额外的坑——BM25 要先切词，切错了关键词那一路直接废掉，而中文分词在型号和缩写上的出错率不低。所以"小库别上混合"这个说法我认，但前提是库真的小，而且语料以自然语言为主。
我的判断线：数专有名词密度，别拍脑袋
不给阈值，给方法。从真实日志里抽一批 query，人工标一下：有多少条里面含型号、编号、人名、缩写这类"字面必须命中"的 token。这个比例得你自己测出来才算数。如果这类 query 占了相当一部分，直接上混合，别先跑纯向量再回头改架构——改架构的成本比一开始就搭两路高得多。
怎么确认：拿纯向量跑这批 query，看 badcase 是不是集中在专有名词上。如果错的全是型号，那就是机制问题，不是模型不够好，也不是 prompt 没写好，调参调不出来。
融合先别急着上 rerank
RRF 是最省事的起步方式，几乎不用调参，两路结果直接排。跑通了再看要不要加 rerank——它效果好，但延迟和成本是实打实的，而且 rerank 模型对型号这类 token 也未必比 BM25 敏感。我的顺序是：BM25 + 向量 + RRF，观察一段时间 badcase，再决定加不加。
这套东西没什么新鲜的，也不酷。但按我现在看，只要语料里型号编号多，混合就是省事的那个选择，不是更复杂的那个。也许等 embedding 模型对罕见 token 的处理再好一代，这话会被打脸——至少现在还没到。