AI 可觀測性

3 秒看懂

AI 可觀測性（AI Observability）是讓 AI/ML 系統從“黑箱”變得透明的工程實踐：通過採集指標、日誌、鏈路追蹤以及輸入/輸出快照，即時或近即時地理解模型推論、訓練管道、資料漂移、資源消耗和異常行為，從而保障模型穩定、安全、合規並持續改進。它不是單獨的監控工具，而是橫跨資料、訓練、部署、業務影響的全生命週期可解釋與可行動的觀測體系。

3 分鐘產業解釋

傳統軟體的可觀測性（監控、日誌、追蹤）聚焦於服務延遲、錯誤率、吞吐量。AI 系統在此基礎上要額外回答：“模型做對了沒有？為什麼做錯了？輸入資料變了嗎？特徵分佈有沒有偏移？GPU 算力浪費在哪？生成內容是否安全？幻覺率多高？”

產業落地時，AI 可觀測性通常覆蓋三層：

• 基礎架構層：GPU 利用率、視訊記憶體頻寬、節點間通訊延遲、訓練中途失敗原因（如 NCCL 超時、XLA 編譯異常）。
• 模型與資料層：訓練 loss 不收斂時的梯度直方圖、啟用值的分佈變化、推論延遲的 p99 分位、模型版本效能對比、資料漂移指標（KL 散度、PSI）、特徵缺失率。
• 業務與安全層：生成文本的毒性/事實性得分、RAG 系統的檢索相關性、輸出內容與輸入提示的一致性、使用者反饋閉環。

與 APM（應用效能監控）不同，AI 可觀測性需處理高維矩陣、非確定性輸出、批次作業（訓練任務跑數小時到數週）以及多元件編排（特徵儲存、訓練架構、推論服務、向量資料庫）。因此，觀測管道本身也需要 GPU 友好的採集器（如 NVIDIA DCGM 結合 Prometheus）、模型指標儲存（度量標準可達到百萬級時間序列），以及能關聯訓練試驗和模型血緣的後設資料管理。

目前賽道玩家包括：平台類（Datadog LLM Observability, Arize AI, Weights & Biases, Neptune, LangSmith, MLflow 的拓展能力），以及自研方案（基於 OpenTelemetry 的語義約定擴充套件）。未形成統一標準，但趨勢是建立 LLM 的 tracing 協議（類似 Gen AI 的 trace 語義），將提示詞、響應、token 消耗、延遲、安全稽核結果串聯為一次“呼叫事務”，實現端到端可觀測。

15 分鐘專家深入

AI 可觀測性不是“監控大屏”，而是建置模型行為置信度的工程基石。它的核心挑戰源於 AI 系統的不確定性：同樣的輸入可能得到不同輸出（溫度取樣、隨機種子），批次推論的延遲取決於動態批處理視窗，訓練失敗往往由分散式集體通訊死鎖引發，而這些失敗需回溯到幾小時前的資料載入階段。

深入拆解，AI 可觀測性涵蓋五個支柱：

1. 指標：分為系統指標（GPU 功耗、SM 佔用率、視訊記憶體回退）和模型指標（困惑度、BLEU/ROUGE、幻覺率、漂移分數）。訓練過程中的步時間、吞吐（tokens/sec/gpu）、梯度的範數是排障的關鍵訊號。
2. 追蹤：以 Span 形式記錄從資料攝取到推論出 Token 的完整路徑。每個 Span 包含操作名稱、耗時、屬性（模型名、提示文本 template id、上下文視窗長度、檢索到的文件塊 id）。這對微調、RAG 和多 Agent 編排尤為關鍵。
3. 日誌：不同於傳統文本日誌，AI 可觀測性推崇“結構化的推論日誌”——將輸入、取樣引數、輸出、安全標記、成本等打包為 JSON 事件，支援後續分析。
4. 資料質量與漂移：持續計算訓練/推論資料的分佈特徵（數值特徵的分位數、類別特徵的出現頻率），並與基線比較，檢測“靜默失敗”。
5. 反饋迴路：直接整合使用者點贊/踩、修正、人工標註，形成模型評估的閉還資料集，實現“以觀測驅動迭代”。

實施時，一套典型的技術棧是：在訓練叢集中，用 Prometheus + DCGM Exporter 採集硬體指標，用 W&B 或 MLflow 記錄實驗指標和產物；在推論服務上，用 OpenTelemetry SDK 對模型呼叫埋點，增加 gen_ai 系列 Span 屬性，將資料傳送到可觀測後端（如 Jaeger、Grafana Tempo、Datadog）；同時，評估管道（如 RAGAS、DeepEval）的輸出指標也被推入指標儲存。整個體系需處理海量高基數資料：每次推論可能包含數百個 Token，模型生成呼叫通常作為一個整體 Span，各個 token 的生成資訊作為 Span 內的事件或屬性記錄，需要取樣和聚合策略防止儲存爆炸。

