先区分 RAG 的失败层次
知识缺失权威信息根本不存在于知识库中。
内容过期或冲突系统里存在旧版本或互相矛盾的来源。
检索遗漏正确文档存在，但查询、切块、Embedding、过滤或排序没有找到它。
生成失真检索结果正确，模型却忽略、误读或添加了来源不支持的内容。
表达失败结论基本正确，但缺少引用、限制、步骤或适合用户的格式。
预期偏差用户期待知识库并不承诺覆盖的能力或实时数据。
如果不先分层，团队很容易把所有问题都交给 Prompt，或者不断补文档，却从未修复检索路径。
“答案不对”只是症状。先找到正确证据在哪一层消失，再决定由谁修。
问出能够验证正确答案的信息
追问用户：答案应该包含什么？依据的是哪份来源、政策或真实工作流？哪些部分错误或遗漏？这个差异造成了什么后果？如果用户无法给出来源，也要记录其预期和信心。
不要要求用户理解 RAG。用户只需说明业务事实；系统负责把事实连接到 Query、检索结果和生成过程。
反馈发生时保存检索上下文
- 稳定的 Response ID 和 Trace ID。
- 模型、Prompt、检索配置和索引版本。
- 归一化后的查询及过滤条件。
- 返回的文档 ID、版本、分数和排序。
- 实际引用与回答中使用的片段。
- 账户、角色、语言、产品版本和时间。
保存标识与受控链接通常比复制全文更安全，也方便知识所有者查看最新来源。
用证据把问题交给正确负责人
知识团队权威内容缺失、过期、含糊或冲突。
搜索 / ML正确内容存在，但召回、过滤或排序失败。
AI 工程上下文正确，模型却没有遵循来源或格式要求。
产品问题来自产品边界、工作流设计或用户预期。
客服需要立即提供替代方案、解释限制或保护高风险账户。
通过用户群和版本找到真正模式
按知识域、查询意图、来源、索引版本、语言、账户分群与发布日期聚类。一个文档缺失可能产生多种用户表述；一个看似统一的主题也可能包含检索和生成两种根因。
关注发布后的突然变化、高价值账户集中问题和持续重复的“答案看起来合理但来源不支持”。已确认的问题应进入 Eval 集，包含输入、期望证据和可接受输出边界。
衡量知识系统是否真的恢复
- 具有 Response 或 Trace 标识的 RAG 反馈比例。
- 能够定位到具体失败层次的比例。
- 从报告到明确知识或工程负责人的时间。
- 修复后相同查询族的成功率和重复投诉率。
- 引用正确率、来源新鲜度和受支持结论比例。
- 真实反馈转化为 RAG Eval 用例的数量。
不要只看检索离线分数。最终目标是用户能够完成任务，并相信答案有依据。