RAG 的演示总是很漂亮：输入干净、问题明确、答案带引用。真正出问题的场景往往安静得多——系统引用了过期的证据、或者把没有的信息补了出来，而输出读起来依然通顺，没人发现。
带固定题集的回归评测值得做（LLM 打分、检索/生成失败分类），但它有个盲区：只测你想得到的问法。下面是一个五分钟的手工测试，用来补上这个盲区。
准备两份文档
同一个事件，写两份合成文档：
- 文档 A（旧）："政策变更 3 月 1 日生效，仅适用于标准版。"
- 文档 B（新）："政策变更 3 月 15 日生效，适用于所有版本。"
两份都上传，然后问"正确答案取决于哪份是当前版本"的问题：
- "政策变更什么时候生效？"——应当引用文档 B。
- "基础版适用吗？"——只有文档 B 能回答，而且只有当工具说明它引用了哪份文档时，你才能核对。
核对三件事
- 是否引用当前来源。 答案引用的是文档 B，还是把两个日期揉成一个看起来合理的数？
- 缺失信息是否诚实。 问一个两份文档都没写的（"谁批准的这次变更？"）。合格的系统说"文档中没有"；不合格的系统会补一个名字。
- 权限边界。 如果工具支持按人/按文件授权，把文档 B 移除后再问一次。答案应该诚实地降级，而不是悄悄退回文档 A、把它当成仍然权威。
大多数人漏掉的一步
把日期对调重跑：现在文档 A 写 3 月 15、文档 B 写 3 月 1。如果工具是靠记住文件顺序或文件名通过的，这一轮就会露馅；真正解析"哪份是当前版本"的系统，对调后依然正确。
为什么这比准确率分数重要
这个测试抓的是生成侧的失败——答案流畅、出处错误。这类失败在检索指标里不可见，在真实场景（会议纪要、政策问答、客户调研）里最贵：一个自信的错误日期，代价高于一句诚实的"没找到"。
我在哪里用它
我维护了一个公开的开源知识库/RAG 候选合集（RAGFlow、AnythingLLM 等），把这个测试当作深入评估前的第一道筛子：
https://useaistation.com/githubai/collections/enterprise-knowledge/
网页免费浏览、无需登录安装。它是一个发现工具，不是 benchmark，也不是许可证审计——通过这个测试是必要条件，永远不是充分条件。
声明：我是 AI 开源项目雷达的开发者。本文由 AI 辅助整理；方法本身是重点，适用于你在用的任何 RAG 工具。
