这道题其实是在问,当面对一个具体的检索场景时,怎么判断用向量还是用关键词,以及怎么量化评估。我的核心观点是:没有绝对的好坏,只有场景的匹配度,真正落地时往往是 [[Hybrid Search]] 混合着上。
先说本质区别。[[BM25]] 是精确词项匹配,你搜什么词,文档里必须有,适合专有名词、短查询、实时性要求高的场景,比如搜订单号、错误码。BGE-M3的dense模式做语义相似度匹配,模型还支持sparse和multi-vector模式,能处理同义改写、跨语言、口语化表达,比如用户说“怎么退款”,文档里写的是“退货流程”,向量能关联上。预训练embedding可直接用于新业务,不以用户点击反馈作为运行前提;领域偏移与实体匹配效果仍要评估。
评估指标我重点看三个。质量上,Recall@k 是首要的,因为 [[RAG]] 里漏检代价最高,你漏了相关文档,后面生成就没了依据。然后是 MRR,它看第一个相关结果排得多靠前,对排序质量敏感。效率上,P99 延迟是红线,向量检索可以选择精确搜索或HNSW等近似索引;延迟、构建、更新与资源成本依实现和负载测量。
权重的考量完全由业务场景驱动。举个例子,电商客服的退换货场景:用户问“我买的鞋码不对怎么办”,如果只靠 BM25,可能命中“鞋码”但漏掉“退换货”的文档。这时候向量就重要。但如果是搜售后工单号“TK20250301”,BM25 精确匹配又快又准,向量反而可能因为语义扩展召回一堆不相关的东西。我会在固定标注集和真实负载上比较BM25、BGE-M3的dense/sparse/multi-vector及混合方案。Recall的分母是全部相关文档,Precision才是返回结果中的相关占比;歧义词还要看上下文与实体消歧,不能由0.85、20毫秒或歧义词直接推出通用选型。
这里有个坑:向量检索不是万能的。它的效果高度依赖 [[Embedding]] 质量和文档切分。如果文档 chunk 切得不好,比如把完整的一个条款切成两半,向量再强也召不回。上线前我会特别关注离线评估,构建一个 query-doc 相关性标注集,至少分三档,避免线上 AB 测试周期太长。另外,BGE-M3的编码与检索要分别核算资源,不能预设必须某个向量数据库或固定高一个量级;小业务可比较较简单的实现。
还有一个点值得展开:动态权重切换。我在一些场景里会按 query 长度或实体密度自动调 BM25 和向量的融合比例,短查询多给 BM25 权重,长查询多给向量。但这里面有个前提,你需要一个分类器来判断 query 类型,这个分类器本身也有精度问题,弄不好会引入新错误。
所以综合来看,我倾向于把 BM25 作为保底基线,向量作为提升语义覆盖的增强手段。如果条件允许,默认走 Hybrid Search,用 RRF 或线性融合做[[重排]]。但我会先跑通 BM25 基线,确保兜得住,再上向量,避免一上来就搞复杂系统,结果问题出在基础切分上。