概念位置

跟其他 eval 概念對照：

工作流：

1Day 1：定義 eval set + 初始 prompt + model
2   ↓ 跑 production 一段時間（如 2 週）
3Day 14：把當下 prompt + model freeze 成 baseline-v1
4   ↓
5新版本 prompt / model 都跟 baseline-v1 比
6   ↓ 定期（如每季）refresh
7Day 90：baseline-v2、標明 refresh 時點

設計責任

讀 eval / production AI 文章看到「frozen baseline」「baseline drift」「regression set」就是這個機制。實作判讀：

1. 為什麼必要：每次 A/B 都跟「最新版本」比、長期累積漂移完全不可見、「整體變好了沒」無從回答。Frozen baseline 是漂移的錨點。
2. 何時 freeze：production 跑穩、user 滿意度可接受時 freeze。太早 freeze 鎖到不夠好的版本、太晚 freeze 鎖不到。
3. 何時 refresh：定期（每季 / 每半年）、或當 baseline 明顯 obsolete（如 model 升級、產品大改版）。Refresh 後標明時點、舊版本仍可保留當歷史對照。
4. 跟 frozen baseline 一起的還有：regression set（failed case 永遠進、防 fix 一個壞一個）、production trace 抽樣補進 eval set（讓 eval set 不脫節）。
5. 失敗模式：baseline 跟 production 分佈差太遠（baseline 用 lab case、production 是 wild input）、跑出來分數沒參考價值。緩解：baseline 的 eval set 用 production trace 抽樣建。

完整 eval 系統設計見 4.13 Eval 設計座標系。

概念位置

跟 traditional logging 的對比：

主流 OTel GenAI span 類型：

每個 span 標準屬性：gen_ai.system（vendor）、gen_ai.request.model、gen_ai.usage.input_tokens / output_tokens、gen_ai.request.temperature 等。

設計責任

讀 LLM observability docs / OTel spec 看到「span」「trace」「OTel GenAI semconv」就是這 framing。寫 code 場景的判讀：

1. 何時值得加 tracing：超過個人 demo、有實際使用者 / production 流量、開始遇到「為什麼 agent 跑這條路」debug 問題
2. 不該自己寫 logging：用 OTel GenAI semconv 標準化、未來可換 backend（LangSmith → Phoenix → 自架）
3. Trace 不只 debug、也是 eval 來源：production trace 餵回 LLM-as-judge 做品質評估
4. 跟 4.20 LLM tracing 章節 的關係：本卡是定義、章節是工程實務（attribute 設計、cost monitoring、failure debug 流程）

概念位置

跟其他 eval 路徑的對比：

主要 use case：

1. In-house benchmark：自己工作流的真實案例、自寫 rubric、judge 評
2. Production trace eval：用 LLM tracing 蒐集的 production trace、定期 judge 跑、抓品質回歸
3. A/B test：兩個 prompt / model 變體、judge 做 pairwise 比較
4. Synthetic data quality：用大模型生 fine-tune 資料、judge 過濾低品質

設計責任

讀 eval framework / production AI app 看到「LLM as judge」「pairwise eval」「LLM evaluator」就是這 framing。寫 code 場景的判讀：

1. Judge 模型選擇：強模型當 judge（GPT-5 / Claude 4 / Gemini 旗艦）、reasoning model 更穩；judge 跟被測同家可能有 self-preference bias
2. 三大 bias 緩解：
   • Position bias：A/B pairwise 換位置跑 2 次取一致 vote
   • Verbosity bias：rubric 加「冗長不加分」明確指示、或長度 normalize
   • Self-preference bias：用 3 個不同 judge model 取多數
3. 跟 4.21 LLM-as-judge 章節 的關係：本卡是定義、章節是工程實務（rubric design、bias 緩解、calibration、trace 串接）
4. 不是萬靈丹：高 stake 任務（醫療、法律、安全）仍需 human eval；judge 的天花板 = judge 模型本身的能力

概念位置

Prefix Cache 在推論流程中的角色：

1傳統推論：
2  Request A：system prompt + user A → 完整 prefill → 生成
3  Request B：system prompt + user B → 完整 prefill → 生成
4                                       ↑ 重複算 system prompt
5
6開啟 Prefix Cache：
7  Request A：system prompt + user A → prefill 整段、cache 共用 prefix
8  Request B：system prompt + user B → 重用 cache 的 system prefix + 只 prefill user B → 生成
9                                       ↑ 省下 system prompt 的 prefill 算力

效益對應的場景：

主流推論引擎的支援度（依版本變化）：vLLM、SGLang、llama.cpp 等都有 prefix cache 機制、命名各異。

事實查核註：prefix cache 的命名、設定方式、tenant 隔離預設行為依推論引擎跟版本差異大、引用前以對應引擎的官方文件為準（如 vLLM Automatic Prefix Caching、SGLang RadixAttention 等）。

設計責任

理解 prefix cache 後可以解釋兩個現象：為什麼 production LLM 服務的 latency 在啟用 prefix cache 後大幅下降（system prompt 不再每次重算）、為什麼 prefix cache 在多租戶場景是隱私風險（A 租戶的 prefix 可能被 B 看到、見 llm-multi-tenant-isolation）。

production 設計時、prefix cache 應該按 tenant 分桶、同 tenant 內可共用、跨 tenant 必須隔離。隔離邊界對齊 tenant-boundary 卡片的設計。

本章目標

學完本章後，你將能夠：

1. 把 OS signal 轉成 root context 取消
2. 用 http.Server.Shutdown 停止接受新 request
3. 讓 worker、hub、WebSocket pump 觀察同一個停止訊號
4. 設計 shutdown timeout 與強制退出邊界
5. 測試 server 與 worker 的停止流程

【觀察】直接結束 process 會留下不確定狀態

Shutdown 的核心風險是停止流程不明確。服務可能正在處理 request、WebSocket client 仍在線、worker 正在寫資料、queue message 尚未 ack、diagnostics 還以為服務可接流量。

不完整停止常見後果：

• 新 request 在服務即將關閉時仍被接受。
• WebSocket client 沒收到 close，server 端 goroutine 殘留。
• 背景 worker 寫到一半被中斷。
• readiness 還是 200，負載平衡器繼續送流量。
• 測試結束後留下 goroutine 或開放 port。

Graceful shutdown 是讓停止策略可預期。

【判讀】shutdown 是多階段流程

Graceful shutdown 的核心流程是先停止接新工作，再讓既有工作收尾，最後釋放資源。

建議順序：

 1receive SIGINT/SIGTERM
 2        │
 3        ▼
 4cancel root context
 5        │
 6        ├── readiness becomes false
 7        ├── HTTP server stops accepting new requests
 8        ├── workers stop consuming new jobs
 9        ├── WebSocket hub unregisters clients
10        └── diagnostics/log records shutdown reason
11        │
12        ▼
13wait within timeout
14        │
15        ▼
16process exits

不同服務會有不同細節，但核心不變：停止訊號要集中，元件各自完成自己的 cleanup，整體流程要有 timeout。

【執行】signal 轉成 root context

Signal handling 的核心責任是把作業系統訊號轉成應用程式可理解的取消訊號。Go 1.16 之後可以使用 signal.NotifyContext。

1func main() {
2    ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
3    defer stop()
4
5    if err := run(ctx); err != nil {
6        log.Fatal(err)
7    }
8}

ctx 是 root context。HTTP server、worker、hub、diagnostics 都應從它派生出自己的 lifecycle，而不是每個元件各自監聽 signal。

Signal handler 不應放大量清理邏輯。它只負責發出停止意圖；實際清理由各元件在自己的 ownership 邊界內完成。

【執行】HTTP server 用 Shutdown 停止接新 request

http.Server.Shutdown 的核心行為是停止接受新連線，並等待既有 request 在 timeout 內完成。它比直接 Close 更適合 graceful shutdown。

 1func RunHTTPServer(ctx context.Context, handler http.Handler) error {
 2    server := &http.Server{
 3        Addr:    ":8080",
 4        Handler: handler,
 5    }
 6
 7    errCh := make(chan error, 1)
 8    go func() {
 9        errCh <- server.ListenAndServe()
10    }()
11
12    select {
13    case <-ctx.Done():
14        shutdownCtx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
15        defer cancel()
16        return server.Shutdown(shutdownCtx)
17
18    case err := <-errCh:
19        if errors.Is(err, http.ErrServerClosed) {
20            return nil
21        }
22        return err
23    }
24}

Shutdown timeout 是必要邊界。沒有 timeout 的 shutdown 可能永遠等待某個卡住 request；timeout 太短則可能讓合理 request 來不及收尾。

【策略】readiness 應先變成 false

Readiness 的核心用途是控制服務是否應接新流量。Shutdown 開始後，readiness 應先變成 false，再停止 server 或等待既有工作。

 1type Lifecycle struct {
 2    shuttingDown atomic.Bool
 3}
 4
 5func (l *Lifecycle) BeginShutdown() {
 6    l.shuttingDown.Store(true)
 7}
 8
 9func (l *Lifecycle) Ready() bool {
10    return !l.shuttingDown.Load()
11}

Signal 收到後：

1lifecycle.BeginShutdown()
2cancel()

這讓負載平衡器或監控能知道服務不應再接新流量。Process 還活著，但 readiness 已經反映操作狀態。

【執行】背景工作要觀察 context

背景 worker 的核心 shutdown 條件是每個 loop 都能觀察停止訊號。Ticker、queue consumer、WebSocket hub 都應該有退出路徑。

 1func RunWorker(ctx context.Context) error {
 2    ticker := time.NewTicker(time.Minute)
 3    defer ticker.Stop()
 4
 5    for {
 6        select {
 7        case <-ctx.Done():
 8            return ctx.Err()
 9        case <-ticker.C:
10            if err := RunOnce(ctx); err != nil {
11                return err
12            }
13        }
14    }
15}

