Sandipan Bhaumik, Databricks · 37:05
這支影片在講：企業級 Agent 上線不能從選模型開始
Sandipan Bhaumik 用一個零售銀行 chatbot PoC 的失敗案例，拆解 production AI agent 的真正順序：先定義成功、建立追蹤與資料基礎，再談 orchestration、治理與模型。
Published: 2026-06-18Video ID: ObTPqBGsEbA
01 / 問題
PoC 花了錢，卻說不出為何失敗
案例中的銀行花了六個月與 85,000 英鎊做 chatbot PoC，但沒有人能解釋為什麼它無法進 production。
02 / 反轉
前六週不是在選模型
團隊八週 engagement 到第七週才選模型；前六週都在做 evaluation data、tracing infrastructure 與 measurement pipeline。
03 / 解法
把 agent 當 production system 管
影片整理五個支柱：evaluation、observability、data foundation、multi-agent orchestration、governance，以及串起它們的 incident playbook。
Watch for this
影片最值得抓的四個訊號
PoC cost
£85k
零售銀行六個月 chatbot PoC 的成本，但仍無法進入 production。
Sequence
Week 7
八週 engagement 到第七週才選模型，因為先要把評估與追蹤做起來。
Incident
6 weeks
上線六週後利率政策更新造成滿意度下降，tracing 抓到文件沒有重新 embedding。
Governance
47 PII
測試階段先抓到 47 起 PII breach，避免治理問題被帶進正式環境。
Core story
這個 production playbook 的五個支柱
01
Evaluation：先用數字定義成功
不要先問「哪個模型最好」，而要先問「什麼答案算成功」。Evaluation dataset 也不是固定 benchmark，而是會隨產品、政策與失敗案例更新的活系統。
02
Observability：每個 agent decision 都要可追
影片把 tracing 放在核心位置，因為 production agent 出錯時，團隊要知道它看了什麼、用了哪份資料、做了哪個決策。對歐洲監管環境，這不是 nice-to-have。
03
Data foundation：Agent 不會像人一樣原諒壞資料
人類客服能察覺文件過期或上下文不一致；agent 常會把 stale source 包成肯定答案。銀行案例中的利率政策更新，就是資料沒有重新 embedding 而被 tracing 抓出來。
04
Orchestration：多 agent pattern 要有明確邊界
Multi-agent 不是把責任拆散就好，而是要定義誰負責 retrieval、誰負責判斷、誰負責 escalation，以及失敗時如何交回人或 incident pipeline。
05
Governance：把合規測試放進 launch gate
PII、policy drift、audit trail 與 regulator requirement 都要在測試與上線流程中被看見。治理不是事後審查，而是 production readiness 的一部分。
Decision map
這支影片真正反對的是「demo-first」上線思維
不要把 PoC 成功等同 production ready能回答 demo 問題，不代表能處理政策更新、資料漂移、監管要求、PII 風險與客訴下降。
模型選型應該被 evaluation 拉著走如果還沒有成功指標與失敗案例資料集，模型比較就會變成主觀品味或 benchmark theater。
Incident playbook 要連接五個支柱上線後滿意度掉下來時，tracing、data freshness、evaluation regression 與治理證據要能串成一條排查路徑。
資料更新是 production event利率政策這種看似普通的內容更新，對 RAG / agent 系統就是會影響答案品質的發布事件。
Use this checklist
如果你要把 agent 推進企業場景，先檢查這六點
你是否已經用數字定義 success / failure？不要只寫「回答正確」。要把 accuracy、coverage、escalation、policy compliance、customer satisfaction 或 cost 明確化。
Evaluation dataset 會不會跟著真實失敗更新？每次 incident、policy change、customer complaint 都應該回流到測試資料，而不是只保留 launch 前的靜態集合。
Trace 能否重建 agent 做決策時看到的上下文？Production 排查需要知道 retrieval 結果、工具呼叫、資料版本、policy source 與最終回答如何形成。
資料 freshness 有沒有發布與回歸流程？文件更新、重新 embedding、index refresh、cache invalidation 都應該被當成 release pipeline，而不是手動補救。
多 agent 分工是否有責任邊界？每個 agent 的權限、輸入、輸出、handoff 條件與失敗升級路徑都要可測，不然 orchestration 只會放大不可觀測性。
治理是否在上線前就會擋關？PII breach、審計紀錄、政策符合性與 regulator requirement 應該進 launch gate，而不是等出事才補文件。