概述

在過去幾篇文章中，我們從傳統監控一路聊到「可觀測性 2.0」，並探討了為何像 ClickHouse 這樣的 OLAP 資料庫會成為新時代的基石。這一切的鋪陳，都是為了迎接今天的主角，一個時代潮流的代名詞：LLM (大型語言模型)。

LLM 看似無所不能，它吸收了人類千年的知識積累，能寫詩、能寫程式、能像專家一樣對答如流。但...事實真的如此嗎？

LLM 可觀測性是什麼

LLM 可觀測性指的是對已上線、實際運行的 LLM 應用服務所產生的「模型層級」遙測資料進行結構化分析。它建立在 MELT 框架（Metrics、Events、Logs、Traces）之上，但重心從系統基礎設施轉向模型行為與輸出動態。

在傳統可觀測性中，MELT 訊號用於追蹤服務可用性、請求延遲、吞吐量與錯誤率。這些指標對於靜態、以規則為主的系統已相當足夠；但對於依賴提示詞、上下文與內部權重而產生高度可變輸出的 LLM 系統，僅靠基礎設施層級的指標，無法完整評估其運作狀態。

因此，LLM 可觀測性在 MELT 之上加入語義與行為層面的觀測：

• Metrics（指標）：例如幻覺率、提示敏感度、回應多樣性。
• Events（事件）：追蹤輸出語氣或準確度的突發性變化等異常。
• Logs（日誌）：擷取結構化的提示詞、模型輸出與模型信心分數。
• Traces（追蹤）：串接多步驟代理（agent）工作流程，顯示中間提示如何影響最終輸出。

這些更豐富的遙測資料，讓工程與產品團隊可在實時中追蹤根因、監測輸出品質，並及早發現模型退化；同時也支援安全更新與定向改進的回饋循環。

重要的是，LLM 可觀測性並不侷限於「成功／失敗」二分法的簡單，這就是為何它被設計用來當作我們觀測在各種輸入的機率性行為。

為何我們需要 LLM 可觀測性

不久前，我與一個知名的 LLM 有過一段有趣的對話。我先問了一個專業問題，它給出了近乎完美的答案。

看起來 LLM 產生的內容跟我們之前所提到的重點符合，並且他的敘述更有組織編排，吸收了人類幾千年知識積累，聽起來他才是無所不知的專家。

接著，我故意提出一個錯誤的觀點，並堅持己見。一開始，LLM 還會嘗試糾正我，但在我用更肯定的語氣引導幾輪後，它居然妥協了，開始「附和」我的錯誤觀念。

但...事實真的是這樣嗎？看似豐富專業的回覆中，LLM 依然存在著對應的缺陷。這正是 LLM 一個很本質的缺陷：它不是在「理解」問題，只是不斷的「預測」出下個機率最高的 Token 而已。

它的智慧來自於龐大的訓練資料，而非真正的邏輯推理。這意味著它的輸出是機率性的、不確定的，而且容易被引導。它是一個我們無法完全預測其內部狀態的系統。

LLM 可觀測性的核心目的，是讓開發者能夠回答以下問題：

• 某次模型回應為何產出錯誤（或出現幻覺）？
• Prompt、上下文、模型版本、超參數與輸出之間的因果關係為何？
• 模型的輸出品質是否隨時間退化？是否因部署版本變更而出現偏差？
• 使用者行為是否揭露出某些 prompt pattern 在特定任務上表現不佳？

這正是為何我們需要 LLM 可觀測性。因為少了它，我們就像是在這個 AI 構成的黑盒子裡摸黑前行，對其內部的運作一無所知。

如何「評估」 LLM 是否表現良好？

假設你擁有一個 LLM AI 助手，每天協助你處理工作任務，例如閱讀電子郵件、回覆客戶訊息、撰寫報告等。即使這位助手在這些任務中從未出錯，且總是能準時交付成果，我們依然無法確定它的表現是否良好。

這反映出一個 LLM 系統獨有的挑戰：在這類非確定性模型中，「任務是否完成」不能僅以輸出是否成功或無錯來評估。模型可能產出語法正確、看似合理的內容，但實際上卻偏離使用者意圖、缺乏上下文相關性，甚至造成決策誤導。

因此，在 LLM 的世界裡，我們不能再用傳統的「成功／失敗」二分法來衡量任務完成與否。我們需要新的觀測與評估方法，來衡量模型的行為品質、輸出合理性，以及對使用者需求的對齊程度。