與傳統可觀測性相比，AI 可觀測性的技術獨特之處在於：必須理解 模型的不確定性來源（偶然不確定性/認知不確定性），並通過溫度引數、Top-p 取樣與輸出的 Entropy 相關聯；必須處理 多模態（圖片、音訊訊號的觀測需要不同評估器）；必須符合 負責任的 AI 治理要求（審計追蹤、模型決策解釋、偏見檢測）。

技術原理

AI 可觀測性的技術核心可以抽象為“採集-轉換-關聯-行動”管道，程式碼塊示意如下：

[ 資料與模型流水線 ]
  │
  ├─ 資料載入 → 資料驗證（Great Expectations） → 漂移指標（Evidently AI）
  │      └─ 輸出: 特徵分佈直方圖、缺失值比率、KL 散度
  │
  ├─ 訓練作業 → 架構回撥 (Keras Callback/PyTorch Lightning hooks)
  │      └─ 輸出: loss, grad_norm, learning_rate, memory_allocated, gpu_util
  │            (通過 OpenTelemetry Metrics API 暴露，或直接推送至 W&B)
  │
  └─ 推論服務 → 模型包裝器  intercept 前向傳播
         └─ 建置 Span:
                ├─ pre_processing (tokenize, embedding lookup)
                ├─ model.generate (整體 Span，內含 token 生成事件)
                ├─ post_processing (detokenize, safety filter)
                └─ Span 屬性:
                      model.name = "llama-3-70b"
                      gen_ai.request.model = "llama-3-70b"
                      gen_ai.response.id = "chatcmpl-xxx"
                      gen_ai.usage.input_tokens = 320
                      gen_ai.usage.output_tokens = 180
                      llm.request.temperature = 0.7
                      llm.request.max_tokens = 500

關鍵觀測點的資料傳遞：

• 訓練節點：通常每個 rank 都會產生指標，為避免通訊風暴，常見做法是每個 rank 本地聚合（如計算每個微批次梯度範數），再由 rank 0 或通過 torch.distributed.all_reduce（底層使用 NCCL）彙總統計值（平均值、方差），然後寫出到共享儲存或指標閘道器。
• 分散式追蹤上下文的傳播：在低延遲推論場景，需要使用 W3C Trace Context 標準通過執行緒或協程傳播，將使用者的請求 ID 與底層 GPU kernel 執行關聯。但由於 GPU 計算多為非同步流，精確關聯 kernel 執行時間需要藉助 CUDA Profiling Tools Integration （如載入 nsys 並通過 CUPTI 產生事件），商業觀測平台通常只取 CPU 端排程時間作為近似。
• 高基數資料的處理：當面臨數億次推論日誌時，使用時間序列資料庫（如 VictoriaMetrics）儲存聚合指標，而日誌/追蹤採用列式儲存（如 Parquet）和物件儲存，通過 Presto/Spark 進行離線分析，實現“熱-溫”分離。

模型行為的觀測機理：計算輸出 token 機率向量的熵（Entropy）作為模型確定性的即時指標；當熵異常升高，可能意味著輸入分佈改變或模型退化。對於生成任務，基於參考文本的 ROUGE/BLEU 雖有限，但可在生產流中作為訊號；更先進的觀測引入 LLM-as-a-Judge（使用另一個強模型對輸出打分），並將分數作為觀測指標納入監控。

技術演進史

1. 2015-2018 萌芽期：深度學習研究團隊使用 TensorBoard 視覺化 loss 曲線和計算圖，這是最初級的“模型可觀測”。但基本不涉及生產監控。
2. 2019-2021 MLOps 興起：模型訓練管理工具（MLflow, Weights & Biases, Neptune）出現，實驗追蹤和模型登錄檔成為標準。此時，“可觀測性”仍被等同於實驗比較和 metrics 記錄臺。
3. 2021-2023 模型服務化與資料漂移監控：模型上線後，資料漂移引發線上事故增多，催生監控工具（Evidently AI, WhyLabs, Arize）。可觀測性開始包括特徵分佈監控、模型效能衰退告警。
4. 2023 至今 LLM 時代爆發：ChatGPT 引爆大語言模型應用，推論成本、幻覺、安全、Token 用量等成為核心痛點。觀測需求從訓練延伸到推論全鏈路，LangSmith, Datadog LLM Observability, OpenLLMetry 等專案湧現，OpenTelemetry 社群成立 Gen AI Working Group，推動 LLM 觀測的語義標準化。可觀測性從“對 AI 有幫助的監控”變為 AI 原生應用的基礎設施。

