公開動態與原創分析 · 消息日期: · 消息來源
一名售後人員問「這台設備的密封件能否單獨訂購」，AI 找到了相近型號的說明書，給出肯定回答。發現錯誤後，將正確答案補進知識庫，看起來很直接。但如果真正的問題是型號檢索混淆，新增一則問答未必能阻止下次誤用。知識維護需要從答案繼續查到錯誤發生的地方。
Google Cloud 在10月22日公布 Knowledge Catalog 的自學習情境增強與新版 Knowledge Studio，兩者均處於預覽階段。這項方向透過分析使用者與智慧代理的使用紀錄，發現企業知識的缺口並提出修訂。它為一個常被留到上線後才考慮的問題提供產品層面的回應：誰來持續處理 AI 使用中暴露的資料問題？
錯誤答案對應的幾種維護工作
開頭的設備問題是分析示例，並非 Google 或墨客雲客戶事件。假設售後資料中只有整機說明，備品是否單售由另一份目錄負責；若目錄沒有接入，補充來源有理由。若目錄已存在，檢索卻選了相近型號，維護重點就在型號識別與資料選擇。兩種情況表面上都答錯，實際需要修改的地方不同。
還有一種更難處理的情況：兩份目前有效的材料給出不同說法。產品說明將密封件列為可更換零件，銷售目錄卻沒有獨立訂購代碼。這些資訊未必彼此錯誤，可更換可能指售後維修時更換，未必意味客戶可以直接下單。若模型將兩份材料合成一句「支援單獨採購」，就跨過了原資料未作出的承諾。
此時更需要產品或服務負責人解釋規則。是否允許銷售、適用哪個地區、需要如何確認設備版本，都可能改變回答。將這次人工解釋保存為有適用範圍的正式資料，後續才有重複使用價值。若只保存一句最終答覆，下次遇到不同型號或地區，仍可能套用錯誤。使用紀錄有助於發現問題，業務依據決定修訂內容。
Knowledge Studio 的文件將這項工作落實為可審閱的修改提案：維護人員能夠查看變更，並用測試問題比較修訂前後的表現。它主要處理企業資料的語意與情境。將類似思路用於售後產品資料，需要另行設計資料組織與任務串接，不能將上述示例當成現成的產業功能。
從維護投入來看，也應區分問題是否重複發生、錯誤後果多大，以及修訂能涵蓋多少任務。一份適用條件說明可能同時協助客服、備品報價與維修交接；一次特殊的歷史設備諮詢，保留人工處理紀錄可能已經足夠。所有異常都自動變成知識條目，容易讓資料庫越來越難維護，也增加日後回答時選擇依據的負擔。
修訂資料前，要比較哪些答案
判斷修訂是否有用，不能只看最初答錯的問題。假設新增資料說明某款密封件可以訂購，應同時檢查同系列其他型號是否仍被正確區分，以及舊設備的維修條件是否受到影響。一項修改修好了目前回答，卻讓相近問題開始混淆，維護工作就只是換了位置。
可以保留少量會影響業務決定的問題，隨相關資料一起更新。問題無須追求數量：能否單購、報價前需要什麼資訊、資料不足時如何回覆，已經對應不同處理。正確答案也不必全是肯定答覆。有條件的說明、明確的待確認項目，都可能比缺少依據的完整回答更適合繼續辦理。
Google 的審閱文件也區分執行日誌、修改提案與逐題評估。企業可以藉此判斷投入：作業執行成功，只說明這輪處理完成；提案有出處，仍須判斷出處是否適用於本次業務；問題測試改善，仍需確認測試包含真實工作會遇到的差異。只盯一個彙總分數，難以決定哪項資料應該發布。
墨客雲知識與推理方向強調從獲准資料檢索依據、核對版本並保留引用。用於這類售後工作時，可以先將每次待確認問題與採用的型號、資料版本、缺失依據放在一起，交給資料負責人處理；確認後的變更再用於相關回答與草稿。這是依現有產品定位提出的導入思路，日誌自動分類、修改提案及具體系統串接是否可用，須按專案驗證，不能聲稱已串接 Knowledge Catalog。
自動維護的投入與適用條件
自動發現缺口最可能節省的是查找與整理時間。業務負責人仍要對有分歧的規則作決定；如果每輪都產生大量相似提案，審核負擔可能抵銷先前的節省。因此，採用時應關注重複問題是否減少、提案是否容易核對、確認一項修改需要什麼材料。這些觀察比持續增加知識條目更接近維護的實際收益。
資料規模較小、變更不頻繁的團隊，可以用問題紀錄配合定期修訂，無須為此立即增加一套平台。當多個助理依賴同一批持續變動的資料，而人工難以追蹤哪些回答受影響時，集中管理變更的價值會更明顯。判斷依據是知識更新的工作量，以及舊資料造成的後果。
準備嘗試 Google 預覽功能的企業，還要先核對資料邊界。Knowledge Studio 目前需要申請預覽存取，文件列出資料落地地區承諾、VPC Service Controls 等方面的限制。涉及受限資料的專案，必須按目前條款評估是否適用，不能用正式版其他產品的能力替代預覽功能的條件。
這輪進展值得關注，是因為資料維護開始利用實際使用中出現的問題。企業也可以據此重新分配工作：讓工具協助找到值得調查的錯誤，將規則決定交給能負責的人，並保留修訂依據。若一項知識沒有人能夠確認，增加自動化程度也不能替企業作出這個決定。
消息來源
墨客雲編輯部 · neo@mokyun.com
