[情報] Uber 多模態 Agent：閉環 Evals 怎麼扛住美食圖改圖
一、誰在講、在解什麼題
Soumya Gupta 是 Uber 的 ML／應用 AI 工程師；Jai Chopra 是 Applied AI 產品。他們在 AI Engineer World's Fair 講一支產線上的真實案例：幫較小、獨立的 Uber Eats（外送市集）商家把食物照修好的多模態 agent——看圖＋讀菜名描述，決定要不要改、怎麼改、能不能上架。
題目難在三件事同時成立：忠於原菜（不加減料、不改份量）、保住店家品牌與擺盤，又不能讓全市場長同一張臉。沒有現成的「窄領域多模態 evals」劇本可抄。
二、小店拍不好、顧客又不信 AI 感
照片常是顧客對店家的第一印象——決定要不要點進去、加進購物車。小店卡在沒時間、不會拍、專業棚拍太貴（菜單還會改）。消費者要「看起來真」的圖，又有一堆人對 AI 感很重的食物照不信任。
所以護欄寫死三條：
- Stay faithful：不加減料、不改份量
- Preserve brand：包裝、擺盤、店家識別一致
- Avoid sameness：不能同一套 prompt 把市場刷成同一風格
全球品質長尾很散（銳利度、構圖、色調、UGC），增強要有選擇性：該修才修。目標還包含安全出貨、持續學習、成本扛得住，且不要為了某幾家好看去吃掉其他商家的曝光。
三、產線長什麼樣：理解 → 路由 → 改圖 → QA
光譜一端是規則系統——可控但脆；另一端是高自由度 agent——有創意但容易踩紅線。他們選中間：給 agent 空間，外面包明確護欄。
- Image understanding + Routing：多模態 LLM 描述照片 → 結構化輸出 → 決定 Enhance 或 Skip（Skip 保留原圖）
- Editing：進編輯 agent，跟 QA agent 迴圈自我修正
- 多次仍失敗就不發佈；過關再進後處理與 Publish-ready QA，才上菜單
- 全程 log：端到端打成扁平 JSON，工程／產品都能個案排查也能彙總——沒有 log 就沒東西可優化。觀測平台用 Arize（觀測／追蹤用的工具）
四、Routing evals：當分類器打 precision／recall
路由把影像＋文字描述＋ metadata 做成 enhance／skip。評估當傳統分類器：confusion matrix 看 TP／FP／FN／TN，對人標量 precision & recall。第一版護欄偏 recall——壞圖不能漏放。以後若要分流到低延遲小模型省成本，矩陣會變成 n×n。
離線第一版：先收代表性資料（地區、菜系、畫質），給標註員客觀規範減主觀雜訊 → agent 輸出對齊 golden set → 護欄過了才 ship。
五、路由錯了會變成「造假菜」
兩個對照案例：
- False enhance：明明很好的漢堡照被拿去修 → 白燒算力，還可能把好圖修壞
- Recall miss：菜單寫 8 塊雞翅、照片只有 6 塊，路由卻放行 → 下游編輯可能為了對齊文字「幻覺」出兩塊翅，直接打穿 faithfulness
離線模型過關後，長尾案例還是會爆；靜態系統扛不住產線漂移，prompts／agents 本身要能跟著長。
六、閉環：Diagnoser + Auto-tune
定期抽產線流量，用同一套規範給人標，跟 agent 決策比對。有 mismatch → diagnoser（傘型診斷 agent）定位是哪個元件壞了 → 觸發 autotuning → 用既有 golden set 再 benchmark；過關才 ship 新設定。
Auto-tune 裡的 prompt optimizer 分兩步：
- Reflect：看 mismatch、濾雜訊、找系統性問題
- Synthesize：依回饋改 agent config，再 benchmark；過關登錄 config store，下次產線吃新版
設定驅動、可觀測、可 rollback。人標仍是「對齊目標」；機器負責診斷／優化／放行評估——留言區也有人提醒：抽樣人標其實還在環裡，只是節奏固定、不卡每次推版。
七、Generation：專屬 prompt、pass@k、pairwise
進增強後：依菜名描述＋路由的改進指令，為這張圖生專屬 prompt → 改圖 → 多維 QA（擺盤、忠實度、色彩等）。失敗就把 QA 理由塞回 prompt 再試；最多 K 次，過關才發，否則接受 coverage hit、寧可不改。指標是 pass@k。
「比較好」用 pairwise：原圖 vs 改圖，對齊產品／設計／政策／法務定義的更好（忠實、完整、自然、真實等），輸出 yes／no／unsure。失敗型態包含：加了不該有的蝦、拿掉壽司底下醬汁、QA 逼太緊後 reward hacking 成無意義的陶瓷碗、盤子蓋住醬料（物件連貫／物理合理性）、份數看不清就 unsure 直接拒發。
最後還有 Publish-ready QA（政策＋品質）——Swiss cheese：多層重疊，刻意留一點冗餘，降低漏網壞圖進產線的機率。
八、三條回饋環，Diagnoser 坐上面
- Model loop：人標對齊＋漂移自動調（上面那套）
- Dogfooding loop：內部／店家／設計／產品按讚倒讚與自由文字 → diagnoser → 重播案例 → benchmark 才推 config
- Marketplace loop：盯轉換等市集健康指標；可切 geo、裝置、菜系，分群調參再推勝出設定
Diagnoser 吃多種訊號，決定要修哪一個（或哪幾個）元件——routing、prompting／generation、LLM QA、publish-ready QA 都能被點名改設定。
九、帶走這幾句
- 窄領域多模態 evals：先把「比較好」寫進產品／政策定義，再談模型分數。
- 路由錯會變成 faithfulness 錯——影像與文字不一致時，編輯不能默默「補齊」不存在的菜。
- 先 log、再優化；閉環要有 golden set 護欄與 rollback，才敢讓 config 自己長。
- Reward hacking 與同質化都是真風險：系統會學會「安全但沒幫助」的改法，或把市場刷成同一風格。
※ 來源：YouTube／AI Engineer — Soumya Gupta & Jai Chopra《Building Closed-Loop Evals for a Multimodal Agent at Uber Scale》；官頁整理 ai.engineer/talks/…。非正式圖文整理，內容以原片為準。