大模型技术博客与论文库怎么做混合检索——BM25 + 向量的工程落地

做大模型方向的技术博客/论文库检索时，纯向量方案经常会"翻车"：用户搜"LLaMA-3 的 context length 是多少"，向量召回回来的却是一堆讲"长上下文综述"的泛文章，因为没有一篇标题恰好语义匹配"context length=8k"这种精确事实。这个问题的解法是混合检索（Hybrid Search）：用 BM25 补精确词匹配，用向量补语义，两路融合。

一、为什么纯向量不够

向量检索擅长"语义相近"，但在两类query上弱：

• 精确实体/参数：模型名（Qwen、DeepSeek）、API 参数（temperature=0）、版本号，这些靠字面匹配最准。
• 稀有组合：同时出现两个冷门词时，向量容易被高频近义项稀释。

BM25 恰恰擅长字面命中。两路结合，召回的上限明显抬升。

flowchart LR
    Q[查询] --> B[BM25 召回 TopN]
    Q --> V[向量召回 TopN]
    B --> M[融合: RRF / 加权]
    V --> M
    M --> R[Rerank]
    R --> A[返回]

二、融合策略：先 RRF 再重排

我们用 RRF（Reciprocal Rank Fusion）做初融合，它不依赖两路分数量纲对齐，比直接加权更稳：

三、三个实践要点

1. RRF 比加权更稳：加权需要两路分数归一化，量纲不同易失衡；RRF 只看排名，工程上省心。
2. 术语表做 lexicon boost：对模型名/参数做同义词扩展（"ctx len"→"context length"），BM25 侧命中率进一步提升。
3. 融合后务必接 Reranker：混合检索解决"召回全不全"，Reranker 解决"排得准不准"，二者职责不同，别省。

四、什么时候可以不用混合

如果语料全是长文观点类、几乎没有精确参数（比如方法论博客），纯向量够用；一旦语料里模型名/API/版本/报错码密布，混合检索几乎是必选项。

五、FAQ

Q1：RRF 和加权求和选哪个？

优先 RRF。它不要求两路分数同量纲，工程落地最省心；加权需额外归一化且敏感。

Q2：BM25 要单独建索引吗？

要。可用 rank_bm25（轻量）或 Elasticsearch（生产），和向量库并存，查询时双路并发。

Q3：向量侧用哪种 embedding？

通用中英双语模型即可，大模型博客以中文为主时选中文优化模型；术语密集场景可加领域微调。

Q4：融合后还要 Reranker 吗？

建议要。混合检索管"召回覆盖"，Reranker 管"精准排序"，职责互补。

Q5：参数/版本号总变怎么办？

把它们作为高权重 lexicon 词，并在入库时结构化抽取（如 context_length: 8192），检索时优先走结构化过滤。

作者：默然｜数智化转型网