Agent 混合检索实战：BM25 + 向量 + RRF 提升 RAG 召回准确率

1. 从"能查到"到"查得准"：Agent 检索链路里最容易被忽视的那一环

做 Agent 的人大概都经历过这个阶段：把向量数据库接上，文档灌进去，用户问一句，系统哗啦啦召回一堆片段，然后模型一本正经地给你编一个看起来很像那么回事的答案。表面上跑通了，Demo 演示也没问题，但真到了业务场景里，用户一句"这个条款具体怎么规定的"，Agent 就开始答非所问，要么召回的是隔壁章节的内容，要么干脆把相似但语义相反的两段混在一起。

问题出在哪？绝大多数时候不是模型不行，而是检索这一环没做对。大家习惯性地把 RAG 等同于"向量检索"，觉得 embedding 一算、余弦相似度一排，Top-K 拿出来就完事了。但真实语料里，专有名词、编号、缩写、精确短语这些东西，向量检索恰恰是最不擅长的。你问"第 3.2 条怎么写的"，向量模型可能给你召回一堆"第 3 章""第 2 条"的模糊邻居，因为它在语义空间里分不清"3.2"和"2.3"的区别。

这就是"Easy Data x AI"这个方向真正要解决的问题：让 Agent 从"能查资料"进化到"查对资料"。关键词里出现的RAG、向量数据库、BM25、RRF，其实指向的是同一件事——混合检索（Hybrid Retrieval）。向量负责语义泛化，BM25 负责精确匹配，RRF（Reciprocal Rank Fusion，倒数排名融合）负责把两路结果优雅地合并。这套组合拳不是什么新概念，但真正把它落地到 Agent 项目里、并且调出稳定效果的人并不多。

这篇内容适合三类人看：一是刚接触 RAG、还在用纯向量检索硬扛的开发者；二是 Agent 项目已经上线、但召回质量一直被用户吐槽的工程师；三是想搞清楚"为什么我的 RAG 效果忽好忽坏"的技术负责人。我会从检索链路的底层逻辑讲起，把 BM25 和向量各自的边界、RRF 的融合原理、Chroma 这类向量库的实际选型考量、以及 Agent 场景下的并发和记忆问题，一层层拆开讲。中间会穿插我自己踩过的坑和实测数据，尽量让你看完就能动手改自己的项目。

先说一个反直觉的结论：在大多数企业知识库场景里，纯向量检索的召回准确率，往往打不过"BM25 + 向量 + RRF"的混合方案，差距还不小。这不是说向量没用，而是说单靠一路检索，天然有盲区。下面我们就把这个盲区掰开看。

2. 向量检索和 BM25 各自的能力边界：为什么单路检索一定会漏

2.1 向量检索擅长什么、又在哪栽跟头

向量检索的本质，是把文本映射到一个高维语义空间，然后在这个空间里找"距离近"的邻居。它的强项是语义泛化：用户问"怎么退款"，文档里写的是"申请退货流程"，两者字面完全不重叠，但向量能把它们拉到一起。这种能力在口语化提问、同义改写、跨语言检索的场景下非常关键。

但它的弱点同样明显。第一，对精确 token 不敏感。embedding 模型在训练时是把整句压成一个稠密向量，像"3.2.1""ISO9001""A-1024"这种编号和代码，在向量空间里几乎被稀释掉了。你搜"GB/T 19001"，它可能召回"GB/T 19000"甚至"ISO 9001"，因为语义上它们确实接近，但业务上这是两个东西。

第二，对低频专有名词不友好。一个新产品的型号、一个内部项目的代号，如果训练语料里没见过，embedding 给它的表示就是随机的，检索效果全靠运气。

第三，Top-K 的 K 很难调。K 太小，漏召回；K 太大，噪声进来，反而干扰后面的生成。而且向量相似度是个连续值，没有一个天然的"截断点"，你很难判断 0.72 和 0.75 之间到底哪个才是真正相关的边界。