若 RunOnce 可能執行很久，也應接收 context。否則外層 loop 看到 cancel，內層 I/O 或計算仍可能卡住。

【策略】WebSocket cleanup 要回到 hub owner

WebSocket shutdown 的核心原則是讓 hub 或 connection manager 統一清理 client。不要讓 signal handler 直接遍歷各種 connection 並隨意 close。

 1func (h *Hub) Run(ctx context.Context) {
 2    for {
 3        select {
 4        case <-ctx.Done():
 5            h.closeAllClients()
 6            return
 7        case client := <-h.register:
 8            h.registerClient(client)
 9        case client := <-h.unregister:
10            h.unregisterClient(client)
11        }
12    }
13}

closeAllClients 應透過 hub 的既有 owner 邏輯關閉 send、移除訂閱、關閉 connection。這延續前面模組的 ownership 原則。

【測試】shutdown 測試要觀察明確條件

Shutdown 測試的核心是確認停止訊號能讓元件退出，而不是等待固定時間。

 1func TestWorkerStopsOnContextCancel(t *testing.T) {
 2    ctx, cancel := context.WithCancel(context.Background())
 3    done := make(chan struct{})
 4
 5    go func() {
 6        defer close(done)
 7        _ = RunWorker(ctx)
 8    }()
 9
10    cancel()
11
12    select {
13    case <-done:
14    case <-time.After(time.Second):
15        t.Fatalf("worker did not stop")
16    }
17}

HTTP server 測試可以啟動 server 後 cancel context，確認 RunHTTPServer 回傳。測試應使用隨機 port 或 httptest.Server，避免固定 port 造成衝突。

本章不處理

本章先處理服務內部的 shutdown 順序與 cleanup owner；平台 hook、timeout 與 load balancer 合約，會在下列章節再往外延伸：

• Go 進階：Kubernetes、systemd 與 load balancer 合約

和 Go 教材的關係

這一章承接的是 goroutine lifecycle、ticker cleanup 與 platform handoff；如果你要先回看語言教材，可以讀：

• Go：goroutine：輕量並發工作
• Go：defer 與資源清理
• Go：select：同時等待多種事件
• Go：goroutine leak 偵測
• Backend：部署平台與網路入口

小結

Graceful shutdown 是多階段流程：signal 轉成 root context，readiness 先關閉，HTTP server 停止接新 request，worker 和 WebSocket hub 觀察 context 收尾，整體流程受 timeout 保護。停止訊號越集中，元件 ownership 越清楚，服務在部署、測試與本機開發時越不容易留下殘存 goroutine 或未釋放連線。

本章目標

學完本章後，你將能夠：

1. 分辨 health、readiness、diagnostics 的語意
2. 設計快速穩定的 /health
3. 用 /ready 控制是否接新流量
4. 條件啟用 pprof、runtime stats 等診斷入口
5. 測試 status code 與 JSON response 合約

【觀察】所有狀態都塞進 health 會讓監控失真

Health endpoint 的核心風險是語意混亂。若 /health 同時檢查 process、database、queue、外部 API、cache、背景同步，任何依賴短暫波動都可能讓服務被判定死亡。

問題範例：

1/health
2  ├── process alive?
3  ├── database reachable?
4  ├── queue lag small?
5  ├── external API reachable?
6  └── background sync fresh?

這些問題不應全部塞進同一個 endpoint。Process 活著、可接流量、依賴降級、工程診斷，是不同操作訊號。

【判讀】health、ready、diagnostics 回答不同問題

操作 endpoint 的核心設計是每個 endpoint 只回答一個問題。

這樣切分後，某個外部依賴故障不一定要讓 process 被重啟；服務可能只是不 ready，或處於 degraded 狀態。

【執行】health endpoint 應簡單快速

Health endpoint 的核心責任是快速回答 process 是否能處理基本 HTTP request。它應該簡單、快速、穩定。

 1func HandleHealth(w http.ResponseWriter, r *http.Request) {
 2    if r.Method != http.MethodGet {
 3        http.Error(w, "method not allowed", http.StatusMethodNotAllowed)
 4        return
 5    }
 6
 7    w.Header().Set("Content-Type", "application/json")
 8    w.WriteHeader(http.StatusOK)
 9    _, _ = w.Write([]byte(`{"status":"ok"}`))
10}

/health 不應執行昂貴查詢，也不應依賴大量下游服務。若健康檢查本身很慢，監控會把診斷工具變成新問題。

【執行】readiness 控制是否接流量

Readiness 的核心責任是回答「服務現在是否應該接新流量」。它可以檢查啟動狀態、必要依賴、shutdown 狀態。

 1type Readiness struct {
 2    ready        atomic.Bool
 3    shuttingDown atomic.Bool
 4}
 5
 6func (r *Readiness) Ready() bool {
 7    return r.ready.Load() && !r.shuttingDown.Load()
 8}
 9
10func HandleReady(readiness *Readiness) http.HandlerFunc {
11    return func(w http.ResponseWriter, r *http.Request) {
12        w.Header().Set("Content-Type", "application/json")
13
14        if !readiness.Ready() {
15            w.WriteHeader(http.StatusServiceUnavailable)
16            _, _ = w.Write([]byte(`{"status":"not_ready"}`))
17            return
18        }
19
20        w.WriteHeader(http.StatusOK)
21        _, _ = w.Write([]byte(`{"status":"ready"}`))
22    }
23}

服務啟動尚未完成、必要背景同步尚未就緒、或 graceful shutdown 已開始時，readiness 應回 503。Process 仍然活著，但不應接新流量。

【策略】dependency check 依照監控語意分層

依賴檢查的核心判斷是故障是否代表 process 應重啟。Database 暫時不可用不一定代表 process 壞掉；重啟可能無法修復，反而造成更多負載。

建議分層：

• /health：只確認 process alive。
• /ready：確認必要依賴是否足以接新流量。
• /diagnostics/dependencies：提供工程師查看細節。

診斷 response 可以包含穩定欄位：

1{
2  "status": "degraded",
3  "dependencies": {
4    "database": "ok",
5    "queue": "lagging"
6  }
7}

監控應依賴 status code 與穩定欄位，工程師再用 body 細節診斷問題。自由文字可以輔助閱讀，但不應成為監控規則的依據。

【執行】diagnostics endpoint 要條件啟用

Diagnostics endpoint 的核心用途是提供工程師排查問題的資料。pprof、runtime metrics、internal queue length、goroutine count 都屬於這類。

 1func RegisterDiagnostics(mux *http.ServeMux, enabled bool) {
 2    if !enabled {
 3        return
 4    }
 5
 6    mux.HandleFunc("/debug/runtime", HandleRuntimeStats)
 7}
 8
 9func HandleRuntimeStats(w http.ResponseWriter, r *http.Request) {
10    var stats runtime.MemStats
11    runtime.ReadMemStats(&stats)
12
13    response := map[string]any{
14        "heap_alloc":  stats.HeapAlloc,
15        "num_gc":      stats.NumGC,
16        "goroutines":  runtime.NumGoroutine(),
17    }
18
19    _ = json.NewEncoder(w).Encode(response)
20}

Diagnostics 可能揭露內部狀態、記憶體資訊、goroutine 數量、路徑與部署細節，不應公開給一般使用者。若需要長期保留，至少應限制在內網、管理 port、認證或防火牆後。

【判讀】status code 是監控合約

健康檢查的核心合約是 status code。監控系統通常先看 HTTP code 與 timeout，不會理解複雜 body。

Body 可以提供人類可讀資訊，但不應讓監控依賴自由文字。若要機器讀取，使用穩定 JSON 欄位，例如 status、reason、dependencies。

【測試】endpoint 測試要鎖定 status code

Endpoint 測試的核心是驗證 status code 與穩定 JSON 欄位，而不是完整自由文字。

 1func TestReadyReturnsUnavailableWhenShuttingDown(t *testing.T) {
 2    readiness := &Readiness{}
 3    readiness.ready.Store(true)
 4    readiness.shuttingDown.Store(true)
 5
 6    req := httptest.NewRequest(http.MethodGet, "/ready", nil)
 7    rec := httptest.NewRecorder()
 8
 9    HandleReady(readiness).ServeHTTP(rec, req)
10
11    if rec.Code != http.StatusServiceUnavailable {
12        t.Fatalf("status = %d, want %d", rec.Code, http.StatusServiceUnavailable)
13    }
14}

Diagnostics endpoint 也應測 gate 關閉時不註冊或回 404，避免診斷入口不小心暴露。

本章不處理

本章先處理 health、readiness 與 diagnostics 的語意切分；Prometheus、OpenTelemetry 與平台設定，會在下列章節再往外延伸：

• Go 進階：Observability pipeline、metrics 與 tracing

和 Go 教材的關係

這一章承接的是 pprof、runtime metrics 與 deploy readiness；如果你要先回看語言教材，可以讀：

• Go：pprof 基礎診斷流程
• Go：GC 與 memory limit
• Go：結構化日誌
• Go：graceful shutdown 與 signal handling
• Go 進階：Kubernetes、systemd 與 load balancer 合約
• Backend：可觀測性平台
• Backend：部署平台與網路入口

小結

/health、/ready、diagnostics endpoint 解決不同問題。Health 檢查 process 基本可用性，readiness 控制是否接新流量，diagnostics 支援工程排查且應限制存取。Status code 是監控合約，JSON body 是補充細節；把這些訊號混在一起會讓操作判斷與安全邊界都變模糊。

本章目標

學完本章後，你將能夠：

