知识库反馈闭环：一句“不准确”之后，谁来处理

让反馈带上足够的上下文

只有一个“不准确”按钮，维护者可能无法重现当时的回答。可以在用户允许的范围内保留问题、所用资料版本和回答引用，并让用户补充哪一处不符合实际。敏感信息应按现有访问范围处理。

反馈表不宜过长。系统已经知道的上下文应自动关联，让员工只补充判断所需的差异。也要允许“缺少内容”“资料过期”“没有权限”等不同反馈，减少把所有问题都归为模型错误。

不同原因需要不同负责人

原始资料错误，应由内容负责人核实；资料正确但没有检索到，需要检查索引与查询；取得资料后误解限制，则需要检查回答设计与评价。若职责没有区分，反馈容易在业务与技术之间往返。

可以先由维护者做一次简单分类，再分派到相应处理入口。不要让模型自动判定投诉已经解决。重要事实变化仍需由有资格确认的人负责。

修订完成，还需要回到原问题

修改文档或配置后，重放原问题并核对引用，同时测试几个相邻问题。某个回答变好，不应以其他常见问题退步为代价。维护记录需要保存变化理由与验证结果。

反馈关闭时可以简要说明调整了什么，或者为什么暂不采纳。回应能让员工知道自己的观察产生了作用，也有助于纠正对系统能力的误解。

从反复出现的问题看见组织缺口

如果很多反馈涉及同一条规则，可能说明规则本身难以理解；如果不同部门给出不同答案，可能需要先统一业务口径。知识库维护因此也是观察组织协作的一扇窗口。

闭环的价值不只是减少错误次数，更是使问题能够找到责任、依据和改进路径。一个愿意承认并修正缺口的知识系统，比一个只展示高满意度数字的系统更值得长期依赖。

给一次不准确反馈找到责任人

保留问题、时间、来源与差异，先分清资料、检索、回答或权限原因。企业完成修订后回测原题并回应反馈；约定咨询可帮助判断原因，资料发布与维护仍由企业负责。