AI 可觀測性：生產環境中監控 LLM 的完整指南 [2026]

AI 可觀測性是擋在你的 LLM 應用程式與靜默失敗之間的唯一防線。跟會拋出 500 錯誤的伺服器崩潰不同，語言模型只會給你一個信心滿滿但完全錯誤的答案——沒有堆疊追蹤、沒有錯誤代碼、什麼都沒有。這就是為什麼傳統監控工具在這裡完全不夠用。

AI 可觀測性一覽

在深入之前，這裡有一份摘要，你可以截圖分享給團隊。

現在讓我們逐一拆解每個部分，先從 AI 可觀測性與你已熟悉的監控之間的根本差異說起。

什麼是 AI 可觀測性（為什麼它跟監控不一樣）？

AI 可觀測性是一種能力，讓你理解 LLM 系統內部正在做什麼——不只是它有沒有在運行，而是為什麼它對特定輸入產出了特定輸出。它將分散式追蹤、即時指標、自動化品質評估和告警整合成一個完整的回饋迴路。

那這跟單純的監控有什麼差別？這樣想：監控告訴你回應延遲飆升到 8 秒。可觀測性告訴你為什麼——你的檢索步驟回傳了 47 個片段而不是 5 個，因為有人改了 embedding 閾值，把 context window 塞滿了，迫使模型產生更長、更慢的回應。

Datadog、New Relic、Grafana 這類傳統 APM 工具是為確定性世界打造的。HTTP 狀態碼、CPU 使用率、記憶體洩漏——這些都是可知的、可重現的狀態。LLM 完全打破了這個假設。同一個 prompt 發兩次，你會得到兩個不同的回應。沒有「預期輸出」可以比對、沒有 schema 可以驗證、沒有可能回傳值的列舉清單。

這種非確定性正是 AI 系統需要專屬可觀測層的核心原因。你不只是在追蹤基礎設施健康，你是在四個支柱上追蹤輸出品質：

• 資料品質——你的 RAG 文件是否過時？Embedding 是否在漂移？
• 模型行為——模型是否比上週產生更多幻覺？供應商的更新是否改變了輸出模式？
• 基礎設施效能——延遲、吞吐量、錯誤率、快取命中率
• 管線完整性——鏈中的所有步驟是否以正確的順序、正確的輸入執行？

監控告訴你東西壞了。可觀測性告訴你為什麼壞了——當你的系統故障看起來跟成功一模一樣時，這個區別就變得格外重要。

為什麼 AI 系統需要專屬的可觀測性

你可能在想：「我就在 LLM 呼叫外面包一層 logging，搞定。」以下是為什麼這樣做撐不了多久。

靜默失敗是常態。 傳統 API 失敗時，你會收到錯誤。LLM 失敗時，你收到的是一段聽起來很合理但完全錯誤的段落。你的使用者可能根本不會注意到——他們只會基於幻覺資料做決策。如果沒有對即時流量運行品質評估，你就是在盲飛。

成本會毫無預警地爆炸。 一個未優化的 agent 迴路，一夜之間就能燒掉數百美元的 token。我認識的一個團隊早上醒來發現帳單是 3,200 美元，因為一個重試迴路每次嘗試都帶著完整對話 context 去呼叫 GPT-4。Token 級別的成本歸因不是選項，是生存必需。

模型漂移是隱形的。 OpenAI、Anthropic 和 Google 定期更新模型。有時候改動對你的使用場景有幫助，有時候會搞壞它。如果沒有基準品質指標和自動化評估，你不會察覺到品質下降——直到使用者抱怨，或直接離開。

Agent 讓問題倍增。 一個簡單的 chat completion 是一次 LLM 呼叫。一個 agent 可能會串接 5 到 20 次呼叫、使用工具、做決策、甚至回溯。如果沒有 session 級別的追蹤，要除錯一個糟糕的 agent 輸出，就像只用 print 語句來除錯分散式系統。可行，但痛苦。