1. 設計穩定 log schema
2. 用 layer、request_id、event_type、reason 支援查詢
3. 區分 message 與 structured fields 的責任
4. 避免重複記錄同一個錯誤
5. 避免把敏感資料寫進 log

【觀察】自由文字 log 很難查詢

Log 設計的核心問題是事故發生時需要快速查詢。若所有資訊都在 message 裡，查詢只能依賴模糊字串。

不穩定 log：

1logger.Info("event accepted for user 123 request abc")

這行給人看可以，但系統很難穩定查 request_id=abc 或 user_id=123。不同工程師改字句後，查詢就可能失效。

結構化 log：

1logger.Info("event accepted",
2    "layer", "http",
3    "request_id", requestID,
4    "user_id", userID,
5    "event_type", event.Type,
6)

Message 描述發生什麼事，欄位提供可查詢資料。這是 log schema 的基本分工。

【判讀】log schema 是查詢合約

Log schema 的核心規則是欄位名稱與值集合要穩定。request_id、requestID、rid 混用會讓查詢與儀表板變得困難。

常用欄位：

欄位不需要很多，但要一致。穩定欄位能讓除錯從「讀一堆文字」變成「查一組條件」。

【執行】layer 表示發生位置

layer 的核心用途是標示 log 來自哪個系統層，協助工程師快速縮小問題範圍。

1logger.Warn("queue full",
2    "layer", "worker",
3    "queue", "events",
4    "reason", "buffer_full",
5)

常見 layer：

• http
• websocket
• worker
• repository
• runtime
• diagnostics

名稱不需要多，但應穩定。若 worker、background、job_runner 混用，查詢就會變麻煩。

【策略】correlation ID 串起一次流程

Correlation ID 的核心目標是把同一次請求或同一個事件流串起來。HTTP request 常用 request_id，背景事件可以用 event_id 或 trace_id。

1func WithRequestLog(r *http.Request, logger *slog.Logger) *slog.Logger {
2    requestID := r.Header.Get("X-Request-ID")
3    if requestID == "" {
4        requestID = uuid.NewString()
5    }
6
7    return logger.With("request_id", requestID)
8}

後續 handler、service、repository 都使用帶有 request_id 的 logger。查詢單次流程時，不需要靠時間範圍猜哪些 log 相關。

Correlation ID 不應包含敏感資料。它是追蹤用識別碼，不是使用者資料容器。

【執行】reason 欄位讓失敗可統計

reason 的核心用途是把錯誤原因變成可聚合分類。Message 可以給人讀，reason 給查詢與統計使用。

1logger.Warn("reject event",
2    "layer", "http",
3    "reason", "invalid_payload",
4    "event_type", event.Type,
5)

穩定 reason 可以回答「最近一小時最多的拒絕原因是什麼」。如果原因只寫在 message 中，查詢會依賴模糊字串比對。

Reason 值應像 enum 一樣維持小集合，例如：

• invalid_payload
• queue_full
• permission_denied
• timeout
• client_disconnected
• dependency_unavailable

reason 應維持小集合分類，完整錯誤應放在 error 欄位。這樣監控可以穩定聚合原因，工程師仍能從錯誤欄位取得診斷細節。

【判讀】錯誤只在負責處理的邊界記一次

錯誤日誌的核心風險是同一個錯誤被每一層都記一次。這會放大噪音，讓事故時很難看出真正的失敗點。

反模式：

1logger.Error("repository failed", "error", err)
2return fmt.Errorf("save notification: %w", err)

上層又記一次：

1logger.Error("request failed", "error", err)

較清楚的做法是底層 wrap error，上層在決定 response 或重試策略的邊界記錄一次：

1if err := service.Create(ctx, cmd); err != nil {
2    logger.Warn("create notification failed",
3        "layer", "http",
4        "reason", reasonOf(err),
5        "error", err,
6    )
7    writeError(w, err)
8    return
9}

底層若有必要補充脈絡，優先透過 error wrapping 或 structured error，而不是每層都 Error log。

【策略】敏感資料不進 log

Log 欄位設計的核心安全邊界是只記錄診斷必要資料。token、密碼、完整 cookie、完整個資與機密 payload 都屬於應排除資料；結構化 log 很容易被集中保存與搜尋，敏感資料一旦進入 log，清理成本很高。

可以記錄：

1logger.Info("user login",
2    "user_id", user.ID,
3)

應排除：

1logger.Info("user login",
2    "password", password,
3    "token", token,
4)

若需要診斷 payload，可記錄長度、hash、欄位是否存在，而不是完整內容。

1logger.Debug("payload received",
2    "payload_bytes", len(body),
3    "payload_sha256", checksum(body),
4)

所有會被收集或保存的 log 都應遵守同一套資料保護規則。Debug log 也會進入檔案、集中式 log 或診斷封包，因此不能把它當成敏感資料的例外通道。

【測試】log 欄位可以用 handler 驗證

Log schema 的測試核心是確認重要欄位存在，避免未來重構時消失。

 1func TestLogAttrsForEvent(t *testing.T) {
 2    event := DomainEvent{
 3        ID:        "evt_1",
 4        Type:      "notification.created",
 5        SubjectID: "notification_1",
 6    }
 7
 8    attrs := LogAttrsForEvent(event)
 9
10    if !hasAttr(attrs, "event_id", "evt_1") {
11        t.Fatalf("event_id attr missing")
12    }
13    if !hasAttr(attrs, "event_type", "notification.created") {
14        t.Fatalf("event_type attr missing")
15    }
16}

不需要測整行 log 字串。測穩定欄位即可，message 文字可以保留一定調整空間。

本章不處理

本章先處理 Go 服務內部的 structured log schema；集中式平台、欄位標準與隱私治理，會在下列章節再往外延伸：

• Go 進階：Observability pipeline、metrics 與 tracing

和 Go 教材的關係

這一章承接的是 structured recording、event log 與 observability pipeline；如果你要先回看語言教材，可以讀：

• Go：如何新增結構化記錄欄位
• Go：結構化日誌
• Go：如何新增一種 domain event
• Go：Observability pipeline、metrics 與 tracing
• Backend：可觀測性平台
• Go 入門：log/slog
• Go 入門：如何新增結構化記錄欄位

小結

結構化日誌的價值在於穩定欄位：layer 定位層級，request_id 串起請求，event_id 串起事件，event_type 支援聚合，reason 支援失敗分類。Message 給人讀，欄位給系統查。好的 log schema 能讓除錯從猜測變成查詢，同時避免敏感資料外洩與錯誤重複記錄。

本章目標

學完本章後，你將能夠：

1. 用 config struct 集中載入 feature gate
2. 把外部版本偵測轉成 capability
3. 為 gate 關閉時定義降級、回錯或延後處理策略
4. 避免在程式各處直接讀環境變數
5. 同時測試 feature 開與關兩條路徑

【觀察】新功能上線需要可控行為

Feature gate 的核心需求來自生產環境差異。新功能可能只在部分部署環境可用，外部依賴可能版本不同，某些診斷入口只應在內網啟用，某些即時能力需要先灰度。

沒有 gate 時常見問題：

• 新功能只能一次性全開或全關。
• 部署環境不支援時服務直接失敗。
• 測試只能覆蓋預設路徑。
• 問題發生時無法快速降級。
• 程式各處用環境變數判斷，行為難以推理。

Feature gate 的目的是讓行為決策集中、可測、可回滾。

【判讀】feature gate 是行為合約

Feature gate 的核心語意是控制某段行為是否啟用，以及未啟用時系統要做什麼。它不只是 if，而是一個操作合約。

1type Features struct {
2    RealtimePush bool
3    Diagnostics  bool
4    Pprof        bool
5}

開關名稱應描述功能，而不是描述臨時任務。RealtimePush 比 NewCode 更能長期維護；Diagnostics 比 DebugStuff 更清楚。

Gate 應在應用啟動時集中載入，再傳給需要的元件。不要在程式各處反覆直接讀環境變數，否則測試與推理都會變困難。

【執行】集中載入 feature config

Feature config 的核心責任是把環境變數、設定檔或啟動參數轉成明確資料。

1func LoadFeaturesFromEnv() Features {
2    return Features{
3        RealtimePush: os.Getenv("FEATURE_REALTIME_PUSH") == "1",
4        Diagnostics:  os.Getenv("APP_DIAGNOSTICS") == "1",
5        Pprof:        os.Getenv("APP_PPROF") == "1",
6    }
7}

組裝時傳入元件：

 1func main() {
 2    features := LoadFeaturesFromEnv()
 3
 4    mux := http.NewServeMux()
 5    RegisterDiagnostics(mux, features.Diagnostics)
 6
 7    publisher := NewPublisher(PublisherConfig{
 8        RealtimeEnabled: features.RealtimePush,
 9    })
10
11    _ = publisher
12}

這樣功能測試可以直接建構 Features，不必依賴全域環境變數。環境變數解析只需要在 LoadFeaturesFromEnv 的測試中覆蓋。

【判讀】版本偵測要轉成能力

版本偵測的核心原則是不要讓整個程式到處比較版本字串。應把外部版本轉成 capability，內部只判斷能力。

 1type Capabilities struct {
 2    SupportsStreaming bool
 3    SupportsMetadata  bool
 4}
 5
 6func DetectCapabilities(version semver.Version) Capabilities {
 7    return Capabilities{
 8        SupportsStreaming: version.GTE(semver.MustParse("2.0.0")),
 9        SupportsMetadata:  version.GTE(semver.MustParse("2.1.0")),
10    }
11}

內部程式應寫成：

1if caps.SupportsStreaming {
2    return useStreaming(ctx)
3}
4
5return usePolling(ctx)

這比到處寫 if version >= ... 更清楚，也更容易測試。版本字串是外部事實，capability 是內部行為判斷。

【策略】gate 關閉時要有降級策略

