知识问答里的点赞和差评只能提示体验，不能直接告诉团队该改哪里。要让反馈变成改进清单，需要保存原问题、当时答案、所用证据和用户指出的具体问题，再区分内容缺失、检索错误、回答错误或表达不清。
收集足够定位的信息
用户说“答案不对”时，可以提供轻量反馈选项，例如资料过期、对象不符、缺少条件或没有解决问题，并允许补充说明。不要要求用户先理解 RAG 技术流程；技术分类应由后续核查完成，用户只需表达哪里影响了工作。
同一问题在不同文档版本下可能得到不同答案，因此反馈记录应关联当时的来源和运行结果。仅保存一段答案截图，之后可能无法重现检索上下文。对于无法恢复的旧反馈，应说明证据有限，而不是凭猜测给出根因。
先复现，再分配处理动作
| 核查结果 | 修复方向 |
|---|---|
| 原件缺少必要说明 | 补充内容并确认适用范围 |
| 原件有答案但未检索到 | 检查解析、切分、查询与排序 |
| 证据完整但答案改了含义 | 检查生成对条件与引用的使用 |
| 事实正确但用户无法行动 | 调整回答组织并补充已有入口 |
例如用户反馈材料清单少了一项，核查发现该项写在附表且没有进入最终上下文。修复事项应写成“恢复附表证据的关联与召回”，而不是泛泛要求“提高回答质量”。动作具体，才有办法验证是否完成。
合并同因问题，保留不同症状
多个反馈可能来自同一解析错误，也可能只是都被用户标为答非所问。归并时看证据与失败环节，不应只按反馈标签聚类。若确认同因，可以建立一项修复并关联多个真实问题，避免重复处理。
优先级可以结合影响、出现频率和可复现程度，但没有准确频率数据时应保留未知。某个问题反馈少，不代表不重要；用户可能已经放弃使用而没有提交差评。业务关键题需要单独关注。
让完成状态依赖复验
每项修复至少记录预期变化、负责人、受影响内容和验证问题。完成修改后，用原始问题复测，再加一个近似但条件不同的问题，检查修复是否过度针对单一问法。通过后保留前后证据，不用“代码已改”或“文档已更新”直接代替效果。
有些反馈暴露的是问题本身信息不足。此时改进可能是让系统更准确地请求补充，而不是生成更长答案。也有些反馈无法在现有资料范围内解决，应明确列为内容待补，不把它们悄悄关闭。
按周期复盘时，展示主要失败类型、已验证修复和仍未解决的事项。满意度变化可以作为补充观察，不能单独证明事实准确性提高。反馈闭环的关键，是每个“已解决”都能回到一条可复查的证据。
在企业文档中验证
如果要把本文方法用于企业文档，可预约演示，结合实际资料核对协作、权限与集成方式。
需要在自己的环境中验证时，可先了解私有化部署方案，再确定试用范围与验收要求。