LLM 系統的 AI 可觀察性是甚麼？
AI 可觀察性是一份紀錄，讓工程師解釋 LLM 系統在正式環境給過的任何答案。每個用戶請求對應一條 Trace。
Trace 記下模型看到的 Prompt、檢索到的文件、調用了哪些工具及參數、最終答案，以及所用的 Token、金錢和時間。
一般的應用程式監察，只告訴你服務是否運作、反應多快。LLM 系統可以運作正常、速度快，但答錯。AI 可觀察性補上內容及質素訊號。
每次 LLM 調用應記錄甚麼？
先記錄能解答「它為甚麼這樣答」的欄位：
| 欄位 | 用處 |
|---|---|
| Trace 及步驟 ID | 把檢索、工具調用和答案連到同一個用戶請求。 |
| 模型名稱及版本 | 供應商更新模型，行為可能改變，而你甚麼都沒有改。 |
| Prompt 範本版本 | 質素下跌時，找出是哪次 Prompt 修改造成。 |
| 檢索到的來源 | 分辨錯誤答案出自模型，還是出自餵給它的資料。 |
| 工具調用及參數 | 看到 Agent 實際做了甚麼，而不是它說自己做了甚麼。 |
| 每步的 Token、成本及延遲 | 找出慢或貴的步驟，只改那一步。 |
| 結果或回饋 | 用戶負評、轉介真人，或業務結果例如成功預約。 |
Prompt 和答案可能包含個人或機密資料。上線前要決定哪些欄位完整儲存、哪些遮蔽，以及 Trace 存放在哪裡。
LLM 監察與 LLM 評估有甚麼分別？
監察看即時流量，告訴你發生了甚麼：用量、錯誤、成本、延遲和用戶回饋。評估用一組有標準答案的固定真實案例，告訴你系統是否答對。
監察發現事故，評估告訴你修正後是變好還是變差。評估案例應從正式環境的 Trace 中挑選，實際出錯的案例最值得每次改動後重測。
應該用 OpenTelemetry 做 LLM 可觀察性嗎？
OpenTelemetry 是大部分追蹤工具都支援的開放標準。它有一套生成式 AI 規範，涵蓋模型調用、Agent 及 MCP 工具調用的 Span、指標和事件。
這套 GenAI 規範已移到獨立代碼庫 semantic-conventions-genai，仍在修訂中（2026 年 10 月查閱）。
實際做法是用標準格式埋點一次，再把 Trace 送到你選擇的後台。日後轉換供應商，紀錄仍屬於你；數據須留在本地時，Trace 也可留在自己的基建內。
可觀察性在真實系統帶來甚麼改變？
它把爭論變成量度。Super Cat Technology 建立的24/7 AI Call Centre每月處理 20 萬通來電，服務 60 個美國 HVAC 品牌。
系統的預約成功率與真人比較：AI 是 67%，人手是 77%。這個數字說明系統現在的位置，以及下一次改動要推動甚麼。
按步驟記錄成本和質素，也讓更換模型變得穩妥。在一個私募市場搜尋項目中，一個便宜約 90% 的模型接手了實體歸類。每一步都有獨立量度，才有信心作這種轉換。
AI 可觀察性有甚麼風險？
- 測試結果與實際使用不同。我們用客戶的真實案例量度，如實匯報數字，再界定修正範圍。
- 模型或供應商有變。每條 Trace 上的版本欄位，顯示供應商更新何時影響質素。我們在選型時檢查供應商條款，條款改變便轉用替代方案。
- Trace 含敏感數據。記錄下來的 Prompt 是用戶數據的副本。政策要求數據留在你的伺服器時，Trace 也留在那裡。
應該由誰建立？
應由建立 LLM 系統的工程師負責埋點，因為他們知道哪一步會無聲出錯。如果團隊正交付第一個正式上線的 LLM 系統，駐場 AI 工程師可以同時建立系統和追蹤，再一併移交。有工具權限的 Agent，上線前應配合保安審查。
Cat 的看法
「我的團隊開發的 Call Centre，最重要的數字是預約率與真人團隊的對比：67% 對 77%。如果每通來電沒有完整的追蹤記錄，我們無法說出是哪一項改動令數字變化。凌晨兩點解釋不了的系統，仍然只是 Demo。」
我的觀察：2026 年 10 月
- 供應商現在按固定日期淘汰模型。有追蹤記錄和評估集的團隊，把換模型當作一次測試。沒有的團隊，要由用戶告訴他們。
- 成本已成為工程問題。每個步驟獨立量度，就可以讓較便宜的模型接手其中一步，我們的私募市場搜尋項目正是如此。
- 騰訊本月表示，旗下運行的 AI Agent 出現了非預期的瀏覽行為。工具調用的追蹤記錄，正逐漸納入安全審查。
Cat Yung，2026 年 10 月
資料來源：OpenAI API deprecations (2026 年 4 月 22 日通知) · Anthropic model deprecations (2026 年 9 月 30 日通知) · 英文虎報（路透社）：騰訊 AI Agent (2026 年 10 月 16 日)
常見問題
正式上線 LLM 系統的 AI 可觀察性是甚麼？
AI 可觀察性把每個請求記錄成一條 Trace：Prompt、檢索到的文件、工具調用、答案，以及成本、延遲和質素訊號。工程師可以解釋系統給過的任何答案，並看到更換模型或 Prompt 後質素有否變化。
每次 LLM 調用應記錄甚麼？
記錄 Trace 及步驟 ID、模型名稱及版本、Prompt 範本版本、檢索來源、工具調用及參數、每步的 Token、成本及延遲，以及結果或回饋。Prompt 常含個人或機密資料，上線前應決定哪些欄位要遮蔽。
OpenTelemetry 適合用來追蹤 LLM 嗎？
OpenTelemetry 有涵蓋模型調用、Agent 及 MCP 工具調用的 GenAI 規範，截至 2026 年 10 月在獨立代碼庫維護，仍在修訂。用這個格式埋點，Trace 可在不同後台之間轉移，也可留在自己的基建內。
LLM 評估與監察有甚麼分別？
監察看即時流量的錯誤、成本、延遲和回饋。評估用一組有標準答案的固定真實案例檢查是否答對。監察發現事故，評估顯示修正有否改善。評估案例應取自正式環境中出錯的個案。
資料來源
- OpenTelemetry, GenAI semantic conventions repository (2026 年 10 月查閱)
建立系統並對成果負責的工程師。
Agent 取得工具權限前的保安審查。
已交付過正式上線 LLM 系統的人。
給 Agent 憑證前的六點清單。
關於作者
Cat Yung是 Super Cat Technology 創辦人，團隊在香港及倫敦開發 AI Agent，並以 AI 專家、Data Scientist 及兼職 CTO 身份與企業合作。擁有逾十年生產級 AI、NLP 及機器學習經驗；Upwork Expert-Vetted 前 1%，Job Success Score 100%（來源：Upwork 個人檔案，2026 年 10 月）。