Feature gate 的核心問題是關閉時要做什麼。常見策略包括降級、回錯、隱藏入口、排程稍後處理。

例如即時推送關閉時，可以改成保存待處理資料：

1func (p Publisher) Publish(ctx context.Context, event DomainEvent) error {
2    if p.realtimeEnabled {
3        return p.realtime.Publish(ctx, event)
4    }
5
6    return p.repository.SaveForLater(ctx, event)
7}

降級策略要符合資料語意。不能即時送出不代表可以直接丟掉重要事件。

【執行】HTTP endpoint 可用 gate 控制註冊或行為

HTTP feature gate 的核心選擇是「不註冊 endpoint」或「註冊但回明確錯誤」。兩者語意不同。

不註冊 endpoint：

1if features.Diagnostics {
2    RegisterDiagnostics(mux, true)
3}

適合診斷入口、內部工具或不希望使用者看見的功能。

註冊但回錯：

 1func HandleRealtimeExport(features Features) http.HandlerFunc {
 2    return func(w http.ResponseWriter, r *http.Request) {
 3        if !features.RealtimePush {
 4            http.Error(w, "realtime export is disabled", http.StatusNotImplemented)
 5            return
 6        }
 7
 8        startRealtimeExport(w, r)
 9    }
10}

適合公開 API，讓呼叫端知道功能存在但目前不可用。

【策略】gate 不應散落成巢狀 if

Feature gate 的核心維護風險是判斷散落在多層呼叫中，最後沒人知道功能到底何時啟用。

反模式：

1if os.Getenv("FEATURE_REALTIME_PUSH") == "1" {
2    if version >= "2.0.0" {
3        if user.Enabled {
4            // ...
5        }
6    }
7}

較清楚的做法是先組出 decision：

 1type RealtimeDecision struct {
 2    Enabled bool
 3    Reason  string
 4}
 5
 6func DecideRealtime(features Features, caps Capabilities) RealtimeDecision {
 7    if !features.RealtimePush {
 8        return RealtimeDecision{Enabled: false, Reason: "feature_disabled"}
 9    }
10    if !caps.SupportsStreaming {
11        return RealtimeDecision{Enabled: false, Reason: "streaming_not_supported"}
12    }
13    return RealtimeDecision{Enabled: true}
14}

Decision 物件讓 log、測試與錯誤回應都能使用相同 reason。

【執行】log 要記錄 gate decision

Feature gate 的核心操作需求是知道功能為何啟用或關閉。當 gate 影響行為時，應記錄穩定 reason。

1decision := DecideRealtime(features, caps)
2logger.Info("realtime decision",
3    "feature", "realtime_push",
4    "enabled", decision.Enabled,
5    "reason", decision.Reason,
6)

這能回答「功能為什麼沒有走即時推送」這類問題。Reason 應是小集合，不要塞完整錯誤字串。

【測試】開與關兩條路徑都要測

Feature gate 測試的核心規則是同時測啟用與停用路徑。只測預設值很容易讓另一條路徑壞掉。

停用路徑：

 1func TestHandleRealtimeExportFeatureDisabled(t *testing.T) {
 2    req := httptest.NewRequest(http.MethodPost, "/export", nil)
 3    rec := httptest.NewRecorder()
 4
 5    handler := HandleRealtimeExport(Features{RealtimePush: false})
 6    handler.ServeHTTP(rec, req)
 7
 8    if rec.Code != http.StatusNotImplemented {
 9        t.Fatalf("status = %d, want %d", rec.Code, http.StatusNotImplemented)
10    }
11}

啟用路徑：

 1func TestDecideRealtimeEnabled(t *testing.T) {
 2    decision := DecideRealtime(
 3        Features{RealtimePush: true},
 4        Capabilities{SupportsStreaming: true},
 5    )
 6
 7    if !decision.Enabled {
 8        t.Fatalf("realtime should be enabled, reason %q", decision.Reason)
 9    }
10}

環境變數解析應單獨測 LoadFeaturesFromEnv。功能測試應直接傳入 Features，不要依賴全域環境狀態。

本章不處理

本章先處理服務內部的 gate 行為邊界；遠端 feature flag 平台與灰度流程，會在下列章節再往外延伸：

• Backend：部署平台與網路入口

和 Go 教材的關係

這一章承接的是 composition root、handler boundary 與 runtime gate；如果你要先回看語言教材，可以讀：

• Go：composition root 與依賴組裝
• Go：把 handler 邏輯拆成可測單元
• Go：用 interface 隔離外部依賴
• Go：testing 基礎
• Go 進階：Kubernetes、systemd 與 load balancer 合約

小結

Feature gate 是生產操作工具，也是程式設計邊界。好的 gate 會集中載入、轉成 capability、定義降級策略、輸出穩定 reason，並同時測試開與關兩條路徑。它控制的是行為合約，不只是把新程式碼藏在 if 後面。

本章目標

學完本章後，你將能夠：

1. 分辨 log、metric、trace 與 profile 各自回答什麼問題
2. 設計穩定的 correlation 欄位
3. 讓 Go 服務輸出適合聚合的診斷訊號
4. 在產生端控制敏感資料進入觀測管線
5. 了解 dashboard 與 alert 為什麼需要依賴穩定欄位

前置章節

• Go 入門：log/slog：結構化日誌
• Go 進階：pprof 基礎診斷流程
• Go 進階：結構化日誌欄位設計
• Go 進階：健康檢查與診斷 endpoint
• Backend：SLI / SLO
• Backend：Metric Cardinality
• Backend：Alert Runbook

後續撰寫方向

1. Log、metric、trace、profile 分別回答哪些問題。
2. request_id、event_id、trace_id、span_id 與 correlation_id 如何分工。
3. OpenTelemetry 導入時，Go 程式碼應保留哪些清楚邊界。
4. Sensitive data policy 如何套用到 log、trace attribute 與 error event。
5. Dashboard 與 alert 應依賴穩定欄位，讓查詢與告警規則可以被重複執行。

【觀察】診斷資料要先可關聯，再談漂亮

Observability pipeline 的第一個要求是關聯能力。Log、metric、trace 的格式可以各自精緻，但欄位需要對齊，才能把同一筆請求、同一個事件、同一條 goroutine 路徑串起來。

通常會先建立幾個穩定欄位：

• request_id
• event_id
• trace_id
• span_id
• user_id 或 tenant_id

【判讀】不同訊號回答不同問題

• log：這次發生了什麼。
• metric：這類事件發生得多不多、快不快、慢不慢。
• trace：它在多個元件之間怎麼走。
• profile：CPU、記憶體、goroutine 與等待成本落在哪裡。

如果某個問題要靠自由文字 log 去猜，通常代表欄位設計還不夠穩。

【策略】敏感資料要在產生端就攔住

敏感資料政策應在產生端執行。Go 服務應該在輸出 log 或 trace attribute 前就決定哪些資訊可以外送。

常見要注意的資料有：

• token
• email
• 身分證號
• raw payload
• 內部路徑與配置

【執行】結構化 log 是 pipeline 的起點

當 Go 服務使用結構化 log 時，最重要的是欄位穩定與語意清楚。這些 log 後面可能會被：

• 集中式 log system 搜尋
• metric extraction 轉成趨勢指標
• alert rule 用來偵測異常

所以 log 欄位要維持穩定命名，分類資訊要放在結構化欄位裡。

【延伸】診斷和容量規劃要串在一起

觀測資料不只是事後排障，也會反過來影響容量規劃與 release 判斷。當你看到 goroutine 數、queue lag、DB latency 或 retry rate 持續變高，就代表系統邊界已經開始吃緊。

本章不處理

本章不會綁定特定 observability SaaS。教材重點會放在 Go 服務如何輸出穩定訊號，讓不同收集平台都能使用。

和 Go 教材的關係

這一章承接的是 Go 的結構化日誌與 runtime 診斷；如果你要先回看語言教材，可以讀：

• Go：結構化日誌
• Go 進階：pprof 基礎診斷流程
• Go 進階：結構化日誌欄位設計
• Go 進階：健康檢查與診斷 endpoint

本章目標

學完本章後，你將能夠：

1. 理解 shutdown、readiness 與 connection draining 的順序
2. 看懂平台 timeout 對 Go server 的影響
3. 分辨 health 與 readiness 的不同責任
4. 把 memory limit 與 Go runtime 的資源管理接在一起
5. 讓部署平台和程式彼此遵守同一份合約

前置章節

• Go 進階：GC 與 memory limit
• Go 進階：graceful shutdown 與 signal handling
• Go 進階：健康檢查與診斷 endpoint
• Backend：Graceful Shutdown
• Backend：Failover

後續撰寫方向

1. SIGTERM、shutdown timeout、readiness false 與 connection draining 的順序。
2. Kubernetes terminationGracePeriodSeconds 與 Go http.Server.Shutdown 如何配合。
3. Load balancer idle timeout 如何影響 WebSocket heartbeat 參數。
4. Container memory limit、Go memory limit 與 OOM killer 之間的關係。
5. systemd restart policy 與 health endpoint 的責任分工。

【觀察】平台會主動改變服務生命週期

Go 程式不會在真空裡執行。Kubernetes、systemd、load balancer、container runtime 都會影響服務何時接新請求、何時開始收尾、何時被強制終止。這表示程式不只要「能跑」，還要能跟平台協調。

常見的生命週期訊號有：

• SIGTERM
• readiness false
• HTTP shutdown
• connection draining
• memory pressure

【判讀】health 與 readiness 有不同合約

health 通常表示服務自己還活著，readiness 則表示它是否適合接新流量。

• health 可以用來讓平台知道 process 還活著。
• readiness 可以用來讓 load balancer 停止送新請求。