技術路線對比

維度	傳統可觀測性 (APM)	傳統 MLOps 監控	現代 AI 可觀測性
監控物件	微服務、資料庫、基礎設施	模型訓練實驗、模型版本	LLM 應用、RAG 管道、Agent 鏈、資料漂移
核心指標	延遲、吞吐、錯誤率、CPU/記憶體	loss、accuracy、硬體利用率	Token 級延遲、輸出事實性/毒性、檢索相關性、成本、資料漂移分數
追蹤粒度	API 請求 Span	訓練 step/epoch	生成呼叫整體 Span，Token 生成資訊作為事件/屬性，Prompt/Response 完整上下文
故障模式	超時、宕機、連線池耗盡	梯度爆炸、視訊記憶體不足、NCCL 錯誤	幻覺、注入攻擊、內容安全違規、模型退化、資料中毒
資料形態	結構化日誌、固定指標	高維張量、實驗配置	自由文本、多模態、非確定性輸出
關聯性需求	服務拓撲關係	實驗與模型血緣	提示-響應-檢索-稽核的全事務鏈路，使用者反饋閉環

此表顯示，AI 可觀測性是在傳統可觀測性基礎上疊加了模型行為和內容解析的垂直能力。

上下游

上游：

• AI 架構與執行時：PyTorch, TensorFlow, JAX, ONNX Runtime, NVIDIA TensorRT。需架構暴露回撥介面或中間表示供採集。
• 訓練編排與推論引擎：Kubernentes+Volcano, Slurm, Ray Serve, vLLM, TGI。需整合 OpenTelemetry 或自定義指標暴露。
• 特徵儲存與向量資料庫：Feast, Tecton, Milvus, Pinecone。需提供資料水準和查詢延遲的觀測端點。
• 資料管道：Apache Kafka, Spark, Airflow。需注入 trace context 並記錄資料血緣。

下游：

• 告警與事件管理：PagerDuty, Opsgenie，對接模型風險告警。
• 評估與測試平台：RAGAS, DeepEval, LM Eval Harness。其評估結果作為觀測指標源。
• 治理與合規：模型事實記錄、審計報告、歐盟 AI 法案的日誌需求，依賴觀測輸出。
• 模型最佳化：基於觀測資料觸發模型微調（例如發現 C 類樣例準確率持續下降，自動收集資料加入下輪訓練），形成 MLOps 閉環。

關鍵指標

• 效能類：TTFT（首個 Token 生成時間）、TPOT（每輸出 Token 時間）、Token / 秒、吞吐量、GPU 利用率、視訊記憶體佔用。
• 質量類：輸出內容的事實一致性（Factuality Score，基於 NLI 模型或自有評判）、幻覺率、檢索相符率（RAG 中答案是否有文件依據）、模型回覆與預期風格的一致性。
• 漂移類：輸入特徵的 PSI（群體穩定性指標）、輸出分佈的 KL 散度變化、嵌入向量空間位移。
• 安全類：毒性分類機率、越獄企圖計數、PII 洩漏事件次數。
• 經濟類：每次推論成本（美元 / 1k tokens）、單個任務 GPU-小時費用、樣本效率（每提升 1% 準確率所需資料量）。

供需與市場資料

據行業估算，AI 可觀測性市場正以較高速度增長，未來有望形成可觀市場規模。推動力包括：企業對 LLM 應用部署的激增（據行業調研，已有相當比例的企業在生產環境中測試 GenAI），監管對 AI 決策透明度的要求（如歐盟 AI 法案要求高風險系統可記錄事件，相當於強制可觀測性），以及用觀測降低 Token 消耗成本（可觀測發現無效 Prompt 導致的浪費不容忽視）。供給端，創業公司（Arize, LangChain, Galileo, Helicone）與傳統監控巨頭（Datadog, New Relic, Grafana）正在爭奪標準話語權。然而，行業仍處早期，標準未統一，企業自建比例高。

代表公司與資本對映