我們可以怎麼對 LLM 進行評估？

既然 LLM 的表現並不總是可靠，那我們該如何科學地評估一個 LLM 應用程式的好壞呢？事實上，在現實世界中，評估本身就是一門深奧的學問，背後往往涉及統計學、測量學、決策理論，甚至與資訊理論、機率論密切相關。因此，對 LLM 的評估方式，自然也不能只是單靠主觀感覺或表面結果。

比方說，我們在職場上評估一個 LLM 的表現，可能會使用不同的方式：

• Human Evaluation（人工評估）： 由人類主動檢查模型產出，例如每天人工閱讀 AI 撰寫的郵件、報告，逐一修正與評分。這種方式最能體現實際使用者的感受，但成本高、不具擴展性。
• LLM-as-a-Judge（模型即評審）： 請另一個語言模型來擔任「評分員」，例如使用 GPT-4o-mini 來對 GPT-4o 的回答進行評論、打分，這種方式可大規模自動化，但會受限於評審模型本身的偏差與能力。
• Metric-based Evaluation（指標評估）： 建立結構化的指標來衡量模型表現，例如錯誤率、命中率、精確率、召回率、F1 分數等，這些多半需要預先定義任務標準答案（ground truth）。
• Rule-based Evaluation（規則評估）： 使用程式化的方式，例如 if-else 條件、正則表達式（regex）、關鍵字比對，來檢查模型回應是否符合某些格式、包含關鍵資訊，或是否出現特定錯誤模式。

這些方法各有優缺點，往往需要交叉搭配使用，才能補足彼此盲點。更進一步來說，真正成熟的 LLM 評估系統，往往還會結合 A/B 測試、使用者點擊回饋（implicit signals）、回應信心分數（uncertainty score）、以及長期的任務績效（task success rate）等指標，才能全面描繪出 LLM 在真實世界的整體表現。

LLM 評估的常見維度

在現實應用中，語言模型的輸出具備高度不確定性——即便是同樣的輸入、在不同時刻也可能出現風格或內容各異的結果。因此，對於 LLM 系統的品質評估，不能單靠單一數值或片段印象來下結論，而是需要從多個角度切入觀察模型行為。

以上的表列出的是業界常見的 LLM 評估維度，包括：

• 正確性（Correctness）：輸出是否符合事實、是否能與真實資料對應。
• 幻覺（Hallucination）：模型是否產生看似合理但實際捏造的資訊。
• 關聯性（Relevance）：輸出是否回應了提問，是否有上下文意識。
• 一致性（Consistency）：針對類似輸入是否能產生可預期的穩定結果。
• 安全性與毒性（Toxicity/Safety）：是否避免了冒犯、偏激或危險建議。
• 偏誤與公平性（Bias/Fairness）：模型是否歧視特定族群，是否提供平衡的觀點。
• 完整性（Completeness）：是否完整回答了問題，涵蓋所需重點。
• 流暢度與連貫性（Fluency/Coherence）：語言是否自然、語法是否通順、邏輯是否合理。

更關鍵的是，這些維度往往需要根據不同的業務情境與商業邏輯來調整。例如，客服應用中可能格外重視「正確性」與「安全性」；而在內容生成場景，則可能會強調「流暢性」與「一致性」。因此，建立一套具有情境彈性的觀測與評估系統，是開發高品質 LLM 應用的關鍵一步。

LLM 可觀測性的重要性

在大型語言模型（LLM）應用進入生產環境的今天，可觀測性（Observability）不再是附加的選項，而是確保系統可靠性、效率與品質的基本能力。LLM 的特性使得其行為常具有非決定性、上下文敏感性與難以預測性，因此若缺乏足夠的觀測與追蹤機制，就難以掌握它是否真的「表現良好」。

• 模型改善（Model Improvement）：透過可觀測性，我們能夠蒐集使用者互動資料、輸入輸出樣本、錯誤模式與上下文資訊，進而持續調整與優化模型，提升生成品質與任務完成度。
• 問題追蹤（Issue Tracking）：有效的紀錄與可追溯性，讓團隊可以迅速定位異常行為與錯誤來源，大幅提升 debug 效率與系統穩定性，尤其在多階段 prompt pipeline、tool calling 或 RAG 系統中更顯關鍵。
• 風險管理（Risk Management）：缺乏觀測能力，就無法及時偵測出不當或高風險的輸出，從而可能造成法規違規、品牌信任受損或資料洩漏等重大問題。可觀測性是降低 AI 風險的第一道防線。
• 成本最佳化（Cost Optimization）：LLM 的計算與上下文處理往往代價高昂。透過可觀測性，我們可以監控 token 使用、API 呼叫頻率、檢索結果數量等關鍵指標，進一步進行資源控制與架構優化。