如果兩者混在一起，部署時就容易出現「服務還沒收尾就被塞新流量」或「其實還能接流量卻被誤判下線」的問題。

【策略】shutdown 應該是可預期流程

典型的 shutdown 順序是：

1. 接收到停止訊號。
2. 先把 readiness 關掉。
3. 停止接新流量。
4. 讓現有 request / worker / websocket 收尾。
5. 超時後強制結束。

這個順序能讓平台有時間把流量移走，也讓應用有時間清理資源。

【執行】資源限制要和 runtime 觀念一起看

container memory limit 不只是部署平台的事，也會影響 Go runtime 的行為。當可用記憶體變少時，應用更需要控制：

• goroutine 數量
• buffer 大小
• cache 體積
• in-memory queue 長度

如果這些沒有限制，平台的 OOM killer 可能會比你的 graceful shutdown 先來。

【延伸】平台合約要被測試

部署平台合約需要在測試或預備環境驗證。至少要確認：

• shutdown 時 request 是否停止接入
• worker 是否有機會收尾
• WebSocket 是否有 close path
• health 與 readiness 是否分工清楚

本章不處理

本章不會完整教 Kubernetes 或 systemd 操作。重點是讓 Go 程式設計能清楚暴露平台需要的生命週期訊號。

和 Go 教材的關係

這一章承接的是 Go 的 shutdown 與 runtime 限制；如果你要先回看語言教材，可以讀：

• Go 進階：GC 與 memory limit
• Go 進階：graceful shutdown 與 signal handling
• Go 進階：健康檢查與診斷 endpoint

讀完本章後、你應該能判讀自己當前處在三層哪一階、要跨到下一階時需要補哪些議題、對應到 backend/07 哪些卡片。

本章目標

1. 區分個人 dev、團隊共用、production 三層 LLM 部署的安全議題差異。
2. 知道從個人 dev 跨到團隊共用時、需要補哪些控制。
3. 知道從團隊共用跨到 production 時、需要補哪些控制。
4. 認識每層演化對應的 backend/07 卡片清單。
5. 知道何時該停留在當前層、何時該主動升級。

三層演化的判讀軸

1個人 dev（本模組前五章）
2   ↓
3團隊共用（家裡 / 小團隊 / 內部部署）
4   ↓
5production 服務（對外服務 / SaaS / B2B）

三層的核心差異：

關鍵原則：控制機制應該跟需求對齊、不該過度設計也不該不足。個人 dev 不需要 SOC 2 audit、production 不能只靠 git track。

個人 dev → 團隊共用：要補什麼

從個人 dev 跨到團隊共用、典型的觸發場景：

1. 家裡跑模型給家人 / 室友用
2. 小團隊共用一台 LLM server
3. 公司內部部署、有 5 ~ 50 個工程師用

需要補的控制（在前五章的基礎上）：

團隊共用階段的常見 anti-pattern：

1. 把個人 dev 的 dotfile config 直接複製到團隊 server：API key、log 路徑、reset 機制都不對。
2. 依賴單一管理員口頭傳遞政策：沒寫下來、新成員不知道、人離職就失傳。
3. 跳過 auth 直接用「公司內網本來就安全」當理由：內網設備有訪客、有實習生、有 BYOD、有合作廠商；零信任的最低版本仍要做。

團隊共用 → production：要補什麼

從團隊共用跨到 production 服務、典型的觸發場景：

1. 把內部 LLM 服務開放給外部客戶（B2B）
2. 做 SaaS-like LLM API 對外賣
3. 把 LLM 嵌入產品給終端用戶用

需要補的控制（在前面兩層的基礎上）：

production 階段不是「把團隊共用放大」、是「另一個複雜度等級」。多數議題從 backend/07 既有卡片開始讀、LLM-specific 議題在 backend/07 的 LLM 相關章節（llm-*.md）補充。

何時該停留在當前層

不是所有工作流都需要升級。停留在當前層的合理判讀：

升級的兩個常見錯誤：

1. 過早升級：個人 dev 階段就上 enterprise stack（IAM、Vault、SIEM）、複雜度過高、自己用不到、維護成本反而傷工作流。
2. 過晚升級：團隊共用階段該補的控制沒補、出事才補、可能已經有資料外洩 / 法律責任。

判讀依據：控制機制對齊實際 threat model 跟 user 規模、不是「越多越好」。

跨層升級的常見 anti-pattern

從各層往上跨時、常見的意外：

1. 把個人 dev 的 LLM client config 直接放上 production：autocomplete model、default model、API key 都不對；production 場景需要重新設計 model 路由。
2. 把個人習慣的 prompt injection 防護當 production 防護：「我 git track 工作流」對個人 dev 夠、production agent 場景下、git 不在迴路裡、要改用 tool spec + review checkpoint。
3. production 場景仍然依賴使用者「看 prompt 內容」：使用者數量大、不可能每個 prompt 都人工看；production 需要自動化偵測訊號。
4. production 場景沒 tenant 隔離：所有用戶的 KV cache / log / context 混在一起、A 用戶能看到 B 用戶的 cache hit。
5. 沒有 vendor 政策的書面化承諾：team 階段口頭講「我們不訓練客戶資料」、production 階段要寫進條款 / SLA。

給讀者的層級判讀清單

判斷自己當前在哪一層：

1[ ] 只有自己用                                              → 個人 dev
2[ ] 1 ~ 5 個人共用一台 server                                → 個人 dev 或團隊共用初期
3[ ] 5 ~ 50 個人共用、內部部署                                → 團隊共用
4[ ] 對外提供 API 服務 / SaaS                                 → production
5[ ] 服務多個客戶 / 涉及客戶 PII                              → production
6[ ] 有 SLA / 合約承諾                                        → production

對應的「要補的議題」：

 1個人 dev → 團隊共用：
 2  [ ] auth                  ← backend/07 identity-access-boundary
 3  [ ] 入口治理               ← backend/07 entrypoint-and-server-protection
 4  [ ] TLS                    ← backend/07 transport-trust-and-certificate-lifecycle
 5  [ ] secret 集中管理        ← backend/07 secrets-and-machine-credential-governance
 6  [ ] 內部 supply chain      ← backend/07 supply-chain-integrity-and-artifact-trust
 7  [ ] 寫下 acceptable use 政策
 8
 9團隊共用 → production：
10  [ ] 多租戶 isolation       ← backend/07 llm-multi-tenant-isolation
11  [ ] deployment 供應鏈      ← backend/07 llm-deployment-supply-chain
12  [ ] agent prompt injection ← backend/07 llm-prompt-injection-in-agent
13  [ ] log / PII 治理         ← backend/07 llm-log-and-pii-governance
14  [ ] 偵測訊號               ← backend/07 llm-as-service-detection-coverage
15  [ ] workload identity      ← backend/07 workload-identity-and-federated-trust
16  [ ] 偵測平台               ← backend/07 detection-coverage-and-signal-governance
17  [ ] IR 流程                ← backend/07 incident-case-to-control-workflow
18  [ ] 合規                   ← backend/07 data-protection-and-masking-governance

下一步

本章是模組六的最後一章。下一步可以回到 模組六 _index 看其他章節、或進入 Backend 模組七 資安與資料保護 接 production 場景。

預計補充內容

這些 backpressure 邊界會在下列章節展開：

• Go 入門：channel：事件流與 backpressure ：先理解 channel buffer 和等待機制，才知道限流不是只有一種做法。
• Go 進階：非阻塞送出與事件丟棄策略：當系統必須在滿載時做出明確選擇，這裡會處理 drop、覆蓋與回錯的語意。
• Backend：部署平台與網路入口：跨節點流量治理、gateway 與 quota，屬於平台層責任。

本章不處理

本章先處理單一 process 內的輸入控制與 backpressure ；跨節點流量治理、gateway 與 quota 的平台責任，會放在 Backend：部署平台與網路入口。

與 Backend 教材的分工

本章只處理 Go process 內的速率控制。API gateway、load balancer、service mesh、broker quota 與跨節點流量治理會放在 Backend：部署平台與網路入口。

和 Go 教材的關係

這一章承接的是 channel backpressure 、non-blocking send 與 worker capacity；如果你要先回看語言教材，可以讀：

• Go：channel：資料傳遞與 backpressure
• Go：select：同時等待多種事件
• Go：非阻塞送出與事件丟棄策略
• Go：bounded worker pool

本模組承接前面的並發、WebSocket、runtime 與測試：graceful shutdown 需要 context 和 goroutine lifecycle，health endpoint 需要區分可用性與診斷，structured log 需要能追 event flow，feature gate 需要能安全控制新能力。

章節列表

本模組使用的範例主題

本模組使用虛構的即時通知服務作為範例。範例包含 HTTP server、WebSocket hub、background worker、runtime diagnostics、structured log 與 feature gate。

範例只用來展示 Go 生產操作設計，不假設讀者正在維護任何特定專案。

本模組的 Go 核心概念

• 用 signal.NotifyContext 或 signal channel 建立 root context。
• 用 http.Server.Shutdown 停止接受新 request。
• 用 context 傳遞停止訊號給 worker、hub、WebSocket pump。
• 用 /health、/ready、/debug/... 分開不同操作訊號。
• 用 log/slog 建立穩定 structured fields。
• 用 config struct 載入 feature gate，而不是到處讀環境變數。

學習重點

學完本模組後，你應該能判斷：

1. 服務收到停止訊號後，哪些元件要先停止接流量
2. health、readiness、diagnostics 各自回答什麼問題
3. structured log 欄位如何支援查詢與聚合
4. 哪些資料不應進入 log
5. feature gate 關閉時應降級、回錯、隱藏還是排程稍後處理

本模組不處理

