34 RAG 评测：召回率、准确率、幻觉率与引用正确率
RAG 评测：召回率、准确率、幻觉率与引用正确率
RAG 评测要拆开看：先看正确证据有没有被召回，再看模型有没有基于证据正确回答。
[TOC]
1. 这一节到底解决什么问题
前面我们已经把文档上传、解析、切片、Embedding、向量入库、向量检索和基础问答串起来了。到这里，RAG 已经不再只是一个“能回答”的 demo。
从 Day30 开始，重点要慢慢转向工程质量：
答案为什么可信
错误为什么能定位
效果为什么能比较
成本为什么能估算
部署为什么能复现
项目为什么能讲清楚
一个答案错了，不一定是模型不行。可能是检索没召回，可能是召回了但模型没用，也可能是引用无法支持结论。评测就是把这些问题拆开。
2. 先看一个业务场景
同一个问题，Top5 检索结果里已经有正确 chunk，但模型回答时引用了另一个片段，还把限制条件漏了。这说明检索不是主要问题，Prompt、上下文排序或生成阶段才是重点。
这个场景里，最容易出错的地方通常不是某一行代码，而是链路边界没有想清楚。
输入是什么
依赖哪份资料
中间结果怎么保存
失败时返回什么
如何证明改动有效
带着这些问题往下看，后面的设计就不会变成空泛理论。
这一节要先拆开“答案不好”。
RAG 评测不能只问最终答案对不对。
判断顺序可以这样写：
1. 先评测检索：正确 chunk 有没有进 TopK2. 再评测引用：答案使用的来源是否真的支撑结论
3. 再评测生成：模型是否忠实于上下文，有没有编造
4. 最后评测工程指标：延迟、成本、失败率、降级率
5. 每个指标都要能回到一批固定样本，而不是临时挑例子
它解决的是问题归因问题：把问题定位到具体层，检索错了就调检索，来源错了就调引用，生成发散才调 Prompt 或模型。
3. 核心概念
1. Hit@K
正确证据是否出现在前 K 个检索结果中。它衡量检索能不能把答案找出来。
可以把它记成一句话：先看证据有没有来。
2. 答案准确率
答案是否覆盖标准事实点，是否符合业务规则。它衡量用户看到的回答是否可用。
可以把它记成一句话：再看答案有没有答对。
3. 幻觉率
答案中没有上下文支持或与上下文冲突的事实比例。RAG 的目标之一就是降低它。
可以把它记成一句话：无证据事实越少越好。
4. 引用正确率
引用不仅要存在，还要能支持对应结论。引用错比没有引用更危险，因为它会制造虚假的可信感。
可以把它记成一句话：引用要真能证明。
4. 整体流程
graph TD;
A["加载评测集"] --> B["执行检索"];
B["执行检索"] --> C["保存 TopK"]; C["保存 TopK"] --> D["计算检索指标"];
D["计算检索指标"] --> E["生成答案"];
E["生成答案"] --> F["评估事实和引用"];
F["评估事实和引用"] --> G["输出失败样本"];
图里每个节点都应该能单独打日志、单独统计耗时、单独写测试。
这就是我一直强调的：不要把 RAG 写成一个黑盒方法。黑盒方法演示时很爽，排查时很痛苦。
5. 落地步骤
1. 先评检索
保存每题 TopK chunk，计算 Hit@1、Hit@3、Hit@5。检索没命中时，不要急着改模型。
落地时要留下可检查的产物：检索评测报告。
2. 再评生成
固定检索结果后比较 Prompt 或聊天模型。这样变量更少。
落地时要留下可检查的产物：生成评测报告。
3. 按类别统计
售后政策、接口文档、无答案、权限问题分开看，避免平均值掩盖高风险问题。
落地时要留下可检查的产物：分类指标表。
4. 人工抽检
自动评分效率高，但关键样本要人工看，尤其是引用和幻觉。
落地时要留下可检查的产物：人工抽检记录。
6. 数据结构或配置示例
| 项目 | 说明 |
|---|---|
| hitAt5 | Top5 是否包含正确证据 |
| factAccuracy | 事实点正确比例 |
| hallucinationRate | 无证据事实比例 |
| citationSupportRate | 引用支持结论比例 |
| refusalAccuracy | 无答案问题正确拒答比例 |
如果项目里已经有自己的字段命名，可以不照抄这张表。但这些信息最好都能找到对应位置，否则排查问题时会缺证据。
7. 示例
Hit@5 = Top5 中包含正确证据的问题数 / 总问题数
事实准确率 = 正确事实点数量 / 应回答事实点数量
幻觉率 = 无证据支持的事实声明数量 / 全部事实声明数量
引用支持率 = 能支持结论的引用数量 / 全部引用数量
示例的重点不是格式，而是思路：把规则、参数、输入、输出和失败状态显式写出来。
8. 为什么不能简单粗暴地做
不能只用“答案看起来不错”做评测。流畅不等于正确，引用存在不等于引用支持，平均分高也不代表关键问题安全。
很多初学者会希望有一个“最简单固定答案”。但 RAG 项目里，简单粗暴通常会把问题藏起来：短期好像能跑，长期很难维护。
9. 调试和排查路径
当结果不符合预期时，建议按这个顺序排查：
1. 输入问题是否正确
2. 权限范围是否正确
3. 检索候选是否包含正确证据
4. 排序或过滤是否把正确证据丢掉
5. Prompt 是否把证据清楚交给模型
6. 模型是否按证据回答
7. 引用是否能支持结论
8. 日志、成本、耗时是否异常
不要一看到答案不对就去改 Prompt。很多时候问题根本不在 Prompt，而是在解析、切片、过滤、召回或数据版本。
10. 工程取舍
- 自动评测能快速回归，但关键样本需要人工。
- 检索和生成分开评，定位更清楚。
- 发布门槛要包含高风险样本，不只看平均分。
取舍要写在文档里。因为过几周再回来看，你很可能只记得“当时这么做了”，却忘了“为什么这么做”。
11. 常见坑
- 只看最终答案，不保存检索结果。
- 让同一个模型回答又评分，没有人工抽检。
- 无答案问题没有单独统计。
- 引用只检查格式，不检查支持关系。
这些坑不是为了吓人，而是为了让你知道项目坏掉时从哪里下手。
12. 验收清单
- ☐ 检索 TopK 已保存
- ☐ Hit@K 已计算
- ☐ 答案事实点已评分
- ☐ 引用支持已抽检
- ☐ 失败样本有分类
验收清单是博客里很有价值的部分。它能把一篇文章从“我讲了一个概念”变成“你可以跟着做出一个结果”。
13. 落地清单
- ☐ 用 50 题跑一次 Hit@5
- ☐ 抽 10 个答案评引用支持率
- ☐ 找出 5 个幻觉样本
- ☐ 写一份失败分类报告
落地后，建议把结果截图或记录到项目文档里。后面写 README、博客复盘或项目说明时，这些都是现成素材。
14. 小结
RAG 评测的关键是拆层。只有知道错误发生在召回、排序、Prompt、生成还是引用，后续优化才不会乱打补丁。
到这里，你应该能把今天的主题讲成一个完整故事：为什么需要它、它解决哪一层问题、怎么落地、怎么验证、有什么代价。