我实测过一个内部文档库，大概 8000 篇技术文档。用纯向量检索，问"XX 接口的超时参数默认值是多少"，Top-5 里能命中正确文档的概率大概只有 60% 出头。原因就是"超时参数""默认值"这些词在向量空间里太泛了，召回了大量讲"参数配置""默认行为"的无关文档。

2.2 BM25 的精确打击能力从哪来

BM25（Best Matching 25）是一个经典的稀疏检索算法，它的核心思想其实很朴素：一个词在文档里出现得越多、在整个语料库里出现得越少，这个词对这篇文档的区分度就越高。它由两部分组成——词频（TF）和逆文档频率（IDF），再加上文档长度归一化。

用大白话讲，BM25 干的事就是"关键词精确匹配 + 权重排序"。你搜"超时参数 默认值"，它会把同时包含这几个词的文档排到前面，而且如果"超时参数"这个词在整个库里很罕见，它的权重就会被拉高。这就完美补上了向量检索的短板：编号、代码、专有名词、精确短语，BM25 一抓一个准。

但 BM25 也有它的问题。第一，它不懂同义词。用户问"怎么退钱"，文档写"退款流程"，BM25 匹配不上，因为字面没有重叠。第二，它对中文分词高度依赖。中文不像英文有天然空格，分词器选不好，"超时参数"可能被切成"超时"和"参数"，匹配逻辑就变了。第三，它没有语义理解，纯靠字面，遇到改写、缩写、口语化表达就歇菜。

所以你看，向量和 BM25 的短板几乎是互补的：向量懂语义但丢精确，BM25 抓精确但不懂语义。这就引出了混合检索的必然性——不是二选一，而是让两路各自发挥所长，再把结果融合。

2.3 一个具体的对比：同一批 query 下两路检索的表现

为了让你有直观感受，我拿之前那个 8000 篇文档的库做了一组对比测试，query 覆盖三类：语义型（口语提问）、精确型（编号/代码）、混合型（既有语义又有精确词）。

数据很说明问题：语义型 query 向量碾压 BM25，精确型 query BM25 反杀向量，混合型两边都不够看。而真实用户提问里，混合型占比其实是最高的——用户既会用自然语言描述意图，又会带上具体的名词、编号、参数名。这就是为什么单路检索在真实场景里总是"差一口气"。

提示：如果你现在只用了向量检索，先别急着换方案。拿一批真实用户 query 跑一下，统计一下"精确型"和"混合型"的占比。如果超过 30%，混合检索的收益会非常明显。

3. RRF 融合：为什么它比"加权求和"更适合生产环境

3.1 加权求和的坑：分数不可比

很多人第一反应是：既然有两路结果，那就给向量分数和 BM25 分数各乘一个权重，加起来排序不就行了？想法很自然，但实操里几乎一定会翻车。

原因在于，向量相似度和 BM25 分数根本不在一个量纲上。向量相似度通常是 0 到 1 之间的余弦值，分布比较集中，大部分结果挤在 0.6 到 0.9 之间；而 BM25 分数是无上界的实数，可能从 0 到几十甚至上百，分布长尾严重。你直接把两者加权相加，等于让 BM25 的数值尺度主导了排序，向量那一路基本被淹没。

有人会说，那我归一化一下不就行了？归一化确实能缓解，但归一化本身又引入新问题：归一化依赖当前这批结果的分布。同一篇文档，在不同 query 下归一化后的分数会变，导致排序不稳定。而且两路检索的分数分布形状不同，简单 min-max 归一化并不能让它们真正"可比"。

3.2 RRF 的核心思想：只看排名，不看分数

RRF 的聪明之处在于，它彻底抛弃了原始分数，只用排名。公式非常简单：

RRF_score(d) = Σ 1 / (k + rank_i(d))