合規不是選項。 如果你的 LLM 產出個資、有毒內容或有偏見的輸出，你需要稽核軌跡。「模型自己幹的」對監管機構來說不是可接受的答案。可觀測性給你追蹤級別的證據來調查和預防這些問題。

AI 可觀測性背後的追蹤架構

追蹤是 AI 可觀測性的骨幹。如果你用過微服務的分散式追蹤，概念是熟悉的，但 LLM 追蹤增加了一些重要的細微差異。

一個 trace 代表一個端到端操作。在 LLM 情境中，通常就是一次使用者請求。每個 trace 包含多個 span——個別步驟，像是「嵌入查詢」、「檢索文件」、「產生回應」或「執行護欄檢查」。Span 可以巢狀嵌套：一個 RAG 管線的 trace 可能有一個父 span，包含檢索 span 和生成 span，各自帶有計時、token 數量和中繼資料。

這裡的重大改進是 OpenTelemetry 的生成式 AI 語意慣例。這些慣例標準化了 LLM 遙測資料的命名和結構——像 gen_ai.system、gen_ai.request.model、gen_ai.usage.input_tokens 和 gen_ai.usage.output_tokens 這類屬性。這種標準化意味著你的 trace 在不同後端之間是可攜的。用 OTEL 做一次埋點，今天送到 Langfuse，明天換到 Datadog。

以下是 LLM 呼叫的基本 OpenTelemetry 埋點長什麼樣子：

from opentelemetry import trace
from opentelemetry.semconv.ai import SpanAttributes

tracer = trace.get_tracer("my-llm-app")

def call_llm(prompt: str, model: str = "gpt-4o") -> str:
    with tracer.start_as_current_span("llm.chat") as span:
        span.set_attribute("gen_ai.system", "openai")
        span.set_attribute("gen_ai.request.model", model)
        span.set_attribute("gen_ai.usage.input_tokens", len(prompt.split()) * 1.3)

        response = openai_client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": prompt}]
        )

        span.set_attribute("gen_ai.usage.output_tokens", response.usage.completion_tokens)
        span.set_attribute("gen_ai.response.model", response.model)
        return response.choices[0].message.content

對於 RAG 管線，trace 會更豐富。你的父 span 包覆整個請求，子 span 分別對應 embedding、向量搜尋、重新排序和生成。每個 span 攜帶自己的延遲、token 數量和自訂屬性（像是檢索到的片段數量或相似度分數閾值）。這種巢狀結構讓你能精確定位一個慢速或低品質回應到底在哪一步出了問題。

大多數可觀測性平台——Langfuse、Braintrust、Arize——要嘛原生接受 OTEL trace，要嘛提供輕量 SDK 產出等效的 trace 結構。趨勢很明顯是朝 OTEL 作為通用標準發展，所以現在投資 OTEL 埋點，未來能給你最大的彈性。

哪些指標對 LLM 真正重要？

不是所有指標都同等重要。以下是該追蹤什麼，大致按照每個指標能多快幫你省錢或防止事故來排序。

延遲是你的第一個信號。分別追蹤 P50、P95 和 P99——P50 告訴你典型體驗，P99 告訴你運氣最差的使用者會有多慘。對於串流應用來說，首 token 時間（TTFT）至關重要，因為感知速度就是一切。

Token 用量同時驅動成本和品質。追蹤每次請求的輸入 token、輸出 token 和總量。輸入 token 突然飆升可能代表你的 RAG 檢索回傳了太多片段。輸出 token 飆升可能代表模型在過度解釋或陷入冗長迴圈。

成本歸因把 token 數量轉換成美元。按請求、按使用者、按功能、按模型拆分。這就是你發現 5% 的使用者產生 60% 成本的地方，或者你的摘要功能比搜尋功能貴 10 倍的地方。

模型之間的成本差距驚人。把簡單查詢路由到較小的模型，把 GPT-4o 或 Claude Sonnet 保留給複雜查詢，可以在不明顯影響品質的情況下削減 60-80% 的帳單。但你需要指標來知道哪些查詢是「簡單的」。

