RAG 检索别只靠向量:BM25 加向量混合检索,召回率实测高出一截
纯向量检索的坑 很多人搭 RAG,第一步就踩坑:把文档切块、扔进 embedding 模型、存进向量库,查询时相似度 Top-K 拉出来就喂给大模型。问题是向量检索擅长语义相似,却对精确匹配天生迟钝——零件编号、合同条款编号、API 函数名、报错信息、英文缩写这类东西,语义上和查询「差不多」,但向量距离拉不开,很容易把该召回的那条挤到 Top-20 之外。这也是为什么很多 RAG 演示很好看、一上真实知识库就答非所问。 混合检索:两条腿走路 正确做法是双路召回:一路 BM25(关键词稀疏检索,Elasticsearch、OpenSearch、MeiliSearch 都内置),一路 dense 向量检索。两路各取 Top-20,再用 RRF(Reciprocal Rank Fusion,倒数排名融合)合并成最终 Top-5。RRF 公式很简单:每条文档的得分等于 Σ 1/(k+rank),k 常取 60,不需要调权重,比手工加权稳得多。 检索方式 擅长 短板 BM25 关键词 编号、专有名词、代码、报错 同义改写召回差 Dense 向量 语义同义、模糊提问 精确匹配弱 混合 + RRF 两者兼顾 多一路索引,工程量翻倍 LangChain、LlamaIndex 都内置了 EnsembleRetriever /混合检索模块,Qdrant 从 1.10 版起原生支持稀疏向量混合检索,不用再维护两套数据库。 三个实操建议 第一,切块别一刀切:正文按 500-800 token 切,代码块、表格单独成块并打上 metadata(来源、章节、文档类型),检索时按 metadata 过滤比切块大小更影响质量。第二,K 值要留余量:双路各取 Top-20、融合后重排取 Top-5,别一路只取 Top-5——融合的前提是两路都有足够候选。第三,用真实提问集回归测试:准备 20-30 条业务高频问题,标注标准答案出自哪一段,每次改切块、改 embedding、改 K 值都跑一遍召回命中率,比凭感觉调参靠谱。 收束 混合检索不是锦上添花,是生产 RAG 的及格线。关键词路保精确,向量路保语义,RRF 把两路排到一起——这套组合在绝大多数企业知识库场景里,都比纯向量检索召回率高出一截。下一步真正值钱的,是在混合召回之后再接一层重排,那是下一篇要拆的事。 ...