AI 功能的可觀測性平台：從日誌到可回答問題

1. 這位使用者剛才那次請求發生了什麼？（完整軌跡）
2. 過去一小時的失敗集中在哪個環節？
3. 哪個功能的成本成長最快？
4. 新版提示上線後，哪些指標變差了？
5. 延遲的長尾來自哪裡？
6. 哪個工具的錯誤率最高？
7. 棄答率上升的原因是檢索還是生成？
8. 這個錯誤是新出現的還是一直存在？
9. 哪些查詢一直查不到答案？
10. 目前有多少請求在排隊？

三種訊號各司其職

• 追蹤（trace）：回答「這一次發生了什麼」。含每個環節的耗時與參數。
• 指標（metric）：回答「整體趨勢如何」。彙總數值，適合告警。
• 日誌（log）：回答「細節是什麼」。含完整內容，量大且昂貴。

# 一次 RAG 問答的追蹤結構
trace(qa_request)
  ├─ span(auth)           12ms
  ├─ span(rewrite_query)  184ms   model=small, in=120 out=32
  ├─ span(retrieve)
  │    ├─ span(vector)     54ms   top_k=40
  │    └─ span(bm25)       31ms   （與 vector 平行）
  ├─ span(rerank)         218ms   n_cand=20
  ├─ span(generate)       842ms   model=main, in=3120 out=286
  └─ span(verify_cite)      6ms   result=ok

取樣策略

全量記錄追蹤太貴。實務做法是分層取樣：

失敗請求        100%   ← 一定要留
慢請求 (>p95)   100%
成本異常        100%
新版本流量       20%   ← 灰度期間加密
正常請求          1%   ← 維持基準樣本

關聯鍵的設計

所有訊號都要能用 trace_id 串起來，而且這個 id 必須傳到前端並在錯誤畫面上顯示。使用者回報時提供這串碼，你就能一次撈出所有相關資料。

敏感內容的處理

• 預設不記錄完整的提示與輸出，只記長度與雜湊。
• 需要內容時，以短期高權限的方式開啟，並記錄誰開啟過。
• 個資欄位在寫入前就遮蔽，不要依賴查詢時才過濾。