品質分數更難追蹤，但最終是最重要的。包括自訂評估分數（下一節會詳述）、RAG 系統的幻覺率，以及衡量模型輸出是否基於檢索到的 context 的忠實度指標。

維運指標補齊全貌：API 錯誤率、護欄觸發率、逾時率、快取命中率、後備觸發次數。逾時率上升可能代表你的供應商有容量問題。快取命中率下降可能代表使用者在問更多樣化的問題。

評估迴路如何彌補品質缺口？

這裡有一個不夠多團隊內化的觀點：評估不是測試的事，是可觀測性的事。 你的評估應該在生產流量上持續運行，而不只是在部署前的 CI/CD 管線裡跑。

原因很簡單。你無法預測使用者會發送的每一個輸入。部署前的測試套件涵蓋已知模式，但生產流量是奇怪的、對抗性的、不斷變化的。線上評估——對抽樣的即時請求運行品質檢查——能捕捉到你的測試套件從未想像過的失敗。

LLM 作為評審是自動化線上評估最實用的模式。你用一個獨立的模型（通常是較便宜的）來為另一個模型的輸出評分，維度包括相關性、忠實度、有用性和安全性。它不完美——評審模型有自己的偏見——但它可以無限擴展，並捕捉大多數品質問題。

正如 Hamel Husain 所論述的，評估應該排在 AI 開發生命週期中幾乎所有其他事情之前。你無法改善你無法衡量的東西。以下是一個最小的 LLM 作為評審函式：

async def evaluate_faithfulness(question: str, context: str, answer: str) -> float:
    """Score whether the answer is grounded in the provided context (0.0-1.0)."""
    judge_prompt = f"""Rate whether this answer is faithful to the context.
    Question: {question}
    Context: {context}
    Answer: {answer}
    Return only a score between 0.0 (hallucinated) and 1.0 (fully grounded)."""

    response = await openai_client.chat.completions.create(
        model="gpt-4o-mini",  # cheap judge model
        messages=[{"role": "user", "content": judge_prompt}],
        temperature=0
    )
    return float(response.choices[0].message.content.strip())

如需更深入地了解相關性、毒性和連貫性等評估指標，Confident AI 的評估指標指南逐一拆解了每個指標並提供實用的評分標準。

人機協作評估補充了自動化方法。領域專家標註一部分生產 trace，標記不良輸出、修正分數、標註邊緣案例。這些標註回饋到你的評估資料集中，讓你的自動化評估隨時間變得更聰明。

結果就是我所謂的評估飛輪：觀察生產輸出、評估品質（自動 + 人工）、改善 prompt 和檢索、部署變更、再次觀察。每個循環都讓你的系統可衡量地變得更好。每週運行這個飛輪的團隊，其品質改善是那些每季才做一次評估衝刺的團隊無法匹敵的。

觀察 AI Agent：2026 年的挑戰

如果單一 LLM 呼叫已經很難觀察，agent 的難度就高了一個數量級。Agent 不只是產生文字——它推理、規劃、使用工具、做決策，有時還會回溯。一個使用者請求可能觸發 5 次、10 次甚至 50 次 LLM 呼叫，每一次都基於前一次的結果。

如果你正在生產環境部署 agent，你會想先了解商業 AI Agent，然後再回來看可觀測層。

根本的轉變是從請求級追蹤到 session 級追蹤。一個 agent session 可能跨越數分鐘或數小時，包含多次工具呼叫、記憶檢索和子 agent 委派。你的 trace 需要捕捉完整的決策樹，而不只是個別 LLM 呼叫。

以下是 agent 追蹤需要捕捉、而標準 LLM 追蹤沒有的：

• 工具呼叫及其結果——Agent 呼叫了哪些工具？回傳了什麼？Agent 是否正確解讀了結果？
• 推理鏈——Agent 在每一步的計畫是什麼？它是否在 session 中途改變了方法？
• 多 agent 系統中的交接——當一個 agent 委派給另一個時，trace 需要乾淨地跟隨交接
• 狀態轉換——能夠逐步重播 agent 的決策，看到每個決策點的完整 context
• Token 預算——Agent 可能消耗直接 LLM 呼叫 10 到 100 倍的 token。追蹤每個 session 的累計 token 花費對成本控制至關重要