本模組不討論 Kubernetes、systemd、雲端平台或完整 SRE 流程的所有細節。這些環境會影響操作策略，但本模組先建立 Go 服務本身應具備的操作邊界；後續可接 Kubernetes、systemd 與 load balancer 合約 以及 Observability pipeline、metrics 與 tracing。

學習時間

預計 3-4 小時

本章寫的是「從本地實驗 → production 該想清楚的維度」、focus 在跨工具世代不變的原理。具體 framework（vLLM、TGI、Triton、SGLang）跟雲端服務（OpenAI / Anthropic / Bedrock）的選型不展開——這些半年一個世代、寫了會過時。本章建立的是「無論用哪套工具、都該回答」的設計取捨清單。

跟 4.1 RAG / 4.3 Tool use / 4.4 Agent 對應「應用怎麼設計」、本章對應「應用怎麼跑」。

本章目標

讀完本章後你能：

1. 列出 production LLM 部署該評估的 6 個 dimension。
2. 解釋 single-user benchmark 為什麼不能直接 extrapolate 到 multi-user 場景。
3. 區分 latency-sensitive 跟 throughput-sensitive 應用的設計差別。
4. 對成本模型（$/request、$/token、$/month）做合理估算。

從本地到 production 的 phase transition

本地 LLM 跑 RAG / MCP 的 baseline（hands-on 章節）：

Production 場景每個維度都跳一個量級：

每個維度跳一個量級的 implication 不是「資源 × 10」、是「全新的失敗模式 + 新的設計取捨」。

維度 1：Concurrent users / Throughput

為什麼這個維度最關鍵

本地 single-user 的 baseline 數字（hands-on 紀錄的 RAM / latency）在 multi-user 場景下幾乎無法 extrapolate、根因是資源爭用會放大原本看不到的成本：

• 100 個 user 同時送 request → 不是「同樣 latency × 100」、是「queueing + memory contention + GPU 排隊」、單個 user 的 latency 可能漲 10×
• 同樣 model 服務 N 個 user → KV cache 占用要乘以 N、單卡 GPU 在容量限制下可能裝不下
• Single-user 「200 ms latency」可能 production 變「p99 5 秒」

Key concept：batching

Batching 跟 KV cache 設計讓 GPU 能多 user 的 request 一次 forward pass、是 production inference server 的核心優化。但 batching 也帶取捨：

• 靜態 batching：等湊滿 N 個 request 才跑、提高 throughput、犧牲首字延遲
• 連續 batching（continuous batching）：vLLM / TGI 等用、新 request 動態加入正在跑的 batch、平衡 throughput + latency
• No batching：每 request 獨立跑、latency 低、GPU 利用率差

選 batching 策略主要取決於 latency 跟 throughput 哪個重要：

評估 concurrent throughput

要做的測試（不在本章 hands-on、是 framework）：

1. Single-user baseline：measure single request 在 idle server 上的 latency
2. N-user load test：用 k6 / vegeta / 自寫 async client 跑 1、10、100 個並發 request
3. 觀察 p50 / p95 / p99 latency 隨並發數變化：通常 < N=batch_size 時平、超過 batch_size 後 latency 線性漲
4. GPU memory 飽和點：tokens-in-flight 超過某個量、新 request 開始排隊

實務評估公式：

1Max concurrent users (steady state)
2    = (GPU memory available - model weights) / (per-user KV cache size)

例：H100 80 GB - 31B model 60 GB = 20 GB 可用 / 每 user 平均 200 MB KV cache = 100 個並發 user。

公式的失效條件（用這幾個 signal 判讀公式何時不可信）：

• 變長 context：per-user KV cache 隨 context 長度線性增長、長 context 用戶（10K+ tokens）的 KV cache 是短 context 用戶的 5-10 倍、用平均值會嚴重低估。修法：依 P95 context 長度估、不用 average。
• Prefix cache 啟用：vLLM、TGI 等用 prefix sharing 大幅省 KV cache、實際容量比公式高 2-3 倍。修法：跑實測量 prefix cache hit rate。
• Speculative decoding：drafter 跟 target 的 KV cache 都要算進去、每 user 佔用會比 dense baseline 高 10-20%。修法：用 drafter+target 合計算。
• 不同 batching 策略：static batching 上限是「batch_size × 等待時間」、continuous batching 是「平均 in-flight tokens」、不同策略下公式的「per-user」定義不同。

但這是上限、實際還要考慮 latency target。

維度 2：Latency budget

Latency-sensitive vs throughput-sensitive

兩類應用的設計取捨完全不同：

混合應用（如 chat with RAG）有兩段：retrieval（throughput-friendly、可 batch）+ generation（latency-sensitive、要 stream）。兩段獨立優化。

Latency 預算分配

一個 RAG 應用的 p99 latency 是各段加總：

1Total p99 = client → API gateway → retrieval → LLM prefill → LLM decode → response stream
2         ≈ 50 ms      20 ms        50 ms        500 ms       1500 ms      100 ms
3         ≈ 2.2 seconds

如果 p99 budget 是 2 秒、要先確認最大消耗段是哪個：

• 通常 LLM generation 是最大、是優化重心
• Retrieval 在大 corpus 場景可能超過 100 ms、要 index 優化（HNSW、近似 nearest neighbor）
• API gateway 通常可忽略、超過 50 ms 就有 SRE 議題

各段監控分開、把監控拆到各段才找得到 root cause；只看 total latency 會錯失定位線索。

維度 3：Cost model

三種計費單位

雲端 API（OpenAI / Anthropic）幾乎都 $/token、給定 model 不同 price tier。自家跑（vLLM on Lambda Labs / RunPod）是 $/server-hour。

成本估算 worked example

假設應用：

• 1000 active users / day
• 每 user 平均 10 requests / day
• 每 request 平均 1000 input tokens + 500 output tokens
• 用 Claude Sonnet 4.6（假設 $3 input / $15 output per million tokens）

每日 cost：

1total_requests = 1000 × 10 = 10000 / day
2input_tokens = 10000 × 1000 = 10M
3output_tokens = 10000 × 500 = 5M
4daily_cost = 10M × $3/M + 5M × $15/M = $30 + $75 = $105 / day
5monthly_cost ≈ $3150

跑自家 GPU 比較：

1H100 instance: ~$2/hour（以 2026 年 spot price 為例、實際隨雲廠商與當期報價變動）
2H100 monthly = $2 × 24 × 30 = $1440
3若 utilization > 50% 且團隊有 SRE 能力維運、自架較划算
4若 utilization < 30%、或團隊無 GPU 維運經驗、API 較划算

Breakeven 點通常在「持續高 utilization + 團隊有維運能力」——尖峰流量短的應用、或團隊無 GPU 維運經驗、API 更划算（不用養閒置 capacity 跟 SRE 人力）。實際判讀還要加合規 / 資料主權 / vendor lock-in 等非價格因素。

Hidden cost

容易漏算的：

• Egress bandwidth：cloud GPU instance 出流量、AWS / GCP 都 $/GB
• Storage：vector DB / log retention / metric retention
• 失敗 retry：5xx error 自動 retry、token 重算
• Cold start：scale-to-zero 設定、cold start 浪費 5-30 秒 GPU time / 次

維度 4：Storage / Vector DB

本地 RAG demo 用 pickle、production 不行——pickle 不支援並發 read、不支援 update、不支援 partition、必須換 vector database。

Vector DB 的設計取捨

具體選型半年一變、本章不展開。設計時要回答的問題：

1. Corpus 多大？1M 以下 in-memory 就好、1M 以上要 disk-based
2. Update 頻率？每天一次 vs 即時、影響 architecture
3. Latency target？< 50 ms 要 in-memory / HNSW、< 200 ms 用 disk-based
4. 並發 query 量？每秒 100 query 跟每秒 10000 query 設計完全不同

Index 大小成長

從 hands-on 章節 extrapolate：

10M docs 以上、單機（256GB RAM、商用 SSD）放不進 in-memory index、要 sharding + 分散式 index。

維度 5：Observability

Single-user tail log 不夠 production 用。要看的 metric：

Latency metrics

• TTFT (Time to First Token)：user-perceived「響應時間」、streaming 場景關鍵
• TPS (Tokens per second)：generation 速度
• End-to-end latency：含 retrieval + LLM + post-processing
• Per-percentile breakdown：p50 / p90 / p95 / p99——p99 反映最差 user 體驗

Throughput metrics

• Requests per second：API 端 RPS
• Tokens per second（aggregate）：GPU 整體 throughput
• Queue depth：等待 batch 的 request 數量、暴漲表示 overload

Cost metrics

• $ per active user per day：產品經濟學基本盤
• Cost per session：互動式應用單位成本
• Cache hit rate：prompt cache / embedding cache 命中率、直接影響 cost

Quality metrics

• Refusal rate：模型 refuse 回應的比例
• Hallucination rate：（要 reviewer 標）
• User feedback score：thumb up / down

工具：metrics / traces / logs 三層

1Metrics（Prometheus / Datadog / CloudWatch）
2    → time-series、aggregate、適合 alerting
3Traces（OpenTelemetry / Datadog APM）
4    → per-request、可追蹤跨服務 latency
5Logs（structured JSON、推 ELK / Loki）
6    → 詳細 context、debug 用

三層各司其職、各層保留專屬職責：metric 看到 p99 漲、用 trace 找哪個 request 哪段慢、用 log 看那 request 的具體 prompt / response。

維度 6：Reliability / SLA

可預期的失敗模式

Graceful degradation

設計 production LLM 應用、要回答「失敗時降級到什麼」：

在 SLA 承諾下、每個 fallback 路徑都要事前設計、避免出事時臨時決策（早期 prototype / 內部工具可接受 reactive 處理、production 階段不行）。

Capacity planning

簡單公式：

