The Production AI Playbook: Deploying Agents at Enterprise Scale — Sandipan Bhaumik, Databricks
三句話摘要
從 Demo 到生產級 AI 的五柱框架：Sandy（Databricks 技術主管）分享如何用評估、可觀測性、資料基礎、協作編排與治理五個支柱，系統性地將 AI Agent 部署到企業生產環境。 --- AI 上生產的關鍵不是模型選擇，而是先建立評估、可觀測性與資料基礎——讓 AI 系統可量測、可追蹤、可問責，Demo 才能真正變成產品。 1. 大多數 AI 專案在生產環境失敗的原因是「先選模型」
重點整理
重點- 1
1. 大多數 AI 專案在生產環境失敗的原因是「先選模型」
- 2
企業通常從「用 GPT 還是 Claude？」開始討論，在受控環境下跑出漂亮 Demo，但上線後因缺乏可觀測性、評估機制與責任歸屬，無法理解 AI 為何答錯，最終既無 ROI 又損失時間與金錢。
- 3
2. 評估（Evaluation）是整個 AI 系統的規格書
- 4
評估不是談「accuracy」，而是用數字定義業務成功條件，收集領域專家的真實案例建立黃金資料集，並建立自動化管道持續與生產回應比對；這個資料集是活的系統，隨時間增長讓整體品質持續提升。
- 5
3. 可觀測性（Observability）在受監管行業是法規要求，不是選項
- 6
透過追蹤每一個 Agent 決策步驟（意圖分類、API 呼叫、政策文件檢索、推理、護欄檢查），才能在客戶投訴時回溯 AI 行為、偵測重複 API 呼叫等隱性問題，並在生產環境中設定線上監控與回退策略。
- 7
4. 多 Agent 協作模式的選擇直接影響延遲與可維護性
- 8
Orchestrator-Worker 模式提供中央控制，易於除錯；Choreography 模式讓 Agent 透過訊息匯流排平行運作，降低延遲；Human-in-the-Loop 在信心分數低於門檻時引入人工審核。三種模式應依業務場景選擇，並需同步處理狀態管理與故障容錯問題。
- 9
--
實用技巧與重點
乾貨- 具體數字與效益
- 零售銀行案例：每月 ~20,000 通客服查詢，60% 為可自動化的簡單問題
- 初次 POC 失敗耗資 $85,000 USD，歷時 6 個月
- 成功重做目標：AI Agent 處理 60% 簡單查詢，準確率 85%
- 測試階段 Governance 層攔截 47 起 PII 洩漏事件
- 模型選擇延至 8 週 POC 的第 7 週才進行
- 工具與平台
- Databricks（Agent Bricks、MLflow、Unity Catalog、Delta Lake、Mosaic AI、Genie text-to-SQL）
- Apache Spark、Delta Lake、MLflow（開源底層）
- 支援三大雲：AWS、Azure、Google Cloud
- LLM as Judge（第二層語意評估）
- OpenTelemetry（開源 Tracing 方案，QR Code 提供設定指南）
- ITSM 系統整合（生產告警）
- 向量資料庫（RAG 政策文件檢索）
- 三層評估架構
- 確定性層（Deterministic）：格式檢查、Regex、NER、PII 偵測、意圖分類
- 語意層（Non-deterministic）：LLM as Judge 評估接地性（Groundedness）、安全性、相關性
- 行為層（Behavioral）：工具呼叫正確性、重複 API 呼叫偵測、Agent 迴圈偵測
- 三種多 Agent 協作模式
- Orchestrator-Worker：中央控制，易除錯
- Choreography：事件匯流排，平行執行，降低延遲
- Human-in-the-Loop：信心分數低於門檻時觸發人工介入
- 生產事故處理 Playbook 步驟
- 偵測（評估儀表板）→ 診斷（追蹤記錄）→ 隔離（Prompt 版本回退 / 偏轉至人工）→ 修復（更新測試案例）→ 回歸測試（Eval Suite）→ 整合 ITSM 告警
- 成本控制技巧
- CI 管道中只對 Eval 資料集的小型子集運行測試；只有合併至主分支時才執行全量測試
- --
結論
結論“AI 上生產的關鍵不是模型選擇，而是先建立評估、可觀測性與資料基礎——讓 AI 系統可量測、可追蹤、可問責，Demo 才能真正變成產品。”
完整解析
詳細Sandy 在 Databricks 擔任資料與 AI 技術主管，此前在 AWS 擔任首席架構師五年。他在演講開頭描述了一個反覆出現的失敗模式：企業在高層壓力下急於展示 AI 成果，第一個動作永遠是「我們該用哪個模型？」，在受控環境下快速打造出一個精緻的 Demo，領導層鼓掌，系統上線——然後幾週後開始崩潰，沒人知道 AI 為何答非所問，既無 ROI 也無法追責。他從這些失敗案例中歸納出三個根本缺口：可觀測性缺口（無法追蹤 AI 決策）、評估缺口（沒有定義可量化的成功標準）、治理缺口（出事時無人負責）。
為此，Sandy 提出一個五柱框架，並強調這五個支柱應在動任何程式碼之前先想清楚。第一柱是評估：不是談泛泛的「準確率」，而是用業務語言定義數字目標，收集領域專家的真實問答案例建立黃金資料集，再打造自動化評估管道持續比對 AI 回應。評估分三層——確定性層處理格式、PII 等規則問題；語意層使用 LLM as Judge 評估接地性與安全性；行為層則檢查 Agent 是否重複呼叫 API、是否陷入迴圈等隱性問題，這第三層常被團隊忽略，但在規模化後成本代價極大。第二柱是可觀測性：以零售銀行 Agent 為例，從意圖分類、資料庫查詢、政策文件檢索、推理到最終護欄檢查，每一步都需要被追蹤記錄，否則無法應對客戶投訴，更無法滿足歐洲監管機構的合規要求。
第三柱是資料基礎，Sandy 認為這是最被低估的支柱，他本人在典型專案中花費 60% 的時間在此。問題在於資料向來是為人類設計的——人類看到錯誤資料會去問人，但 Agent 會自信地給出錯誤答案。資料基礎分兩類：供 AI 回答問題的「問題資料」（預訓練資料、RAG 向量庫、API 連接）與用於監控的「追蹤資料」，後者需要一套完整的 Schema 設計策略，以便同時服務於監管稽核、線上監控與 LLM Judge 評估。第四柱是多 Agent 編排，介紹了 Orchestrator-Worker、Choreography 與 Human-in-the-Loop 三種模式，強調選型需考慮狀態管理與故障容錯。第五柱是治理，包含稽核軌跡、PII 預先驗證、Prompt 版本控制（必須走正式變更管理流程）、以及模型變更管理——模型供應商的 Benchmark 不代表適合企業自己的資料，必須在自有評估資料集上重新驗證。
演講最後以一個零售銀行真實案例作結。該銀行曾花 $85K、六個月打造失敗的 POC，Sandy 的團隊重新介入後，前兩週先建評估框架（200 筆真實客服案例、自動化比對管道），第三至六週完善資料基礎與追蹤系統，直到第七週才選定模型——因為有了評估資料集，模型比較迅速完成。系統上線六週後，一次銀行利率政策更新導致 CSAT 下滑，正因為監控系統到位，團隊迅速追蹤到 Agent 引用了向量資料庫中的舊版政策文件，更新嵌入後問題解決。這個案例完整示範了五柱框架讓 AI 系統「可見、可量測、可問責」的核心價值。
---
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
