RAG 调优实战指南：混合检索、Query 改写、Rerank 与评估指标怎么做

很多团队做 RAG（Retrieval-Augmented Generation，检索增强生成）时，会遇到一个很典型的尴尬：Demo 看起来很惊艳，上线后却经常答非所问、漏召回、引用不准，甚至同一个问题换个问法结果就不稳定。
问题往往不在“大模型不够强”，而在 RAG 链路没有被系统调优。RAG 的效果由检索、召回、排序、上下文组织、生成约束和评估体系共同决定。只盯着 Prompt，或者只换 Embedding 模型，通常很难解决根因。

本文用工程视角总结一套 RAG 调优方法，覆盖混合检索、Query 改写、Rerank、上下文压缩、效果评估与常见误区，适合知识库问答、智能客服、企业搜索、技术文档助手等场景参考。

一、先理解 RAG 的核心链路

一个典型 RAG 系统大致包含以下步骤：

1. 用户提出问题；
2. 系统对问题做 Query 理解与改写；
3. 从知识库中召回候选片段；
4. 对候选片段进行重排、过滤与去重；
5. 将高质量上下文交给大模型；
6. 大模型基于上下文生成答案；
7. 系统返回答案、引用来源与置信度；
8. 通过日志、反馈和评测集持续优化。
   可以把 RAG 看成“搜索系统 + 生成系统”的组合。搜索负责找对资料，生成负责把资料讲明白。如果搜索阶段没有召回正确内容，大模型再强也只能“聪明地胡说”。如果召回内容太多、太乱、重复严重，模型也容易抓错重点。
   因此，RAG 调优的第一原则是：不要只优化最后的回答，要分段定位问题。

二、常见痛点：RAG 为什么会答不好？

1. 召回不到正确内容

用户问的是“如何配置权限”，知识库里写的是“访问控制策略”。语义相近，但关键词不同，如果只做关键词搜索，可能搜不到；如果只做向量检索，也可能因为领域术语、缩写、版本号、代码符号而召回不稳定。

2. 召回太多但排序不准

系统可能找到了相关片段，但真正有答案的片段排在第 8、第 12 位，最后没有进入上下文窗口。用户看到的结果仍然是错误答案。

3. 文档切分不合理

Chunk 太小会丢失上下文，Chunk 太大会引入噪声。比如一个接口参数说明被切到两个片段里，模型拿到其中一半就容易误解。

4. Query 没有被正确理解

用户问题常常带有省略、口语、上下文依赖和多意图。例如“这个报错怎么解决”，如果系统不知道“这个”指的是哪类报错，就很难检索正确资料。

5. 缺少评估闭环

不少团队凭主观体验调 RAG：今天觉得变好了，明天换一批问题又变差。没有固定评测集、指标和失败归因，就无法稳定迭代。

三、混合检索：不要在关键词和向量之间二选一

RAG 检索最常见的两类方法是关键词检索和向量检索。
关键词检索擅长处理：

• 产品名、接口名、字段名；
• 错误码、日志片段、版本号；
• 精确短语；
• 专有名词和缩写。
  向量检索擅长处理：
• 同义表达；
• 口语化问题；
• 概念相近但用词不同的问题；
• 需求描述类问题。
  两者各有盲区，所以生产环境更推荐混合检索（Hybrid Search）。

典型做法

常见混合检索流程如下：

1. 对同一个 Query 同时执行关键词检索和向量检索；
2. 分别取 Top K 候选结果；
3. 对候选结果合并、去重；
4. 使用归一化分数或 RRF（Reciprocal Rank Fusion）融合排序；
5. 再交给 Rerank 模型做精排。

RRF 融合示例

RRF 的思路很简单：一个文档在多个排序结果中都靠前，就应该获得更高分。

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

其中rank_i(d)是文档 d 在第 i 个检索器中的排名，k 是平滑参数，常用 60。
这个方法实现简单、鲁棒性好，不要求不同检索器的分数可直接比较，因此很适合 RAG 初期落地。