1Required capacity = peak_concurrent_users × per_user_RAM
2                  × overhead_factor (1.3-1.5)
3                  × redundancy_factor (2x for HA)

例：peak 100 並發、每 user ~500 MB KV cache、overhead 1.3、HA 2x → 130 GB GPU memory。一張 H100 不夠、要兩張 A100 80GB 或 H100 + sharding。

跟本地 hands-on 的對照

本地數字是「能跑」的證明、production 數字是「能用」的驗證。本地驗證完 architecture 後、production deployment 該重做 load test、不能 assume 線性 scale。

跨 framework 不變的設計問題

不管你用 vLLM / TGI / Triton / SGLang / OpenAI API、production 設計都要回答：

1. Latency vs throughput：哪個是主要 metric？
2. Batch strategy：static / continuous / per-request？
3. Cost ceiling：$/day budget 多少？超過怎麼處理？
4. Storage：vector DB 規模？update 頻率？
5. Observability：哪些 metric 是 alert worthy？
6. Reliability：failure mode + graceful degradation 設計
7. Capacity：peak + redundancy 需要多少 GPU memory

這 7 個問題回答一致時、framework 選擇通常不是 production 失敗的根因——資源評估跟設計取捨已對齊、framework 多半是配套選項。

何時這篇會過時

不會過時的部分：

• 6 個維度（concurrency / latency / cost / storage / observability / reliability）
• Latency-sensitive vs throughput-sensitive 應用的設計差異
• 三類計費單位的取捨
• Metrics / traces / logs 三層觀測
• Graceful degradation 設計

會變的部分：

• 具體 inference framework（vLLM / TGI / SGLang 等）的 ranking
• 雲端 API price tier
• 哪些 vector DB 主流

新 framework 出來時、回到 6 維度 framework 問：它在哪個維度有突破？對既有設計問題的答案有沒有改變？通常會發現核心問題沒變、只是工具更熟。

跟其他章節的關係

• hands-on RAG/MCP 資源：本地 baseline 數字、本章的 production extrapolation 起點
• 4.1 RAG / 4.3 Tool use / 4.4 Agent：應用層設計、本章是「應用如何跑」的補完
• 0.5 硬體記憶體預算：本地單機 perspective、本章對應 multi-machine production
• 1.7 排錯方法論：本地 trouble-shooting、本章是 production observability 的對照

本章目標

讀完本章後、你應該能：

1. 解釋 LLM tracing 跟 traditional logging 的差異。
2. 用 OpenTelemetry GenAI semantic conventions 設計 span 結構。
3. 用 trace 做 cost / latency 監控跟 failure debug。
4. 把 production trace 餵回 LLM-as-judge 做品質迴路。
5. 對自己應用判斷該用 self-host vs SaaS observability platform。

Traditional logging 為什麼不夠

LLM 應用的 debug 問題對傳統 logging 太抽象：

LLM tracing 用「結構化 span + parent-child 關係 + 標準化 attribute」直接編碼這些訊息。

OpenTelemetry GenAI semantic conventions

OTel GenAI semconv 是 2024-2025 標準化中的 trace schema。核心概念：

 1Trace（一次 user query 從進來到 response）
 2  ├── Span: gen_ai.agent.invocation（agent loop iteration 1）
 3  │     ├── Span: gen_ai.client.operation（LLM call 1）
 4  │     │     attrs: model, temperature, input_tokens, output_tokens, cache_read
 5  │     ├── Span: gen_ai.tool.execution（tool: read_file）
 6  │     │     attrs: tool_name, input, output, duration
 7  │     └── Span: gen_ai.memory.read（retrieval）
 8  │           attrs: query, top_k, similarity_scores
 9  ├── Span: gen_ai.agent.invocation（iteration 2）
10  │     └── ...
11  └── Span: gen_ai.agent.terminate
12        attrs: reason, total_tokens, total_cost

主要 attribute 分類：

實作概要（Python 例）：

 1from opentelemetry import trace
 2from openinference.semconv.trace import SpanAttributes
 3
 4tracer = trace.get_tracer(__name__)
 5
 6with tracer.start_as_current_span("gen_ai.client.operation") as span:
 7    span.set_attribute(SpanAttributes.LLM_MODEL_NAME, "claude-sonnet-4-6")
 8    span.set_attribute(SpanAttributes.LLM_TEMPERATURE, 0.7)
 9
10    response = llm_client.chat(messages=...)
11
12    span.set_attribute(SpanAttributes.LLM_TOKEN_COUNT_PROMPT, response.usage.input_tokens)
13    span.set_attribute(SpanAttributes.LLM_TOKEN_COUNT_COMPLETION, response.usage.output_tokens)
14    span.set_attribute("gen_ai.usage.cached_tokens", response.usage.cache_read_tokens or 0)

實務上多用 framework auto-instrumentation（LangChain / LlamaIndex / Anthropic SDK 都有 OTel integration）、不必手寫 span。

Use case 1：Cost monitoring

Trace 是 LLM 應用 cost 監控的核心 — token usage attribute 內建、不必另外算。

實作模式：

11. Trace 端記錄 input_tokens / output_tokens / cached_tokens
22. Observability 平台用「per-model pricing table」算出 USD
33. Aggregate by：
4   - User（哪個 user 燒最多）
5   - Endpoint（哪條 API path 最貴）
6   - Feature（哪個 feature 最費 token）
7   - Time（哪天 spike）

典型 dashboard 指標：

Use case 2：Latency / failure debug

Trace 自然編碼 latency tree、能定位「哪個 span 卡」：

1User query → response total: 5.2s
2├── Agent iteration 1: 4.8s
3│   ├── LLM call (claude): 4.2s     ← 主要時間在這
4│   │   - prefill: 3.8s             ← prefill 太久、看 prompt 是否需要 cache
5│   │   - generation: 0.4s
6│   ├── tool: read_file: 0.5s
7│   └── memory: retrieval: 0.1s
8└── Agent iteration 2: 0.4s

從這 trace 看出「90% 時間在 prefill、開 prompt cache 可以救」、不必猜。

Failure debug：

1User query → response: ERROR
2├── Agent iteration 1: success
3│   └── LLM call: tool_call(run_bash, cmd="rm -rf /")
4├── Agent iteration 2: failure
5│   └── tool: run_bash: REJECTED by permission system
6└── Agent fallback: error response
7
8從 trace 看：tool call 被 permission 擋下、不是 LLM 自己亂、而是 user query 觸發危險 tool call、permission 正確擋下。

對應 6.2 tool use 權限模型 跟 hands-on permission-boundary 的判讀。

Use case 3：Production trace → eval loop

Production trace 是 LLM-as-judge 的最佳資料來源：

 1Production users
 2   ↓ 產生 trace
 3Trace storage（LangSmith / Phoenix / Langfuse）
 4   ↓ filter（e.g. user thumbs-down 的 trace）
 5   ↓ sample N 個
 6LLM-as-judge eval
 7   ↓ rubric scoring
 8找出系統性問題（哪類 query 品質差）
 9   ↓
10改 system prompt / tool / agent loop
11   ↓
12A/B test on production traces

這是 4.14 benchmarking 提的「in-house benchmark」的具體 implementation — production trace 是最真實的 benchmark dataset。

主流平台選型

判讀：

1. 個人 / 小流量：SaaS 免費 tier（LangSmith / Langfuse / Phoenix）夠用
2. 隱私敏感（user data 不能離本機）：Self-host（Langfuse / Phoenix self-hosted、或 OTel + Jaeger）
3. 已有 observability stack：用 OTel + 現有 Datadog / Grafana、別再加一層
4. 重 eval：Braintrust / Langfuse 的 eval feature 強

跟 4.9 production resource 的關係

4.5 寫 production resource 的 6 個 dimension（concurrency / latency / cost / storage / observability / reliability）、其中 observability 是 4.5 點到、本章展開。讀者讀完 4.5 知道「需要 observability」、本章補「具體怎麼做」。

設計失敗模式

1. 過度 instrument：每個 internal function 都加 span、trace overhead 大、實際 production noise 多

緩解：聚焦 LLM-related 跟跨 service 邊界、internal logic 不必 trace

2. PII / sensitive data 寫進 span attribute：user prompt、API key、會被 SaaS 平台看到

緩解：Span attribute 過 PII filter、敏感資料 hash / masking、跟 6.4 跨雲端邊界 結合

3. 不 sample：production 100% trace、storage / cost 爆

緩解：Production sample rate < 10%、error / outlier 100% capture

4. 沒設 trace 保留期：trace 越累積越多、舊 trace 沒人看但仍付儲存

緩解：明確保留 policy（如 7-30 天 hot、之後 archive 或刪）

5. Trace 不跟 metric 串：trace 是 sample、metric 是 aggregate、debug 要兩個一起看

緩解：cost / latency 也輸出 metric（Prometheus 等）、trace 補 specific instance debug

何時不需要 tracing

1. 純 demo / 個人玩：log 字串夠用
2. 單一 LLM call、無 agent loop：簡單到 grep log 也能 debug
3. 隱私極敏感且不 self-host：trace 內容流向 SaaS 是邊界、評估 risk
4. 每 request 都 trace 的 overhead > 收益：超低 latency 場景看是否 worth it

何時過時 / 何時不過時

不會過時的部分：

• LLM tracing 跟 traditional logging 的根本差異
• 結構化 span + parent-child 關係的 framing
• Cost monitoring / latency debug / failure debug 三大 use case
• Trace → eval 的閉環概念
• 5 個設計失敗模式

會變的部分：

• OTel GenAI semconv 的具體 attribute 名稱（仍在 stabilizing）
• 主流 SaaS 平台（每年 1-2 個新進入者）
• Auto-instrumentation 的支援度（持續擴展）
• 跟具體 framework 的整合方式

