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

一个事实被埋在了关于混合检索的每一次技术分享里，直到最近才被数学完整地戳破——单个向量无法表达你需要的全部排序。不是因为模型不够大、维度不够高，而是它的数学形式本身就有一堵翻不过去的墙。而 BM25 恰好站在这堵墙的外面。所以混合检索的收益根本不是「语义补齐了关键词」这类说法，而是两条腿的失效模式在数学上完全无关。两个独立的黑天鹅联合出现的概率，比其中任何一个单独出现都低。这个洞察一旦建立，工业界很多看起来合理的选择就立刻变成了错误——融合函数的选型、参数调优、甚至「要不要混合」本身的判断，全都需要重新过一遍。这篇会从零写一个能跑的 C++ 混合检索引擎。先故意写错，让每个关键环节都当场崩掉，再一个一个修。全修完之后，你会有四种融合函数的完整对比、一套无需训练的调参法则，还有一条非常实用的判据：什么时候该用 RRF，什么时候必须换掉它，什么时候干脆别碰混合检索。中间我还会回答一个我被问过数十次、但几乎没人答对过的问题——把嵌入维度从 1024 加到 4096，能不能解决向量检索的型号搜索问题。内容不轻松，第 3 和第 6 节确实要动一点线性代数。但每一节都附带完整可运行的代码。代码本身比讲座的价值大得多。1. 一次找不到型号的检索事故——从这里开始看懂混合检索这个故事发生在我负责一套企业知识库的时候。下午 3 点，客服投诉说搜不到东西，工单标题是「为什么搜 R7-9700X 的 TDP 限制找不到官方文档」。检索系统返回的前十条全是通用散热白皮书、机箱风道选型指南。那篇叫《R7-9700X 平台功耗与散热配置说明》的文档排在第 47 位。而上线前的离线评测，