停止像監控網路服務那樣監控AI系統

許多AI系統的監控方式仍然與它們旁邊的網路服務相同。API閘道器會發出正常執行時間、錯誤率和延遲百分位數，儀表板隨基礎設施免費提供。不幸的是，這些數字都無法告訴你使用者盯著空白螢幕四秒鐘後才看到第一個token，或者自上次提示更新以來每個任務的token消耗翻了一番，或者模型已經開始在檢索到的上下文之外編造答案。

這種差距的存在是因為LLM系統打破了網路監控所依賴的假設。響應是逐個token生成的，因此“延遲”取決於你在時間線上的位置，至少有三個不同的數字。成本隨token而非請求數量變化。此外，最具破壞性的故障是無聲的：質量回歸不會丟擲500錯誤，而是以200狀態碼返回自信的文本。

文章提出了一種方法：將指標按它們回答的問題分組。五個問題涵蓋了生產中的大部分問題：是否快速、能否擴充套件、是否正確、是否可靠、當有代理參與時表現如何。文章詳細介紹了每個組、指標的機械含義以及哪些需要自行構建。

指標地圖

在進入問題之前，文章還預告了一個關於將AI演示轉化為部署應用的研討會。

是否快速？（延遲）

LLM請求有兩個階段，產生不同的延遲數字。預填充階段模型處理整個提示並構建內部狀態，使用者看不到任何東西。解碼階段模型逐token生成輸出。每個值得追蹤的延遲指標都是該時間線上的一個位置。

首token時間（TTFT）是從傳送請求到第一個token到達的時間，包括排隊時間和預填充時間。在流式UI中，這是使用者感知的延遲。TTFT隨提示長度增長，因此RAG系統將大上下文塞入提示會付出感知速度的代價。

token間延遲（ITL，也報告為每輸出token時間TPOT）是流式傳輸開始後連續token之間的間隔，它決定了輸出是否流暢。使用者容忍穩定但略慢的流式傳輸遠勝於快速但凍結的流式傳輸。

端到端延遲的p50、p95和p99是完整跨度，輸出長度主導它。單一的全域性百分位數幾乎毫無意義：它將50個token的分類呼叫與2000個token的報告生成平均在一起。按用例追蹤端到端延遲，讓每個數字對應一個工作負載。

代理會放大效果。一個鏈式呼叫多個LLM的任務會倍增每次呼叫的數字，可容忍的每次呼叫p95可能變成不可容忍的任務級延遲。對於代理工作負載，將延遲預算設定在任務級別，並讓它約束步驟。

能否擴充套件？（吞吐量和成本）

每個使用者的每秒token數與總系統吞吐量。服務系統對同一硬體上的併發請求進行批處理，批次大小是可調整的：更大的批次提高總系統每秒token數，但每個單獨的流會變慢。這兩個指標在同一GPU上相互權衡。因此，為每個工作負載決定你要保護哪一個。互動式聊天應偏向每個使用者的速度，離線批處理應偏向總吞吐量。

每個請求的輸入和輸出token數。這是單位經濟的核心，輸出token通常定價為輸入token的倍數。記錄每個請求，按用例分解，仔細監控。

快取命中率。提示快取使重複的提示字首處理成本大幅降低，是系統提示、工具定義或共享文件上下文穩定的系統中的最大成本槓桿之一。它也容易出錯，因為快取逐位元組匹配提示字首：一個插在提示前部的時間戳或重排的工具列表都會使快取失效。監控快取命中率下降，這可能意味著有人更改了提示的組裝方式。

每次成功任務的成本，而非每次請求的成本。每次請求成本使得錯誤廉價的系統看起來很好。成本只有三分之一但成功次數減半的請求實際上更昂貴，而且失敗的嘗試會觸發重試，無形中倍增支出。這也是連線所有五個組的指標：你可以單獨壓低延遲、成本或質量，而每次成功任務的成本告訴你係統整體是變好還是變壞。

是否正確？（質量）

服務棧中沒有任何東西會生成正確性。這一組中的所有指標都需要自行構建。

標記評估集上的任務成功率。幾十到幾百個已知正確結果的示例，在提示更改、模型升級或檢索更改時重新執行。這是AI系統的迴歸測試套件。評估集不需要很大就能有用，但需要具有代表性並得到維護。

基於性（RAG）。答案是否由檢索到的上下文支援，還是編造的？系統可能有出色的檢索能力，但仍然在檢索到的內容與最終輸出之間產生幻覺。隨著強大模型的出現，這個問題正在減少，但在實際生產系統中，最終你會希望使用盡可能小的模型來降低成本。

