AI 学习笔记（十二）：RAG 评估体系与检索质量调优（实战版）

上一篇我们把本地模型接进知识库和 RAG 流程，这一篇继续 Phase 4，解决真正决定效果上限的问题：
怎么评估 RAG，怎么系统化调优检索质量，而不是靠感觉改参数。

很多团队做了向量库和问答接口后，都会遇到同一个瓶颈：
“能回答一些问题，但稳定性差，错了也不知道是检索错还是生成错。”
要走出这个阶段，必须先有评估基线，再做有证据的优化。

1. 先把问题分层：检索质量不等于最终回答质量

RAG 至少要分两层看：

1. Retrieve 层：是否把“正确证据”找出来
2. Generate 层：是否基于证据给出正确答案

如果不分层，只看“用户觉得答得好不好”，调优会很盲目。
一个常见误判是：其实检索已经命中，但生成阶段没有引用或总结偏了。

2. 最小可用评测集：先做 30~50 条高价值问答

不要一开始追求几千条数据。先做一套小而准的评测集：

• 每条样本包含：question、expected_doc_ids、expected_answer_points
• 覆盖高频场景、易混淆场景、边界场景
• 标记业务类型（FAQ、规范问答、故障排查、流程说明）

建议先从“真实用户历史问题”抽样，而不是纯人工臆造问题。
这样测出来的结果才和线上体验相关。

3. 先看检索指标，再看生成指标

3.1 检索层核心指标

• Recall@K：前 K 条结果是否包含目标文档
• MRR：正确结果出现在第几位
• Hit Rate：至少命中一次正确证据的比例

如果这三个指标都低，先别动 prompt，优先修检索链路。

3.2 生成层核心指标

• Citation Accuracy：答案引用是否真实、是否对得上原文
• Groundedness：答案是否可由检索片段支撑
• Answer Correctness：关键结论是否正确、是否遗漏关键点

这层建议先做人工抽样评审，再逐步引入自动评估器。

4. 常见失败归因模板（建议固化到日志）

每次失败至少归因到以下之一：

• index_miss：文档未入库或 metadata 错误
• retrieve_miss：已入库但检索没命中
• rank_miss：命中但排序太靠后
• context_overflow：命中但拼接后被截断
• generation_drift：有证据但回答偏离证据

这一步很关键。没有结构化归因，就没有可重复调优。

5. 检索调优的稳妥顺序（避免无效折腾）

推荐按下面顺序做，收益通常最高：

1. 调整分块策略：按标题/语义分块，控制 chunk 长度和 overlap
2. 规范 metadata：保留 docId/section/updatedAt/source
3. 改检索策略：向量检索 + 关键词检索（Hybrid）
4. 引入重排：对 topN 做 rerank，提高前几位准确率
5. 调整 topK 和阈值：按问题类型动态配置
6. 最后再改 prompt：强化引用约束和拒答策略

为什么是这个顺序？因为前 5 步主要解决“找不准”，最后一步才是“说得更稳”。

6. 一个可执行的评估-调优闭环

可以固定成每周一次的小循环：

1. 用同一评测集跑基线（记录版本号）
2. 只改一个变量（例如 chunk size 或 rerank 模型）
3. 对比 Recall@K/MRR/Citation Accuracy
4. 若指标提升且无明显副作用，再进入下一轮

不要同时改多个变量，否则无法判断真正有效因子。

7. 上线前最低要求（建议作为发布门槛）

• 关键场景 Recall@5 达到团队设定阈值
• 引用准确率稳定在可接受范围
• 无证据时能稳定拒答，不胡编
• 有失败归因日志，支持回放

满足这些条件后，再考虑扩大知识库规模或接入更复杂的 Agent 流程。

总结

RAG 调优不是“调 prompt 的艺术”，而是一个工程化评估问题：

• 先有评测集和基线
• 再按层拆解问题
• 再做单变量迭代优化
• 最后把经验固化为发布门槛

只要这条链路跑起来，RAG 质量会稳定提升，而且每一次优化都可解释、可复盘、可继承。

参考资料

• LangChain Retrieval Concepts
• LlamaIndex Evaluation
• BEIR Benchmark
• RAGAS

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-rag-evaluation-retrieval-quality-tuning/