下一章

下一章：4.21 LLM-as-judge 評估方法、把 production trace 變成系統性 eval 的閉環。

Judge 在 eval 系統中的定位：4.13 Eval 設計座標系 把 eval 分三軸八象限、判斷哪個象限該用什麼工具——judge 的位置是 subjective 軸（沒 ground truth 的行為）、不是 objective 軸（有 ground truth 用 deterministic check 更便宜更準）。讀本章前先看 4.13 的軸誤選段、避開「全部 eval 都做成 judge」的常見反模式。

本章目標

讀完本章後、你應該能：

1. 區分 LLM-as-Judge、standard benchmark、human eval 三條 eval 路徑。
2. 設計可重現的 judge rubric（input / output / rubric / reasoning 四段）。
3. 用 pairwise vs direct scoring、知道何時用哪種。
4. 緩解三大 bias（position / verbosity / self-preference）。
5. 把 production trace 餵回 judge、形成自動 eval 閉環。

為什麼需要 LLM-as-Judge

4.14 推「in-house benchmark 是 final test」、但操作層是個 gap：

主要 use case（重複 LLM-as-Judge 卡片）：in-house benchmark、production trace eval、A/B test、synthetic data quality。

Judge prompt 結構

可重現的 judge 必須四段式：

 1[Section 1: Task description]
 2你是 LLM 輸出品質評估員。要評估 coding assistant 對使用者請求的回答品質。
 3
 4[Section 2: Input + Output to evaluate]
 5User request: {input}
 6Assistant response: {output}
 7
 8[Section 3: Rubric（評分標準）]
 9評分維度：
101. Correctness（程式碼能否運作、邏輯是否正確）：1-5
112. Style（是否符合 codebase convention）：1-5
123. Completeness（是否完整解決 user request）：1-5
13
14評分規則：
15- 5：完美無瑕、可直接 merge
16- 4：小修可用、整體正確
17- 3：方向正確、需 substantial 修改
18- 2：部分對、主要邏輯有錯
19- 1：完全錯、誤導使用者
20
21明確不加分：
22- 冗長 / verbose（同樣正確的短答 = 長答）
23- 道歉 / 開場白
24- 「我希望這有幫助」這類禮貌話
25
26[Section 4: Output format]
27請依下列 JSON 輸出：
28{
29  "correctness": <1-5>,
30  "style": <1-5>,
31  "completeness": <1-5>,
32  "reasoning": "<簡短解釋>",
33  "overall": <1-5>
34}

關鍵設計原則：

1. Rubric 明確、可重現：用 1-5 scale + 每分明確定義、避免 judge 自由發揮
2. 明確列「不加分項」：vag rubric 容易讓 judge 加分長答 / 道歉 / 客套（verbosity bias）
3. 要求 reasoning：強迫 judge 寫評分理由、提升 calibration、後續可 debug
4. Structured output：用 JSON / structured output 強制格式、後續可程式化處理

Pairwise vs Direct scoring

兩種主流評分方式：

Direct scoring（直接打分）

給一個 (input, output)、judge 給絕對分數（1-5、1-10）。

優點：簡單、可看「絕對品質」隨時間改變 缺點：分數 calibration 不穩（不同 batch 跑、judge 可能 baseline drift）

Pairwise comparison（兩兩比較）

給一個 input + 兩個 output（A、B）、judge 選哪個比較好。

優點：相對比較比絕對打分穩、適合 A/B testing 缺點：需要兩個 candidates、結果是「A > B」不是「A 多好」

實務組合：

三大 Bias 跟緩解

1. Position bias（位置偏見）

Pairwise 比較時、judge 對「先出現」的 candidate 有偏好（通常偏 A）。

緩解：

• 換位置跑 2 次（A-B 跟 B-A）
• 只 count 兩次都偏 A 的為「prefer A」、不一致為「tie」
• 標準 LLM-as-Judge framework（如 MT-Bench）內建這做法

2. Verbosity bias（冗長偏見）

Judge 傾向給「長答」高分、即使內容沒比「短答」更好。

緩解：

• Rubric 明確寫「冗長不加分」「同樣正確的短答 = 長答」
• 長度 normalize：分數 = raw_score / log(length)
• 用 length-controlled benchmark（如 length-controlled AlpacaEval）

3. Self-preference bias（自家偏好）

Judge 偏好自家風格的答案（GPT 當 judge、偏好 GPT-style 輸出；Claude 當 judge、偏好 Claude-style）。

緩解：

• 用 3 個不同 family 的 judge model（如 Claude + GPT + Gemini）取多數
• 避免 judge 跟 test subject 同 model
• 用 reasoning model 當 judge（多家 reasoning model 共識更穩）

補充 bias：Format bias

Judge 對「有 markdown / 有 code block / 有結構」的答案偏好、即使內容沒比「純文字」更好。

緩解：rubric 明確寫「格式不加分、看內容」。

Calibration（校準）

Judge 不該光信、要 calibrate：

 11. 蒐集 100 個 (input, output) pair
 22. Human eval（你自己或可信 human）打 ground truth 分數
 33. Judge 跑同樣 100 個
 44. 算 agreement rate：
 5   - Pairwise：judge 跟 human 同意比例（target > 75%）
 6   - Direct scoring：Spearman correlation（target > 0.7）
 75. 若 agreement 低：
 8   - 改 rubric（更明確）
 9   - 換 judge model（更強）
10   - 改 prompt（few-shot example）
116. Calibrate 後的 judge 才能跑 production

Calibration 是「judge 評什麼」跟「人類評什麼」對齊的步驟、跳過會讓 production eval 失準。

跟 4.20 LLM tracing 的閉環

Production trace + LLM-as-Judge 形成自動 eval pipeline：

 1Production users
 2   ↓ 產生 trace
 3[LLM tracing 平台]（LangSmith / Phoenix / Langfuse / Braintrust）
 4   ↓ filter：user thumbs-down、error、long latency 等 trace
 5   ↓ sample 100 個 / day
 6[LLM-as-Judge batch run]
 7   ↓ rubric scoring
 8[Dashboard]
 9   - 哪類 query 品質下降
10   - 哪個 deployment version 品質差
11   - 哪個 user segment 體驗差
12   ↓
13觸發 alert / 改 prompt / 改 model / 回退
14   ↓ A/B test
15   ↓ Pairwise judge eval new vs old
16   ↓ Deploy 勝者

這是 production LLM 應用 quality engineering 的標準閉環。

Judge model 選型

判讀：

1. 大 stake / final QA：雲端旗艦 reasoning model
2. 大量 production trace eval：中等模型（GPT-4o / Sonnet）、cost / speed 平衡
3. 隱私敏感（user trace 不能送雲端）：本地 reasoning model（QwQ-32B / R1 distill）
4. A/B test prompt 改進：用同個 judge 跑前後比對、保持 baseline

失敗模式

1. Rubric 太 vague：judge 自由發揮、分數沒重複性

緩解：rubric 寫得像 unit test、每分有具體 criteria

2. 沒做 calibration：judge 跟 human agreement 沒驗、可能 systematically off

緩解：每次大改 rubric / 換 judge model 都重新 calibrate

3. Sample 不代表 production：只 eval easy case、production 真實困難 case 沒覆蓋

緩解：用 stratified sampling（按 difficulty / user segment / feature 抽樣）

4. Bias 沒緩解：position / verbosity / self-preference 直接 baked in

緩解：標準 framework（DeepEval / Inspect / Braintrust）內建 bias 緩解、用既有 framework 比 DIY 穩

5. Judge cost 比預期高：production trace 全跑 judge、cost 爆

緩解：sample rate < 10%、配合 LLM tracing 的 sampling

6. Over-reliance on judge：忘記 judge 也會錯、把 judge 當絕對真理

緩解：高 stake 任務仍需 spot human review、judge 是 80% 解、不是 100%

主流 framework

何時不該用 LLM-as-Judge

1. 可機械驗證：unit test、exact match、output schema validation — 用 deterministic rule 比 judge 穩
2. 極小 dataset（< 20 items）：直接 human eval、不必 judge
3. 判讀需要 domain expertise：醫療 / 法律 / 安全的 high-stake 判讀、judge 不該替代 expert
4. Judge 能力 < test subject：用 GPT-4o judge 評 o3 輸出、judge 看不懂 reasoning trace

何時過時 / 何時不過時

不會過時的部分：

• LLM-as-Judge 作為 production eval 主流方法的地位
• 四段式 judge prompt 結構（task / input-output / rubric / format）
• Pairwise vs direct scoring 的取捨
• 三大 bias 分類跟緩解方法
• Production trace → judge → action 的閉環

會變的部分：

• 主流 framework（DeepEval / Inspect / Braintrust 等）
• 各 judge model 的具體能力（每代強模型）
• Bias 的具體量化（人類 agreement 數字會隨時間 / 任務變）
• 新興 bias 跟緩解方法

下一步

下一步：模組四到此覆蓋從基礎（4.0 prompt 技術光譜 / 4.1-4.2 RAG / 4.3 tool / 4.4 agent / 4.5 HITL）、協議與編排（4.6 protocols / 4.7 workflow / 4.8 multi-agent）、production 細節（4.9-4.12 resource / artifact / long-context / embedding）、到 eval 跟 production observability 閉環（4.13 eval 框架 / 4.14 benchmarking / 4.17-4.21 harness / caching / memory / tracing / judge）的完整應用層地圖。Hands-on 端到端案例見 hands-on 子分類。可進入 模組五 看本地推論硬體、進入 模組六 看安全議題（特別是 6.6 OWASP LLM Top 10 對照、把 production eval 的安全議題對應到企業合規詞彙）、或回 4.13 Eval 設計座標系 看 judge 在 meta eval 框架中的定位。