第十一章：检索范式：稀疏、稠密与后期交互¶

11.1 三种范式的本质区别¶

范式	文档表示	匹配依据	代表
稀疏检索	高维稀疏向量（词表维度，大部分为 0）	字面匹配 + 统计权重	BM25、TF-IDF
稠密检索	低维稠密向量（几百到几千维）	语义相似度	双塔 Embedding 模型
后期交互	每个 Token 一个向量	词级细粒度匹配	ColBERT 系

这三种范式不是简单的新旧替代关系，更准确的说法是：它们分别擅长不同类型的匹配。

11.2 稀疏检索：不要低估它¶

11.2.1 BM25 在做什么¶

BM25 的打分逻辑可以拆成三个直觉：

Query 中的词在文档里出现得越多，越相关（词频）；
一个词在整个语料中越罕见，它的匹配越有价值（逆文档频率）——「的」匹配上不说明什么，「XR-2100」匹配上意义重大；
长文档天然容易包含更多词，需要按长度归一化，否则长文档会占便宜。

打分形式大致是：

\[ \mathrm{score}(q, d) = \sum_{t \in q} \mathrm{IDF}(t) \cdot \frac{f(t, d) \cdot (k_1 + 1)}{f(t, d) + k_1 \cdot \left(1 - b + b \cdot \frac{|d|}{\mathrm{avgdl}}\right)} \]

其中 \(f(t,d)\) 是词 \(t\) 在文档 \(d\) 中的频次，\(|d|\) 是文档长度，\(\mathrm{avgdl}\) 是平均文档长度，\(k_1\) 和 \(b\) 是可调参数。

公式本身不是重点，关键是词频、逆文档频率和长度归一化这三个因素。

11.2.2 BM25 的不可替代之处¶

在专业术语密集的领域，BM25 经常优于稠密检索。

具体场景：

产品型号、错误码、API 名：ERR_CONN_REFUSED、XR-2100——这些在 Embedding 模型的训练数据里出现极少，向量表示很差；
人名、机构名、专有名词：语义空间里区分度低；
域外领域（医疗、法律、企业内部黑话）：Embedding 模型没见过这些分布；
精确短语匹配：用户明确要找某个确切说法。

而且 BM25 还有三个工程优势：无需训练、无需 GPU、新文档写入即可检索（不需要向量化）。

BM25 不是过时技术，在混合检索里通常都是不可省略的一路。

11.2.3 学习式稀疏检索¶

有一类方法（如 SPLADE）试图兼顾两者：用模型学习稀疏表示，在保留倒排索引效率的同时做词项扩展（把「汽车」自动扩展出「车辆」「轿车」等相关词的权重）。

这类方法思路清晰，但在工程实践中，它已经被「BM25 + 稠密检索 + Rerank」这个更简单的组合实质性取代。原因是后者的每个组件都更成熟、更容易调优、生态也更完整。

把它当作背景知识即可，不宜写成主流生产方案。

11.3 稠密检索：语义匹配¶

原理已在第六章展开，这里只强调它的失败模式：

失败模式	例子
罕见词表示差	型号、错误码、内部术语
否定语义弱	「不含糖的饮料」可能召回含糖饮料
数值与精确条件不敏感	「超过 500 元的报销」中的数值约束
域外泛化差	通用模型在专业领域表现下降
短 Query 信息不足	两三个词的 Query 语义模糊

这些失败模式恰好是 BM25 的强项。 混合检索之所以成立，不是因为“两个都用通常更好”这种泛化表述，而是因为两者的失败模式互补。

11.4 后期交互：中间路线¶

第六章 6.3.4 已介绍原理。这里补充它在检索范式中的定位：

flowchart LR
    A[稀疏 BM25<br/>字面精确] --- B[稠密双塔<br/>语义相似]
    B --- C[后期交互 ColBERT<br/>词级语义匹配]
    C --- D[Cross-Encoder<br/>完整交互]

    A -.-> A1[快 无需训练<br/>不懂同义]
    B -.-> B1[快 懂同义<br/>细粒度弱]
    C -.-> C1[较快 兼顾两者<br/>存储成本高]
    D -.-> D1[最准<br/>无法预计算]

