代码库知识库系列（07）：混合检索 BM25 + 向量——Q8 还是失败，而且总分退步了

Boss 关，第五次挑战如果你从第 03 篇一路读到这里，那你应该已经认识 Q8 这个老对手了。它是我们那 12 道测试查询里的第 8 道：process payment and create Stripe charge（处理支付并创建 Stripe 扣款）。它的 ground truth 有两个函数，其中一个calculate_order_total，我们已经追了整整四篇文章都没抓到。第 03 篇，向量检索基线，它漏了。第 04 篇，换了三种 chunking 策略，它还漏。第 05 篇，图增强检索总算把它捞回来了——代价是 Q1 退步，总分原地踏步。第 06 篇，把called_by结构信息编码进 embedding，相似度从 0.46 涨到 0.51，方向对，但推不过那堵词汇高墙，它又漏了。四篇，五次交手（第 04 篇试了三种切法），Q8 就像游戏里那个反复复活的 boss 关，你每次以为找到了破绽，它总能换个姿势再站起来。而这一篇，我带了业界公认的"终极武器"——BM25 关键词检索，把它和向量检索拧成一股绳，做成hybrid search（混合检索）。这套组合拳在无数生产系统里被验证为向量检索的最佳增强方案。逻辑很直白：向量检索靠语义，BM25 靠字面词频，两条路的失败模式不一样，理论上能互相补位。第 06 篇结尾我自己也是这么规划的——用两条正交的路盖住彼此的盲区，Q8 理应有救。先把结论摊开，免得你读到一半空欢喜一场：Q8 还是失败了。不仅如此，混合检索继承了 BM25 在另一道题上的退步，总分从 0.958 掉到了 0.931——比纯向量检索还差。但这次失败，是整个系列最有价值的一次。因为它不是"又一种方案没成"，而是——它彻底揭开了 Q8 的根因，量出了整条文本路线的边界在哪里。读完这一篇，你会明白为什么前面四篇的每一次失败都是必然的，为什么它们其实一直在做同一件事。先补两个概念：BM25 和 RRF在动手之前，花两分钟把两个关键词说清楚。BM25是信息检索领域的经典算法，你可以把它理解成"加了权重的关键词匹配"。它不理解语义，只数词频——查询里的词在某个文档里出现得越多、而这个词在整个语料里越稀有，这个文档的得分就越高。搜索引擎、Elasticsearch 的默认相关性排序，底层都是它。用一个类比：向量检索像一个读过很多书的语言学家，你说"收钱"，他知道你可能想找"结账"“扣款”“支付网关”；而 BM25 像一个一丝不苟的图书管理员，你说"收钱"，他就去翻哪本书里"收钱"这两个字出现得最多。语言学家懂意思但可能想多，管理员认死理但绝不会张冠李戴。RRF（Reciprocal Rank Fusion，倒数排名融合）是把多路检索结果合并成一个排序的方法。它不看每一路给出的原始分数（因为向量的余弦相似度和 BM25 的分数根本不在一个量纲上，没法直接加），只看排名。某个函数在向量结果里排第 2、在 BM25 结果里排第 5，RRF 就给它算1/(k+2) + 1/(k+5)的分，k是个平滑常数，业界标准取 60。谁在多路里都排得靠前，谁的融合分就高。RRF 的代码短得可爱：defrrf_fuse(ranked_lists:list[list[str]],k:int=60)-list[str]:"""Reciprocal Rank Fusion。k=60 是标准常数。"""scores:dict[str,float]={}forrankedinranked_lists:forrank,nameinenumerate(ranked):scores[name]=scores.get(name,0.0)+1.0/(k+rank+1)return