先監控完整服務，而不只是模型 API
企業 AI 系統通常不是單一模型，而是一條由使用者介面、身分驗證、提示詞組裝、知識檢索、模型呼叫、工具執行與 ERP、CRM、LINE 等外部服務組成的鏈路。模型端即使回傳成功，只要檢索找到錯誤版本的文件、工具呼叫失敗，或回覆沒有送回原本的通道，使用者看到的仍是一個故障系統。因此，監控範圍應以一次完整任務為單位，追蹤請求從進站到產生最終結果的每個階段。
基礎層仍需觀察請求量、成功率、HTTP 錯誤、逾時、重試、佇列深度、CPU、記憶體與資料庫連線，但平均值往往會掩蓋少數嚴重延遲。工程團隊應查看 p50、p95、p99 等延遲分位數，並分解為檢索時間、模型首字延遲、完整生成時間、工具執行時間與通道傳送時間。這樣才能判斷問題來自模型供應商、向量資料庫、內部 API，還是下游 SaaS。
- 可用性：端到端任務成功率、各相依服務成功率、逾時與取消請求。
- 效能：首字延遲、總回應時間、檢索與工具呼叫延遲，以及佇列等待時間。
- 可靠性：重試次數、備援模型切換、重複執行與部分完成的任務。
- 容量：並行請求、速率限制、連線池、佇列深度與模型配額餘量。
品質指標必須連結到實際任務
AI 回覆通常不會像傳統程式一樣直接丟出例外；它可能語句流暢，內容卻不完整、沒有根據，甚至違反業務規則。只用錯誤碼監控，會漏掉最重要的品質事故。較可靠的方法，是先按任務分類，例如知識問答、摘要、表單擷取、客服分流與工具操作，再為各類任務定義可判定的完成條件。結構化輸出可檢查欄位完整性與 schema；問答可檢查引用是否存在、來源是否支援結論；工具型代理則要確認工具選擇、參數、授權與最終狀態。
線上品質訊號包括使用者重問、改寫問題、負面回饋、人工接手、對話中斷與工具操作遭撤銷。這些訊號有價值，但不能直接等同模型好壞：重問可能源自資料過期，人工接手也可能是既定流程。工程團隊應保留可抽樣的追蹤資料，定期以固定評測集執行離線評估，並依語言、任務、資料來源、模型版本及客戶環境切分結果。只看全體平均值，容易讓某一種高風險任務的退化被其他流量稀釋。
- 任務完成：答案是否解決問題，或指定動作是否真正完成。
- 正確與有據：關鍵主張能否由核准的資料來源支持，引用是否可開啟且對應內容。
- 格式與規則：JSON、欄位、語言、語氣、敏感資訊與業務限制是否符合要求。
- 安全性：提示詞注入、越權工具呼叫、個資外洩與不當內容是否被偵測或阻擋。
RAG、代理與整合流程要各自拆開觀察
對 RAG 系統而言，回答錯誤往往是資料管線問題，不一定是模型問題。應監控文件擷取成功率、解析失敗、切塊數量異常、嵌入工作積壓、索引新鮮度、權限同步，以及檢索結果是否包含正確來源。線上可記錄查詢、改寫後查詢、文件識別碼、版本、相關性分數與引用關係，但要避免把敏感原文直接寫入一般日誌。若知識庫更新後品質下降，這些資料能協助區分是文件內容、切塊策略、嵌入模型還是排序器造成。
代理與系統整合則應追蹤每一步狀態，而不是只記錄最終文字。重要指標包括工具選擇錯誤、參數驗證失敗、權限拒絕、外部 API 限流、重複寫入、補償動作與人工核准等待。所有有副作用的動作都應使用冪等鍵或等效機制，並把「模型建議執行」和「系統確認完成」分成不同事件。否則，模型說已更新 CRM，不代表 CRM 真的收到且接受了資料。
追蹤資料還需要一致的關聯識別碼，將前端請求、RAG 檢索、模型呼叫、工具操作與外部回應串成單一 trace。日誌記錄發生了什麼，指標顯示趨勢是否異常，trace 則回答時間花在哪裡、錯誤從哪一步開始；三者缺一，事故排查通常只能靠猜測。
成本與告警要能支持工程決策
AI 成本不只包括模型輸入與輸出 token，也包括嵌入、重新排序、向量資料庫、語音處理、日誌儲存、網路流量與人工審核。建議按功能、環境、模型、租戶與任務類型分攤，觀察每次成功任務的成本，而非只看整體帳單。單次請求變貴可能來自對話歷史持續增長、檢索內容過多、代理反覆呼叫工具或失敗重試。這些原因需要不同修正，不能只靠切換較便宜的模型。
告警門檻應對應使用者影響與服務目標。短暫的單點失敗適合記錄或自動重試；持續的端到端成功率下降、延遲分位數惡化、安全阻擋異常、索引長時間未更新，才適合通知值班人員。可同時使用固定門檻與相對基線，並要求足夠樣本量，避免低流量時被偶發事件洗版。每個告警都應附上影響範圍、近期部署、模型與提示詞版本、相關 trace，以及可執行的處理手冊。
最後，把模型、提示詞、評測集、索引與整合流程都視為可版本化的生產元件。變更前跑離線評測，部署時採分階段流量與可回滾策略，部署後比較品質、延遲、錯誤和單次成功任務成本。真正成熟的 AI 維運，不是建立一面塞滿圖表的儀表板，而是讓每個指標都能回答：使用者受到什麼影響、問題位於哪一層，以及團隊下一步該採取什麼行動。