[Day 20] RAG 追蹤一次 Request 的完整生命週期

前幾天我們完成了 RAG 系統的 Evaluation、Error Case、Observability 與 Alerting

但到了 Production，又會遇到一個更實際的問題：

如果某一次 Request 特別慢、回答錯誤，甚至整個請求失敗，我要怎麼知道到底是哪一個環節出了問題

這時候只看 Log 或 Metrics 往往不夠

今天要加入 分散式追蹤，讓我們可以從一個 Request 開始

這解決了：

「系統現在有沒有問題」

但如果收到 Alert 後，我們還會問：

「到底是哪個 Request、哪一個階段出問題」

光看 Metrics，只知道這次 Request 很慢

但實際可能的瓶頸其實是 LLM

因此：

Metrics 告訴我們「哪裡有問題」，Tracing 幫助我們找到「問題發生在哪裡」

什麼是 Trace

一次完整的 Request 可以稱為一個 Trace

這就是一次完整的 Request Trace

什麼是 Span

Trace 裡面還可以再拆成很多個 Span

Trace ID 與 Span ID

要把不同階段串起來，就需要 ID

最重要的是：

Trace ID

代表：

這整次 Request

同一個 Request 裡面的所有 Span 都屬於同一個 Trace

而每個 Span 又有自己的 Span ID

因此可以建立完整的父子關係

Tracing 最重要的用途之一，就是分析

時間到底花在哪裡

不要把所有資料都塞進 Trace

Tracing 很方便，但不代表什麼都要記

設計原則就是：

建立最小可觀測性且在必要資料的基礎上

所以：

Tracing 不只是拿來看時間，也可以協助判斷 Error 發生在哪一個 RAG Stage

今天學到什麼

今天最重要的概念有：

Trace

代表一次完整 Request

Span

代表 Request 中的一個處理階段

Trace ID

把同一次 Request 的所有 Span 串起來

這時候的 RAG 已經不只是：

「把文件丟給 LLM，讓它回答問題」

而是開始具備一套真正可以被：

監控、分析、除錯與持續優化 的 Production 架構

而今天我們可以追蹤

但 Production 還有一個非常現實的問題：

這個系統到底花了多少錢

每個階段都可能產生成本

因此下一篇將進一步從 Tracing 裡面的 Token Usage、Request 數量與模型使用量

Day 21：RAG Cost 從 Token Usage 到 Production 成本分析

讓我們繼續把這套 RAG 系統，從「能運作」一步一步推向真正可以上線的 Production 系統