Dat Ngo, Arize · 16:32
這支影片在講：Agent debug 要從 trace 走到自動 eval
Dat Ngo 把 LLM observability 拆成三件事：先看見 agent 的執行路徑，再從 trace 裡萃取 eval signal，最後用 experiments 改 prompt、model、orchestration 或設定。重點不是多一個 dashboard，而是讓系統能知道哪裡壞、怎麼量、下一輪該改什麼。
Published: 2026-06-07Video ID: JsCCrBF7F1g
01 / 問題
非決定性讓傳統 debug 不夠
Agent 每次可能走不同路徑。像先 call tool B 再 call tool A 這種依賴順序錯誤，不一定會被程式碼本身捕捉。
02 / 反轉
Eval 不只是一個分數
Signal 可以來自 LLM judge、人類回饋、golden datasets、deterministic checks 與 business metrics，而且要選對執行層級。
03 / 解法
把改善流程產品化
從 trace 找低分樣本，收成 dataset，跑 experiments，比較 prompt、model、orchestration 或 config 變更，形成可重複迴圈。
Watch for this
影片最值得抓的四個訊號
Eval flavors
5
LLM judge、人類回饋、golden data、deterministic checks、business metrics。
Eval scopes
4
單一 span、multi-span、trajectory、session，從一個 call 放大到整段狀態機。
Runtime
1 container
Arize Phoenix 開源，可本機單一 container 跑，不需要 Kubernetes layer。
Goal
Auto eval
Alex 的方向是掃 traces、找 latency / errors，並自動建立需要的新 eval。
層 1
Observability：看見 agent 實際走了哪條路
Dat 從 OpenTelemetry traces / spans 講起，但很快放大到 sessions、branches、loops 與 trajectory。重點是回答：流量走到哪個分支？哪個 component 造成 latency？工具呼叫順序是否違反依賴？
層 2
Evaluation：把 trace 轉成可用訊號
Observability 只是第一步。接下來要決定 signal 從哪裡來：LLM as judge 可以近似 domain expert，human feedback 很珍貴，golden datasets 可校準 judge，deterministic checks 便宜，business metrics 則對齊賺錢、省錢或省時間。
層 3
Experimentation：讓改善不是憑感覺改 prompt
當 trace 或 dataset 抓出壞樣本後，experiment 的對象可以是 prompt、model、orchestration 或 configuration。這也是為什麼 agent 品質平台不能只停在監控，而要接到測試與比較。
Eval design
Eval 要同時選「訊號種類」與「作用範圍」
Span eval：看單一輸入輸出最小單位通常是一個 LLM call、tool call 或 component 的 input/output。適合檢查格式、schema、單步品質。
Multi-span eval：看元件之間是否傳對資料如果問題在多個 agent 或多個 component 之間的資料交接，單一 span 不夠，需要跨 span 看資料流。
Trajectory eval：看流程路徑是否正確例如 B 依賴 A，但 agent 先做 B 再做 A；這不是某個單點輸出錯，而是整條執行路徑錯。
Session eval：看整段互動狀態機例如使用者是否曾經挫折、問題是否被完整回答，這類判斷必須 zoom out 到整段 conversation / session。
Practical implications
如果你在做 agent / LLM app，先落地這五件事
先把 traces 變成 audit record不要只存最後答案；保留 tool calls、輸入輸出、branch、latency、errors 與 session context，否則後面無法重建 root cause。
不要只跑 LLM judge便宜的 deterministic checks、可信的 golden data、人類回饋與 business metrics 都是 signal。成本高的 eval 不一定比較適合每個層級。
用最小足夠 eval 集合不是所有東西能 eval 就該 eval。Eval 有成本，目標是最少但足以判斷應用是否照預期工作。
把 failures 收成 dataset從 traces 找到壞 signal，整理成 input-output pairs 或 curated datasets，才能讓下一次 prompt / model / orchestration 變更可比較。
讓非工程角色也能定義品質AI 工程師擅長自動化，但 domain experts / PM 才知道體驗應該長什麼樣。平台應讓他們能參與 eval 定義，而不是只交給寫 code 的人。
Where it is heading
Arize 的產品方向：把 observability loop 自動化
Phoenix：工程師本機起步開源、單一 container、本機可跑，適合工程團隊先把 traces、evals 與 experiments 接起來，不必先上 Kubernetes。
AX / Alex：企業級自動分析Dat 展示的方向是讓 Alex 掃 trace，指出 high latency、errors 等問題，並在需要時自動提出或建立 eval。
Production triage：從 trace 主動找問題Enterprise 產品的 Alex 方向是掃描 traces，主動浮出高延遲、錯誤與需要補 eval 的地方，減少純手動排查。
最終目標：不用手動選 eval理想狀態是 AI 看到 traces 與系統變化後，知道該新增什麼 eval，而不是要求人一直待在 dashboard 裡按按鈕。