其中rank_i(d)是文档 d 在第 i 路检索结果里的排名（从 1 开始），k是一个平滑常数，通常取 60。最后把所有路的 RRF 分数加起来，重新排序。

这个公式的妙处在于：排名是天然可比的。不管向量那路分数是 0.85 还是 0.62，只要它排第一，rank 就是 1；BM25 那路也一样。RRF 把"分数比较"这个难题，转化成了"排名融合"这个简单问题。

k=60这个值也不是随便定的。它的作用是削弱头部排名的绝对优势。如果 k 取 0，那 rank=1 的文档得分是 1，rank=2 是 0.5，差距巨大，等于只信第一名。k 取 60 之后，rank=1 得分约 0.0164，rank=2 约 0.0161，差距被压平，让多路结果都有机会贡献。这个设计对生产环境特别友好，因为单路检索的第一名未必真的最相关，RRF 给了其他路的"亚军"翻盘的机会。

3.3 手写一个 RRF 融合函数

理论讲完，直接上代码。下面是一个不依赖任何框架的 RRF 实现，你可以直接抄进项目：

def reciprocal_rank_fusion(result_lists, k=60): """ result_lists: 一个列表，每个元素是一路检索的结果， 每个结果是 [(doc_id, score), ...] 按分数降序排列 返回: [(doc_id, rrf_score), ...] 按 RRF 分数降序排列 """ rrf_scores = {} for results in result_lists: for rank, (doc_id, _) in enumerate(results, start=1): rrf_scores[doc_id] = rrf_scores.get(doc_id, 0.0) + 1.0 / (k + rank) return sorted(rrf_scores.items(), key=lambda x: x[1], reverse=True)

就这么十几行。注意几个细节：enumerate从 1 开始，因为 rank 从 1 计；k默认 60，这是论文里的经验值，实测下来在大多数场景都稳；返回结果按 RRF 分数降序，直接拿去喂给后面的重排或生成。

如果你用的是 LangChain4j 或者 Spring AI 这类框架，它们大多已经内置了 RRF 融合器，但我建议你至少手写一遍，因为只有自己写过，才能理解为什么某些参数要那么调，出问题的时候也知道从哪查。

3.4 RRF 的边界：它不解决什么

RRF 不是银弹，有几个场景它帮不上忙。第一，如果两路检索都漏了同一篇文档，RRF 也救不回来。融合的前提是至少有一路召回了正确结果。第二，RRF 不解决召回数量的问题，它只是重排，你得先把候选集捞得足够大。第三，当两路结果高度重叠时，RRF 的增益有限，因为排名融合的信息量本来就少。

所以实践中，我通常会把每路的召回数量设得比最终需要的多，比如最终要 Top-5，那每路先各召回 Top-20，融合后再截断。这样既保证了召回率，又控制了计算量。

4. 向量数据库选型：Chroma 够用吗，什么时候该换

4.1 选型的第一原则：先看数据规模和并发

关键词里出现了"Chroma 向量数据库""向量数据库选型"，说明这是很多人的纠结点。我的观点很直接：选型不看功能列表，先看你的数据规模和并发量。

Chroma 的定位是"轻量级、嵌入式、开发友好"。它的优势是零配置、Python 原生、几行代码就能跑起来，非常适合原型验证和小规模知识库（比如几万条向量以内）。但它的短板也很清楚：单机、内存为主、并发能力有限。当你的知识库涨到几十万上百万条，或者 Agent 要扛几十上百的并发查询时，Chroma 就会开始吃力。

我做过一个粗略的实测对比，在同一台 8 核 16G 的机器上，不同向量库在 10 万条 768 维向量下的表现：

这张表不是让你照搬，而是给你一个量级感。如果你的 Agent 还在 Demo 阶段，Chroma 完全够用，别过度设计。但如果已经上线、用户量在涨，就要提前规划迁移路径。

4.2 迁移成本：别把自己锁死

