一个 RAG 问答系统最容易得到的夸奖是：“它回答得挺像那么回事。”
但企业真正担心的，往往不是它完全答错，而是它用一段流畅的语言，回答了一个没有证据、过期或不属于当前用户权限范围的问题。
所以 RAG 测试不能只给最终回答打分。你至少要把链路拆成四层。
第一层：知识是否找对
用户问“差旅报销的住宿标准”，检索结果却是去年版本的报销制度，或者混入了外包人员不适用的规则。即使模型总结得很顺，也不能算通过。
测试集要包含文档版本变化、相似标题、冲突制度、跨部门规则。并记录每个问题理应命中的文档或段落。
第二层：证据是否被正确使用
检索到了正确文档，也不代表回答就可靠。模型可能只取了其中一句，忽略后面的例外条款；也可能把两段不同场景的内容拼成一个结论。
因此要测试引用完整性：答案中的结论能否追溯到证据；关键数字、范围、角色限制是否被保留。
第三层：不知道时会不会承认不知道
这是很多系统最缺的一层。当知识库没有答案、文档已失效、问题超出权限时，最好的回答不是“猜一个最像的”，而是明确说明信息不足，并告诉用户下一步去哪里确认。
可为每类系统专门准备“不可回答集”：不存在的制度、被删除的产品、需要人工审批的问题、未经授权的信息。
第四层：答案对不同角色是否一致地安全
同一问题，普通员工、HR、财务、管理员看到的答案可能不同。RAG 的权限问题不能只测检索接口；要一直测到最终生成文本，确保引用、摘要、工具补充信息都不越界。
答案正确之前，先看检索是否正确
一个最小可用的评测记录可以长这样：
{
"question": "住宿标准是多少？",
"expected_docs": ["travel_policy_2026_v3#hotel"],
"forbidden_docs": ["travel_policy_2024_v1"],
"must_include": ["城市等级", "发票要求"],
"must_not_include": ["已废止标准"],
"role": "employee"
}
把“ expected_docs ”加进评测，不是要强迫模型逐字引用，而是为了让团队知道：这次错误发生在切分、召回、重排、权限，还是生成。
真正可用的 RAG，不怕被追问
用户追问“这个标准适用于出差到上海吗”“那如果没有发票呢”，系统仍能解释依据、说明边界，才算真的能够进入业务流程。
对测试工程师而言，RAG 测试的吸引力就在这里：你不只验证一个模型输出，而是在验证数据、检索、权限、生成与用户信任组成的一整条链路。
如果你已经会接口自动化，完全可以从一个小知识库项目开始：准备 30 条业务问题、10 条无答案问题、5 个角色权限，再做一份可复用的评测报告。这就是一段非常有含金量的 AI 测试项目经历。
你在使用企业知识库时，最不能接受的错误是答错、答旧，还是越权？
