向量双塔编码器为什么无法替代 BM25 的稀有词 IDF：C++ 混合检索中从编码层到融合层的完整技术栈

一个事实被埋在了关于混合检索的每一次技术分享里，直到最近才被数学完整地戳破——单个向量无法表达你需要的全部排序。不是因为模型不够大、维度不够高，而是它的数学形式本身就有一堵翻不过去的墙。而 BM25 恰好站在这堵墙的外面。

所以混合检索的收益根本不是「语义补齐了关键词」这类说法，而是两条腿的失效模式在数学上完全无关。两个独立的黑天鹅联合出现的概率，比其中任何一个单独出现都低。这个洞察一旦建立，工业界很多看起来合理的选择就立刻变成了错误——融合函数的选型、参数调优、甚至「要不要混合」本身的判断，全都需要重新过一遍。

这篇会从零写一个能跑的 C++ 混合检索引擎。先故意写错，让每个关键环节都当场崩掉，再一个一个修。全修完之后，你会有四种融合函数的完整对比、一套无需训练的调参法则，还有一条非常实用的判据：什么时候该用 RRF，什么时候必须换掉它，什么时候干脆别碰混合检索。中间我还会回答一个我被问过数十次、但几乎没人答对过的问题——把嵌入维度从 1024 加到 4096，能不能解决向量检索的型号搜索问题。

内容不轻松，第 3 和第 6 节确实要动一点线性代数。但每一节都附带完整可运行的代码。代码本身比讲座的价值大得多。

1. 一次找不到型号的检索事故——从这里开始看懂混合检索

这个故事发生在我负责一套企业知识库的时候。下午 3 点，客服投诉说搜不到东西，工单标题是「为什么搜 R7-9700X 的 TDP 限制找不到官方文档」。

检索系统返回的前十条全是通用散热白皮书、机箱风道选型指南。那篇叫《R7-9700X 平台功耗与散热配置说明》的文档排在第 47 位。而上线前的离线评测，