RAG评估应从检索开始。如果正确的证据从未到达模型,提示调整和模型升级只会让错误的上下文听起来更有说服力。将检索、生成和操作作为单独的阶段进行测试。保持一个小的、版本化的回归集,当任何阶段变得更糟时,它会失败。
读者水平: 中级。本指南假设您知道检索增强生成(RAG)在请求语言模型回答之前查找文档。
在本指南中
RAG评估有三个独立的失败层
RAG应用程序是一个管道。最终答案的一个分数隐藏了哪个组件需要改进。
| 层 | 要回答的问题 | 有用的起始指标 |
|---|---|---|
| --- | --- | --- |
| 检索 | 系统是否找到了并对问题所需的证据进行了排名? | 命中率或召回率@k,精确度@k,MRR或NDCG |
| 生成 | 模型是否正确使用了该证据? | 基础性、完整性、相关性、弃权 |
| 操作 | 管道在实际约束下是否正常工作? | p95延迟、成本、错误率、新鲜度、访问控制失败 |
顺序很重要。检索是上游的。生成器无法引用从未进入其上下文的政策段落,而流畅的答案并不能证明检索器有效。
微软当前的 RAG评估文档 在实现术语上做了相同的分离。它提供了排名证据的文档检索度量,然后在答案层评估基础性、相关性和响应完整性。文档检索评估器包括保真度、NDCG、XDCG、最大相关性和缺失相关性判断。

