設計一套 AI 系統

AI 回答出錯，問題可能出在模型、輸入的證據，或外圍的應用程式。漏掉合約、讀錯表格與缺乏佐證的摘要，各自需要不同的修補方式。本課說明如何劃清明確的元件邊界，讓這類失敗更容易定位與攔截。

設計時應先釐清任務需求，再挑選模型與外圍元件。只要應用程式需要回答私人合約問題，不論由哪個模型起草回覆，都必須具備授權資料存取與證據查核機制。系統組合也會增加延遲、成本與失敗點，因此每個元件都應有可驗證的用途。

貫穿本課程的範例是虛構旅行社 OptiVerse Travel。以下訂單 ID、合約、條款、照片與預算皆為教學用測試資料，用來設計證據流程，不能證實真實行程是否符合預算，也不能證實合作夥伴的房況。

為何「只靠模型」的思維會失敗

先看旅遊規劃師提出的問題：

我們能否在櫻花季期間，為四口之家規劃 10 天的日本無障礙行程，預算控制在 13,000 至 15,000 美元以內？另外，京都合作飯店是否仍維持合約中的輪椅無障礙房型費率？

基礎語言模型面對這段提示，確實能寫出看似合理的回覆，但看似合理不等於系統給出了正確答案。

要可靠地回答這個問題，應用程式可能需要完成以下工作：

• 找出訂單檔案 JPN-2026-0417 及其既有限制條件

• 檢索對應的合作飯店合約與航空公司費率表

• 從 PDF 合約擷取費率表與無障礙條款

• 正規化幣別、日期格式與房型代碼

• 比對合約費率與當季即時房況

• 附上佐證呈現結果，並清楚標示仍不確定的部分

單靠模型無法保證上述任何一步。這些工作仰賴存取正確的資料、依正確順序執行步驟，以及針對模型輸出的檢查。缺少這些機制時，系統就無法確認所需事實，此時應直接揭露資訊缺口，而非憑沒有根據的記憶硬湊答案。

這裡延續基礎課程建立的核心區分：

• 模型（model） 是將輸入映射到輸出的統計學習元件。

• 系統（system） 是圍繞該模型建構的完整應用程式，涵蓋資料流、編排、限制條件與評估機制。

把這兩者分開，排查故障才有頭緒。資訊過時、缺少內部資料或輸出格式錯誤，可能源自缺少必要元件、既有元件出錯，或模型本身的行為。追查根因時，應先檢視資料路徑、實際傳入的上下文與驗證結果，不能只看最終答案下定論。

定義核心術語

用可操作的工程語言定義核心術語，能讓設計審查更精準。

模型（Model）

模型是根據輸入上下文產生文字、分類、結構化欄位或其他輸出的統計元件。在本系列中通常指大型語言模型，但同樣的系統模式也可以納入 OCR 模型、版面分析模型、視覺語言模型或排序模型。

系統（System）

系統是將使用者任務轉化為結果的完整應用程式，包含模型呼叫，以及讓這次呼叫發揮作用所需的一切：輸入處理、資料存取、工作流程步驟、錯誤處理、輸出格式化與評估。

複合式 AI 系統（Compound AI system）

複合式 AI 系統是由多個互動元件組成的 AI 應用程式，而非單次單體式的模型呼叫。組成的元件可包含模型、檢索層、工具呼叫、擷取服務、確定性邏輯、驗證器，以及針對高風險操作的核准邊界（approval boundary）。核心概念在於組合式架構：整體能力取決於元件如何協同運作，而非單靠放大基礎模型規模。本教學依循 BAIR 的論述（Zaharia et al., 2024）；這套說法具影響力，但並非已確立的技術標準。

這個詞用來描述架構，不能用來預測品質。若檢索品質不佳、介面傳遞遺失資訊，或驗證邏輯本身引入錯誤，複合式系統的表現反而可能不如簡單的基準做法。

控制邏輯（Control logic）

控制邏輯是系統中決定「下一步做什麼」的部分。無論以確定性程式碼實作，或採用模型輔助路由，這層工作流程都負責協調系統，並實質影響系統行為。下一篇會詳細說明管線設計。

