AI O11y：數據決策到技術選型

Observability → Decision System

Che-Chia Chang

同事在問

• Spec-kit SDD 好用，要不要試？
• rtk 省 Token，要不要導入？
• 新模型 Benchmark 更好，要不要換？

身為技術負責人，如何回答？

面對 AI 工具快速迭代

• 全部試用
• 參考專家與供應商分享
• 採用代理商或雲端商推薦

試用是一種選擇；團隊更需要數據化決策

新工具出現速度 > 研究速度

Coding Agent 會動就好？

為何需要 O11y / Evaluation？

• 建立效能 Baseline
• 劣化時告警並追查原因
  • 例如上游 API 不穩
• Claude API Uptime 僅 99.4%
• 沒有 O11y，就沒有 SLA

Change Management

• 改變後，效能變好還是變差？
• Spec-kit：SDD 聽說好用
• rtk：聽說省 Token
• Opus 4.8：聽說很強
• 改變有成本，也可能讓效能劣化

用數據決策，避免 FOMO

Cost Management

• 依本月用量，收斂下月預算
• Chargeback：讓團隊看見成本
• 分清哪些問題能用錢解決
• 需求演進比模型快
• 沒有單一模型能解決所有問題
• 用合適預算與模型
• 有效率地解決能解的問題

為何需要 Observability

• 建立 Baseline
• 管理改變（Change）
• 管理成本（Cost）

關於我

• Che Chia Chang
• SRE @ Maicoin
• Microsoft MVP
• 投影片與講稿都在 chechia.net
• Hello Dev 2026: LLM O11y
• Hello Dev 2026: LLM O11y
• Cloud Summit 2026: LLM O11y
• Cloud Summit 2026: SDD with Spec-kit
• K8s Summit 2024: Etcd Workshop
• DevOpsDay 2025: RAG Workshop

今天的內容

• ✅ Change & Cost Management
• 建立 Baseline、完成第一次優化
• LLM-as-a-Judge
• Dataset & Experiment
• 釐清 Coding Agent 效能需求
• Decision System

從 Observability 開始

• 用 Gateway / O11y Tool 收集 Tracing
• 建立流程：LLM O11y → Judge
• Dataset → Experiment
• LLM O11y Workshop
• Observability → Decision System
• Agent 怎麼花 Token？
• 如何系統化評估輸出品質？

導入 Gateway / O11y Tool

• 看見 Observability Stack

• 量化 Token Usage、Latency、Error Rate

• Chargeback：讓團隊看見自己的成本

• 用監測數據控管預算，不只看市場喊價

• 建立 Cost / Token Usage Baseline

• 定義預算界線

Step 1｜Baseline 與第一次優化

• 先理解 CLI 行為
  • Copilot、Codex、OpenCode 各不同
• 停用不必要的 Tools
  • Copilot 內建 50+ 個 Tools
  • 實務上只用 10+ 個
  • VSCode Extension 也可能增加 Tools
• 透過 AI Gateway 增加控制點

控制你的 Coding Agent

Step 1｜第一次優化成果

• Token Overhead：20,000+ → 1,000+
• 成本：$0.10 → $0.005（降至約 5%）
• 降低進入 Long Context 的機率
  • ≥272K Tokens 價格翻倍
• 把 Context Window 留給真正有用的內容

OpenAI API Pricing

Step 2｜LLM-as-a-Judge

• 依 Tracing Metadata 優化成本
• 依 Input / Output 優化品質
• LLM 評估輸出品質
• 傳統測試難涵蓋多變情境

Step 2｜Observation 評估

• 評估每次 API Call
• 看 Input、Output 與 Metadata
• 小範圍量化，觀察局部品質
• 不代表 Project 整體品質
• 從局部分析錯誤類型，找出改進方向

Step 2｜根據評估結果優化

• 依 LLM-as-a-Judge 結果持續調整
• 控制變因：
  • Token Usage、Latency、Cost
  • Model Version
• 調整 Prompt / Instruction
• 改善 Input / Output 品質

控制變因、調整變因，提升局部評分

Step 2｜Multi-turn Agent

Long-running Agent 不能只看最終答案：

Input: 更新 README.md
讀取 → Plan → Apply Patch → 完成
Output: README.md 修改成功

改評估單一步驟
例如 Plan 或 Apply Patch

Step 3｜Dataset & Experiment

Dataset｜真實工作考題
從 Daily Work Tracing 整理

Input：真實工作需求
Output：Model 的回答
Judge Score：回答品質

Experiment｜同一份考題
控制變因，重複執行

Model：5.4 → 5.5
Tools / Instruction：改動前後

Step 3｜整理 Dataset

• Plan：Context Precision
• Coding：Answer Correctness
• 依 Judge 分數分類
• 高品質案例作為改進參考

注意：從 O11y 走進Dataset，是個大坑

Step 3｜Data Preprocessing

• 清理 Tracing 格式，挑選所需 Features
• 例如 Output.tool_calls.args
• 記錄呼叫哪些 Tools、帶哪些參數
• 用 Langfuse SDK 轉換格式
• Partition Dataset

持久化儲存，作為測試題庫

Step 3｜第三次優化：選擇最佳工具

• 用題庫測試不同選項：
  • Model：Pro、Mini、Nano
  • Model 版本：GPT-5.4、GPT-5.5
  • Thinking Effort
  • Agent：Codex、OpenCode、Copilot
• 不必等 Model 變強才解決問題
• 選適合的工具，平衡品質與成本

Step 3｜Evaluation → Cost Estimate

• 測試題數與使用的 Model
• LLM API Metrics、Token 用量
• Quality Estimate

沒有測試基礎的預算，只是市場喊價

Step 0｜先釐清需求

需求應該先釐清

許多團隊卻先討論要不要換工具：

• 需求還不清楚
• 成員對 LLM 的理解有落差

Step 0｜Coding Agent 效率

想提升團隊效率，先定義「效率」：

$$ \text{Overall Efficiency} = \frac{\text{產出數量} \times \text{產出品質}}{\text{Token Cost} \times \text{花費時間}} $$

Step 0｜從需求走向 Action

依任務選工具：

• Model：
  • Mini、Nano
  • Low Latency、Low Error Rate
• Gateway Routing：
  • AgentGateway
  • LiteLLM
• Context Management：rtk
• Greenfield：Spec-kit

Step 0｜讓團隊 On the Same Page

• Dev Team：Chargeback
• 選擇 Model 與 Tool
• 與 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：釐清需求 → Action

Q&A

• Lab｜LLM O11y Decision System
• Lab｜Spec-kit SDD