_一个有用的RAG评分卡将检索、生成和操作检查作为独立层可见。_
为什么一个端到端的分数提供弱调试证据
几个研究框架从不同的方向得出了相同的实际结论。
RAGChecker 分别评估检索器和生成器的行为。其作者比较了十个领域的八个RAG系统。他们的指标包括检索的声明召回率和上下文精确度,以及生成的上下文利用率、噪声敏感性、幻觉和忠实度。在280对元评估中,RAGChecker的总体评估分数与人类偏好的斯皮尔曼相关性为0.609。两位人类注释者达到了0.689。自动评估是有用的,但并没有消除人类差距。
Ragas 提出了无参考的忠实度、答案相关性和上下文相关性的度量。在其WikiEval比较中,与人类偏好的一致性在忠实度上为0.95,在答案相关性上为0.78,在上下文相关性上为0.70。作者发现上下文相关性最难判断。将这些数字视为该研究的结果,而不是每个评审、数据集或领域的普遍准确率。
一个更新的框架,RAGe,增加了组件选择和硬件遥测。它评估跨块、嵌入、检索、存储和生成的管道配置,同时修剪超过延迟或VRAM限制的组合。该论文默认使用Natural Questions、NewsQA和TriviaQA,并支持自定义CSV或JSON数据集。其主要贡献是提供了一种在资源约束下比较质量的方法;它并没有建立一个在所有领域中获胜的配置。
这些论文共同支持一种诊断方法。它们并没有证明某个特定的度量或库足以用于生产。
在选择指标之前构建测试集
从您服务的领域中选择40到60个问题开始。这个范围是一个实用的起点,而不是统计法则。它足够大,可以暴露几种失败类型,同时又足够小,以便在每次重大更改后进行人工审查。
至少包括五个查询类别:
生产日志可以建议问题,但在将示例添加到评估集之前,请删除个人数据和机密信息。最近关于生产RAG评估的 从业者讨论 也强调了固定查询、版本化配置以及单独的检索和生成检查。该讨论是关于工作流程痛点的轶事证据,而不是证明该方法在每个系统中有效。
将判断与稳定的文档ID存储在一起,附上任何复制的文本。当您调整分割器时,块边界会发生变化。一个规范的源ID可以让同一测试在这种变化中生存。
{ "query_id": "refund-window-01", "query": "客户退还未开封物品的时间是多久?", "relevant_document_ids": ["returns-policy-v4"], "required_claims": ["未开封的物品可以在30天内退还。"], "must_abstain": false, "allowed_roles": ["customer", "support"], "as_of": "2026-07-01" }
对于无法回答的情况,将 `relevant_document_ids` 设置为空列表,并将 `must_abstain` 设置为 `true`。对于受限情况,在两个角色下运行相同的查询。授权用户应检索文档;未授权用户不应了解该文档的内容。
构建自己语料库和应用层的团队应在测试集旁边版本化内容合同。相同的规则适用于 使用Next.js和AI构建的自定义数据系统:架构或内容更改可以在不触及提示的情况下改变检索。
第一步:在不生成答案的情况下评估检索
通过检索器运行每个查询,并保存排名结果ID、分数、时间戳和访问决策。现在不要调用语言模型。
选择与证据形状匹配的指标
当一个正确的文档足够时,使用 hit rate@k。它询问在前 `k` 个结果中是否至少出现了一个相关来源。
当答案需要多个来源时,使用 recall@k。它测量在前 `k` 中出现了多少已知的相关文档。
当无关上下文代价高或分散注意力时,使用 precision@k。高召回率和低精确度可能会使生成器淹没在噪声中。
当第一个相关结果最重要时,使用 MRR。当几个分级结果应以有用的顺序出现时,使用 NDCG。微软在其评估器中记录了NDCG和相关的排名检索度量,而RAGChecker使用声明召回率和上下文精确度将检索到的证据与答案所需的声明联系起来。
不要默认收集每个指标。选择一个覆盖度量和一个排名或噪声度量。仅在它改变决策时添加度量。
在更改模型之前对未命中进行分类
检索失败通常落入一小部分:
每个失败都有不同的责任人。重新嵌入无法修复缺失的文档。更大的语言模型无法修复权限过滤器。当证据存在但顺序错误时,重新排名可能会有所帮助。
对于与工具连接的应用程序,保留检索请求、过滤器、结果ID和工具响应在跟踪中。这符合 MCP开发者工作流程 中描述的更广泛控制模式:检查合同、状态转换和最终文本。
第二步:在固定证据上评估生成
一旦检索达到其阈值,冻结检索到的上下文并将其重放到生成器中。这将提示或模型更改与索引更改隔离开来。
测量四种行为:
参考答案可以帮助完整性。作为唯一的真相来源时,它的用处较小,因为几种措辞可能都是正确的。尽可能存储所需的声明和支持文档ID。
使用故意不完整的上下文运行第二次生成测试。一个可靠的系统应该暴露不确定性,而不是从模型记忆中填补空白。当语料库包含私有、变化或特定领域的事实时,这一点尤为重要。
模型选择仍然会影响答案质量、延迟和成本,但它是在检索证据之后。如果相同的固定上下文在生成器之间失败,请比较 模型和API权衡。如果上下文本身是错误的,改变生成器是徒劳的。
将安全和冲突案例添加到检索套件
普通的相关性测试会遗漏对抗性或冲突证据。
2026年7月的一篇关于 RAG中的多态性Sybil中毒 的论文测试了支持相同攻击者选择答案的词汇不同的段落组。在论文的强制曝光设置下,多态段落的劫持率为22.8%,而重复的单态段落为4.0%。令牌重叠过滤器捕获了所有单态集群,而没有捕获任何多态集群。
该结果并未测量这种攻击在生产中成功的频率。作者将检索到的混合固定为六个攻击段落、两个金段落和两个填充段落,以隔离读者行为。他们还报告了一个攻击类别的局限性、数据集污染风险、500个问题的消融和基于LLM的验证。
有用的评估教训更为狭窄:对“正确”和“攻击者目标”以外的情况进行分类。该论文跟踪了四个结果:
将冲突案例添加到您自己的集合中。包括不同措辞的重复声明、与当前政策相矛盾的过时来源,以及与权威来源冲突的低信任来源。记录系统是否回答、弃权或漂移。
在信任其分数之前校准LLM评审
LLM评审使回归测试更便宜,特别是在基础性和声明覆盖方面。它们仍然是软件依赖项,具有提示、模型版本、解析行为和已知盲点。
使用四个控制:
Ragas和RAGChecker的研究都表明了校准的重要性。协议因维度而异,自动相关性仍低于人类协议。数字分数应触发检查,而不是结束检查。
当前的开源版本也显示出对评估器的积极工作。 DeepEval 4.1.3,于2026年7月12日发布,增加了对代理循环和工具权限的确定性检查,同时修复了Ragas集成。 TruLens 2.9.0,于2026年7月23日发布,增加了评审集、A/B标准测试、分数分布分析和黄金集生成。发布活动是维护工程工作的证据,而不是证明任何库是您堆栈的正确选择。
一个最小的RAG回归工作流程
对每个重要的管道更改使用相同的顺序:
一个紧凑的结果记录可以如下所示:
{ "run_id": "rag-2026-07-26-b", "test_set": "support-v7", "corpus_snapshot": "2026-07-25T22:00:00Z", "retrieval": { "recall_at_5": 0.91, "ndcg_at_5": 0.84, "unauthorized_hits": 0 }, "generation": { "grounded_pass_rate": 0.94, "complete_pass_rate": 0.87, "abstention_pass_rate": 0.90 }, "operations": { "p95_ms": 1380, "cost_per_query_usd": 0.0042 } }
这些数字是示例。根据您的风险、基线和错误成本设置阈值。医疗知识助手和产品搜索助手不应共享相同的发布门。
从失败层决定修复
| 症状 | 待检查的证据 | 可能的首要行动 |
|---|---|---|
| --- | --- | --- |
| 相关文档缺失 | 摄取状态、规范ID、过滤器 | 修复摄取或元数据 |
| 相关文档排名过低 | 排名跟踪、查询词、分数 | 测试查询重写、混合检索或重新排名 |
| 正确证据加上不支持的声明 | 声明与上下文映射 | 收紧生成指令或基础性门 |
| 正确但不完整的答案 | 所需声明覆盖 | 修订上下文组装或答案提示 |
| 在缺失证据时回答 | 负面测试和弃权跟踪 | 添加证据充足性门 |
| 质量良好但缓慢 | 阶段时序和资源遥测 | 优化测量瓶颈 |
| 检索到未经授权的来源 | 身份、过滤器、结果ID | 阻止发布并修复授权 |
该表是RAG评估的关键:失败的分数应识别下一个实验。如果不能,度量就离您需要更改的组件太远。
证据支持的内容
这些论文测量了特定的系统和数据集。RAGChecker发现模块化指标可以与人类偏好相关,并揭示检索器-生成器之间的权衡。Ragas发现评审一致性在忠实度、答案相关性和上下文相关性方面有所不同。RAGe展示了一个将质量指标与延迟和内存约束结合的框架。中毒基准显示,一个受限的攻击设置产生了明显的劫持、弃权和漂移模式。
证据并未建立普遍的阈值、普遍最佳评估者或生产攻击的普遍性。我的实际解释是分离阶段,保持人工校准的切片,并要求每个指标指向工程行动。
声明检查
| 声明 | 支持证据 | 检查边界 |
|---|---|---|
| --- | --- | --- |
| 检索应与答案质量分开测量 | 微软RAG评估者;RAGChecker | 架构指导,而不是普遍保证 |
| RAGChecker比较了八个系统跨越十个领域 | RAGChecker论文 | 结果取决于其基准和度量设置 |
| Ragas报告了在三个维度上0.95、0.78和0.70的人类一致性 | Ragas论文,表1 | 研究特定的成对准确性 |
| RAGe包括硬件遥测和配置修剪 | RAGe论文 | 框架贡献,而不是最佳配置的证明 |
| 多态段落在论文的消融中产生了22.8%的劫持率,而单态段落为4.0% | Sybil中毒论文 | 强制6:2:2曝光;不是生产普遍性 |
| DeepEval和TruLens发布了最近的评估功能 | 官方GitHub发布说明 | 维护信号,而不是采用或质量证明 |