后期交互的价值在于：它既保留了词级的精确匹配能力（缓解稠密检索的罕见词问题），又具备语义匹配能力（缓解 BM25 的同义词问题），而且文档表示仍可离线预计算。

代价是存储：文档不再是一个向量，而是几百个。 这个几十倍的开销是它没有大规模普及的主要原因。

11.4.1 视觉文档检索¶

后期交互在多模态方向上有一个重要衍生：直接对文档页面图像做多向量嵌入，用视觉语言模型编码页面，完全绕开 OCR 和版面解析（第三章 3.5 节）。

在版面复杂、图表密集的文档上，公开评测显示它优于「OCR + 文本嵌入」管线。

它的局限也很直接：存储成本高、依赖 GPU、与文本检索的混合方案尚未定型，2026 年仍不是主流生产选择。

11.5 怎么组合¶

默认方案：BM25 + 稠密检索并行召回，用 RRF 融合，再接 Rerank。

这个组合从 2023 年至今没有被撼动，原因是：

覆盖了字面和语义两类匹配；
每个组件都成熟、可独立调优、可独立降级；
成本可控。

flowchart TB
    Q[Query] --> B[BM25 召回]
    Q --> D[稠密向量召回]
    B --> RRF[RRF 融合]
    D --> RRF
    RRF --> RR[Rerank 精排]
    RR --> TOP[Top-K]

什么时候考虑加第三路（后期交互）：

前两路 + Rerank 已经调到位，效果仍不达标；
领域内的细粒度词级匹配确实很重要；
存储成本可以接受。

如果没有这些条件，通常不必加。每多一路召回，就多一套需要维护、调优和监控的链路。

11.6 一个实用的判断方法¶

不确定该侧重哪一路时，做这个实验：

用评测集分别跑纯 BM25 和纯稠密检索，记录各自的 Hit@K；
重点看两者的 Query 分布——哪些问题只有 BM25 能召回、哪些只有稠密能召回；
分析这两类问题的特征。

这个分析结果会直接影响融合权重的设定，以及是否需要引入第三路。 它来自你自己的数据分布，通常比通用经验更有针对性。

11.7 常见错误¶

11.7.1 认为向量检索全面优于关键词检索¶

在术语密集领域经常相反。这一类 Query 往往更依赖字面匹配。

11.7.2 只用一路召回¶

单路必然存在系统性盲区，且这个盲区无法通过调参消除。

11.7.3 把 SPLADE 说成主流¶

它已被更简单的组合实质取代，属知识广度而非推荐方案。

11.7.4 把后期交互和 Rerank 混为一谈¶

后期交互的文档表示可离线预计算，Rerank 的 cross-encoder 必须在线成对计算。这是架构上的根本差异。

11.7.5 忽略后期交互的存储成本¶

几十倍的存储开销是它的主要落地障碍，讨论这一路线时通常需要把部署成本一起算进去。

11.7.6 说视觉文档检索已经取代了 OCR 管线¶

它在特定场景有优势，但尚未成为主流生产方案。

11.8 本章总结¶

三种范式各自擅长不同类型的匹配，不是新旧替代关系；
BM25 的三个直觉：词频、逆文档频率、长度归一化；
BM25 在术语密集、罕见词、精确匹配、域外领域上常优于稠密检索，且无需训练、无需 GPU、写入即可检索；
稠密检索的失败模式（罕见词、否定、数值、域外、短 Query）恰好是 BM25 的强项——这也是混合检索的主要依据；
后期交互兼顾词级与语义匹配且可离线预计算，但存储开销几十倍；其视觉版本可绕开文档解析，但尚未主流；
默认方案：BM25 + 稠密 + RRF + Rerank，这个组合多年未被撼动；
是否加第三路要靠实测：分析两路各自独占的召回 Query，比套用通用经验更有针对性。