四、Query 改写：让用户问题更适合检索

用户不会总是用知识库里的标准术语提问。Query 改写的目标不是“美化问题”，而是提升召回质量。

1. 同义词扩展

例如用户问：

系统怎么限制不同用户能用哪些工具？

可以扩展为：

用户权限、工具权限、访问控制、RBAC、ABAC、最小权限、工具调用授权

这样更容易召回权限设计相关文档。

2. 上下文补全

多轮对话里，用户可能说：

那这个怎么排查？

系统需要结合上一轮内容补全为：

CSDN 草稿保存失败时如何排查 Chrome 调试端口、登录态和编辑器导入问题？

3. 多 Query 生成

对于复杂问题，可以生成多个检索 Query：

• 原始问题；
• 关键词版本；
• 语义扩展版本；
• 假设答案版本（HyDE）；
• 过滤条件版本。
  多 Query 能提高召回率，但会增加成本和噪声，所以需要配合去重和 Rerank。

Query 改写模板

请将用户问题改写为适合知识库检索的 3 个查询语句： 1. 保留用户原始意图； 2. 补充必要上下文； 3. 加入可能的专业术语和同义词； 4. 不要编造用户没有提到的限制条件。 用户问题：{{question}} 对话上下文：{{history}} 领域词表：{{domain_terms}}

五、Rerank：把真正有用的内容排到前面

召回阶段更关注“别漏掉”，Rerank 阶段更关注“排得准”。
向量检索返回的 Top K 结果不一定最适合回答问题，因为向量相似度只代表语义接近，不代表片段包含答案。Rerank 模型会同时阅读 Query 和候选片段，判断片段对回答问题的相关性。

推荐流程

初召回 Top 50 或 Top 100 → 去重与过滤 → Rerank 精排 → 取 Top 5 到 Top 10 进入上下文

Rerank 的收益

• 提升答案命中率；
• 降低无关片段进入上下文的概率；
• 改善引用准确性；
• 支持更复杂的语义匹配。

需要注意的成本

Rerank 会增加推理成本和延迟。实际落地时可以：

• 只对 Top 50 做 Rerank；
• 对热门问题缓存 Rerank 结果；
• 对低风险问题使用轻量模型；
• 对高价值问题使用更强模型。

六、文档切分：Chunk 不是越小越好

文档切分是 RAG 效果的底层变量。切分不好，后面的检索和生成都会受影响。

常见切分策略

1. 按标题层级切分：适合技术文档、产品手册；
2. 按段落切分：适合 FAQ、说明文；
3. 固定 Token 长度切分：实现简单，但容易切断语义；
4. 语义切分：效果更好，但实现成本更高；
5. 父子 Chunk：小 Chunk 用于检索，大 Chunk 用于生成。

实践建议

• 技术文档优先按标题层级切；
• Chunk 中保留标题路径，例如“权限设计 > 工具权限 > 审批流程”；
• 对代码、表格、接口参数避免硬切；
• 设置合理 overlap，避免上下文断裂；
• 对超长文档保留摘要字段，辅助检索。

示例

不推荐：

把所有文档按 500 字一刀切。

更推荐：

一级标题 + 二级标题作为结构边界； 每个 Chunk 保留标题路径、文档来源、更新时间、版本号； 对超过长度的章节再做语义切分。

七、上下文组织：召回到了也要喂得对

即使检索结果正确，如果上下文组织混乱，模型也可能回答不好。
推荐在 Prompt 中明确：

• 只基于给定资料回答；
• 引用资料编号；
• 资料冲突时说明冲突；
• 找不到答案时明确说不知道；
• 优先使用更新版本的资料。

上下文模板

你是企业知识库问答助手。请只基于以下资料回答用户问题。 如果资料不足，请说明“当前知识库没有足够信息”。 回答时引用资料编号，例如 [1]、[2]。 用户问题：{{question}} 资料： [1] 标题：{{title_1}} 来源：{{source_1}} 更新时间：{{updated_at_1}} 内容：{{content_1}} [2] 标题：{{title_2}} 来源：{{source_2}} 更新时间：{{updated_at_2}} 内容：{{content_2}}

