第 6 章 — AI 可觀測性與追蹤

LLM Primer V: Building Real-World LLM Applications 章節走讀的第六篇。這一章把使用者的查詢當成一棵因果樹處理,不當成請求日誌,並展示要讓那棵樹可讀,得追蹤什麼。

這一章為什麼存在

LLM 系統裡一個使用者查詢會展成一棵樹:一次 query rewrite、對兩個索引三次檢索、一次重排、一次 planner 呼叫、四次工具呼叫、一次 summarizer、以及最後一次生成。把那棵樹壓成「收到請求、送出回應」,真相就沒了。使用者抱怨答案錯,團隊沒辦法回答檢索有沒有漏掉對的 chunk、planner 是不是挑錯工具、工具是不是回錯資料、還是 generator 忽視了它拿到的東西。第 6 章為這種形狀重建可觀測性。傳統分散式追蹤是那個底層;OpenTelemetry GenAI 語意慣例是把模型呼叫升格為一等公民的擴展;LLM 專屬指標 — TTFT、TPOT、每次呼叫成本、judge 分數 — 是把 trace 變成團隊能對之營運的東西的關鍵。

6.1 從請求日誌走到因果 trace

這步是從平面請求日誌走到嵌套 span。OpenTelemetry 加上 GenAI 語意慣例提供了跨供應商可攜、對 LLM 呼叫、嵌入、檢索、工具呼叫都通用的 span 形狀。代理迴圈變成根 span;每一輪迭代變成子 span;每一次 LLM 呼叫、工具呼叫、檢索都嵌在下面。多回合對話變成樹的樹,span link 標出跨回合共享的狀態 — 第三回合的摘要,到了第七回合還在依賴。價值第一次除錯時就顯現:「retriever 對那個查詢撈出哪個 chunk、generator 有沒有真的引用它」這個問題在平面日誌上必須靠考古學來回答,現在只要看一條 trace 就好。Span 形狀跨廠商可攜,因為那是 OpenTelemetry 標準、不是某家專有格式,從 LangSmith 換到 Langfuse 變成路由改動、而不是重寫。

6.2 真的重要的指標 — TTFT、TPOT、成本、品質

總延遲不夠。時間到首 token — TTFT — 對串流回應主宰感知速度:使用者盯著第一個字元,不是最後一個 — 而 TTFT 應該跟總延遲並列在 span 上。每輸出 token 時間 — TPOT — 主宰長回應的節奏感,是使用者說「它跑到最後很慢」時感受到的東西。成本應該當一級屬性掛在 span 上,由呼叫端根據帶版本的定價表算出,好讓歷史 trace 在價格改動後仍然說的是真話。品質訊號 — 使用者按倒讚、評估管線的 judge 分數、包裝觸發的 fallback — 當屬性掛在 trace 上,這就是團隊把壞答案跟產出它的那次模型呼叫與檢索對起來的方法。指標會在儀表板上被看見,但更高報酬的地方是它們可以按 trace 查詢,一次回歸可以用「高成本、低 judge 分」過濾,出事的那條路徑立刻浮上來。

6.3 平台與收攏迴圈

四個平台佔了目前的景觀。LangSmith 是 LangChain 整合最順的選項,如果應用已經在 LangChain 裡摩擦最小。Langfuse 是自架的開源選項,適合規範型部署跟需要「trace 留在自家邊界內」的組織。Arize Phoenix 有強的嵌入分析,是「哪些查詢落到向量空間錯的區域」這種診斷問題的對的工具。Helicone 當作供應商 API 前面的 proxy 跑,是最低介入的整合,但只看得到 LLM 呼叫那一層。這個選擇是營運面的、不是品質面的 — 大多數平台露出的是同一套核心形狀。更高價值的工作是匯出管線:負回饋 trace、低 judge 分數、fallback 觸發變成候選評估案例,精煉進評估集,由下一次發布 gate 擋住。那個迴圈就是把生產環境變成開發的老師的東西。

第 6 章接下來會怎麼走

Trace 也是安全事故變得可見的地方。一次成功的 prompt injection 在 trace 樹上看起來是一次意料外的工具呼叫。外洩看起來像一次檢索 span,而模型接下來把那個 chunk 當指令服從了。被洩漏的 system prompt 看起來像一次補全 span,而它的文字跟上面的 prompt 重疊得不像巧合。第 7 章把同樣的追蹤底層轉向安全紀律 — 用 OWASP LLM Top 10 當 2025 年中的詞彙、那個詞彙想命名的直接對上間接注入分類,以及那個把「權限必須配得上信任來源」原則落實的四層緩解矩陣。

下一篇 — 第 7 章:LLM 安全與護欄。回答追蹤層剛把「這件事到底該怎麼發生、誰有權讓它發生」這個問題變得可問後的那個安全姿態。