先判断错误发生在哪一层
RAG 最初的研究论文把参数化模型记忆与外部非参数化记忆结合起来。今天的 RAG 系统通常把多个步骤包装成一次对话：理解问题、检索文档、选择片段、生成回答、添加引用。只给最终回答打一个“好”或“坏”的分数，无法告诉工程团队应该修改索引、查询、排序还是提示词。
第一项指标是证据召回：正确回答所需的材料是否出现在前若干个检索结果中？如果没有，生成模型再强也只能猜测。第二项是证据精度：返回的片段中有多少真正与问题有关？大量无关文本会挤占上下文，并诱导模型混合不同版本或不同客户的数据。
把回答拆成可以核查的陈述
一段流畅文字可能同时包含正确事实、合理推断和没有依据的补充。评估时应把回答拆成独立陈述，例如日期、金额、资格条件和操作步骤，然后为每一项标记：
- 被引用片段直接支持；
- 需要多个片段共同支持；
- 与来源冲突；
- 来源没有提到；
- 属于明确标注的推断。
“有引用”不是通过条件。引用必须支持它旁边的具体结论，而且链接应指向用户有权访问的正确文档版本。
建立来自真实工作的黄金集合
先收集几十个经过人工复核的问题，而不是立即制造成千上万个合成问题。集合应包含常见问题、过去的事故、旧版政策、信息不足、相似产品名称、多语言输入和用户无权访问的内容。
每个样本保存预期证据、可接受回答的要点、必须拒绝的内容和风险等级。不要把客户聊天原文不加处理地复制到测试库；先最小化个人数据，并设置访问和删除规则。
时间与权限也是答案质量
知识库会变化。同一个问题在三个月前可能有不同答案，所以索引必须保留版本或生效时间。测试“截至某日的政策”时，系统不能引用未来版本。
权限同样需要单独评估。检索层必须在查询时执行访问控制，而不是先取回全部内容再要求模型不要泄露。加入跨团队、跨客户和已撤销权限的测试，确认结果列表本身也不会暴露标题或摘要。
用失败类型指导修复
如果正确证据从未被召回，检查文档解析、分块、元数据过滤、查询改写和嵌入。如果证据出现但排序太低，调整重排器和候选数量。如果证据正确而回答仍添加不存在的内容，收紧回答规则、提供反例，并在证据不足时允许拒答。
不要同时更换模型、索引和提示词。旧版本与新版本应在同一组样本上成对运行，并分别报告总体结果和高风险切片。一次平均分提升不能掩盖权限泄漏或关键政策问题的退步。
可以用于发布决策的记分板
每次版本变更至少报告：证据召回率、无关片段比例、受支持陈述比例、正确拒答率、权限违规数、端到端延迟和每个可接受回答的成本。严重权限或错误行动应设置为零容忍门槛。
真正有用的 RAG 评估不是为了得到一个漂亮分数，而是为了回答两个问题：用户能否从可验证的来源得到正确帮助，以及失败发生时团队能否快速定位并安全回退。
常见问题
RAG 评估最先应该测什么？
先测回答所需的证据是否出现在检索结果中，再测最终回答的每个重要结论是否被引用内容支持。
引用了文档就代表回答正确吗？
不代表。引用可能相关但并不支持具体结论，因此必须把回答拆成可核查的陈述逐项验证。
生产数据可以直接加入评估集吗？
不能直接加入。应先去除敏感信息、取得必要权限、人工确认失败类型，并记录数据的来源和保留规则。