工具（Tool）

工具是系統可呼叫的外部能力，例如搜尋、資料庫查詢、PDF 解析、匯率換算、程式碼執行，或特定領域的訂房服務。工具使用是系統組合的一種形式，不是單靠模型本身就具備的特性。

檢索（Retrieval）

檢索是從文件庫、資料庫、訂房紀錄或已建立索引的合作合約中，為當前任務挑出相關外部資訊的過程。檢索之所以重要，是因為有用的企業級答案往往仰賴不應假定存在於模型參數內的資料。

驗證（Validation）

驗證是在接受或呈現答案前執行的明確檢查。應把驗證當成核心設計元件；後續文章會把它拆解為具體的管線檢查與工作流程契約。

狀態（State）

狀態是系統在執行過程中保留的資訊，例如當前任務階段、已選取的文件、已擷取的欄位或使用者的限制條件。本篇只用到最基本的概念：有些工作會跨越多個步驟。後續文章會更仔細地區分狀態、記憶與持久知識。

什麼算是 LLM 系統

即使是規模不大的正式環境應用程式，結構通常也比「輸入提示、輸出文字」複雜。最基本的 LLM 系統往往包含以下步驟：

1. 接收並解讀使用者請求。

2. 判斷任務是否需要外部資料或工具。

3. 收集或準備所需的上下文。

4. 在明確限定的角色下呼叫模型。

5. 檢查輸出結果是否可用。

6. 將答案格式化後交付給使用者或下游服務。

這樣的流程依然簡單，但本質上已與單一提示不同：系統有了邊界、明確的職責分工，以及可偵測故障的節點。

應用程式的能力往往屬於系統層級的特性。模型或許擅長摘要文字，但要根據內部合作合約與訂房紀錄回答問題，並附上引用出處與費率查核，靠的是整體系統。這是兩種不同的主張：前者屬於模型，後者屬於模型外圍的架構。

從單體式模型到複合式系統

許多 AI 產品早期的思路很單純：挑選現有最強的模型、把提示寫得更好，再讓模型承擔更多工作。這種做法適合實驗，但一旦任務變得知識密集、涉及合規要求或營運流程複雜，就會失靈。

架構演進的方向是走向複合式系統。團隊不再指望單次模型呼叫包辦所有問題，而是拆解職責：

• 由檢索取得相關佐證

• 由擷取將文件轉成結構化輸入

• 由確定性邏輯處理規則明確的轉換

• 由模型步驟綜合或解讀模糊素材

• 由檢查機制判定結果能否採用

這種做法並未放棄模型能力。模型仍居於核心，只是在更大的工作流程中承擔範圍更窄、更站得住腳的角色。

幾項研究展現了這個設計方向。檢索增強生成把預訓練模型的參數記憶，與從外部索引檢索到的文件結合起來；Toolformer 展示語言模型以自我監督方式，學會判斷何時及如何呼叫 API；ReAct 則讓模型產生的推理軌跡與特定任務的行動及觀察交錯進行。每項研究回報的改善，都是相對於它評估的任務與基線而言。這些結果足以支持在合適的任務上測試系統組合，但不代表系統組合在一般情況下都優於擴大模型規模。

對技術決策者而言，結論很清楚：只要使用案例仰賴即時資訊、私有資料、來源追溯、結構化輸出或可重複執行的工作流程，架構審查就必須同時涵蓋資料存取、控制邏輯與評估機制，而不能只討論選哪一個模型。

模型周圍的主要元件

具體架構因產品而異，但真實系統中反覆出現六種元件角色。

輸入與路由

系統需要先分類請求，再導向合適的處理路徑。一般概念解釋可能只需直接呼叫模型；查詢特定訂單或合作合約，大概需要檢索與佐證整理；涉及大量文件的問題，則可能要先執行擷取。

資料存取

許多高價值任務仰賴基礎模型以外的資訊，例如合作夥伴合約、訂房資料庫、PDF 協議、無障礙規格表或當前費率資訊。若系統無法存取這些資料，無論模型多強，答案品質都有上限。

