可以肯定地说，“用人工智能取代主要的询问响应/服务台”的想法现在已经是一个普遍的想法吗？ 其实我想做什么很清楚。我们希望减少等待时间、减轻操作员负担、减少人员并提高响应质量。 对于这个目的没有人反对。

一个常见的错误是“让 RAG 吃掉所有东西”作为方法。 我亲自测试了一个配置，一次性输入过去的日志、内部wiki和聊天记录，但得到的并不是预期的效率，而是大量产生看似垃圾的答案。

结论很明确。 部分替换是可以的，但是没有设计知识操作的SD替换失败概率很高。 而且大多数失败并不是由于模型选择错误造成的。输入数据的质量和运营职责的设计不足。

在服务台领域，同时需要正确的答案和可审核性。 为了实现这两个目标，实现这两个目标的唯一方法是最终获得“组织认可且正确的官方知识”。

先结论

  • 即使你输入了整个过去的日志，如果质量较低，它也会简单地高速搜索垃圾并返回类似垃圾的答案。
  • 即使输入了组织内的所有信息，如果正式和非正式之间的界限不明确，它就会成为在不假设组织的官方背景或规则的情况下证明错误答案的手段。
  • 仅笼统回答的结构违反组织规则，不能在现场使用。
  • 真正的解决方案是在人工智能辅助下运行KCS（以知识为中心的服务）循环，并明确参考源的质量和责任人。
  • 无法参考经认可的官方知识的人工智能不能用于服务台生产。

为什么“暂时放入所有内容”会失败？

1. 过去的通​​信日志本来就不是知识。

许多查询日志都是为了在现场关闭票证而写入的。 虽然这本身对于商业目的来说是正确的，但作为可重用的知识，它通常是不够的。

  • 缺少必要信息（使用的设备、权限、连接路径、环境差异）。
  • 目标是完成票证，在极端情况下可能以“通信完成”结束。不适合重复使用。
  • 缩写和口语的混合，并且依赖于负责人的默会知识。
  • 根本原因和临时解决方法没有分开。

如果将这种状态下的日志提交给RAG，即使搜索成功，答案也不会准确。 这是因为人工智能可以合理地补充即使人类阅读时也模棱两可或难以理解的文档，从而产生不切实际的妄想答案。 这就造成了一个麻烦的情况，答案很快，但问题却没有解决。 即使你认为提示不好并尽力调整它，也可能会徒劳。至少它发生在我身上。

2.内部信息全输入导致“官方稀释”

乍一看，允许用户读取“所有内部维基”、“所有文件服务器”和“所有聊天日志”的配置很全面。 然而，实际上，这类似于在同一搜索屏幕上排列具有不同可靠性程度的信息。

通常会发生以下情况：

  • 官方手续（已批准）和个人笔记（未批准）同栏检索
  • 过时的程序仍然存在并与最新程序冲突
  • 临时专有技术被错误地引用为永久程序
  • 当文章的更新日期和时间是新的但内容是旧的时，就会发生逆转。

RAG擅长“找文件”。 然而，必须创建一个单独的系统来确保该文档对于组织来说是正确的。

3.不了解组织规则的概括即使是正确的也不能使用。

形式知识不足的人工智能通常会返回技术上正确但操作上不可行的答案。

  • 授予本地管理员权限
  • 暂时放宽安全设置
  • 自行决定是否使用外部云
  • 直接访问跨职能数据

即使AI返回通用解决方案，如果违反组织规则，也无法实施。 此时此刻，服务台人工智能甚至可能成为一种为打破规则辩护的设备。它不能用作业务问题的解决方案。

现场发生的故障示例

失败示例1：VPN连接失败导致误导

  • 症状：“无法从家里连接到 VPN”
  • AI回答：“请初始化操作系统网络设置并重新启动。”
  • 实际：原因是认证基础设施侧的证书吊销，用户侧无法解决。

你为什么醒来？ 这是因为过去的日志包含许多“个人设备的临时故障”，而AI被它们吸引了。 此外，“隔离服务端故障”的程序作为官方知识还很薄弱，因此它没有被列为首选候选程序。 此外，“用户是否可以在未经许可的情况下重置 NW 设置？”的组织上下文并未考虑到答案中。

###失败案例2：提出软件应用违规问题

  • 症状：“我想使用分析工具”
  • AI回答：“自行下载试用版并开始使用。”
  • 实践：采购、许可证管理和随身携带筛查对于组织来说至关重要。

你为什么醒来？ 这是因为官方采购流程文件通过引用外部一般文章和个人备忘录而被埋没。 这是无法区分“可以做什么”和“可以做什么”的典型例子。

