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

010Apoorva Joshi（MongoDB）28:522026-06-28

AI System Design: From Idea to Production - Apoorva Joshi, MongoDB

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

重點摘要

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

時間軸13 段

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:54	AI 設計模式總覽	介紹 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 寫程式、從最簡單的設計做起、評估要從一開始就內建進流程。

值得記的話4 句

Specs are the new code. The art is in defining the product requirements, the system design, and evaluation criteria, so you can be confident that your AI coding buddies are building the right thing.規格才是新的程式碼，難的是把產品需求、系統設計與評估標準定義清楚，這樣才能放心讓 AI 幫你做對的事01:27
There's so much hype around them, or let a coding agent decide what the system architecture should look like, but you risk ending up with an over-engineered system by doing this.agent 話題正熱，但如果讓寫程式的 AI 自己決定系統架構，很容易做出過度設計的系統12:20
Design the simplest system that meets your needs, evaluate it, and then iterate from there.先做出滿足需求的最簡系統，評估之後再逐步迭代27:48
That brings me to evaluation. Build evaluation and from the start, you can't improve what you can't measure.這就帶到評估：從一開始就要做評估，因為沒有量測就沒辦法改善28:06

名詞與人物9 個

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

提到但沒有展開

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

Agent開發工具評估產業觀察

在 YouTube 看原片 ↗