这道题其实是在问[[RAG]]系统里召回与精度的取舍。说白了,没有一种检索方法能通吃所有场景,真正落地的做法往往是混合的。我先说[[BM25]],它本质是精确关键词匹配,靠词频和逆文档频率打分。它的好处是零数据依赖,即插即用,计算开销极低,倒排索引毫秒级响应。但缺点也很明显,同义词、上下位词它完全抓不到。比如用户搜‘苹果手机’,BM25只能匹配到字面‘苹果’和‘手机’,如果文档里写的是‘iPhone’,它就漏了。所以BM25适合品牌名、型号、订单号这种精确检索场景。
再说向量检索,它用[[Embedding]]模型把查询和文档都映射到语义空间,算余弦相似度。它能理解‘苹果手机’约等于‘iPhone’,召回率很高。但这里有个坑:向量检索的质量完全取决于embedding模型有没有在目标领域上微调过。如果直接用通用模型去搜医疗或法律文档,召回的全是语义相似但实际无关的内容,噪声很大。而且向量计算加[[ANN]]近似,延迟和资源开销都比BM25高一个量级。
所以实际落地,[[混合检索]]是标配。常见做法是BM25和向量检索并行跑,然后用RRF,也就是倒数排序融合来合并结果。RRF公式是score等于1除以k加排名,k通常取60。它只看排名不看绝对分数,所以鲁棒性不错。但这里有个容易翻车的点:如果两个通道的召回量级差异很大,比如向量通道召回500条但BM25只召回10条,直接RRF可能把BM25的高质量结果埋没掉。我上线前会做一遍小流量A/B测试,分别调k值和召回截断数,确保融合后的Recall@K和延迟都达标。
举一个电商搜索的例子。你在淘宝搜‘显白口红’,用户意图是场景化的,向量检索能理解‘显白’对应橘调或蓝调色系。但商品标题里‘口红’、品牌名‘MAC’这些精确词,必须靠BM25锁定。所以实际策略是:搜索词含品牌或型号时,动态提高BM25权重;长尾场景词时,提高向量权重。这个权重不是拍脑袋定的,而是用历史点击日志训练一个轻量分类器,实时判断当前query的类型。
另外还有一个值得深挖的点:混合检索的融合时机。是先检索再融合,还是先融合索引再做单一检索?后者就是[[ColBERT]]那种late interaction的思路,能减少工程复杂度,但对索引结构的改动比较大。
所以我的总体判断是:BM25是保底,向量检索是增量,混合检索是工程落地的最优解。但前提是embedding模型要领域适配,融合参数要按场景调过。如果资源有限,我会优先把预算花在embedding模型的微调和检索链路的监控上,而不是盲目上多路召回。