内部助手的每个回答下面都有“点赞”和“点踩”按钮。两个月后，累计了 300 个点踩，却没人知道该怎么处理。有的是答错了，有的是回答太慢，还有的是答案正确、只是提问的人不喜欢。

反馈只有在能转化为具体改进时才有用。这取决于收集了什么，以及收集之后做了什么。

一键选择原因

有人把回答标为没帮助时，提供几个简短选项：

  • 错误或过时
  • 缺少信息
  • 找不到来源
  • 太长或不清楚
  • 应该转人工

可以加一个选填的备注框，但不要强制填写。大多数人愿意点一下原因，很少有人会写一段话。

反馈要带上上下文

只有一个点踩，没有对应的问题和回答，几乎无法处理。把反馈和请求、回答、所用来源以及当时的助手指令版本一起保存。为什么版本很重要，可参考AI 指令变更记录指南。

约定这些记录保存多久、谁能查看，尤其是问题中可能包含客户或员工信息的时候。

每周抽查一部分

每周留出三十分钟，由一位负责人阅读最近的负面反馈和几条正面反馈。把每一条归入以下四种处理之一：

  1. 修内容： 文档缺失、错误或过时，转给负责这份文档的团队。
  2. 改助手： 指令、检索或格式需要调整。先把这个用例加入测试集。
  3. 转人工： 这类问题本来就不该由助手回答。
  4. 无需改动： 答案是对的，记下来即可。

统计哪一类在增加。“修内容”越来越多，说明是文档问题，而不是模型问题。

让员工知道反馈有回音

如果反馈像石沉大海，大家就不会再反馈。每月发一份简短说明：最常见的问题、已经修复的内容、仍在处理的事项。有人报告了具体问题，解决后要告诉他。

也要留意“没有反馈”

反馈少不一定代表满意度高。要结合使用量一起看。如果某个团队不再使用助手，直接去问原因。如何开展这类回访，可参考 AI 团队推广指南。

如需为正在使用的助手建立反馈流程，欢迎联系 Storm Nova Labs。