全部場數

010 · 從需求到上線的 AI 系統設計框架

透過一個健康保險理賠審核系統的案例，示範如何從產品需求走到系統設計、評估與優化的完整流程。

2026-06-2828:52Apoorva Joshi（MongoDB）Agent開發工具評估產業觀察看原片

原標題：AI System Design: From Idea to Production - Apoorva Joshi, MongoDB

重點摘要

  • 先定義問題，別急著動手與其直接找 agent 或讓 AI 生成程式碼，應該先量化商業問題、盤點限制條件，並釐清 AI 在產品裡扮演的角色。
  • 成功指標要具體可衡量用 SMART 原則設定目標，例如把某類理賠的處理時間從兩天縮短到一小時，並限期驗收。
  • 架構從最簡單的設計開始先畫出資料怎麼流過系統，再回頭挑合適的檢索方式與設計模式，寧可先簡單再迭代，也不要一開始就做出複雜系統。
  • 上線前後都要評估上線前用忠實度、引用缺失率等指標把關，並靠 guardrails 擋掉無關或缺引用的回答；上線後持續追蹤同樣的指標，再加上人工覆寫率之類的間接訊號。
  • 達標準確度只是及格線還要靠重新排序、語意快取、結構化輸出等技巧，兼顧成本、延遲與可靠性，系統才真正撐得住上線。

時間軸

時碼點下去會跳到影片的那一段。

時碼段落重點
00:00開場：講者與主題Apoorva Joshi 是 MongoDB 的開發者關係工程師，這場要示範一套能套用到任何 AI 系統的完整設計框架。
00:36對「隨手上線」的提醒隨手讓 AI 生成程式碼就直接上線，在真正有後果的場景裡很危險，連 Anthropic、OpenAI 的人都這樣說。
01:42框架四階段把設計拆成產品需求、系統設計、評估與監控、優化四個階段，依序決定每一步該做什麼。
02:28案例：健康保險理賠審核用一個理賠審核系統當範例，示範框架每一步怎麼具體套用。
03:40量化商業問題與限制先寫清楚審核員平均要花多久處理理賠、哪些資料不能離開組織、哪些案件一定要人工複核，才開始談要做什麼系統。
07:33訂出成功指標用 SMART 原則訂目標，例如把緊急理賠的處理時間從兩天縮短到一小時，並限九十天內達成。
08:39資料策略：來源與更新頻率盤點臨床指引、理賠政策、病患紀錄各自存在哪裡、多久更新一次，以及需要怎麼前處理才能被系統使用。
12:03先畫流程再選架構別急著找 agent 或讓寫程式的 AI 決定架構，先畫出理賠怎麼流過系統，再回頭挑合適的設計模式。
13:54AI 設計模式總覽介紹 RAG、agent、控制流程、LLM as a router、human-in-the-loop、fine-tuning 六種常見模式的差異。
16:17套用模式決定架構理賠系統需要 RAG 取資料、用控制流程管理審核順序，再加上 human-in-the-loop 讓人工把關複雜案件。
20:56評估與監控：先立 guardrails上線前要先替輸入輸出畫界線，擋掉無關或缺引用來源的回答，再談其他評估指標。
25:20優化：準確度、成本、可靠性準確度達標只是及格線，還要靠重新排序、語意快取、結構化輸出等技巧，才能真正撐得住上線。
27:13結語三個要點先想清楚產品需求再讓 AI 寫程式、從最簡單的設計做起、評估要從一開始就內建進流程。

值得記的話

名詞與人物

MDB Health講者虛構出來示範用的保險公司名稱，是這場理賠審核案例的主角，不是真實客戶
RAG用外部知識庫補足 LLM 既有知識的做法，這裡指檢索臨床指引與理賠政策
Control flow流程順序由設計或程式碼預先定好，LLM 只負責其中特定任務
LLM as a router讓 LLM 只負責把請求分類、導向不同下游流程，自主性有限
Human-in-the-loop流程中保留人工介入點，例如複雜案件要轉給資深醫師覆核
Guardrails為輸入輸出設下界線，擋掉無關或有害內容，也抓出沒有附引用的回答
Faithfulness用來評估回答是否真的根基於檢索到的臨床指引與政策內容
Voyage AIMongoDB 旗下的嵌入模型服務，講者提到會搭配 MongoDB 一起用來做檢索
Semantic caching用語意相似度快取先前的回答，加速處理相似的理賠案件

延伸

  • 演講中提到的 AI 設計模式參考資源，講者只留了連結，沒有在台上展開內容。
  • 結尾提到 MongoDB 的 GenAI cookbook，裡面有更多檢索與優化的範例，講者同樣沒有細講。
  • Fine-tuning 的適用時機，講者只用一句話帶過判準（行為性失敗、需要領域專用表現），沒有進一步說明實際怎麼做。