AI 監控與告警怎麼設計？品質、RAG、Agent、成本與人工指標
AI 系統最危險的監控盲點，是服務仍回 200、儀表板仍有流量，但答案依據變差、跨權限文件被召回、Agent 重複執行，或人工 queue 已經超載。AI 輸出具有變異，模型、提示、資料、索引、工具與供應商也會持續改變；只用 uptime、平均延遲與 token 量，無法判斷使用者是否得到合格成果。
NIST AI RMF Manage 要求部署後監控、事件、覆寫、停用、回復與持續改善。AI RMF 1.0 正在更新，而且 Core 與 Playbook 都不是逐項勾選表或合規認證；監控項目、門檻與接手角色仍應由組織在實際脈絡中定義。
從任務成功與重大失敗開始
先寫出使用者要完成的正式工作，以及什麼錯誤不能被平均抵銷。生成系統可看合格成果、重大無依據主張與拒答；RAG 分開看前 k 命中、來源版本、引用支持與無答案；擷取看欄位、數值、單位與人工修正；分類看高影響類別、分群與申訴；Agent 還要看批准、工具成功、外部真實狀態、重複與部分成功。可到AI 評測指標資料庫選擇起始指標。
建立版本、分群與基準
每筆結果要能連到模型、prompt、索引、資料、工具與政策版本。依用途、使用者角色、語言、文件類型、租戶與高影響情境分群，不讓整體平均掩蓋少數重大退步。先保存上線前基準、分母、抽樣方式與限制；變更時用AI 系統變更資料庫決定哪些指標和案例必須重跑。
同時監控安全、營運與成本
追蹤敏感資料輸出、跨權限拒絕、注入攔截、未批准工具、異常目的地、秘密與政策繞過；營運面看有效成功率、P95／P99、queue、timeout、重試與供應商依賴；成本要算每個合格成果與人工修正，不只總 token。控制本身也要有健康度，例如 ACL 決策缺欄、評分器失效或告警未送達。
把人工與受影響者訊號納入
人工修改率、推翻率、升級完整率、等待時間、每人負荷、申訴、客服與正式更正，常比模型自評更早揭露問題。高通過率可能是介面誘導或沒時間覆核，不一定代表品質好。保存人工看到的資訊、決定與實際結果，同時依最小必要和保存政策限制敏感資料。
告警要連到可執行動作
每個告警明列 Owner、優先度、觀察窗口、觸發理由、查詢連結、第一時間、停止條件與升級。重大未授權動作、跨租戶與敏感資料不應只等每日報表；已知延遲與成本波動則可用持續窗口降低雜訊。告警後若沒有人能撤權、停 queue、切人工或回復，監控仍不完整。
用合成事故測端到端送達
定期在有權環境注入可識別的合成錯誤，驗證資料產生、收集、規則、通知、值班接手、停止與關單。測夜間、Owner 缺席、通知通道中斷、告警風暴與證據即將輪替。結果記錄偵測時間、確認時間、停止時間、漏報、誤報與改善 Owner；失敗案例加入AI 測試案例庫。
發現異常後要能回到事件與變更
告警不是終點。從AI 事故初步分流器建立時間線、止血、證據與通知角色；修正後用AI 變更影響分析器確認重測、回復與恢復條件。若已造成錯誤決定或外部副作用，追蹤更正、取消、補償、申訴與受影響者處理，而不是等指標回綠就關單。
定期檢查監控本身是否失真
資料分布、產品流程與使用者行為改變後，舊測試集和門檻可能失去代表性。定期抽樣真實成果與標準來源，由領域人員複核；校準自動評分器，檢查日誌缺欄、時鐘、延遲與保存。用企業 AI 控制措施資料庫對照監控、稽核、事件與供應商韌性，避免只補一張儀表板。