從模型到複合式 AI 系統

真實 AI 產品裡的多數失敗，根本不是模型能力不夠。問題出在我們要求模型去做本該屬於更大系統的工作：擷取正確的資料、解讀混亂的文件、檢查 schema、追蹤跨步驟的狀態、為答案附上佐證。Demo 階段可以掩蓋這些問題，但一進正式環境，馬上就暴露了。

所以現代 AI 架構的正確起點不是「該用哪個模型？」，而是「這個任務需要什麼樣的系統？」對工程師和技術決策者來說，這個轉變至關重要——能力往往來自周圍的設計，而不只是模型呼叫本身。實務上，有用的 AI 應用很少只是一次模型呼叫，它們是結合了模型、資料存取、控制邏輯（control logic）、工具和驗證（validation）的複合式系統（compound system）。

這篇用一個貫穿全系列的例子來說明這個轉變：為 OptiVerse Travel 打造的旅遊 Copilot——一家專做客製化行程的中型旅行社。目標不是讓系統聽起來很自主，而是用具體案例說明為什麼模型只是更大設計中的一個元件。

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

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

我們能否在櫻花季期間，為一個四口之家規劃一趟無障礙的十天日本行程，預算控制在 13,000–15,000 美元以內？還有，我們的京都飯店合作夥伴是否仍遵守合約中的無障礙客房價格？

一個基礎語言模型可以產生看似合理的答案。但看起來合理，跟真正正確是兩回事。

要妥善回答這個問題，應用程式可能需要：

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

• 檢索相關的飯店合作夥伴合約與航空公司費率表

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

• 統一貨幣、日期格式和房型代碼

• 將合約費率與當前季節性供應狀況做比較

• 以佐證和明確的不確定性呈現結果

這些需求沒有任何一項能靠模型單獨保證。它們取決於正確的資料存取、正確的步驟序列，以及對模型輸出的檢查。如果系統不提供這些能力，模型就只能猜、從訓練資料概括推論，或在沒有來源追溯的情況下作答。

這裡有個本系列的第一個關鍵區別：

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

• 系統（system）是圍繞該模型的完整應用程式，包括資料流、編排、約束條件和評估。

釐清這個區別之後，很多常見的挫折就更容易診斷。當一個 AI 產品回傳過時的資訊、忽略內部資料庫，或用錯的格式輸出答案，問題往往不是「模型不好」，而是任務所需的系統元件根本沒被設計出來。

定義核心術語

在把這些術語用得太隨意之前，先用比較操作性的語言把幾個關鍵詞定義清楚。

模型（Model）

模型是根據輸入上下文產生文字、分類、結構化欄位或其他輸出的統計元件。這個系列裡通常指大型語言模型（large language model），但同樣的系統模式也可能涉及 OCR 模型、版面模型、視覺語言模型或排序模型。

系統（System）

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

複合式 AI 系統（Compound AI system）

複合式 AI 系統是由多個互動元件組成的 AI 應用程式，不是一次整體式的模型呼叫。這些元件可以包括模型、檢索層、工具呼叫、擷取服務、確定性邏輯、驗證器，以及針對高風險操作的核准邊界（approval boundary）。重點在組合式的架構：能力來自各元件的協同運作，而不是來自更大的基礎模型。

這個術語有用，是因為它描述了許多真實系統的現狀。不管研究還是產業實務，大家越來越傾向把高效能應用看成有明確編排的多元件系統，而非孤立的模型。

控制邏輯（Control logic）

控制邏輯就是系統裡決定「下一步做什麼」的部分。可以是簡單的確定性邏輯，也可以涉及用模型來做路由。不管哪種，它都是負責協調系統的工作流程層。流程（pipeline）設計的細節下一篇再談，這裡只需要知道：這個協調層確實存在，而且會實質影響系統行為。

工具（Tool）

工具是系統可以呼叫的外部能力。例如搜尋、資料庫查詢、PDF 解析、貨幣轉換、程式碼執行，或特定領域的訂房服務。工具的使用應該被理解為系統組合的一部分，不是模型自帶的某種神奇屬性。

檢索（Retrieval）

檢索是為任務選取相關外部資訊的過程。來源可能是文件庫、資料庫、訂房紀錄或已索引的合作夥伴合約。檢索之所以重要，是因為有用的企業級答案往往依賴不在模型參數中的資料。

驗證（Validation）

驗證是在答案被接受或呈現之前所做的明確檢查。它是一等公民的設計元件，不是事後補救。後續文章會把驗證拆解為具體的流程檢查和工作流程契約。

狀態（State）

狀態是系統在執行工作時保留的資訊。包括當前的任務階段、已選取的文件、已擷取的欄位或使用者的限制條件。這篇裡狀態只是最基本的概念——某些工作會跨越多個步驟。後續文章會更仔細地區分狀態、記憶和持久知識。