OpenTelemetry 社群正在積極制定 agent 專屬的追蹤標準，擴展 GenAI 語意慣例，加入工具呼叫、規劃步驟和 agent 交接的 span 類型。它仍在演進中，但方向很明確：agent 需要在可觀測性堆疊中獲得一等公民的支持，而不是事後拼湊的變通方案。

實務上，目前最適合 agent 追蹤的工具是 Langfuse 和 Braintrust，兩者都支持 session 級分組、巢狀多步驟 trace 和工具呼叫歸因。如果你用 LangChain 或 LangGraph 在開發，LangSmith 提供深度的原生整合和思維鏈可見性。

AI 可觀測性工具比較：你該選哪個？

工具生態自 2024 年以來已經爆發。以下是 2026 年值得評估的八個平台，後面附有比較矩陣。

Langfuse 是開源領域的領導者。MIT 授權、可自架，從 v3 開始完全原生支持 OpenTelemetry。涵蓋追蹤、評估、prompt 管理和成本追蹤。如果你想要完全掌控資料且零供應商鎖定，Langfuse 是預設選擇。

Braintrust 採取評估優先的方法。它的評分框架可以說是同類中最好的——你定義自訂評分器、在生產流量上運行、追蹤品質趨勢。非常適合輸出品質是第一優先的團隊。

Arize Phoenix 來自傳統 ML 可觀測性世界。開源（BSD 授權），擅長漂移偵測和 embedding 聚類，特別適合有 ML 工程背景、想把熟悉概念應用到 LLM 上的團隊。

Helicone 採取截然不同的方法：它是一個代理。把你的 LLM 流量路由通過 Helicone，你就能得到追蹤、成本追蹤和快取，完全不需要改程式碼。如果設定速度是你的優先考量，沒有比它更快的了。

LangSmith 是 LangChain 團隊的可觀測性平台。如果你已經在用 LangChain 或 LangGraph，整合非常順暢——你得到深度鏈追蹤、playground 除錯和資料集管理。代價是鎖定在 LangChain 生態系。

Weights & Biases Weave 將 W&B 的實驗追蹤擴展到生產環境。如果你的團隊已經用 W&B 做模型訓練和評估，Weave 可以無縫橋接到生產可觀測性，不需要再加一個供應商。

Datadog LLM Observability 是企業級方案。它將 LLM trace 直接整合到 Datadog 的 APM、儀表板和告警中。如果你的維運團隊已經活在 Datadog 裡，這是最省力的路徑。

Elastic Observability 把 LLM 追蹤帶入 ELK 堆疊。開放原始碼（SSPL 授權）、可自架，如果你已經在跑 Elasticsearch 和 Kibana 做日誌分析，這是自然的選擇。

詳見我們的最佳 AI 可觀測性平台【即將推出】，內有實測的深度工具評測。

結論：沒有唯一的贏家——取決於你的技術棧、團隊和優先事項。 Langfuse 是大多數團隊最安全的預設。Braintrust 在評估品質上領先。Helicone 在設定速度上獲勝。如果你已經在 Datadog 生態系中，Datadog 就是最佳選擇。

如何選擇正確的 AI 可觀測性工具

與其糾結於功能矩陣，不如問自己這些問題，讓答案幫你縮小範圍。

最重要的建議？從簡單開始，逐步演進。 選一個工具，為你的關鍵路徑做埋點，這週就把基本追蹤跑起來。你隨時可以加評估、換平台或之後再自架。最糟糕的決定就是不做決定——在沒有可觀測性的情況下跑生產 LLM，就像夜間開車不開頭燈。

選擇正確的技術棧也會影響你的可觀測性需求——參見我們的最佳 SaaS AI 技術棧指南，了解不同架構選擇如何塑造你的監控需求。

實作路線圖：5 步從零到可觀測

