RAG 系统效果评估指南（离线 + 在线）

一、评估的意义与总览

1.1 为什么必须评估？

RAG 系统的效果是多个环节叠加的结果（分块 → 检索 → 重排 → 生成），任何一环出问题都会影响最终答案。没有评估，就无法判断：

• 改动到底有没有变好？
• 该优化分块、检索、还是 Prompt？
• 上线的系统是否满足业务要求？

RAG 优化必须"用指标说话"，否则一切优化都是拍脑袋。评估是 RAG 工程的方向盘。

1.2 两类评估：离线 vs 在线

正确姿势：先用离线评估快速迭代验证，达标后再上线；用在线评估持续监控，两者互补，形成闭环。

1.3 三层评估视角

┌─ 检索层评估：检索到的 chunk 是否相关？──────── 召回 / 精度
├─ 生成层评估：生成的答案是否正确、忠实、完整？─ 忠实度 / 相关度 / 答案质量
└─ 端到端评估：用户最终体验如何？───────────── 综合质量 / 业务指标

二、评估的三个对象：检索、生成、端到端

2.1 为什么要把评估拆开？

• 端到端分数差，不知道是"没检索到"还是"检索到了但没答好"——拆开才能定位。
• 检索和生成各自优化，反馈回路更清晰。

2.2 完整评测链路

评测问题集 → 系统执行（检索+生成） → 分别打分：
   ├─ 检索结果 → 检索指标（Recall/MRR...）
   ├─ 生成答案 → 生成指标（忠实度/相关度...）
   └─ 最终回答 → 端到端指标（综合分/业务指标）

三、离线评估：指标与数据

3.1 检索层指标（衡量"捞得全不准、排得对不对"）

（1）Recall@K —— 召回率（最重要，衡量"捞得全"）

Recall@K = 正确答案所在 chunk 出现在 Top-K 中的问题数 / 总问题数

• 意义：RAG 检索的命脉。Top-K 里没有正确 chunk，生成再好也无从谈起。
• 关注点：评估分块、Embedding、混合检索、查询改写是否有效。
• 通常 K=5 或 10，理想应接近 0.8~1.0。

（2）Precision@K —— 精确率（衡量"捞得准"）

Precision@K = Top-K 中相关 chunk 的数量 / K

• 衡量检索结果里有多少是真正相关的（检索结果越干净越好）。

（3）MRR（Mean Reciprocal Rank）—— 排得够不够靠前

MRR = 平均 (1 / 第一个正确结果的排名)

• 只有第一个正确答案的位置重要。如果正确答案总排第 1，MRR=1.0。
• 关注点：评估 Rerank 是否把正确答案提到最前面。

（4）NDCG（Normalized Discounted Cumulative Gain）—— 排序质量

• 对"多个相关结果分布在前几位"加权评估，排名越靠前权重越大。
• 比 MRR 更全面（考虑多个相关结果），评估 Rerank 效果常用。

（5）其他

• Hit Rate：正确答案是否在结果集中（= Recall@K 的 0/1 形式）。
• MAP（Mean Average Precision）：多个相关结果时综合 precision 均值。

3.2 生成层指标（衡量"答案质量"）

生成层是文本质量评估，通常三种方式：

1. 人工打分（最准，慢、贵）——金标准；
2. LLM-as-a-Judge（自动、可规模化）——主流；
3. 规则/传统指标（BLEU/ROUGE，机械、不太适用 RAG，仅参考）。

核心指标（RAGAS 框架的标准维度）：

① 忠实度 / 事实性（Faithfulness / Groundedness）

• 答案是否完全基于检索到的上下文，有没有编造（幻觉）。
• 打分方式：把答案拆成若干声明（claim），逐条检查是否能在上下文中找到依据。
• 意义：RAG 的核心价值就是减少幻觉，这是最关键的生成指标。

② 答案相关性（Answer Relevancy）

• 答案是否针对用户问题，没有答非所问。
• 打分方式：让 LLM 判断答案对问题的相关性（1~5 分）。

③ 上下文相关性（Context Relevance）

• 检索到的上下文是否包含回答问题所需的信息（检索质量对生成的直接影响）。
• 打分方式：LLM 判断上下文中"有用部分"的比例。

④ 正确性 / 完整性（Correctness / Completeness）

• 答案内容是否正确、完整，有没有遗漏关键信息。
• 有标准答案时用语义相似度/LLM 对比。

⑤ 其他

• 可读性、流畅度、语言风格、引用准确性（Citation Accuracy——答案里的引用是否真的支持对应句子）。