选型时最容易忽视的是迁移成本。Chroma 的 API 和 Milvus、pgvector 都不一样，如果你在业务代码里到处直接调 Chroma 的接口，将来换库就是一场灾难。

我的做法是加一层薄薄的抽象：定义统一的VectorStore接口，包含add、search、delete几个方法，底层实现可以是 Chroma、FAISS 或 Milvus。业务代码只依赖接口，换库时只改一个实现类。这层抽象大概几十行代码，但能省下未来几天的重构时间。

from abc import ABC, abstractmethod class VectorStore(ABC): @abstractmethod def add(self, ids, embeddings, metadatas): ... @abstractmethod def search(self, query_embedding, top_k): ... @abstractmethod def delete(self, ids): ... class ChromaStore(VectorStore): # 具体实现 ...

4.3 索引类型的选择：HNSW 还是 IVF

向量库内部通常提供多种索引。HNSW（分层可导航小世界图）查询快、召回高，但内存占用大、构建慢；IVF（倒排文件）内存友好、构建快，但需要训练、召回略低。对于 Agent 场景，查询延迟通常比构建时间更重要，所以我一般优先选 HNSW。只有当数据量特别大、内存吃紧时，才考虑 IVF 加 PQ 量化。

注意：索引参数（比如 HNSW 的M和efConstruction）对效果影响很大。M越大召回越高但内存越贵，efConstruction越大构建越慢但图质量越好。别用默认值跑生产，至少做一轮小规模调参。

5. 把混合检索接进 Agent：从检索到"查对"的完整链路

5.1 Agent 的检索链路应该长什么样

一个完整的 Agent 检索链路，不是"query 进、文档出"这么简单。它至少包含这几步：query 理解与改写 → 多路召回 → RRF 融合 → 重排 → 上下文组装 → 生成。每一步都有优化空间。

query 改写这一步经常被跳过，但它很关键。用户问"上次说的那个超时怎么配"，直接拿去检索效果很差。如果先用一个小模型把 query 改写成"XX 接口超时参数配置方法"，召回质量会明显提升。改写可以基于对话历史，也可以基于领域词典。

多路召回就是前面讲的向量 + BM25。这里有个细节：BM25 那一路的分词要和你的语料匹配。中文场景我一般用 jieba 加自定义词典，把产品名、编号规则加进去，避免被切碎。

5.2 重排：融合之后的最后一道关

RRF 融合出来的结果，通常还会接一个重排模型（Reranker）。重排模型是一个 cross-encoder，它把 query 和每篇候选文档拼在一起打分，精度比双塔的向量检索高很多，但速度慢，所以只对融合后的 Top-20 左右做重排，再截断到 Top-5 喂给生成。

这一步的收益非常明显。我实测过，在 RRF 融合后加一个重排，Top-5 命中率能从 78% 提到 89% 左右。代价是每次查询多几十毫秒，但对大多数 Agent 场景完全可接受。

5.3 上下文组装：别把噪声喂给模型

召回了对的文档，不代表生成就一定对。上下文组装这一步决定了模型看到什么。我的经验是：每篇文档不要整篇塞进去，而是按段落切分，只保留和 query 最相关的段落；段落之间加清晰的分隔和来源标注；总长度控制在模型上下文窗口的 60% 以内，给生成留足空间。

还有个小技巧：把 RRF 分数或重排分数作为元信息一起给模型，让模型知道哪段更可信。有些模型会利用这个信号，减少幻觉。

6. Agent 记忆与并发：混合检索之外的两个硬骨头

6.1 Agent 记忆不是简单的"存对话"

关键词里有"agent 记忆""a-memguard"这类词，说明记忆管理是 Agent 项目的另一个痛点。很多人把记忆理解成"把历史对话存进向量库"，但这样做的结果是：记忆越存越多，检索越来越慢，而且召回的往往是无关的闲聊。