以下是我們建議的實務路徑。每一步都建立在前一步之上，步驟 1-3 應該可以在一個 sprint 內完成。

步驟 1：埋點

為每個 LLM 呼叫加上追蹤。如果你從零開始，用 OpenTelemetry——它供應商中立且面向未來。如果你想要更快看到價值，用你選擇的平台 SDK（Langfuse、Braintrust 等）。關鍵是捕捉：模型名稱、輸入/輸出 token、延遲，以及 prompt/completion 配對。

步驟 2：追蹤

把你的埋點連接到後端，驗證 trace 正確流動。檢查 RAG 管線和多步驟鏈的巢狀 span 是否正確渲染。為三大指標設定儀表板：延遲（P50/P95）、token 用量和錯誤率。這是你的維運基準線。

步驟 3：評估

對抽樣的生產流量設定自動化品質評分。從簡單的 LLM 作為評審評估器開始，評估忠實度（RAG）或有用性（聊天）。初期在 5-10% 的流量上運行。追蹤分數隨時間的變化，建立品質基準線。

步驟 4：告警

為最重要的指標設定告警。建議的起始閾值：

• 成本： 每日花費超過 7 天平均的 150% 時告警
• 延遲： P95 超過基準 2 倍且持續 15 分鐘以上時告警
• 品質： 平均評估分數低於基準 10% 以上時告警
• 錯誤： 任何 10 分鐘窗口內錯誤率超過 5% 時告警

步驟 5：迭代

這是飛輪開始轉動的地方。用生產 trace 建立評估資料集。用評估分數找出弱 prompt。用成本資料優化模型路由。把改善回饋到生產環境並衡量影響。每週重複。

從可觀測性中獲得最多價值的團隊，不是儀表板最漂亮的那些——而是持續運行這個回饋迴路的那些。

Techsy 如何看待 AI 可觀測性

在 Techsy，我們在多個產業建構和部署了 AI 應用，可觀測性從第一天起就是每個生產系統不可妥協的一部分。

我們為客戶專案制定的標準方法遵循三個原則：

1. OTEL 優先埋點——我們預設用 OpenTelemetry 做埋點，保留更換後端而不需要重新埋點的選項。這在客戶需求演變時為他們節省了大量遷移成本。
2. 評估驅動開發——我們在第一次生產部署之前就建立評估迴路，而不是之後。自動化品質評分從第一天就運行，給我們一個可持續改善的基準線。
3. 成本感知架構——我們在架構早期就內建模型路由，用可觀測性資料辨識哪些查詢可以由較便宜的模型處理而不損失品質。大多數專案在優化的第一個月就能看到 40-60% 的成本削減。

我們通常建議想要開源掌控權的團隊使用 Langfuse，或者評估品質是第一優先的團隊使用 Braintrust。對於已經在跑 Datadog 的企業客戶，我們將 LLM 可觀測性整合到他們現有的技術棧中。

正在建構 AI 應用，需要協助設定可觀測性？預約免費諮詢。

常見問題

什麼是 AI 可觀測性？

AI 可觀測性是在生產環境中理解 AI 系統（特別是 LLM）內部行為的實踐。它超越正常運行時間監控，涵蓋輸出品質、成本追蹤、延遲分析和追蹤級除錯。目標是回答「模型為什麼產生這個輸出？」而不只是「模型有沒有在跑？」

AI 監控和 AI 可觀測性有什麼區別？

監控追蹤預定義的指標，在閾值被突破時發出告警——它回答「有沒有東西出問題？」可觀測性給你工具去調查為什麼出問題，即使是你沒有預見到的失敗模式。對 LLM 來說，這個區別很重要，因為大多數失敗都是全新的：模型不會崩潰，它只是產生細微錯誤的輸出，沒有任何預定義告警會捕捉到。

2026 年最好的 AI 可觀測性工具是什麼？

頂尖開源選項是 Langfuse（MIT，最受歡迎）、Arize Phoenix（BSD，ML 導向）和 Helicone（代理式，最容易設定）。商業平台方面，Braintrust 在評估上領先，LangSmith 最適合 LangChain 使用者，Datadog LLM Observability 是企業級選擇。完整比較請見上方的比較表。