什麼算是 LLM 系統

即使是一個簡單的正式應用，結構通常也比「使用者輸入提示，模型輸出文字」複雜。一個最基本的 LLM 系統大概長這樣：

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

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

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

4. 以有限定的角色呼叫模型。

5. 檢查結果是否可用。

6. 為使用者或下游服務格式化答案。

這仍然是一個簡單的系統，但本質上已經不同於單一提示。它有邊界、有明確的職責，也有可以偵測故障的位置。

重點是：應用程式的能力往往是系統層面的特性。模型可能擅長摘要文字；但要根據內部合作夥伴合約和訂房紀錄、附上引用來源和費率檢查來回答問題——那是系統的工作。前者屬於模型，後者屬於圍繞模型的架構，兩者不能混為一談。

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

很多 AI 產品早期的思路很直覺：選最強的模型、寫更好的提示、讓模型承擔更多工作。拿來做實驗沒問題，但當任務變得知識密集、合規敏感或操作複雜時，就開始出問題了。

架構轉變的方向是走向複合式系統。團隊不再期望一次模型呼叫解決整個問題，而是把工作拆開：

• 檢索取得相關佐證

• 擷取將文件轉換為可用的輸入

• 確定性邏輯處理已知的轉換

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

• 檢查判斷結果是否可用

這不是對模型能力的退讓，而是更務實地運用它。模型仍然在核心位置，但在更大的工作流程中被賦予更窄、更站得住腳的角色。

過去幾年的研究也支持這個方向。檢索增強生成（RAG）把模型知識與外部知識存取之間的界線釐清了。工具使用的研究顯示，語言模型可以嵌入會呼叫外部函式的系統中。ReAct 風格的方法展示了模型驅動步驟與外部動作交錯執行的價值。更廣泛的系統框架——包括近期關於複合式 AI 系統的研究——讓一個趨勢越來越明顯：許多實際的效能提升來自組合，而不只是規模。

對技術領導者來說，啟示很直接：如果一個使用案例依賴資料即時性、私有資料、來源追溯、結構化輸出或可重複的工作流程，那設計討論就不能只停在「選哪個模型」。

模型周圍的主要元件

確切的架構因產品而異，但有幾個元件在真實系統中反覆出現。

輸入與路由

系統需要分類請求並導向正確的路徑。一般性的解釋型問題可能只需要模型。關於特定訂單或合作夥伴合約的問題可能需要檢索加佐證格式化。文件密集的問題可能得先做擷取。

資料存取

許多高價值任務依賴基礎模型以外的資訊：合作夥伴合約、訂房資料庫、PDF 合約、無障礙規格表或當前費率資訊。系統拿不到這些資料的話，不管模型多強，答案品質都會受限。

擷取與轉換

文件很少能直接拿來做綜合分析。費率表可能需要解析，欄位名稱在不同來源間可能不一致，貨幣可能需要轉換，物件照片可能需要連結回房間描述或無障礙備註。這些是架構層面的任務，不是靠修改提示就能解決的。

模型推論

模型用在需要機率性解讀的地方：摘要佐證、比較選項、起草說明，或將半結構化資訊轉換成目標格式。關鍵是，模型應該做它擅長的部分，而不是預設承擔所有工作。

驗證與防護機制

系統應該能拒絕或限制不符合已知要求的輸出。如果比較必須引用來源，缺少來源的答案就該失敗。如果費率欄位要求標準貨幣的數值，輸出就該先經過檢查才能被信任。

呈現與來源追溯

使用者往往不只需要答案，還需要知道答案從哪來、用了什麼佐證、哪些地方仍有不確定性。在旅遊規劃中，來源追溯通常是產品需求，不是選配功能。

實例演練：OptiVerse Travel 旅遊 Copilot

把架構轉變套用到旅遊 Copilot 上看看。

使用者問的是：能否在櫻花季期間為一個四口之家、在 13,000–15,000 美元預算內規劃一趟無障礙的十天日本行程，以及京都飯店合作夥伴是否仍遵守合約 KYO-H12 第 4.3 條中的無障礙客房合約費率。如果只靠模型來處理，馬上就碰到問題：

• JPN-2026-0417 的內部訂單資料可能不在提示的上下文中

• 相關的合作夥伴合約可能把費率佐證藏在表格或條款裡，不是純文字

• 飯店物件在不同訂房系統中可能有不同的名稱

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

• 使用者需要的是有佐證的答案，不是流暢的猜測

複合式系統可以把任務拆成更細的職責。

