Observing and Evaluating LLM Coding Agents
觀察，建立基礎，迭代驗證
Che-Chia Chang
Coding Agent 會動就好
為何還需要 Observability 與 Evaluation？
- 紀錄 Coding Agent 效能 baseline
- 效能劣化時告警
- 紀錄原因：e.g. 上游 API 不穩定
- Claude API Uptime 只有 99.4%
- 沒有 o11y 就沒有 SLA
Change Management
- 改變後，效能是變好還是變差
- Spec-kit SDD 聽說好用要不要試
- rtk 聽說省 Token，要不要導入
- Opus 4.8 聽說很強
- 改變可能會劣化
- 改變需要成本
- 需要數據化的決策流程，避免 FOMO
Cost Management
- 根據監測控管預算，本月花費收斂下月預算
- charge back 團隊看見自己的成本
- 哪些問題用錢解決，哪些不能
- 需求進化比模型快
- 剛好的預算，選適合的模型，選適合的問題
為何需要 Observability
- Baseline
- change management
- cost management
今天的內容
- ✅ Change & Cost Management
- 建立 baseline 與第一次優化
- LLM as a Judge
- Dataset & Experiment
- 釐清需求：提升 Coding Agent 效能
- Decision System
從 Observability 開始
「我的 Agent 到底怎麼花 Token 的」「如何系統化評估 Agent 輸出品質」
- 觀察到 Observability Stack
- 看見量化數據：Token Usage、Latency、Error Rate
- Chargeback 讓團隊成員看見自己的成本
- 根據監測紀錄控管預算，而不是只看市場喊價
先建立 Cost 與 Token Usage baseline，定義什麼是符合預算、什麼是超出預算
Step 1: 建立 Baseline，完成第一次優化
- 先理解正在使用的 CLI
- VSCode Copilot、Codex、OpenCode 的行為都不相同
- 停用不必要的 Tools
- VSCode Copilot 內建 50+ 個 Tools，但實務上只用到 10+ 個
- VSCode Extension 也可能增加 Tools
- AI Gateway 提供額外的控制點
控制你的 Coding Agent
Step 2: 用 LLM 作為 Judge
- 前一步根據 Tracing Metadata 優化成本
- 接著根據 Tracing 的 Input/Output 優化品質
- 讓 LLM 根據 Input 與 Output 評估結果品質
- 傳統程式碼測試的場景有限，難以涵蓋 LLM 多變的使用情境
Step 2: 以 Observation 為單位評估
以 Observation 為單位，評估每次 API Call 的品質
- 針對 Input、Output、Metadata 或部分資料進行評估
- 先在小 scope 內進行量化，以管窺天
- 反映局部品質
- 但無法代表 Project 的整體品質
先從局部開始，分析錯誤類型並找出改進方向
Step 2: 根據評估結果完成第二次優化
LLM-as-a-Judge 的評估結果，持續調整
- 控制其他變因，例如
- Metadata：Token Usage、Latency、Cost
- Model Version
- 優化 Input/Output 品質
控制變因，調整變因，持續提升局部分數
Step 2: Multi-turn Agent
Long-running Agent 很難只看最終答案來評估，例如
Input: 更新 README.md
- Assistant: 先看 README.md 內容
- Assistant: [tool] cat README.md -> README.md 內容
- Assistant: [tool] plan -> plan
- ...
- Assistant: 根據 README.md 內容，修改 README.md
- Assistant: [tool] apply patch -> 修改後 README.md 內容
Output: README.md 修改成功
針對單一步驟評估，例如 Plan 或 [tool] Apply Patch
Step 3: 建立 Dataset，執行 Experiment
Dataset：從 Daily Work Tracing 整理出的真實考題
Input 反映真實工作需求
Output 反映 Model 上次的回答
LLM-as-a-Judge 的分數反映回答品質
Experiment：使用同一份考題，控制不同變因重複執行
Model：5.4 -> 5.5
Tools：改動前後
Instruction：改動前後
Step 3: 整理 Dataset
先根據更細緻的需求定義分類 Dataset
- Plan 著重 Context Precision
- Coding 著重 Answer Correctness
再根據 LLM-as-a-Judge 分類 Dataset
Warning: o11y 走進 Dataset 是一個大坑
Step 3: 進行 Data Preprocessing
- 清理 Tracing 資料格式
- 根據需求，挑出有意義的 Features
- 例如
Output.tool_calls.args - Model 收到 Input 時呼叫哪些 Tools，帶什麼參數
- 用 Langfuse SDK Transform 成其他格式
- Partition Dataset
儲存到持久化儲存系統，作為測試題庫
Step 3: 完成第三次優化
針對題庫中的特定題目，測試最佳 Model
- Pro, Mini, Nano
- Thinking Effort
- GPT-5.4, GPT-5.5
- Codex, OpenCode, Copilot
不要等待 Model 變強來解決問題
選擇最佳的工具，在品質與成本之間取得平衡
Step 3: Evaluation 後，就取得 Cost Estimate
- 完成多少題目
- 使用的 Model 與 metrics
- LLM API metrics，使用多少 Token
- Quality Estimate
沒有測試做基礎的預算，其實是市場喊價
Step 0: 先釐清需求
釐清需求，應該是第一件要做的事
實務上，很多團隊還沒做到前兩件事
- 沒有清楚定義需求
- 成員對 LLM 的理解存在落差
- 就開始討論要不要更換工具
建議「先建立監測」：先看見顯微鏡下的世界，再相信微生物存在，會比較容易接受
用數據調整團隊認知，後續討論才更容易回到現實
Step 0: 定義 Coding Agent 的效率
我們想提升團隊使用 Coding Agent 的效率
但 Coding Agent 的效率到底是什麼？
$$
\text{整體效率 Efficiency} = \frac{\text{產出數量} \times \text{產出品質}}{\text{Token Cost} \times \text{花費時間}}
$$
降低 Cost、Latency、Error Rate
控制 Context Window
提升 Output Quality
Step 0: 從需求走向 Action
依照不同任務選工具
- Model: Mini, Nano, Low Latency, Low Error Rate
- AI Gateway Routing
- Context Management -> rtk
- 加速 Greenfield 專案開發 -> Spec-kit
Step 0: 讓團隊 On the Same Page
- Dev Team: Chargeback
- Stakeholders 與管理者對齊期待
- 量化效能指標：正確率、Error Rate、Latency、Cost
- 有 AI 不代表就能十倍產出
有 Evaluation 後，可以明確講出「我們產出大概 2-3 倍，數據在此」
Takeaway: 從觀察到決策系統
- Step 1: 建立 Baseline，完成第一次優化
- Step 2: 使用 LLM-as-a-Judge 評估品質
- Step 3: 建立 Dataset，執行 Experiment
- Step 0: 先釐清需求
- Decision: 釐清需求 -> Take Action