先定義「正常運作」，否則每月只能憑感覺檢查
AI 上線不是專案結案，而是從建置階段進入營運階段。傳統系統通常可用錯誤率、回應時間與服務可用性判斷健康狀態；企業 AI 還必須處理回答是否正確、引用是否可靠、拒答是否合理，以及產生的內容能否安全地進入後續流程。系統即使沒有報錯，也可能因知識過期、檢索偏移或提示詞變更而逐漸失去實用性。
因此，上線時就應建立一份營運基準：系統服務哪些使用情境、哪些問題必須轉交人工、可使用哪些資料來源、哪些動作需要核准，以及誰負責判斷內容品質。不要把「回答看起來不錯」當成驗收條件。較實際的方式，是保留一組來自真實業務的固定測試題，記錄預期答案要點、必要引用、不可出現的內容與允許的回答範圍。這組測試題會成為往後每月比較品質變化的共同尺規。
每月盤點應同時涵蓋品質、資料、串接與風險
月度維運不需要把所有紀錄逐筆人工閱讀，但也不能只看模型供應商的用量圖表。工程團隊應先用監控與抽樣找出異常群組，再由熟悉業務的人判斷影響。建議固定檢查以下項目：
- 回答品質：重跑固定測試題，抽查高頻問題、低評價對話、人工接手案件與無法完成的任務。將問題分成事實錯誤、指令誤解、資訊不足、引用不符、語氣不當或應拒答卻未拒答，避免所有問題最後都被歸因於模型。
- RAG 與知識資料：確認新文件是否已進入索引、舊版本是否仍被檢索、權限是否正確繼承，以及切段、標題與中繼資料是否讓搜尋找到真正相關的內容。回答錯誤有時不是生成問題，而是系統根本沒有取回正確資料。
- 系統串接：檢查 LINE、ERP、CRM、身分驗證與內部 API 是否有格式或權限變更。特別留意重試造成的重複寫入、逾時後狀態不一致，以及下游系統成功回應但實際沒有完成交易的情況。
- 安全與稽核：檢視敏感資料是否出現在提示、紀錄或回覆中，確認服務帳號權限仍符合最小權限原則，並抽查管理操作、資料匯出與高風險工具呼叫是否留下足夠的追蹤資訊。
- 成本與容量：拆解成本來自模型推論、嵌入、搜尋、雲端運算、資料傳輸或第三方 API，而不是只看總額。成本上升可能是使用量增加，也可能是提示內容膨脹、失敗重試或不必要的長對話累積。
- 使用行為：觀察使用者在哪些步驟離開、反覆改問、直接改用人工或自行繞過系統。低使用量不一定代表需求不存在，也可能是登入流程、回應速度、可信度或工作流程設計造成阻力。
每一類問題都要對應到負責人與判斷門檻。基礎架構團隊能處理延遲，卻未必能判斷採購規範是否回答正確；業務單位能辨識內容問題，卻不一定知道是檢索、權限或 API 所致。月度維運的價值就在於把這些訊號放在同一張問題地圖上，而不是讓各團隊各自看一套儀表板。
修改模型或提示詞之前，先找出真正的故障層
看到錯誤回答就更換模型，通常是成本最高、也最難驗證的第一反應。工程上應先判斷問題位於哪一層：來源文件是否正確、索引是否更新、檢索條件是否過窄、提示詞是否互相衝突、工具回傳是否完整，最後才是模型能力是否不足。同一個表面症狀可能有完全不同的原因；例如回答過時，可能是文件未更新，也可能是舊文件沒有下架，而不一定需要更大的模型。
所有調整都應版本化，包括系統提示、模型與參數、檢索設定、知識索引、工具介面及安全規則。變更前先以固定測試題建立基準，再加入此次問題的重現案例；變更後除了確認目標問題改善，也要檢查其他任務是否退步。若一次同時修改模型、提示與切段策略，即使結果變好，也很難知道哪個調整真正有效，更難在出現副作用時回復。
並非每個月都必須發布新版。當問題影響有限、證據不足或修改可能破壞更重要的流程時，先增加監控、收集案例或提供人工替代路徑，往往比立即調整更穩健。維運的目標不是追逐每次模型更新，而是在品質、成本、速度、隱私與可回復性之間做有紀錄的取捨。
一次有效的月度會議，最後要留下可執行的產物
月會不應只是展示使用量。會議前，工程團隊先整理品質測試、異常分類、串接狀態、成本來源與未結事件；會議中則由業務、資料、資安與系統負責人共同確認影響與優先順序。需要立即處理的風險、可排入下一次發布的改善，以及暫不處理但持續觀察的項目，應明確分開。
- 一頁式營運摘要：說明目前服務狀態、主要風險、品質變化與成本驅動因素。
- 問題與事件清單：保留症狀、影響範圍、根因、臨時處置、永久修正與負責人。
- 變更決策紀錄：記下為何調整或不調整模型、提示、資料與流程，以及回復條件。
- 下一個月的驗證計畫：列出要補充的測試案例、監控訊號、資料更新與預定發布項目。
成熟的 AI 維運會讓每次變更都能說明原因、驗證結果並安全回復。若系統橫跨模型、雲端、企業資料與多個既有平台，維運責任也應跨越相同邊界；必要時由熟悉整合架構的團隊協助建立共同流程，比把 AI 當成單一應用程式交給某個部門更實際。