擷取與轉換

在進入綜合分析前，系統可能需要先解析費率表、正規化欄位名稱與幣別，並將照片對應到房型說明或無障礙備註。這類轉換都應定義明確的輸入與驗證；提示雖能引導由模型執行的步驟，本身卻無法證明轉換結果正確。

模型推論

模型適合用在機率性解讀能發揮效益的環節，例如摘要佐證、比較選項、起草說明，或將半結構化資訊轉成目標格式。重點在於讓模型專注於擅長的步驟，而非預設把所有工作都交給它。

驗證與防護機制

系統應能拒絕或限制違反已知要求的輸出。若比較結果必須附上引用來源，缺少出處的回答就無法通過驗證；若費率欄位要求以標準幣別表示的數值，應用程式會先檢查該值，才會採信。

呈現與來源追溯

使用者常常需要看到答案從何而來、依據哪些佐證，以及哪些地方仍不確定。在旅遊規劃情境中，來源追溯往往是產品需求的一部分，而非選配功能。

授權、資安、評估、可觀測性，以及模型、提示、工具與資料的版本追蹤，都橫跨所有元件。它們是系統層級的控制，不是額外的模型能力。NIST 的生成式 AI Profile 是 AI RMF 的自願性配套文件，用於在 AI 系統的設計、開發、使用與評估中納入可信任性考量（NIST, 2024）。

完整範例：OptiVerse Travel 旅行 Copilot

接著把這套元件視角套用到 OptiVerse Travel 旅行 Copilot。

規劃師詢問：能否在櫻花季期間，以 13,000 至 15,000 美元預算為四口之家安排 10 天日本無障礙行程？京都合作飯店是否仍依合約 KYO-H12 第 4.3 條提供輪椅無障礙房型的合約價？若只靠單一模型處理，馬上會遇到瓶頸：

• 訂單 JPN-2026-0417 的內部資料不在模型權重中，也未必已放進提示上下文

• 合約 KYO-H12 可能把所需的費率佐證放在表格或條款中，而非純文字

• 同一間京都飯店在不同訂房系統可能使用不同名稱

• 價格與可訂房時段可能以不一致的格式儲存

• 規劃師需要有憑有據的回覆，而非通順的猜測

複合式系統會把這項任務拆解成職責明確的步驟。

首先，路由步驟將請求判定為需要證據錨定的比較任務，而非一般閒聊。接著，檢索模組收集候選的合作飯店合約、費率表與無障礙規格表。若關鍵佐證位於 PDF 內，擷取路徑會抽出費率表欄位、條款編號，以及作為補充視覺證據的照片集 ACC-09（單憑照片無法證明入口寬度、當下排房狀況，或是否符合特定輪椅規格）。隨後由正規化步驟統一飯店名稱與幣別，最後才交由綜合模型比對合約價與當季售價並起草回覆。

實際管線會因情境而異。結果依然是以模型為核心的 AI 應用程式，但它之所以有用，來自各元件的協同運作：

• 檢索器帶入相關佐證

• 擷取路徑把版面複雜的文件轉成結構化輸入

• 控制層維持步驟順序一致

• 綜合步驟負責解讀彙整好的佐證

• 驗證與呈現層決定哪些內容可以交付

在複合式 AI 系統中，模型並沒有被取代，而是被放進定位明確的工作流程裡。

做具體邊界測試時，可傳入 booking_id=JPN-2026-0417、contract_id=KYO-H12 與 contract_status=not_found。預期輸出應為附帶條件的提案，標示 rate_status=unverified，且不宣稱任何合約金額。即使找到合約 KYO-H12，若缺少涵蓋指定房型與日期的即時庫存確認，預期狀態仍應為 availability_unconfirmed：合約只能確立其適用範圍內的條款，本身不能證明有可用庫存，也不能證明整趟行程符合預算。

單體式思維與模組化思維

在許多情境下，把模組化架構當成「等模型變更強就能淘汰的過渡做法」，其實誤解了工程問題。

