RAG 答不出来，90% 是召回的问题：2026 年召回率调优的七个杠杆

做过 RAG 的人都有过这种体验：用户问的问题答案明明在文档里，模型却一本正经地说”根据现有资料无法回答”。团队第一反应往往是换更强的模型、调系统提示词、加大 top_k——然后发现改善有限。

原因很简单：RAG 的忠实度问题在生成端，但”答不出来”的绝大部分问题在检索端。生成模型只能就”喂给它的内容”作答。如果正确的 chunk 排在第 47 位，你给 top_k=5，模型就是无能为力。

先做一件事：把召回率单独测出来。构造 50 条真实问题，人工标注每条问题对应的”金标准 chunk”，然后计算 Recall@k。经验上，如果一个 RAG 系统的 Recall@5 低于 0.7，就不要去调生成端了，先把召回修好。

杠杆一：混合检索，别只信向量

纯向量检索擅长语义相似，但对精确匹配很弱——产品型号、错误码、人名、缩写、条款编号，这些恰恰是用户最常问的。BM25 反过来，精确匹配强，语义泛化弱。

生产环境应该做向量 + BM25 的混合检索，然后用 RRF（Reciprocal Rank Fusion）融合两路结果。RRF 不需要分数可比，只利用排名：

score(d) = Σ 1 / (k + rank_i(d))    # k 通常取 60

这个改动通常在半天内上线，Recall@5 能有 10 到 20 个百分点的提升，是最划算的一个杠杆。

杠杆二：查询改写要分场景

不是所有查询都该改写。先做意图分类：

• 原样检索：用户直接复制了一段报错信息，改写反而引入噪声
• 多查询展开：口语化问题，用 LLM 生成 3 个不同角度的检索式，分别检索后合并
• 假设文档（HyDE）：问题很短且抽象时，先让模型生成一段”假设答案”，用它的向量去检索，效果往往更好
• 指代消解：多轮对话中把”它的价格”补全成”XX 产品的价格”

盲目对所有查询做改写，会让延迟涨三倍、召回还变差。用一个小分类器或规则先分流。

杠杆三：分块策略要跟文档类型走

“固定 512 token 重叠 64”这种默认值只在结构均匀的文档上成立。实际业务里至少要区分：

文档类型	推荐策略
规章制度、合同	按条款层级切，保留父标题路径
技术手册	按小节切，代码块不切断
会议纪要	按发言段落切，附上时间与发言人
表格 / 财报	先转成 Markdown 表格，整表入 chunk
FAQ	一问一答为最小单位

更关键的是父子分块：用小的子块做检索（匹配更精准），命中的子块往上追溯父块（上下文更完整）作为生成输入。这一步能同时改善召回精度和答案完整性。

杠杆四：元数据过滤是被低估的大杀器

用户问”2026 年新版的价格政策”，如果知识库里有 2023、2024、2025 三个版本，不给时间过滤纯粹靠语义排序，很容易召回到旧版。

在 chunk 上打结构化标签（生效日期、文档类型、产品线、密级、部门），检索时先过滤再排序。前提是入库时就把元数据抽取做好，这一步经常被跳过，后期补非常痛苦。

杠杆五：重排（Rerank）要把候选量开大

检索 50 条，用 cross-encoder 重排后取前 8 条。常见错误是只检索 10 条然后重排——重排的价值就在于”从大量候选里挑出真正相关的”，候选池太小就失去了意义。

代价是延迟。50 条候选的 rerank 通常增加 80 到 200 毫秒，具体取决于模型和硬件。如果延迟敏感，可以把 rerank 做成异步，或者只对低置信度查询启用。

杠杆六：召回缺失要能归因

做一套”召回失败归因”的诊断流程，把每条失败案例归到以下四类：

1. 分块问题：答案被切断了，金标准 chunk 根本不存在
2. 查询问题：用户表述与文档用词差异过大，需要改写或同义词扩展
3. 索引问题：文档没被正确解析入库（PDF 表格、扫描件）
4. 排序问题：召回了但排名太靠后

每一类的修法完全不同。不归因就调参，等于蒙着眼睛改代码。

杠杆七：把评估集做成资产

每周从线上真实提问里抽样 30 条，人工标注答案与金标准 chunk，累积成回归测试集。每次改索引、改分块、换 embedding 模型，都跑一遍评估。

没有评估集的 RAG 项目，所有优化都是靠感觉。有评估集的团队，能明确回答”这次改动提升了多少”。

一个现实的时间线

按经验，一个中等规模的 RAG 项目，从”能用但经常答不上”到”稳定召回”，通常需要 3 到 6 周，投入主要集中在数据侧而不是模型侧。顺序建议是：

1. 第一周：构造评估集 + 失败归因，先知道问题在哪
2. 第二周：混合检索 + 重排，通常是最大的一次跃升
3. 第三周：分块重构 + 元数据，处理长尾
4. 第四周起：查询改写分流、持续迭代

最后一句实话：RAG 是数据工程，不是提示词工程。愿意在文档解析、分块、标注上投入时间的团队，最终效果会明显好过不断换模型的团队。