完整题目
请解释稀疏检索（Sparse Retrieval）和稠密检索（Dense Retrieval）的基本原理及各自的相似度度量方式，并说明为何在实际系统中常采用混合检索策略。
本文目录
稀疏检索（Sparse Retrieval）
原理：基于词项空间的高维稀疏向量，经典代表是 BM25 和 TF-IDF。
- 维度 = 词表大小（通常 10万+），向量极度稀疏（大部分为0）
- 相似度度量：词袋匹配 + 词频加权，BM25 公式核心衡量词项与文档的相关性
- 优势：精确匹配能力强、可解释性好、无需训练、对关键词敏感
稠密检索（Dense Retrieval）
原理：通过编码器（如BERT、双塔模型）将文本压缩为低维稠密向量。
- 维度通常 256-1024，向量稠密
- 相似度度量：余弦相似度或点积，衡量语义空间中的距离
- 优势：语义泛化能力强，能处理同义词、改写、跨语言等语义匹配
为何采用混合检索？
| 场景 | 稀疏检索 | 稠密检索 |
|---|---|---|
| 专业术语/ID/人名 | ✅ 精准 | ❌ 可能失配 |
| 语义改写/口语化查询 | ❌ 字面不匹配 | ✅ 语义捕获 |
| 长尾低频词 | ✅ 稳定 | ❌ 学习不充分 |
实际做法：
- 并行召回：BM25 + 向量检索各取Top-K
- 融合排序：线性加权
score = α·BM25_score + β·dense_score，或训练 LTR 模型 - 两阶段：混合召回 → Cross-Encoder 精排
美团这类业务场景（POI搜索、外卖Query）尤其需要混合策略——用户既搜"麦当劳"（精确品牌）也搜"好吃的汉堡"（语义意图），单一检索无法兼顾。
学习建议
建议系统学习该知识点
换一种问法，检查是否真正理解
场景切入
假设你在做电商搜索，用户搜‘iPhone 14黑色’，用BM25能精确匹配到商品标题；但搜‘新款苹果手机’时，字面匹配可能不灵。这两种场景你怎么分别设计检索策略？
层层追问
搜索系统里，你怎么做召回？……如果只靠关键词匹配，用户说‘性价比高的手机’能找到吗？……那用语义向量呢，会不会把‘苹果’和‘水果’搞混？……实际中怎么平衡这两者？
直球架构
请解释稀疏检索和稠密检索的原理和相似度度量方式。为什么很多系统要混合使用两者？具体怎么混合，比如在召回和排序阶段如何结合？
练习口述回答 · 约4分钟
- 这道题在问检索系统的精准与泛化怎么取舍
- 稀疏检索的本质是精确关键词匹配，适合ID、术语
- 稠密检索靠语义向量，泛化强但长尾和精确匹配弱
- 混合检索把两者并行召回再融合，是工程最优解
- 落地要关注权重调优和延迟，我倾向用两阶段架构
这道题其实是在问一个很本质的取舍：检索系统到底是要精准的关键词匹配，还是要语义上的泛化理解。我理解，[[稀疏检索]]和[[稠密检索]]分别代表了这两个极端，而真正落地的时候，我们往往需要把两者结合起来。
先说稀疏检索，典型代表就是 [[BM25]] 和 [[TF-IDF]]。它的思路很简单，把文本拆成词，每个词作为一个维度，整个词表可能有几十万维，但大部分是0，所以叫稀疏。相似度度量就是看词有没有匹配上，再结合词频算个加权分数。它的优势是 精确匹配能力极强，比如搜一个订单号、错误码、或者像“麦当劳”这种专有名词，它一定能命中。而且它不需要训练，上线就能用，可解释性也好，出了问题好排查。
但它的短板也很明显：对语义改写、同义词、口语化表达不敏感。比如用户说“好吃的汉堡”，它可能就匹配不上“美味汉堡”这种同义表述，因为字面不一样。
再来看稠密检索，它走的是另一条路。通过 [[Bi-Encoder]] 这类双塔模型，把文本压缩成一个低维的稠密向量，比如768维，然后用 余弦相似度 或者点积来衡量语义距离。它的优势是 语义泛化能力强，能理解“好吃的汉堡”和“美味汉堡”其实是一个意思，甚至跨语言也能做。
但这里有个坑：稠密检索对长尾、低频词覆盖不好。比如某个很冷门的专业术语，训练数据里出现的次数少，向量表达就不够准确。另外，它对精确标识符、ID这类东西天生不敏感，比如搜“订单号12345”，它可能把12345当成语义的一部分，反而匹配到不相关的内容。
所以你看，两者正好互补。稀疏检索擅长精确匹配和长尾词，稠密检索擅长语义泛化和同义改写。那在实际系统里，比如美团做POI搜索，用户既会搜“麦当劳”这种精确品牌，也会搜“附近好吃的汉堡”这种语义意图，单一检索肯定搞不定。所以 [[混合检索]] 就成了工业界的标配做法。
具体落地，我一般会分成两阶段：第一阶段并行召回，BM25 和 向量检索 各取Top-K，然后做融合排序。融合的方式可以是线性加权，比如 score = α·BM25_score + β·dense_score，这个α和β需要根据业务调优，或者用 LTR 模型学一个更复杂的融合。第二阶段再用 [[Cross-Encoder]] 做精排，把混合召回的候选集重新打分。
这里有一个风险点：混合检索的前提是两边的分数要可比。如果BM25分数和向量分数不在同一个量级，直接加权会出问题。常见的失败场景是，向量检索的分数普遍偏低，结果融合后BM25完全主导，混合就失去了意义。所以上线前我会特别关注分数归一化，比如用min-max归一化或者分位数归一化，让两边分数对齐。