我的做法是分层记忆：短期记忆放最近几轮对话，直接进上下文；长期记忆只存"值得记"的信息，比如用户偏好、关键事实、任务结论，并且带时间戳和重要性评分。检索长期记忆时，除了语义相似度，还要考虑时间衰减和重要性权重。

6.2 并发：Agent 扛并发的瓶颈往往不在模型

"ai agent 怎么扛并发"是个高频问题。很多人以为是模型推理慢，其实检索层才是隐藏的瓶颈。向量检索、BM25、RRF 融合、重排，每一步都有延迟，串起来可能比模型推理还慢。

优化思路有几个：缓存（相同 query 的结果缓存，命中率在知识库场景往往不低）、批处理（把多个 query 的 embedding 一起算）、异步（多路召回并行发起，而不是串行等待）、降级（高并发时跳过重排，直接用 RRF 结果）。这几招组合下来，吞吐能提升好几倍。

提示：并发压测一定要用真实 query 分布，别用随机字符串。真实 query 的缓存命中率和随机 query 完全不是一个量级。

7. 我踩过的几个坑和对应的解法

第一个坑：BM25 分词把编号切碎了。搜"3.2.1"被切成"3""2""1"，匹配全乱。解法是加自定义词典和正则预处理，把编号、代码、型号保护起来，不让分词器动它们。

第二个坑：RRF 的 k 值照搬论文。论文说 60，但我的场景里 k=60 太平滑，头部区分度不够。后来调到 20 左右，效果更好。k 值要按场景调，别迷信默认值。

第三个坑：向量库和 BM25 的候选集大小不一致。一开始向量召回 Top-10，BM25 召回 Top-50，结果 RRF 融合时 BM25 那路贡献过大。后来统一成每路 Top-20，融合才均衡。

第四个坑：重排模型和 embedding 模型不匹配。重排模型是在特定语料上训练的，如果你的领域差异大，重排效果可能还不如不排。上线前一定要做 A/B 对比，别想当然。

第五个坑：忽略了 query 改写。用户的口语化提问直接检索，召回质量差一大截。加了改写之后，同样的库，命中率提升非常明显。

8. 一套可以直接复用的最小实现

最后给你一套最小可跑的混合检索实现，基于 Chroma + rank_bm25 + 手写 RRF，不依赖重型框架：

import chromadb from rank_bm25 import BM25Okapi import jieba # 1. 准备语料 docs = [...] # 你的文档列表 doc_ids = [f"doc_{i}" for i in range(len(docs))] # 2. 向量库 client = chromadb.Client() collection = client.create_collection("kb") collection.add(ids=doc_ids, documents=docs, embeddings=embeddings) # 3. BM25 tokenized = [list(jieba.cut(d)) for d in docs] bm25 = BM25Okapi(tokenized) def hybrid_search(query, top_k=5, per_route=20): # 向量路 vec_results = collection.query(query_texts=[query], n_results=per_route) vec_ranked = list(zip(vec_results["ids"][0], vec_results["distances"][0])) # BM25 路 tokens = list(jieba.cut(query)) scores = bm25.get_scores(tokens) bm25_ranked = sorted(zip(doc_ids, scores), key=lambda x: x[1], reverse=True)[:per_route] # RRF 融合 fused = reciprocal_rank_fusion([vec_ranked, bm25_ranked], k=60) return fused[:top_k]

这套代码不到 50 行，但已经包含了混合检索的核心。你可以在此基础上加重排、加缓存、加 query 改写，逐步演进。

我个人在实际项目里的体会是：RAG 的效果提升，80% 来自检索链路的工程优化，而不是换更大的模型。把混合检索、RRF、重排这几件事做扎实，比盲目追新模型实在得多。至于 Agent 记忆和并发，那是另一条战线，但底层逻辑是一样的——先搞清楚瓶颈在哪，再动手优化，别一上来就堆方案。