AI System Design: From Idea to Production - Apoorva Joshi, MongoDB
三句話摘要
從構想到生產環境系統化設計AI應用的四階段框架，以健康保險理賠審核為實例。 AI系統的難點在規格而非代碼，需在需求階段系統地定義商業問題、數據策略和評估指標，以此驅動而非跟隨架構決策。 產品規格優先於代碼：在編寫任何代碼前，需深入思考商業約束、監管要求、成本上限和延遲預算，這些決策會級聯影響系統的每個架構選擇，不應由AI編碼工具代決。
重點整理
重點- 1
產品規格優先於代碼：在編寫任何代碼前，需深入思考商業約束、監管要求、成本上限和延遲預算，這些決策會級聯影響系統的每個架構選擇，不應由AI編碼工具代決。
- 2
從最簡單設計開始迭代：常見錯誤是未經評估就過度工程化，應先設計滿足需求的最簡系統，評估找出缺陷後才迭代，避免前期過度投入不必要的複雜性。
- 3
多維度評估不可或缺：需同時測量輸入守衛欄合規性（拒絕率）、輸出質量（引用完整性、忠實度）、領域指標（處理時間）和系統健康（成本、令牌用量），不能只關注準確度。
- 4
監控隱性指標追蹤產品健康：上線後除追蹤離線指標外，還應監控人工審核員對AI決策的覆蓋率和審核耗時，這些指標能隱性反映用戶滿意度和系統行為是否發生迴歸。
實用技巧與重點
乾貨- 業務問題量化：MDV Health醫療審核員平均耗時2天審核理賠請求，為非緊急案件行業標準的4倍、緊急案件的12倍
- 業務約束：患者數據限於批准雲環境；模型只能用批准雲供應商的；複雜案件需高級醫生審核；拒絕決定需人工審核
- 成功指標：將緊急理賠平均處理時間從2天降至1小時，啟動後90天內達成
- 數據更新頻率：臨床指南（年更新）、覆蓋政策（季度更新）、患者理賠歷史（小時級更新）
- AI設計模式應用：RAG（檢索臨床指南和保單）、控制流程（固定審核路徑）、人工參與迴圈（人工複審）、LLM作路由器（判斷複雜案例）
- 評估指標類別：輸入守衛欄（理賠拒絕率）、輸出守衛欄（缺失引用率）、忠實度、處理時間、單次建議成本、令牌用量
- 優化技術：精確度（提示工程、重排序）、成本和延遲（語義緩存、批處理）、可靠性（結構化輸出）
- 監控指標：人工覆蓋率變化、審核耗時
結論
結論“AI系統的難點在規格而非代碼，需在需求階段系統地定義商業問題、數據策略和評估指標，以此驅動而非跟隨架構決策。”
完整解析
詳細AI應用開發的常見誤區在於急著編碼而忽視需求定義。講者以健保理賠審核系統為例，系統性地展示設計框架的四個階段如何相互銜接。
首先是產品需求階段。不應籠統地說「用AI加速審核」，而要量化業務痛點：MDV Health醫療審核員審核一筆理賠平均耗時2天，遠超行業標準（非緊急4倍、緊急12倍），導致患者就醫延誤。這個具體問題才能指導後續設計。同時須列舉業務約束——患者數據不能離開批准的雲環境、模型必須由雲服務商提供、複雜案例仍需人工審核、拒絕決定必須人工確認。定義成功指標時應SMART原則：將緊急案件處理時間在90天內從2天降至1小時。
其次是系統設計。先梳理數據流：理賠申請進入，系統檢索臨床指南和保單，提取患者歷史，送入LLM生成建議，複雜案件升級醫生複審，最終決策存入MongoDB。基於這個流程選擇架構模式：RAG處理指南和保單檢索、控制流程管理固定的升級邏輯、人工參與循環確保人工審核。設計者應抵住過度工程化的誘惑，不盲目跟風多代理系統，而是設計最簡方案先評估。
再次是評估和監控。需要多維度指標：輸入層面測量合規性（有多少無關理賠被拒絕），輸出層面檢查引用完整性和決策忠實度，領域指標追蹤處理時間是否達成目標，系統層面監控成本和令牌用量。上線後還要監控隱性指標，比如人工審核員對AI建議的覆蓋率，若率上升表示系統性能迴歸，需要介入調查。
最後是優化。成本和延遲約束在生產環境變成硬指標。可應用語義緩存加速相似理賠決策、批處理降低推理成本、結構化輸出確保格式一致。這些優化須建立在已被驗證的評估指標基礎上。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
