可以肯定地說，「用人工智慧取代主要的詢問回應/服務台」的想法現在已經是一個普遍的想法嗎？ 其實我想做什麼很清楚。我們希望減少等待時間、減輕操作員負擔、減少人員並提高回應品質。 對於這個目的沒有人反對。

一個常見的錯誤是「讓 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循環，培養官方知識。

當組織開始接受這種謙虛時，他們的回應品質就會發生明顯的變化。 在服務台使用人工智慧時，首要任務始終是相同的。 **不斷發展經批准且制度上正確的官方知識。 **

參考資料