LLM 可觀測性幫助我們「看到模型做了什麼」，更讓我們有能力「理解它為什麼這樣做、何時失誤、如何修正」，這是每一個希望將 LLM 部署於實務中的團隊，無法忽視的基礎工程。

傳統可觀測性與 LLM 可觀測性的差別

有了評估目標，下一步就是收集數據。而正是在這裡，我們才真正意識到：LLM 可觀測性並非傳統可觀測性的簡單延伸，它在根本上就是一個全新的物種。

我們可以從四個核心層面對比它們的巨大差異：

遙測 (Telemetry): 從機器訊號到人類對話

• 傳統： 我們關心的是機器的狀態，如 CPU 使用率、記憶體、應用日誌 (Application Logs)。這些是高度結構化的數字和字串。
• LLM： 我們關心的是對話的內容。遙測數據變成了 Prompt、Response、Token 使用量、模型參數等。這些是半結構化、高基數且充滿語義的文本數據。我們監控的對象從機器變成了「對話」。

輸出 (Output): 從確定性到機率性

• 傳統： 系統是確定性的。相同的輸入（例如一個 API 請求），必然會得到相同的輸出。f(x) = y。
• LLM： 系統是機率性的。即使是完全相同的輸入，每次得到的輸出都可能略有不同。f(x) ≈ y。這種不確定性是 LLM 的核心特徵，也給可觀測性帶來了巨大挑戰。

成功/失敗 (Success/Failure): 從狀態碼到語義判斷

• 傳統： 判斷一次操作的成敗非常直接。HTTP 狀態碼 200 就是成功，500 就是失敗。這是個非黑即白的二元世界。
• LLM： 一次 200 OK 的 API 回應幾乎沒有任何意義。我們真正關心的是：回應的內容在語義上是否正確？是否切合上下文？是否產生了幻覺？ 成敗的定義從一個簡單的狀態碼，變成了一個需要複雜上下文和語義分析才能得出的模糊結論。

成本 (Cost): 從基礎設施到按次計費

• 傳統： 成本主要來自於運行服務的基礎設施，如 CPU 和記憶體。成本相對固定且可預測。
• LLM： 成本與每一次 API 呼叫和 Token 消耗量直接掛鉤。一個設計不良的 Prompt、一次冗長的回應，或是一個更昂貴的模型選擇，都會直接反映在你的帳單上。成本變得動態、即時且難以預測。

迎接 OpenTelemetry 標準化是唯一的出路

面對這樣一個機率性、語義化、且以對話為中心的全新領域，我們顯然無法再沿用過去的工具和思維模式。如果為每個 LLM 應用都打造一套客製化的監控方案，那將是一場永無止境的災難。

人們迫切需要一個統一的標準，一套通用的語法和工具，來描述、收集和傳輸這些複雜的 LLM 遙測數據。

幸運的是，這個標準早已存在，它就是在雲原生時代統一了 Traces, Metrics, Logs 的 OpenTelemetry。它不僅定義了數據如何收集，更重要的是，它正在為 GenAI 制定一套全新的語義約定 (Semantic Conventions)，為我們提供了一把解鎖 LLM 這個黑盒子的鑰匙。

在下一篇文章中，我們將深入探討如何實際運用 OpenTelemetry 的力量，一步步探索一個真正有效、可擴展的 LLM 可觀測性平台。

總結

走到這裡，相信各位已經能清楚感受到，傳統可觀測性與我們今天討論的LLM 可觀測性在概念上存在顯著差異。或許一開始你也跟我一樣，對「LLM Observability」這個詞感到懷疑，覺得它可能只是另一個流行的 buzzword。然而，深入了解之後你會發現，這其實是一個從傳統可觀測性體系自然延伸出來的下一步。

LLM 的不確定性、語境依賴性、多階段推理與外部工具整合，使得我們需要重新思考「什麼是可以觀察的？」、「該如何還原模型的決策過程？」以及「如何衡量模型的品質與風險？」。因此，LLM 可觀測性不是取代傳統觀測手法，而是在原有基礎上，進一步加入語意理解、行為重播、使用者意圖對齊等全新維度。

這是一場從系統監控走向語言理解的轉變，而我們正站在這個技術轉折點之上！