失败示例3：同样的问题，每次答案都不同

  • 症状：“设置电子邮件转发的步骤是什么？”
  • AI回答：取决于当天
  • 实际：旧操作流程页面和新流程页面共存

你为什么醒来？ 这是因为没有元数据表明“有效版本”（有效开始日期、废除日期、批准者），并且搜索排名中的答案各不相同。 当个人电子邮件和聊天片段混合在一起时，非​​正式解释偶然排名更高的可能性就会增加。

那么该怎么做：在 AI 协助下运行 KCS 循环

真正的解决方案不是用AI取代KCS。 利用 AI 加速 KCS。

###什么是KCS？

KCS（Knowledge-Centered Service）是一个运营概念，记录查询响应领域中产生的知识，重用它，并持续改进它。 重要的不是“解决问题后写文档”，而是将知识更新嵌入到解决问题本身的行为中。 KCS在RAG时代被重新评估的原因很简单：搜索目的地的质量很大程度上决定了答案的质量。

短篇故事：老故事，但很有效。

KCS 是一个始于 1992 年的想法，比 AI 更古老。 但目前之所以有效，是因为现实问题没有发生本质改变。

  • 有一个日志，但我看不懂。
  • 有文档，但不知道正式版本。
  • 没有更新并且腐烂

当你考虑到人工智能一代时，这三件事往往会被放大而不是消失。 这就是为什么在华丽的新功能之前回到简单但牢不可破的 KCS 模式是有意义的。

KCS 运行的最低配置

  • “捕获”：在回复询问时构建并记录症状、原因、对策和适用条件。
  • 结构：创建模板，将环境条件、目标范围、禁止事项设为必填项。
  • Reuse：参考下一个查询并呈现答案和基础URL作为一组
  • 「改进」：反映实际操作中的差异，继续纠正歧义词语和旧程序

生产循环：用官方知识培育人工智能答案

在现场，在下一个循环中逐步扩大应用范围是现实的。

  1. 用户先询问AI
  2. 如果 AI 无法解决问题，请升级至服务台 (SD)
  3. 使用适合AI阅读的模板将SD对应记录转换为知识 4.仅将经过批准和审查的官方知识添加到AI参考数据源中
  4. 类似查询，AI 的初次回复率和正确回答率增加

这个循环的关键点是可用于“认可”或官方答复的知识积累，而不是“数量”。 仅将“批准的信息”而非“记录的信息”作为人工智能的数据源。 如果这个规则被打破，答案的范围将会扩大，但准确性却不会。

可以留给AI的领域

  • 相似查询的聚类
  • 生成草稿答案（带证据）
  • 指出缺失的项目（“目标操作系统未知”、“未说明权限先决条件”等）
  • 介绍整合重复知识的候选人

人类应该负责的领域

  • 官方/非正式判断
  • 程序的批准和废除程序的决定
  • 允许异常处理
  • 知识过期管理

即使你试图把这个问题交给AI，AI也无法做出正确的反应。

实用要点

实践中应注意以下几点。

###知识运营端

  • 定义谁将在何时创建和发布哪种官方知识，并决定创建和质量保证方案。
  • 定义谁可以查看知识并决定访问控制。

###人工智能方面

  • 明确指示学生在提示中提供答案的理由。
  • 不允许在答案生成中使用非官方/未经授权的来源。

改进操作

  • 确定收集人工智能错误答案的方法，并将用于改进的知识生成纳入正常操作中。

这三点看似抽象，但落实起来却大有不同。 首先决定“谁来负责”的团队进步很快，而没有做出决定的团队却不断犯同样的错误。

“可以更换吗？”的答案

如果你问我服务台是否可以100%被AI代理取代，目前的答案是“不能”。 但是，如果分解询问类型并建立明确知识职责的操作， 主要答案、固定指导和标准程序的呈现可以完全替代。

换句话说，问题的关键不在于人工智能本身的智能。

  • 哪些知识可以作为官方采用？
  • 谁保证质量？
  • 当你犯错时谁会阻止你？

只有能够设计出这三点的组织才能将人工智能代理从“只是一个快速聊天工具”转变为“一支商业力量”。 相反，没有经过批准的官方知识运营的组织将无法创建高质量的服务台，无论模型多么复杂。

＃＃ 概括

“如果你包含所有日志，你就会变得更聪明”的想法是一种幻想。 服务台AI陷入困境的真正原因不是知识量，而是缺乏对知识的治理。

我们现在需要做的不是全面自动化。 这是一个低调的操作，利用AI辅助运行KCS循环，培养官方知识。

当组织开始接受这种谦虚时，他们的回应质量就会发生明显的变化。 在服务台使用人工智能时，首要任务始终是相同的。 **不断发展经批准且制度上正确的官方知识。 **

参考资料