3.3 端到端综合指标

• 综合质量分：LLM 或人工对最终回答整体打分（正确性+完整性+相关性+可读性）。
• 失败率：明显错误/不相关回答的比例。
• 业务相关目标：如客服场景的"一次解决率"、问答场景的"答案采纳率"。

3.4 离线评测数据怎么来？

⚠️ 评测集要与优化集分离：调参用的"开发集"和最终验收的"测试集"分开，避免过拟合评测集。

四、在线评估：指标与数据

4.1 为什么离线够了还要在线？

• 离线评测集可能覆盖不到真实分布（用户真实问法和评测集有偏差）。
• 用户的行为反馈（点赞/点踩/追问/放弃）是离线无法模拟的。
• 需要持续监控线上质量退化（新数据、模型漂移、检索库更新）。

4.2 在线评估分三类

（1）质量指标（真实打分）

• 人工抽检 / 众包标注：定期抽样线上问答，人工打分（正确性、忠实度）。
• LLM-as-a-Judge 在线抽样：对线上问答抽样用 LLM 自动打分。

（2）用户行为指标（隐式反馈）

（3）业务指标（最终目标）

• 客服场景：一次性解决率、工单量变化、平均处理时长。
• 电商/内容：转化率、留存、点击率。
• 企业搜索：任务完成率、用户满意度（CSAT/NPS）。

4.3 在线评估的工程手段

• A/B 测试：新旧版本分流量对比，用统计显著性判断优劣（不能只靠感觉）。
• 金丝雀/灰度发布：新模型/新索引先小流量，监控指标无异常再全量。
• 指标监控大盘：实时监控召回率（抽样人工）、答案质量分、用户行为指标、延迟/错误率。
• 数据回流：把线上差评案例加入评测集，迭代优化（离线↔在线闭环）。

五、自动化评估工具与框架

建议：离线用 RAGAS（中文也适用，需配置中文 Embedding/LLM 打分器）；在线用 LangSmith/Langfuse 做监控 + 人工抽检。

六、评估流程与迭代闭环

6.1 建立评估体系四步走

Step1 建评测集：收集 100 个真实问题 + 黄金答案 + 标准答案来源
Step2 定基线与工具：跑出当前各项指标（Recall@K、忠实度...）
Step3 分级优化：先检索（Recall）→ 再生成（忠实度）→ 再端到端
Step4 回归验证：每次改动全量重跑评测集，确认指标不降反升

6.2 分层迭代（遵循"先检索后生成"）

6.3 判断改动是否有效

• 只改一个变量，全量跑评测集，对比前后指标（A/B in offline）。
• 指标提升且无副作用（如 Recall 升了但忠实度降了，需权衡）才采纳。
• 保留基线版本，方便回滚和对照。

七、常见坑与最佳实践

7.1 常见坑

1. 只看端到端分数，不拆分 → 无法定位问题在检索还是生成。
2. 评测集与真实场景脱节 → 离线好、线上崩。评测问题必须来自真实用户。
3. 评测集和调参集不分 → 过拟合评测集，线上失效。
4. LLM 打分器不稳定 → 用固定 prompt、固定温度（temperature=0）、多次采样取均值。
5. 忽略忠实度 → 答案漂亮但全是编造，RAG 白做了。
6. 在线只看点赞率 → 用户行为噪声大，需结合人工抽检。
7. 指标与业务脱节 → 检索指标好≠业务达标，最终看业务目标。

7.2 最佳实践清单

• 评测集 100 个真实问题起步，覆盖事实型/语义型/多跳型/边界型。
• 分离开发集与测试集。
• 离线：检索指标（Recall@K/MRR）+ 生成指标（忠实度/相关度）一起看。
• LLM 打分统一配置（temperature=0、固定 prompt、中文语言设置）。
• 在线：行为指标 + 人工抽检 + A/B 测试三者结合。
• 每次改动全量回归，用数据说话。
• 建立"线上差评 → 进评测集 → 优化 → 上线验证"的闭环。

八、总结速查

关键数字经验（仅供参考，需按场景实测）：

• Recall@5 ≥ 0.8 通常算检索合格。
• 忠实度 ≥ 0.85 算生成合格（具体依赖打分器）。
• 评测集 100 条起步，越多越稳定。

一句话总结：离线评估用「召回率（捞得全）+ 忠实度（不编造）」两大支柱快速迭代，在线评估用「行为指标 + 人工抽检 + 业务指标」持续监控；三层拆开定位、一改一测、闭环回归，才是科学的 RAG 评估。