如何實作 LLM 可觀測性？

先為你的 LLM 呼叫加上追蹤，用 OpenTelemetry 或你選擇的平台 SDK。捕捉模型名稱、token 用量、延遲和輸入/輸出配對。連接到後端（Langfuse、Braintrust 等），設定延遲和成本的儀表板，對抽樣流量加入自動化評估，設定告警。你可以在一小時內把基本追蹤跑起來。

AI 可觀測性工具要花多少錢？

Langfuse、Arize Phoenix 和 Helicone 等開源工具可以免費自架——你只需要付基礎設施費用。雲端託管方案從每月 25 美元（Braintrust）到每月 50 美元（W&B Weave）起。Datadog 等企業平台使用客製報價。大多數團隊可以免費開始，只有在每月超過 5 萬筆 trace 後才需要付費方案。

LLM 可觀測性應該追蹤哪些指標？

必要指標包括：延遲（P50/P95/P99 和首 token 時間）、token 用量（每次請求的輸入/輸出）、成本（按請求、按使用者和按功能的歸因）、品質分數（來自自動化評估）和錯誤率（API 失敗、護欄觸發、逾時）。先從延遲和成本開始，隨著成熟度提升再加入品質評分。

如何在生產環境偵測幻覺？

最實用的方法是忠實度評分——用 LLM 作為評審來評估模型輸出是否基於檢索到的 context（針對 RAG 系統）。你對抽樣的生產流量運行這個評估，並追蹤分數隨時間的變化。當忠實度低於你的閾值時，調查特定的 trace。搭配對標記輸出的人機協作審查，可以獲得更高的準確度。

什麼是 LLM 的 OpenTelemetry？

OpenTelemetry（OTEL）是一個開源可觀測性框架，已成為分散式追蹤的產業標準。GenAI 語意慣例為 OTEL 擴展了標準化的 LLM 遙測屬性名稱，像是 gen_ai.request.model、gen_ai.usage.input_tokens 和 gen_ai.system。這意味著你只需埋點一次，就可以把 trace 送到任何相容的後端。

如何觀察多 agent AI 系統？

Agent 可觀測性需要 session 級追蹤，捕捉跨多次 LLM 呼叫、工具呼叫和子 agent 交接的完整決策樹。你需要追蹤推理鏈、工具呼叫結果、狀態轉換和每個 session 的累計 token 預算。Langfuse 和 Braintrust 目前提供最佳的 agent 追蹤支持，OpenTelemetry 社群也在開發 agent 專屬的語意慣例。

Langfuse 比 LangSmith 好嗎？

取決於你的技術棧。Langfuse 更適合想要開源、自架、供應商中立和 OpenTelemetry 原生接入的人。LangSmith 更適合深度投入 LangChain/LangGraph 生態系、想要原生思維鏈除錯的人。Langfuse 適用於任何框架；LangSmith 針對 LangChain 優化。對於大多數從零開始的團隊，Langfuse 提供更多彈性。

我可以用現有的 APM 工具做 LLM 可觀測性嗎？

部分可以。Datadog 和 Elastic 等工具已經加入了 LLM 專屬功能，所以如果你已經在用它們，不用加新供應商就能得到基本追蹤和成本追蹤。但它們在評估能力、prompt 管理和 agent 追蹤上通常落後於專用工具（Langfuse、Braintrust）。許多團隊用現有的 APM 做基礎設施指標，再加一個專用 LLM 可觀測性工具做品質和評估。

參考來源

• OpenTelemetry 生成式 AI 語意慣例
• OpenTelemetry 部落格：AI Agent 的可觀測性
• Langfuse 文件
• Langfuse 追蹤指南
• Arize Phoenix 文件
• Braintrust 文件
• Helicone 文件
• Confident AI：LLM 評估指標
• Hamel Husain：你的 AI 產品需要評估
• Datadog LLM Observability 文件