面试题 · 检索
搜索「IVF」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请详细解释在检索系统中采用混合检索策略的原因，分别阐述稀疏检索（Sparse Retrieval）和稠密检索（Dense Retrieval）的基本原理、技术特点及常用相似度度量方法，并结合实际场景说明各自的适用条件与优势对比。
单一检索方式都有明显短板：
混合检索的核心价值是互补召回：稀疏保证字面匹配精度，稠密覆盖语义泛化能力，最终提升整体召回率和排序质量。
原理：基于倒排索引的关键词匹配，计算query与doc的词项重叠程度。
代表方法：BM25
score(D,Q) = Σ IDF(q_i) · [f(q_i,D)·(k1+1)] / [f(q_i,D) + k1·(1-b+b·|D|/avgdl)]按学习路线查看教程、项目和面试题。
特点：
适用：商品名称、法律条文、医疗术语等需要精确匹配的场景。
原理：用双塔模型将query和doc编码为低维稠密向量，通过向量相似度召回。
常用相似度度量：
| 方法 | 公式 | 特点 |
|---|---|---|
| 余弦相似度 | cos(θ) = A·B/(‖A‖‖B‖) | 归一化后只关注方向，适合语义匹配 |
| 点积 | A·B | 保留模长信息，训练时更稳定 |
| 欧氏距离 | ‖A-B‖ | 对向量尺度敏感，较少直接用 |
特点：
适用：开放域问答、对话系统、语义搜索等需要理解意图的场景。
以外卖搜索为例：
关键经验：稠密检索的增益在头部热门query最明显，长尾query仍需稀疏兜底。
建议先掌握向量空间模型与词袋模型基础，再学习BM25和Sentence-BERT等典型算法，通过动手实现简单检索系统加深理解。
场景切入
假设你在做电商搜索，用户搜“苹果手机”，稀疏检索能精确匹配到商品标题，但用户也可能搜“iPhone”，这时候稠密检索就能补上。你理解这种混合的必要性吗？具体说说两种检索各自怎么工作的？
层层追问
检索系统你肯定熟悉，那稀疏检索和稠密检索你分别讲讲原理……它们各自有什么优缺点？……那在实际系统中，什么场景下你会只用一种，什么情况下必须混合？
直球架构
请直接解释在检索系统中为什么要用混合检索策略。分别阐述稀疏检索和稠密检索的基本原理、技术特点、常用相似度度量方法，并对比它们的适用条件和优势。
这道题表面在问[[混合检索]]，其实是在考你对检索系统本质的理解，任何单一方法都有先天缺陷，落地时必须在 精确匹配 和 语义理解 之间做取舍。我先分别讲清楚两边，再说为什么实际项目里必须混着来。
先说[[稀疏检索]]，典型代表是 [[BM25]]。它的核心是倒排索引加词频统计，说白了就是看 query 和文档里哪些词撞上了，撞得越多分越高。BM25 有个关键参数 k1 和 b，控制词频饱和度和文档长度归一化，这个调参挺讲究的。它的优点很明确：可解释性强，新词零成本，对精确匹配场景特别好用。比如搜「iPhone 15 Pro Max」，你必须匹配到那个准确的产品名，用[[稠密检索]]反而可能因为语义泛化召回一堆「手机」「苹果」这种不相关的。所以它的适用条件就是那些对字面匹配要求极高的场景，比如商品名称、法律条文、医疗术语。但它的短板也明显，无法处理同义词和语义变体，搜「苹果手机」找不到「iPhone」。
再说稠密检索，也就是 Dense Retrieval。它用[[双塔]]模型把 query 和文档编码成稠密向量，然后算向量相似度。常用度量有 余弦相似度、点积，还有欧氏距离，但实际工程里余弦相似度最常用，因为它只关注方向，对向量长度不敏感。稠密检索的优势是语义泛化能力强，能理解「适合聚会的餐厅」背后的「包厢」「多人套餐」这些隐含语义。但它的前提是训练数据要覆盖好，如果遇到训练集里没见过的罕见词或专有名词，召回会崩。而且它依赖 [[ANN]] 索引，比如 [[HNSW]] 或 [[IVF]]，内存开销大，冷启动时效果很差。所以它的适用场景是开放域问答、语义搜索这类需要理解用户意图的地方。
真正落地的时候，你会发现这两个方法其实是互补的。我拿外卖搜索举个例子：用户搜「肯德基」，稀疏检索能精确匹配到商家名，稠密检索反而可能因为语义泛化召回一些炸鸡店，这就不对了。但用户搜「适合带小孩吃的餐厅」，稠密检索能抓到「儿童套餐」「亲子区」这些语义特征，稀疏检索就完全无能为力。所以实际线上通常是两阶段：先用稠密检索做语义召回，拿到 Top-K，再用稀疏检索补充那些精确匹配但稠密漏掉的，最后统一走 [[Rerank]] 阶段融合分数。这里有个坑：稠密检索的增益其实集中在头部热门 query，长尾 query 尤其是带数字、型号、错别字的，稀疏检索反而更稳。所以上线前我会特别关注长尾 query 的召回率，如果掉得厉害，可能得调融合权重甚至降级回纯稀疏。
另外还有一个容易被忽略的点，混合检索的代价是系统复杂度翻倍。索引要维护两套，延迟和资源都要额外考虑。所以如果业务场景本身对精确匹配要求不高，比如内部知识库问答，可能纯稠密就够了，没必要强行混合。
所以我的判断是：混合检索不是银弹，而是一个工程取舍。我更倾向先理解业务场景的匹配需求，如果字面匹配是刚需，那混合检索是必选项；如果语义理解就够了，就别给自己找麻烦。面试官可以追问一下：在资源受限的场景下，你会怎么简化混合检索？ 比如只保留稀疏检索，或者用 [[ColBERT]] 这种端到端模型替代两阶段？