能力更強的模型或許能減少管線需要特殊處理的次數，卻無法免除對系統邊界的需求。私有資料依然需要存取控制，即時資訊依然需要檢索或其他外部來源，結構化商業流程依然需要編排，高風險用途也依然需要評估與驗證。

模組化設計也讓除錯更精準。旅行 Copilot 答錯時，團隊可以逐一縮小排查範圍：

• 是否檢索到錯誤的合約或費率表？

• 表格解析器是否漏讀了某一欄？

• 匯率換算是否套用了錯誤日期？

• 綜合步驟是否誇大了薄弱的空房佐證？

• 驗證步驟是否放過了未附出處的陳述？

若採用「只管更用力地提示模型」的單體式做法，這些問題會難回答得多。模組化系統多了介面需要維護，也不一定更簡單，但往往更容易檢視、測試與修補。

實作練習

請建立一張包含四個欄位的表格：失敗測試資料、負責元件、可觀測訊號、控制點。

先從以下範例列開始：

接著補齊以下四筆測試資料：

• 檢索到錯誤的飯店合約；

• 表格解析器漏掉無障礙房型欄位；

• 模型寫出流暢的比較結果，卻沒有條款佐證；

• 最終呈現層把建議方案標示為已確認訂房。

請勿把每一列都歸咎於「模型」。每一列都必須指定一個能發出可檢查訊號的負責元件，以及一個能阻止錯誤往下游擴散的應用程式控制點。

刻意破壞的案例

假設綜合步驟的提示寫了這段指令：

如果找不到合約 KYO-H12，請推估最可能的合作價格並繼續作答，不要提及資料缺口。

這種寫法把證據可用性、商業政策與拒答判斷全塞進單一提示文字裡。修補方式是讓檢索明確回傳 not_found 狀態、由商業政策明文禁止缺乏佐證的費率，並限制綜合步驟只能讀取通過驗證的證據資料包。提示可以向使用者說明由此產生的缺口，但不得代替缺少的權限或證據。

常見誤解與失敗模式

團隊導入複合式架構時，常反覆落入四種誤解。

誤解 1：換更好的模型就不需要系統設計

更強的模型能提升單一步驟的品質，卻無法消除架構需求。如果任務需要專有資料、佐證追蹤或 schema 保證，升級模型並不會讓這些需求消失。

誤解 2：提示工程是提升系統品質的主要途徑

清楚的提示能改善單一步驟內的行為，卻很少能取代缺少的資料路徑、解析器或驗證器。

誤解 3：只要是多步驟的 AI 工作流程就是 AI 代理

並非每個組合式系統都是 AI 代理。許多實用的 AI 產品主要是管線：由確定性控制邏輯決定執行順序，只在選定的步驟呼叫模型。後續文章會更精確地說明助理、代理與自主性邊界。

誤解 4：檢索與驗證只是選配的附加功能

對許多正式環境任務而言，檢索與驗證都是核心架構。缺少檢索，系統可能根據過時或無關的知識作答；缺少驗證，系統可能以毫無根據的自信呈現缺乏佐證的主張。

一旦忽略這些邊界，就會出現可預期的失敗模式：

• 回答仰賴外部工具的問題時，未呼叫必要工具

• 依賴過時或不完整的模型記憶作答

• 未以已授權的內部紀錄作為回答依據

• 輸出格式偏離規定的 schema 或幣別

• 在需要引用的陳述上漏掉來源追溯

• 證據不足時未執行拒答

這些問題可能出在模型、外圍元件，或兩者交接的介面。排查時應把觀察到的缺陷，對應到能攔截它的元件與控制點，而非籠統地同時怪罪模型與外圍系統。

實用的 AI 能力往往是組裝出來的：系統之所以實用，在於分離關注點，並讓每個元件承擔它確實做得到的角色。

完成標準

成果必須滿足以下所有條件才算完成：

• 每筆測試資料都有且僅有一個主要可觀測負責元件；

• 每個元件邊界都定義了可檢查的輸入與輸出；

• 缺乏依據的證據、格式錯誤的擷取結果與違反商業規則的輸出，都會在呈現前被攔截；

