LLM observability:log、trace、eval 三件事

大部分 LLM 產品蒙眼在做。團隊寫個 prompt 出貨,收到 bug 報告但重現不了,亂試一些修法希望有一個會中。半年下來,沒人知道最近一次模型升級是讓事情變好還是變壞。

Observability 是讓你的 LLM 系統「可讀」的紀律。三層 —— log、trace、eval —— 把黑盒子變成可以 debug 的東西。

為什麼一般 APM 不夠用

Datadog、New Relic、Sentry 這些對 HTTP 請求流很好。它們告訴你某個 request 花了 800ms,某 endpoint 99% 成功。但它們不是為這些 LLM 特定問題設計的:

• 為什麼模型給這個答案? 你要看完整 prompt,含動態檢索的 context。
• 模型用對工具了嗎? 你要看 agent 決策鏈的每一步。
• 這個對話是不是越跑越爛? 你要比較第 5 輪跟第 1 輪,不只是看單一 HTTP call。
• 新 prompt 是不是把什麼弄壞了? 你要在固定 eval set 上做 before/after。

這就是專門 LLM observability 在解的事。

第 1 層:結構化 log

最低限度有用的 log,每次 LLM 呼叫要記:

• 完整 request body。 模型名稱、system prompt、user prompt、所有 messages、工具定義、temperature、max_tokens、所有 sampling 參數。
• 完整 response body。 所有輸出區塊(文字、tool_use、reasoning 模型的 thinking block)、stop_reason、finish_reason。
• token 用量。 輸入 token(如果用 prompt caching 要拆成 cached vs non-cached)、輸出 token。
• 延遲。 time-to-first-token、總時間。
• 成本。 用 token 數跟當下定價算出來。
• trace ID。 把這次呼叫連回觸發它的使用者 request 的唯一 ID。

開發環境不要遮蔽 prompt。production 如果隱私要求需要,在儲存前遮 PII。

小提示:把 log 存成可查詢格式(Postgres 裡的 JSON、S3 裡的 Parquet、或託管 observability 工具)。純文字 log 過了 1000 筆就沒用了。

第 2 層:trace

單一 LLM 呼叫很少是全貌。真實系統是多步驟的:

user_request -> retrieve(query) -> rerank -> llm_call(plan) -> tool_call(search) -> llm_call(answer) -> response

Trace 把這些都記成巢狀 span,像 Jaeger 或 OpenTelemetry trace 但有 LLM 特定欄位。你看到:

• 完整時間軸。
• 哪一步造成延遲。
• 哪次檢索回傳哪些文件。
• 模型為什麼選工具 X(它完整的推理文字)。
• 錯誤發生在哪。

對 agent 來說 trace 是必備。沒有它,debug「agent 在第 4 輪做錯事」是不可能的。

第 3 層:eval

Eval 是 LLM 行為的測試。兩種:

• 離線 eval。 固定的輸入 + 預期行為資料集,每次改 prompt 或換模型就跑,有 regression 就擋 deploy。RAG evaluation 那篇有詳細介紹。
• 線上 eval。 對真實生產流量近即時打分。LLM-as-judge 跑在抽樣 X% 對話上,標出低品質答案讓你 review。

組合起來很強:離線在 deploy 前抓蓄意破壞,線上抓 eval set 沒涵蓋的真實使用漂移。

2026 工具現況

主要玩家、各自強項跟弱點:

• Langfuse(開源)。trace 很強、原生 eval 支援、可自架。對成本敏感團隊的預設選項。
• LangSmith(LangChain)。如果你已經在 LangChain/LangGraph 上,首選。深度整合、付費。
• Helicone(開源)。輕量,proxy 方式接入很容易。入門好用。
• Arize Phoenix(開源)。RAG 特定指標跟視覺化很強。
• Honeyhive / Galileo / Patronus(商用)。企業導向,更多 guardrails-as-a-service。
• OpenTelemetry GenAI semantic conventions。 LLM tracing 正在浮現的標準,上面工具都在向它收斂。

2026 年從零開始:Langfuse 自架或 Helicone proxy 都行,兩個都不到一小時搞定。等規模長大再重評。

該設警報的四個訊號

Observability 接好之後,dashboard 跟警報設在這些上:

1. 每使用者 / 每請求成本。 一個 bug 把 token 用量翻三倍會悄悄把你的帳單翻三倍。任一單一使用者超過中位數 10 倍就警報。
2. 失敗率。 API 錯誤、timeout、拒答。爆衝代表有東西壞了(廠商當機、key 過期、prompt 改過頭撞 context)。
3. 延遲 p95。 LLM 延遲會漂。同一個 prompt 在 UTC 下午兩點跟晚上八點可能差 3 倍。p95 超過 8 秒通常代表你該上 streaming。
4. 品質訊號。 使用者讚踩、解決時間、重試率。最難打點但最重要。如果品質週對週掉 10% 你沒發現,你的產品在悄悄死掉。

有了 observability 之後可以做什麼

以前做不到的事突然可以了:

• 任何 bug 幾秒內重現。 點一個 trace,複製 exact request,對任何模型重播。
• 科學地比較模型升級。 把上個月流量重跑 GPT-5 跟 Claude 4.7,看誰在你真實分布上比較好。
• 追蹤 prompt 變動。 每個 prompt 標版本,看每版本在幾千次對話上的表現。
• 抓最爛 1%。 按使用者踩數或延遲排序對話,修長尾不修平均。
• 成本優化。 看哪個 prompt 太肥、哪些檢索文件多餘、哪個模型 tier 大材小用。

什麼時候還不要投資

• 單人創辦人、第一天、沒使用者。 Console.log 就夠,時間花在出貨。
• 原型階段。 先把原型出去拿 10 個使用者,再加 observability。太早加 observability 是沉沒成本。
• 單一短 prompt、沒有 agent、沒檢索。 把 input/output 記到 DB 表就好,別過度工具化。

認真投資的觸發點:你開始一週問「它為什麼這樣?」超過一次而且答不出來。

務實起手堆疊

2026 年有真使用者的產品:

• Langfuse 自架 做 trace 跟 log(免費、開源)。
• 30 題回歸 eval 放版本控制,每次 prompt 改在 CI 跑。
• PostHog 或 Mixpanel 做使用者層事件(signup、chat_completed、thumbs_down),讓品質訊號接回產品指標。
• Sentry 處理真 bug(typeerror、500)—— 不是 LLM 特定但還是需要。
• 每週 review 會議 找人讀 50 段隨機對話。最便宜、訊號最強的 eval。

等這套不夠用再升級花俏工具。

下一步

• Langfuse 文件跟範例。
• OpenTelemetry GenAI semantic conventions(W3C 草案)。
• Honeycomb 部落格的 observability 基礎(通用,不是 LLM 特定,但心智模型可轉移)。
• 查這些詞:LLM-as-judge、online evals、drift detection、prompt versioning。