檢索精確度和召回率@k。在k個檢索塊中，精確度@k詢問有多少實際上相關。召回率@k詢問在最初的k箇中有多少相關材料被檢索到。生成無法修復檢索從未浮現的內容，因此當答案質量下降時，在重寫提示之前先檢查檢索指標。檢索仍然是AI系統中更難的問題。

LLM-as-Judge評分隨時間變化，並針對人工標籤進行校準。評判員使得質量可在大規模上測量，但它們會漂移——評判模型升級可能會改變評分，而系統本身沒有變化。在開始時根據人工標籤樣本進行校準，並在評判模型更改或評分趨勢看起來過於樂觀時重新校準。

使用者反饋訊號。顯式點贊很少見且偏向極端。重新生成率和使用者在接受生成輸出前編輯的程度更常見且更真實，因為它們是在使用者對輸出採取行動時記錄的，而不是在他們感覺想評分時。

是否可靠？（可靠性）

每個提供商的錯誤率、超時率和限流率。按提供商拆分很重要，因為聚合可用性會隱藏哪個依賴項正在退化，特別是限流往往以突發形式出現，與某個提供商的配額繫結。

重試和回退率。回退到備份模型保持可用性為綠色，但質量悄然變化。按服務路徑追蹤質量指標。

護欄觸發率和拒絕率。兩者激增意味著使用者行為發生變化、可能發生注入攻擊或模型更改移除了拒絕邊界。無論如何，都值得追蹤，而且在護欄操作被正確記錄後成本很低。

代理如何表現？（代理指標）

代理以單個LLM呼叫不會的方式失敗，因為模型做出了一系列決策，每一個都可能悄然退化。

工具呼叫錯誤率，按原因拆分。模式和引數錯誤意味著模型誤解了工具，修復方法在工具描述中。執行錯誤意味著工具本身壞了，修復方法在你的程式碼中。

每個已完成任務的步驟數和token數。成功率保持穩定但每個任務的步驟數增加意味著成本上升而準確性不變。在每次模型交換和提示更改後觀察這一點。

上下文視窗利用率。壓縮和截斷問題的早期預警。質量通常在上下文填滿時下降，因此利用率趨勢告訴你需在失敗對使用者仍不可見時進行干預。

迴圈檢測。代理重複相同工具呼叫和相同引數的比例。迴圈純粹是token浪費，從軌跡日誌中用幾行程式碼即可檢測。

監測差距

回顧五個組，模式很明顯。延遲和可靠性在第一天就出現，因為閘道器、負載均衡器和提供商SDK作為服務流量的副產品發出它們。質量、每次任務成本和代理行為指標不會產生，直到你構建測量它們的管道：從每次響應記錄的token和快取欄位、每次更改時執行的評估集、校準過的評判員、代理的軌跡日誌。

這也是為什麼全面監控和真正的盲點並存：監控覆蓋了基礎設施報告的維度，而故障位於它沒有報告的維度。後果是預算問題。質量和每次任務成本的檢測應屬於AI功能的初始構建估算，而不是在後續審查中。

從何處開始

你不應該透過一次性實施所有措施來減慢開發進度。按資訊密度排序的順序：

TTFT和端到端延遲，按用例區分。如果你使用流式傳輸，TTFT是使用者感知的延遲，兩者都來自你已有的時間戳。

每個請求的token數和快取命中率。兩者都是API響應中的欄位，記錄它們很容易，並且它們能立即闡明單位經濟。

帶任務成功率的標記評估集。從50個示例開始，並在每次相關更改時重新執行的紀律。

每個提供商的錯誤率和回退率。新增成本低，回退與質量的互動是常見的無聲退化。

代理指標，當你部署代理時。按原因拆分的工具呼叫錯誤、每個任務的步驟數和上下文視窗利用率都可以在軌跡日誌中找到。

這個列表具有代表性而非詳盡無遺。它故意省略了當你自己託管推理時重要的GPU級服務指標（KV快取利用率、批處理佔用率），以及嵌入和資料漂移，以及業務層指標如包含率或每次會話的收入。

要點

按指標回答的問題分組：速度、擴充套件性、正確性、可靠性、代理行為。

將延遲作為請求時間線上的位置追蹤：TTFT用於感知速度。

每次成功任務的成本是連線所有指標的單一數字。

質量指標需要自行構建，它們不會自動生成。

代理指標需要追蹤步驟、工具呼叫和迴圈。

從TTFT和延遲開始，逐步新增成本、質量和代理指標。