• 面對單純的概念解釋請求，仍保留直接呼叫模型的輕量路徑；

• 更換模型版本時，不會悄悄改變檢索、授權或驗證政策。

知識檢核

請不回頭翻閱文章，直接回答：

1. 複合式 AI 系統與單次模型呼叫有何不同？

2. 為何單靠升級模型無法解決私有資料存取問題？

3. 匯率換算日期錯誤應由哪個元件負責？

4. 實作成果中的每筆失敗測試資料都必須具備哪兩項屬性？

參考答案

1. 系統由多個互動元件組成，並透過明確的控制邊界協同產出結果。

2. 存取私有資料需要模型參數之外的身分驗證資料路徑與授權檢查。

3. 由正規化元件負責，並在進入下游綜合步驟前透過驗證器攔截。

4. 一個可觀測的負責元件，以及一個能攔截該失敗的控制點。

實作練習四列的參考對應如下：錯誤合約 → 檢索元件負責，訊號為飯店與合約識別不符，攔截該證據資料包；漏掉欄位 → 擷取元件負責，訊號為必要欄位覆蓋檢查未通過，拒絕該筆解析結果；缺乏佐證的比較 → 綜合元件負責，訊號為陳述缺少對應條款支持，不呈現該項陳述；誤標為已確認訂房 → 呈現元件負責，訊號為顯示狀態與權威訂房紀錄不符，僅呈現紀錄中的狀態。不同實作可調整檢查點位置，但可觀測訊號與攔截點必須明確。

本文不涵蓋的內容

有些任務非常單純，直接呼叫模型加上輕量格式化即可完成，無須堆疊複雜的編排框架。不過，一旦任務仰賴外部知識、結構化佐證、多步驟控制或輸出驗證，設計問題就已進入系統工程的範疇。

複合式系統也不等同於 AI 代理。代理迴圈只是 AI 系統架構中的一種控制模式，適合用在確實需要彈性多步驟決策、而非固定管線的任務。許多實用的應用程式並不是從那裡起步。

本系列接下來的方向

建立架構優先的視角後，後續文章將逐一展開各層細節。

文章 2 深入探討可靠的 LLM 管線與控制邏輯，說明如何將工作拆解為具型別契約的階段、在規則明確處保留確定性邏輯，並在綜合前攔截語意錯誤。

文章 3 聚焦於透過檢索增強生成落實證據錨定（grounding）：如何取得相關佐證、保留來源追溯，以及在證據薄弱、互相矛盾或缺漏時拒答。

更後面的篇章會進一步擴展證據邊界：當表格與版面結構承載語意時，進入具版面感知能力的文件智慧；當影像本身成為證據時，系統則進入多模態證據處理。

這些主題遵循同一項設計原則：只要任務仰賴外部證據、工具或受控操作，就把這些責任交給模型外圍職責明確的系統元件；不需要這些能力的任務，則保留直接呼叫模型的路徑。

來源與延伸閱讀

本文參考以下主要研究與實務來源：

• BAIR. "The Shift from Models to Compound AI Systems." 複合式 AI 系統的核心架構論述，說明現代 AI 應用程式如何由模型、檢索、工具、控制邏輯與驗證組合而成。bair.berkeley.edu/blog/2024/02/18/compound-ai-systems

• Lewis, P., Perez, E., Piktus, A., et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." 探討如何以檢索取得的外部證據約束生成，而非單靠模型參數的代表性論文。arxiv.org/abs/2005.11401

• Schick, T., Dwivedi-Yu, J., Dessì, R., et al. "Toolformer: Language Models Can Teach Themselves to Use Tools." 探討語言模型如何學習呼叫外部工具，作為複合式系統元件之一的參考論文。arxiv.org/abs/2302.04761

• Yao, S., Zhao, J., Yu, D., et al. "ReAct: Synergizing Reasoning and Acting in Language Models." 探討如何將語言模型的推理軌跡與行動及觀察交錯執行的參考論文。arxiv.org/abs/2210.03629

• National Institute of Standards and Technology. "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile." 生成式 AI 部署的系統層級風險、評估與可信任設計框架。nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence