RAG 系列（十）：混合检索——让召回更全面

向量检索的一个盲区假设你的知识库里有一篇文档内容包含这样一句话“中文场景推荐使用BAAI/bge-large-zh-v1.5向量维度为 1024。”用户问“BAAI/bge-large-zh-v1.5 的向量维度是多少”你以为这是送分题——完全一样的词向量检索应该能轻松找到。实际上不一定。向量检索依赖语义相似度当查询和文档的用词高度重叠时它并不比 BM25 更有优势有时甚至更差。BM25 算法是专门为精确词频匹配设计的处理这类问题是它的主场。真正的问题是你的 RAG 系统一定会同时遇到两类查询关键词查询包含精确的型号、参数、公式、人名——“BAAI/bge-large-zh-v1.5 维度”语义查询换了一种说法的概念性问题——“AI 助手总是给出过时答案怎么解决”纯向量检索擅长后者但对前者力不从心。纯 BM25 恰好相反。混合检索Hybrid Search的思路很简单两个都用再融合结果。BM25 原理速览BM25Best Match 25是搜索引擎领域的经典排名算法Elasticsearch、Lucene 都在用它。核心公式score(D, Q) Σ IDF(qi) × (f(qi, D) × (k1 1)) / (f(qi, D) k1 × (1 - b b × |D|/avgdl))人话版本IDF逆文档频率一个词在所有文档里越罕见它在匹配时越有价值。的不值钱“BGE-large-zh-v1.5” 非常值钱。TF词频这个词在文档中出现越多分数越高但收益递减。文档长度惩罚长文档不因词数多而自动获得高分。BM25 的优势完全基于词汇查询词和文档词只要有重叠就能精准命中。精确型号、产品名、函数名——这是它的主场。BM25 的劣势不理解语义。知识截止问题和AI 不知道最新信息在 BM25 看来毫无关系尽管它们说的是同一件事。RRF 融合算法有了 BM25 和向量检索两份结果怎么合并最简单的思路是把两个分数加权平均但两种算法的分数尺度完全不同直接相加没有意义。RRFReciprocal Rank Fusion的做法更优雅只看排名不看分数。公式RRF_score(d) Σ 1 / (k rank(d))rank(d)文档 d 在某个检索器中的排名第 1 名、第 2 名…k常数通常取 60防止最高排名的文档独占分数对每个检索器的排名求和举例文档BM25 排名Vector 排名RRF 分数k60doc-006131/(601) 1/(603) 0.0164 0.0159 0.0323doc-003311/(603) 1/(601) 0.0323doc-002241/(602) 1/(604) 0.0161 0.0156 0.0317RRF 的好处无论两个检索器的分数范围差多少都能公平地基于排名融合不需要手动对齐分数。实验设计6 条测试查询覆盖两种场景类型查询期望文档测试点关键词BAAI/bge-large-zh-v1.5 维度doc-003精确模型名匹配关键词RRF score sum 1/(krank) 公式doc-006精确公式字符串关键词chunk_size 256 1024 overlap 推荐doc-004精确参数值语义AI 助手总是给出过时的答案有什么方法让它了解最新信息doc-001没提 RAG语义多个团队共用一套问答系统怎么保证不同团队的资料互相看不到doc-008没提多租户语义换一种问法检索结果就完全不同怎么解决这种不稳定性doc-007没提 Multi-Query评估指标MRRMean Reciprocal RankRR 1/rank正确文档排在第几位 MRR 所有查询的 RR 均值每次都排第一 → MRR 1.0平均排第二 → MRR 0.5全部未命中 → MRR 0.0三种检索器实现BM25 检索器中文要先做分词用 jiebaimportjiebafromlangchain_community.retrieversimportBM25Retrieverdefchinese_tokenizer(text:str)-list[str]:returnlist(jieba.cut(text))bm25_retrieverBM25Retriever.from_documents(docs,k3,preprocess_funcchinese_tokenizer,)向量检索器fromlangchain_chromaimportChromafromlangchain_openaiimportOpenAIEmbeddings embeddingsOpenAIEmbeddings(modelBAAI/bge-large-zh-v1.5,api_keyos.getenv(EMBEDDING_API_KEY),base_urlhttps://api.siliconflow.cn/v1,)vectorstoreChroma.from_documents(docs,embeddingembeddings)vector_retrievervectorstore.as_retriever(search_kwargs{k:3})混合检索器EnsembleRetriever RRFfromlangchain_classic.retrieversimportEnsembleRetriever hybrid_retrieverEnsembleRetriever(retrievers[bm25_retriever,vector_retriever],weights[0.5,0.5],# 两者权重相同内部用 RRF 融合排名)EnsembleRetriever的weights参数控制的是各检索器在 RRF 中的权重不是直接加权分数。实际实现里它会对每个检索器的结果排名做加权 RRF 融合。实验结果 逐条查询结果 (RR Reciprocal RankHit1 正确文档是否排第一) [KEYWORD ] BAAI/bge-large-zh-v1.5 维度 期望文档: doc-003 BM25 [H1✓] RR1.00 | rank1 | 召回: [doc-003, doc-006, doc-004] Vector [H1✓] RR1.00 | rank1 | 召回: [doc-003, doc-005, doc-002] Hybrid [H1✓] RR1.00 | rank1 | 召回: [doc-003, doc-006, doc-004] [KEYWORD ] RRF score sum 1/(krank) 公式 期望文档: doc-006 BM25 [H1✓] RR1.00 | rank1 | 召回: [doc-006, doc-002, doc-004] Vector [H1✗] RR0.50 | rank2 | 召回: [doc-004, doc-006, doc-003] Hybrid [H1✓] RR1.00 | rank1 | 召回: [doc-006, doc-004, doc-003] [KEYWORD ] chunk_size 256 1024 overlap 推荐 期望文档: doc-004 BM25 [H1✓] RR1.00 | rank1 | 召回: [doc-004, doc-003, doc-006] Vector [H1✗] RR0.50 | rank2 | 召回: [doc-006, doc-004, doc-003] Hybrid [H1✓] RR1.00 | rank1 | 召回: [doc-004, doc-006, doc-003] [SEMANTIC] AI 助手总是给出过时的答案有什么方法让它了解最新信息 期望文档: doc-001 BM25 [H1✗] RR0.33 | rank3 | 召回: [doc-007, doc-005, doc-001] Vector [H1✓] RR1.00 | rank1 | 召回: [doc-001, doc-005, doc-007] Hybrid [H1✓] RR1.00 | rank1 | 召回: [doc-001, doc-007, doc-005] [SEMANTIC] 多个团队共用一套问答系统怎么保证不同团队的资料互相看不到 期望文档: doc-008 BM25 [H1✗] RR0.33 | rank3 | 召回: [doc-002, doc-007, doc-008] Vector [H1✓] RR1.00 | rank1 | 召回: [doc-008, doc-001, doc-002] Hybrid [H1✓] RR1.00 | rank1 | 召回: [doc-008, doc-002, doc-007] [SEMANTIC] 换一种问法检索结果就完全不同怎么解决这种不稳定性 期望文档: doc-007 BM25 [H1✗] RR0.00 | rankmiss | 召回: [doc-005, doc-001, doc-003] Vector [H1✓] RR1.00 | rank1 | 召回: [doc-007, doc-001, doc-005] Hybrid [H1✓] RR1.00 | rank1 | 召回: [doc-007, doc-001, doc-005]MRR 汇总 MRR 汇总对比 MRR1.0 → 每次都排第一MRR0.5 → 平均排第二MRR0.0 → 全未命中 查询类型 BM25 Vector Hybrid 最佳 ──────────────────────────────────────────────────────── 关键词查询 1.000 0.667 1.000 BM25 语义查询 0.222 1.000 1.000 Vector 总体 0.611 0.833 1.000 Hybrid 结论 ✓ 关键词查询BM25 MRR 更高精确词匹配优势 ✓ 语义查询Vector MRR 更高语义理解优势 ✓ 混合检索总体 MRR 最高兼顾两类查询数字解读BM25 在关键词查询上达到满分 1.000但在语义查询上只有 0.222——第三条语义查询“换一种问法”完全 miss排名都没有进前三。向量检索在语义查询上完美1.000但在关键词查询上只有 0.667——有两条 RRF 公式和 chunk_size 的查询排到了第二名而非第一。混合检索全类型满分 1.000不仅继承了 BM25 的关键词优势语义查询也不弱于纯向量。关键认知BM25 和向量检索的边界维度BM25向量检索擅长精确词匹配型号、公式、参数语义理解同义词、换一种说法失效场景查询和文档用词不同精确术语的向量表示不够区分性典型查询“BERT-base-uncased 层数”“为什么预训练模型需要微调”适合语言英文效果更好中文需分词中英文均可计算成本低无需 GPU无 API 调用较高需要 Embedding 调用什么时候一定要上混合检索知识库里包含产品型号、API 名、参数名、缩写等精确术语用户查询行为多样技术用户问精确术语普通用户问概念要求高召回率不能漏掉任何相关文档什么时候可以只用向量知识库全是自然语言文本没有精确术语查询都是语义性的概念问题资源有限不想引入额外依赖完整代码代码已开源https://github.com/chendongqi/llm-in-action/tree/main/10-hybrid-search核心文件hybrid_search.py— 三种检索策略的完整对比实验运行方式gitclone https://github.com/chendongqi/llm-in-actioncd10-hybrid-searchcp.env.example .env# 填入 Embedding API Keypipinstall-rrequirements.txt python hybrid_search.py小结本文通过代码实验对比了三种检索策略纯 BM25——关键词精确匹配的专家精确术语场景无敌但不懂语义纯向量检索——语义理解的专家概念性问法场景强但精确术语不如 BM25混合检索RRF——两者融合MRR 全场景最高RRF 算法的核心思路值得记住不比分数只比排名。这使它能够无缝融合任何两个评分体系完全不同的检索器。生产环境中混合检索已经是 RAG 系统的标配。Elasticsearch、Qdrant、Weaviate 都原生支持混合检索模式——向量检索BM25 不再是可选项而是默认推荐配置。参考资料LangChain EnsembleRetriever 文档BM25 算法论文Okapi BM25RRF 论文Reciprocal Rank FusionQdrant 混合检索文档