RAG 评估不应只看“回答读起来像不像”。对于商户运营知识库，更先要确认系统是否进入正确领域、是否引用正确版本、是否在知识不足时拒答。

一、评估数据

项目维护 10 条评估问题、5 个 Bad Case 和 5 份 Runbook，五个知识领域各有可验证样本。每条问题记录expected_source，用于检查 Metadata 过滤和来源引用。

二、校验内容

GET /api/assessment和离线校验器检查字段完整性、预期领域、Bad Case 编号与 Runbook 覆盖。它们验证数据和链路是否自洽，不把静态样本结果包装成线上准确率。

三、典型 Bad Case

• 过期规则：提示人工确认最新版本。
• 相似门店混淆：不能把其他对象的资料带入答案。
• 缺少周期或口径的指标问题：不能擅自推导结论。

先用 Bad Case 暴露边界，再决定是否调整阈值或文档，是比盲目追求“回答更多”更稳妥的迭代方式。