只看回答满意度不够：把 RAG 质量拆成三层
RAG 质量至少要分三层看：检索是否找到必要证据，答案是否忠实使用证据，用户是否得到完成任务所需的信息。满意度可以补充体验反馈，却不能代替这三层核查。一个流畅而简短的错误答案也可能获得好评。
第一层检查证据够不够
以申请培训为例，正确回答可能需要资格、材料和截止时间三处依据。检索找到了其中两处，属于证据不完整；找到另一类培训的完整说明，则属于对象错误。两者都不能因为结果里出现相关关键词而判为召回成功。
评测时先在原件中标出必要证据，再查看检索候选和最终上下文。需要区分“初始找到了”和“最终传给模型了”，否则排序或截断造成的缺口会被误归到生成阶段。文档本身没有答案时，则应标记内容缺口。
第二层检查答案有没有越过依据
证据齐全后，逐项核查答案中的事实、条件和数字。来源说“通常处理”，回答变成“保证完成”；来源仅覆盖某类人员，回答扩大到所有员工，都属于没有忠实保留依据。引用链接正确，也不能自动抵消这些错误。
| 维度 | 典型失败 |
|---|---|
| 证据召回 | 缺少附表中的例外要求 |
| 回答忠实度 | 把建议写成制度强制要求 |
| 任务可用性 | 事实都对，但未回答用户要交什么 |
Microsoft 的 RAG 评测文档也区分检索、忠实度、相关性和完整性等维度。采用何种评分工具可以另行决定，但这些概念不应被压成一个看不出原因的总分。
第三层检查用户能否继续工作
答案可能每句话都有依据，却只是复述大段政策，没有回答用户下一步该做什么。任务可用性要依据具体意图判断：查金额时需要明确口径，查材料时需要清单，比较方案时需要可比较的条件。不能用“内容丰富”代替完成任务。
这一层也不是鼓励模型额外编造建议。如果现有资料没有提交入口，回答应说明未找到入口，而不是为了显得可操作而捏造路径。可用性的前提仍然是事实与依据可靠。
把三层结果连成改进记录
为每个失败问题记录最早可证实的缺口及后续影响。召回缺失交给资料或检索环节处理，忠实度错误检查上下文和回答行为，任务表达问题调整组织方式。一个问题可以有多个标签，但应保留证据，避免所有失败都被归为模型不好。
汇报时按层展示通过情况，并单列关键业务题。只有第二层提高，不能声称端到端体验必然改善；满意度上升，也不能声称事实错误已经减少。把这些边界讲清楚，团队才能知道下一轮应修复哪一处，而不是反复更换工具。
在企业文档中验证
如果要把本文方法用于企业文档，可预约演示，结合实际资料核对协作、权限与集成方式。
需要在自己的环境中验证时，可先了解私有化部署方案，再确定试用范围与验收要求。