AI 系統上線後怎麼監控?幻覺、延遲、成本三類指標的 SLA 設定範本

上線後第三週,客戶的 IT 主管半夜打電話給我。他們的 RAG 客服系統前一天答錯了一筆退貨政策,把「七天鑑賞期」講成「三十天無條件退款」,一位客人截圖去投訴。問題不是模型笨,而是沒人知道它答錯了——系統上線那天大家慶祝完,監控就停在「服務有沒有掛掉」這個層次。API 回 200,大家就以為沒事。

這是我們最常補的洞。傳統系統監控盯的是可用性,AI 系統要盯的是「它有沒有在胡說、有沒有變慢、有沒有燒錢」。這三件事,傳統 APM 一個都看不到。

為什麼 AI 上線後監控 SLA 要重寫

一般後端服務,健康的定義很清楚:回應碼、延遲、錯誤率。AI 系統多了一個維度——輸出「語意上」對不對。一個回 200、延遲 800ms 的請求,內容可能整段是幻覺。所以 AI 上線後監控 SLA 不能只沿用 Ops 那套,它要同時管三類指標:品質(幻覺與正確性)、效能(延遲)、成本(token 花費)。三者還會互相拉扯——你把模型換小一點省成本,幻覺率就可能上去;你加一層檢索重排壓幻覺,延遲又上來。監控的意義,就是讓這些取捨變成看得見的數字,而不是等客人截圖。

我們的原則是:每一類指標都要有三個東西——量測方式、SLA 目標值、觸發告警的閾值。少了任何一個,監控就是裝飾。

可直接套用的三類指標 SLA 範本

以下是我們實際交付時用的起手式,數字是給一般企業客服/知識查詢型應用的保守基準,你應該依自己的風險容忍度調整。低風險內部工具可以放寬,金融、醫療這種答錯要負責的場景必須收更緊。

幾個實作上的重點,我們踩過雷才學會的。

幻覺不能靠人工抽查。 上線後流量一大,人工一天看幾十筆根本代表不了整體。我們的做法是用一個獨立的 LLM 當裁判(judge),對每筆回答比對它引用的來源片段,判斷「這句話有沒有真的出自檢索到的文件」。抽樣 5% 到 10% 即時跑,成本可控,又能算出滾動的有據回答率。judge 的 prompt 要跟主模型分開版本控管,不然你改主流程時把評分標準也一起改了,數字就失真。

延遲要拆開看,不要只看總時間。 一次 RAG 請求裡,檢索、重排、生成各佔多少,分不開就找不到瓶頸。我們一定把 TTFT(使用者多久看到第一個字)跟端到端分開設 SLA——對聊天介面來說,TTFT 才是體感,總時間長一點使用者反而能接受,因為字在動。

成本告警要盯「異常」而不只是「總量」。 最容易失血的不是平常流量,是某個 prompt 被灌進整份 PDF、或是重試迴圈打爆 token。所以我們設的閾值是「日均對話成本超過基準 1.5 倍」這種相對值,比單看總帳單更早抓到問題。

閾值只是起點,滾動調整才是真功夫

範本給你的是第一版,不是終點。上線頭兩週告警一定會太吵——半夜 P95 飆高其實是批次任務、負評率破表其實是同一個客訴洗了十次。這時候的工作不是關掉告警,是校準:哪些是真訊號、哪些是雜訊,把閾值和分組維度改到「一響就值得有人看」。我們通常設兩級,warning 進 Slack 頻道供上班時間追,critical 才叫醒 on-call。

還有一件常被忽略的事:這些指標要有人負責看,而且要寫進交接文件。系統交回客戶團隊時,如果沒有指定的 owner 和每週回顧的節奏,再漂亮的看板三個月後也會沒人打開。監控的失效往往不是技術問題,是責任沒落地。

在 Tenten,我們把這份 SLA 範本當成上線交付的一部分,而不是事後補件——工程師進場時就跟客戶一起把閾值、告警路由和回顧節奏定下來,並在陪跑的頭幾週親手校準過一輪才撤場。Demo 漂亮不算數,上線後三個月還有人盯著這些數字、還在用,才算真的交付完成。