AI Engineer Europe 2026 · 演講 · 2026-06-18 · 37 分
企業把 Agent 推上線的五根支柱
The Production AI Playbook: Deploying Agents at Enterprise Scale · Sandipan Bhaumik，Databricks
Sandipan Bhaumik 從客戶導入 AI 失敗的經驗，歸納出評估、可觀測性、資料基礎、多 agent 編排與治理五根支柱，並用一個零售銀行聊天機器人的案例說明怎麼落地。
概要
- Demo 到上線的三個缺口Sandipan 在客戶端看到的共通問題是可觀測性、評估與治理。大家先吵用哪個模型，上線幾週後卻沒人說得清 AI 為什麼答不對。
- 評估是 AI 系統的規格成功要用數字定義，還要先跟領域專家蒐集真實案例做測試集。評估分成三層：確定性檢查、LLM as a judge 的語意檢查、看工具呼叫的行為檢查。
- 追蹤資料是稽核依據Sandipan 說在受監管的行業，沒有 tracing 與 observability 就不能把 AI 上線。客戶來申訴時，沒有追蹤紀錄就查不出 AI 做了什麼。
- 資料品質比模型選擇吃重Sandipan 說自己的專案有 60% 的時間花在資料基礎。人類會原諒錯誤的報表，agent 不會，只會自信地給出錯誤答案。
- 治理包含提示版本與換模型提示要當程式碼走變更管理，換模型要拿自己的測試集驗證，不能只看供應商公布的基準。
- 案例：先建評估、第七週才比模型銀行聊天機器人的專案用八週 POC，先做評估層，第七、八週才拿評估資料集比較模型，上線後靠追蹤找出過期的政策文件。
原話
▶ 05:38“you cannot even onboard AI into production without having tracing and observability in place”
在受監管的行業，沒有 tracing 與 observability 連 AI 都不能上線
▶ 15:31“Agents don't forgive you, right?”
agent 不會原諒你的錯誤資料
▶ 27:27“your evaluation data set is a living system.”
評估資料集是一個會持續成長的系統
▶ 29:00“Once we had that system that can make AI visible, measurable, and accountable.”
有了讓 AI 看得見、量得到、有人負責的系統之後，才開始上線
延伸
- 在銀行案例的測試階段，個資預先驗證那一層就抓到 47 次個資外洩。
- Sandipan 建議替測試集的資料列分類，例如把「agent 沒有要求登入憑證」歸在安全類，之後回頭查才知道哪類問題變了。
章節
點時碼直接跳到原片的那一段。
- 背景與框架預告Sandipan 自介是 Databricks 的資料與 AI 技術負責人，曾在 AWS 當五年首席架構師，這場要分享從現場經驗整理出來的上線框架。
- 為什麼 demo 上線就出事客戶的對話總從選 GPT 還是 Claude 開始，demo 在受控環境很漂亮，上線幾週後使用者就質疑 AI 為什麼答得不一樣。
- 三個缺口Sandipan 歸納出可觀測性缺口、評估缺口與治理缺口：看不到決策、沒定義要量什麼、出事時沒人負責。
- 五根支柱總覽評估、可觀測性、資料基礎、編排、治理，建議照順序建，但 Sandipan 也承認現實中常常做不到。
- 第一根：評估評估等於 AI 系統的規格，要用數字定義成功，先蒐集真人客服的答案與邊緣案例，再自動化測試流程。
- 評估的三層第一層是格式與傳統 ML 的確定性檢查，第二層是 LLM as a judge，第三層看行為，例如同一題為什麼呼叫了三次資料庫。
- 第二根：可觀測性以銀行聊天機器人的免除透支費用為例，攤開 agent 每一步決策，才能回應客戶申訴，也能做線上監控與重試上限。
- 第三根：資料基礎Sandipan 認為這根最重要，分成回答問題用的資料與追蹤資料，agent 不像人會原諒錯誤的資料。
- Databricks 的資料平台從雲端儲存、Delta Lake、Unity Catalog 到集中收集各框架的追蹤資料，再供儀表板與 LLM judge 使用。
- 第四根：多 agent 編排介紹 orchestrator worker、choreography 與 human in the loop 三種模式，各自的取捨是集中控制、降低延遲與信心不足時交給人。
- 第五根：治理稽核軌跡、個資預先驗證、提示版本管理當變更管理，以及換模型時用自己的資料集驗證。
- 案例：零售銀行聊天機器人客戶每月約兩萬通客服對話，其中六成是簡單問題，先前花了六個月、約 85k 做的 POC 沒成功。這次的目標是讓 agent 處理六成問題、準確率約 85%；八週 POC 先建 200 筆評估案例與成功指標，第七、八週才開始比模型。
- 上線後抓到過期政策銀行改了利率政策後客戶一直按倒讚，靠追蹤才發現向量資料庫裡的政策文件沒更新。
- 事故處理手冊偵測、診斷、遏制、修復四步，修好後把案例補進測試集，並串接既有的 ITSM 系統通知對的人。
- 明天就能做的事與三個教訓先從業務角度定義成功、做一份範例資料集，再談測試集要有負責人、提示的 commit 訊息要寫原因。
- 行為評估的成本控制第三層評估每次要跑整個資料集，費用會很高，Sandipan 建議 CI 只跑子集，合併到主分支才跑完整測試。
名詞
- LLM as a judge
- 用另一個 LLM 依安全性、groundedness、相關性等標準評判主模型的輸出，屬於評估的第二層
- 行為評估
- 評估的第三層，檢查工具呼叫與是否陷入重複呼叫，例如答對餘額卻呼叫了三次資料庫
- Orchestrator worker pattern
- 由一個協調者集中分派工作給專長不同的 agent，出事時看協調者的紀錄
- Choreography pattern
- 各 agent 獨立並行，透過 message bus 聽取自己關心的事件，不必來回等協調者
- Delta Lake
- Databricks 平台上替原始資料加上類似資料庫表格特性的一層
- Unity Catalog
- Databricks 的資料目錄，集中管理權限，並用描述與標籤提供 AI 查詢時的脈絡
- MLflow
- Databricks 所用的開源專案之一，Sandipan 提到它提供開箱即用的 LLM judge
- Agent Bricks
- Databricks 正在做的產品，把五根支柱的各項作業做成開箱即用
- ITSM
- 企業既有的事件通知系統，事故手冊要串接它才能通知對的人