• Arize AI：專注於 ML 可觀測性，提供漂移監控、模型效能分析和 LLM 評估，已融資數千萬美元。
• Weights & Biases：從實驗追蹤擴充套件到 LLM 管道監控，最新估值數十億美元，是訓練可觀測的標杆。
• LangChain (LangSmith)：LLM 應用建置架構的配套可觀測平台，通過大量使用者網路鎖定開發者，已獲數千萬美元融資。
• Datadog：憑藉廣泛 APM 客戶基礎推出 LLM Observability 整合，延續其傳統優勢。
• Helicone, Trulens：提供專注於 GenAI 的追蹤和反饋整合，代表輕量化工具。
  從資本路徑看，賽道的投資邏輯是“AI/LLM 應用爆發 × 合規強制力”，既是企業效率工具也是治理基礎設施。

投資邏輯

1. 滲透率提升邏輯：當前 AI 可觀測性在 AI 工作負載中的部署率尚處低位（行業估算），隨著生產級大型模型部署增加，該比例預期快速提升，頭部企業將享受 TAM 擴張紅利。
2. 平台化邏輯：可觀測平台天然具備資料入口優勢，可向模型評估、最佳化、安全閘道器延伸，提升單客戶價值。
3. 合規壁壘：在受監管行業（金融、醫療），AI 可觀測是滿足審計追溯和風險控制的剛需，先行建立客戶關係的公司粘性極高。
4. 開源 genAI 觀測標準化：OpenTelemetry GenAI 工作組等標準化努力可能降低入場門檻，但也會加速產品同質化，需關注有獨特分析能力的廠商（如基於模型行為預測衰退、自動根因分析）。
   風險包括：開源工具成熟侵蝕商業空間，以及 LLM 推論逐漸內聚為黑箱 API 廠商（如 OpenAI）自有觀測能力替代三方。

常見誤讀糾偏

• 誤讀：“可觀測性只是裝個監控大屏”
  糾偏：AI 可觀測性的核心在於建置高質量資料資產的反饋閉環，用即時模型行為資料驅動模型迭代和風險管控，而不是靜態的儀表板顯示 GPU 溫度。
• 誤讀：“AI 可觀測性是傳統 APM 加個 ML 外掛”
  糾偏：傳統 APM 無法解析自然語言輸出內容、無法計算內容的事實一致性，也無法刻畫模型不確定性，AI 可觀測性需要深度融合評估模型和語義理解，形成全新的處理層。
• 誤讀：“訓練階段指標就夠了，推論不需要”
  糾偏：離線模型指標（如驗證集準確率）不能保證線上真實分佈下的表現，且無法捕捉生成文本的安全風險，推論可觀測是模型安全上線的必要條件。
• 誤讀：“直接使用 LLM 的 API 日誌即可滿足觀測”
  糾偏：API 日誌只記錄呼叫後設資料，缺少上下文（RAG 檢索的文件片段、多步驟鏈的路由決策），無法排查複雜編排失敗，必須有追蹤體系。

學習路徑

1. 基礎：掌握 OpenTelemetry 的 Traces、Metrics、Logs 概念，理解分散式追蹤的 Span Context 傳播。
2. ML 基礎：瞭解 ML 訓練流程、評估指標、資料漂移概念（PSI, KS 統計），學習 TensorBoard 和 MLflow 的基本用法。
3. LLM 觀測專項：熟悉 LLM 應用的典型技術棧（如 LangChain, vLLM, RAG 架構），閱讀 OpenTelemetry GenAI 語義約定草案，實踐用 LangSmith 或 Arize 監控一個簡單的 RAG 問答應用。
4. 高階主題：研究 LLM-as-a-Judge 的可靠性，探索高基數指標儲存方案（如 ClickHouse），建置模型安全防火牆與觀測的聯動。
5. 工程實踐：在公司內部落地一條包含訓練和推論的可觀測管線，需解決 GPU 監控的精細化（NVIDIA DCGM 指標含義）、多租戶指標隔離、成本歸因。

一句話總結

AI 可觀測性是將模型行為從“藝術”變為“工程”的神經系統，它通過追蹤每一 token 的生成、監控每一組特徵的漂移，讓 AI 產品從勉強可用走向可信可控。

延伸閱讀與來源

• OpenTelemetry GenAI Working Group: opentelemetry.io (GenAI 語義約定草案)
• Arize AI 部落格：對大型模型可觀測性的系列實踐文章
• Weights & Biases 文件：LLM 追蹤和評估整合
• Datadog: LLM Observability 產品文件
• 書籍：《機器學習系統：設計與實現》（涵蓋訓練觀測內容）、《觀察的藝術》（Adapt 理念到 AI）
• CNCF 雲端原生可觀測性白皮書（對基礎概念理解有幫助）
• 由於搜尋資料不可用，以上定性內容來源於公共技術社群、廠商公告及筆者知識整合，未引用特定財報或精確數字，具體部署指標請以各廠商實際測試為準。