八、效果评估：没有评测集，就没有稳定优化

RAG 调优必须建立评估体系。否则每次改参数都像“玄学”。

1. 检索指标

常用指标包括：

• Recall@K：正确资料是否出现在前 K 个结果中；
• MRR：第一个正确结果排名是否靠前；
• NDCG：排序质量；
• 命中文档覆盖率：不同知识类型是否都能被召回。

2. 生成指标

可以评估：

• 答案是否正确；
• 是否基于上下文；
• 是否引用准确；
• 是否遗漏关键步骤；
• 是否出现幻觉；
• 表达是否清晰。

3. 业务指标

最终还要看业务效果：

• 用户问题解决率；
• 人工转接率；
• 用户点赞/踩比例；
• 平均响应时间；
• 单次问答成本；
• 高风险错误率。

评测集模板

九、实践调优路线图

如果你正在从 0 到 1 优化 RAG，可以按这个顺序来：

第一步：建立基线

先固定一批真实问题，记录当前系统的召回结果、答案质量和失败案例。不要一上来就改模型。

第二步：优化知识库结构

清理过期文档、重复文档和无来源内容。补充标题、来源、更新时间、版本号等元数据。

第三步：调整切分策略

按文档类型分别设置 Chunk 策略，不要所有文档统一一刀切。

第四步：引入混合检索

关键词检索解决精确匹配问题，向量检索解决语义匹配问题，两者融合提升稳定性。

第五步：增加 Query 改写

对口语化、多轮上下文、专业术语不一致的问题进行改写和扩展。

第六步：接入 Rerank

对候选结果做精排，把真正能回答问题的片段放到前面。

第七步：优化上下文与生成约束

减少噪声内容，要求模型引用来源，资料不足时不要强答。

第八步：上线评估闭环

把用户反馈、失败案例和线上日志持续沉淀到评测集中。

十、常见误区

误区一：只换大模型，不改检索链路

大模型可以提升表达能力，但不能凭空知道知识库里没有召回的内容。RAG 的根因常常在检索和排序阶段。

误区二：Embedding 模型越大越好

更大的 Embedding 模型不一定带来更好的业务效果。领域词表、切分策略、元数据和评测集同样重要。

误区三：Top K 越大越好

Top K 太大会带来更多噪声，占用上下文窗口，反而降低答案质量。应该通过 Rerank 和过滤选择高质量片段。

误区四：只看答案，不看引用

RAG 的可信度很大程度来自可追溯引用。如果答案看起来正确但引用错了，系统仍然不可靠。

误区五：没有区分问题类型

事实查询、操作步骤、故障排查、对比分析、多文档总结，对检索和生成策略的要求不同。一个统一 Prompt 很难覆盖所有场景。

十一、可直接复用的 RAG 调优清单

上线前建议检查：

• 是否有固定评测集；
• 是否记录 Recall@K、MRR、答案正确率；
• 是否支持关键词 + 向量混合检索；
• 是否对 Query 做上下文补全和术语扩展；
• 是否对 Top K 候选做 Rerank；
• 是否保留文档来源、更新时间、版本号；
• 是否有引用和“不知道”机制；
• 是否能追踪每次回答使用了哪些 Chunk；
• 是否定期清理过期和重复知识；
• 是否把用户反馈进入评测集。

总结

RAG 调优不是单点优化，而是一套系统工程。混合检索解决“召回更全”，Query 改写解决“问法更适合检索”，Rerank 解决“排序更准确”，评估体系解决“优化可验证”。
真正稳定的 RAG 系统，不是靠一次 Prompt 调参做出来的，而是靠数据、链路、评测和反馈闭环持续迭代出来的。
如果只记住一句话：先让系统找对资料，再让模型基于资料好好回答。RAG 调优的核心，就是持续提升“找得到、排得准、答得稳、可追溯”。