先由路由步驟把請求判定為需要基礎化的比較任務，而非一般聊天。接著檢索收集候選的合作夥伴合約、費率表和無障礙規格表。如果關鍵佐證埋在 PDF 中，擷取路徑會擷取相關的費率表欄位、條款參照，以及用於無障礙客房驗證的照片集 ACC-09。正規化步驟調和命名和貨幣差異。到了這一步，綜合模型才將合約費率與當前季節定價做比較並起草回應。重點不在確切的流程步驟，而在有用的行為來自協調的元件，不是一個填滿內容的模型提示。

結果仍然是一個圍繞模型建構的 AI 應用。但它有用的行為來自組合：

• 檢索器帶入正確的佐證

• 擷取路徑將混亂的文件轉換為可用的輸入

• 控制層保持序列的連貫性

• 綜合步驟解讀佐證

• 外圍系統決定輸出是否可接受

這就是複合式 AI 系統的實際意義。模型沒有被取代，而是被放在適當的位置。

整體式思維與模組化思維

你可能會想：「等模型變更強，這些不就不需要了嗎？」在很多工程情境下，這其實是個問錯的問題。

更強的模型或許能降低系統需要特殊處理的頻率，但消除不了對系統邊界的需求。私有資料仍然需要存取控制。即時資訊仍然需要檢索或其他外部來源。結構化的商業流程仍然需要編排。高風險的操作仍然需要評估和驗證。

模組化設計也提升了可除錯性。旅遊 Copilot 的答案出錯時，團隊可以提出有意義的問題：

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

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

• 貨幣轉換是不是失敗了？

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

• 驗證是不是沒抓到缺失的來源？

用整體式的「只管更努力地提示模型」做法，這些問題難以回答得多。模組化系統不一定更簡單，但通常更容易檢視、測試和改進。

常見誤解與失敗模式

向複合式系統的轉變容易被誤讀。以下幾個誤解反覆出現。

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

更強的模型有幫助，但消除不了架構需求。如果任務需要專有資料、佐證追蹤或 schema 保證，換更好的模型不會讓這些問題消失。

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

提示很重要，但替代不了架構。提示可以改善某一步驟內的行為，但很少能替代步驟本身。

誤解三：任何多步驟的 AI 工作流程都是 agent

不是每個組合式系統都具有代理性。許多有用的 AI 產品主要是帶有選擇性模型呼叫和確定性控制邏輯的流程（pipeline）。這篇刻意限縮這個區別的討論範圍。後續文章會更精確地描述助理、agent 和自主性邊界。

誤解四：檢索和驗證是可選的附加功能

對很多正式環境的任務來說，它們是核心架構。沒有檢索，系統可能從過時或無關的知識中作答。沒有驗證，系統可能以不合理的信心呈現缺乏依據的輸出。

失敗模式直接源自這些誤解：

• 在回答依賴工具的問題時沒用到所需的工具

• 依賴過時或不完整的知識

• 沒把答案基礎化在企業或私有資料上

• 產出的格式偏離所需的 schema 或貨幣

• 在需要佐證的陳述上省略來源追溯

• 系統證據不足時沒有選擇拒答

這些既是系統失敗，也是模型失敗。區分它們很重要，因為它告訴你該從哪裡下手修。

這就是這篇的核心架構教訓：有用的 AI 能力往往是組裝出來的。系統透過分離關注點、賦予每個元件一個它確實能執行的角色，來贏得實用性。

本文不涵蓋的內容

這篇不是在主張每個 AI 應用都需要複雜的編排堆疊。有些任務簡單到直接呼叫模型加輕量格式化就夠了。主張的範圍更窄：一旦任務依賴外部知識、結構化佐證、多步驟控制或驗證，你就已經進入了系統的範疇。

這篇也不是在主張複合式系統等同於 agent。Agent 迴圈是 AI 系統更廣泛空間中的一種設計模式，只有當系統需要靈活的多步驟決策時才變得相關。許多有用的應用不是從那裡起步的。

本系列接下來的方向

這個架構優先的觀點，為後續文章奠定了基礎。

下一篇會深入探討可靠的 LLM 流程與控制邏輯：怎麼把工作分解為階段、確定性工作流程在哪些場合仍然勝出，以及明確的檢查怎麼提升系統可靠性。

第三篇文章聚焦在透過檢索增強生成來做基礎化（grounding）。我們會談系統怎麼擷取相關佐證、為什麼來源追溯很重要，以及為什麼一個好的應用有時候需要說：「我不知道。」

後續文章中，佐證問題會繼續擴展：當表格、圖表和頁面結構開始變得重要，檢索就變成文件智慧問題；而當影像本身成為佐證，系統就進入多模態佐證處理的領域。

當核心轉變清晰之後，這些主題會更容易理解：現代 AI 產品不只是模型，而是圍繞模型建構的複合式系統。

來源附註

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

• 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., Dessi, 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