今天最先進的方法很快就會變成明天的舊系統。投資於基於人工智能的 SaaS 解決方案的機構面臨著一個關鍵問題：我們如何才能確保今天實施的系統不會成為明天的技術債務？

‍

答案不在於選擇當下最先進的技術，而在於選擇建構在彈性與適應性架構上的平台，能夠隨著新興的人工智慧能力而演進。本文將分析模組化架構在人工智慧領域的不同實作，並將重點放在檢索-增強世代 (Retrieval-Augmented Generation，RAG)，並比較不同的架構方法。

‍

僵化 AI 實作的隱藏風險

許多組織在選擇 AI 解決方案時，主要以目前的功能為基礎，著重於即時功能，而忽略了決定長期適應性的底層架構。這種做法會造成數種重大風險：

技術過時

AI 創新的腳步持續加快，基本的進步在更短的時間內出現。圍繞特定 AI 方法而建立的僵化系統往往難以融入這些進展，導致與較新的解決方案之間出現能力差距。

修改業務需求

即使技術一成不變（也不會），業務需求也會不斷演進。組織往往會發現在最初實施時未曾預見的人工智慧寶貴用例。缺乏彈性的平台往往難以超越其原始設計參數。

整合生態系統的演進

圍繞 AI 解決方案的應用程式、資料來源和系統會隨著時間的推移，透過升級、替換和新增而改變。僵化的人工智慧平台往往會成為整合瓶頸，需要昂貴的變通方法或限制其他技術投資的價值。

法規與合規性變更

全球的 AI 治理要求持續演進，新法規不斷出現，對可解釋性、公平性評估和文件提出要求。沒有架構彈性的系統往往難以適應這些不斷變化的法規要求。

‍

RAG Paradigm：模組化架構的案例研究

Retrieval-Augmented Generation (RAG) 是模組化架構的絕佳範例，正在徹底改變人工智慧系統的設計與實作方式。AWS 將其定義為「優化大型語言模型 (LLM) 輸出的過程，該模型在產生回應之前會參考其訓練資料來源之外的權威知識庫」。

AWS RAG 實作

AWS 開發了一個 RAG 雲端架構，充分體現了模組化與彈性的原則。正如陳雲傑和Henry Jia在AWS Public Sector部落格中指出，此架構包含四個不同的模組：

‍

1. 使用者介面模組：透過 Amazon API Gateway 與終端使用者互動
2. 協調模組：與各種資源互動，以確保資料擷取、提示和回應生成流程順暢
3. 嵌入模組：提供存取各種基礎模型的功能
4. 向量儲存模組：管理嵌入式資料的儲存和向量搜尋的執行

處理流程遵循兩個主要路徑：

用於上傳資料：

1. 儲存於 Amazon S3 儲存桶的文件會由 AWS Lambda 函式進行分割與分塊處理
2. 文字片段會傳送到嵌入範本，轉換成向量
3. 嵌入資料會儲存在所選向量資料庫中，並建立索引

用於產生答案：

1. 使用者傳送提示
2. 提示傳送到嵌入式範本
3. 此模型可將提示轉換為向量，以便在歸檔文件中進行語意搜尋
4. 最相關的結果會傳回 LLM
5. LLM 會考慮最相似的結果和初始提示來產生回應
6. 產生的回應會傳送給使用者

AWS RAG 架構的優勢

AWS 強調此模組化架構的幾個主要優勢：

• 模組化與可擴充性：「RAG 架構的模組化特性以及基礎架構即程式碼 (IaC) 的使用，讓您可以輕鬆地根據需要新增或移除 AWS 服務。透過 AWS 管理服務，此架構有助於自動且有效率地管理增加的流量和資料請求，而無需事先進行佈建。"
• 彈性與敏捷性："模組化的 RAG 架構可更快速、輕鬆地實施新技術和服務，而無需徹底革新雲端架構框架。這讓我們能夠更靈活地回應不斷變化的市場和客戶需求"。
• 適應未來趨勢：「模組化架構將協調、生成式 AI 模型和向量儲存區分開來。單獨而言，這三個模組都是積極研究和持續改進的領域"。

向量技術：RAG 架構的核心

RAG 架構的一個重要元素是向量資料庫。AWS 指出：「由於所有資料（包括文字、音訊、圖片或視訊）都必須轉換成嵌入向量，才能讓產生式模型與之互動，因此向量資料庫在基於 AI 的產生式解決方案中扮演著不可或缺的角色」。

AWS 提供多種向量資料庫選項，以支援此彈性：

• 增加向量功能的傳統資料庫，例如 OpenSearch 和 PostgreSQL
• 專用的開放原始碼向量資料庫，例如 ChromaDB 和 Milvus
• 本機 AWS 解決方案，例如 Amazon Kendra

這些選項之間的選擇「可以由一些問題的答案來引導，例如新增資料的頻率、每分鐘傳送多少次查詢，以及傳送的查詢是否大體相似」。

‍

模型整合的 AI 架構：神經方法

AWS RAG 架構是以分散式系統跨越數個雲端服務來實作，而其他 AI 系統則採取更整合的方式，在統一的神經架構中存在模組化原則。

進階 IA 助理的案例

先進的 AI 助理，例如基於最新 LLM 模型的助理，使用類似 RAG 的原則，但在架構上有一些顯著的差異：

1. 神經整合：功能元件 (查詢理解、資訊檢索、回應產生) 整合在神經架構內，而非分佈在單獨的服務上。
2. 概念模組化：模組化存在於概念與功能層級，但不一定是物理上獨立且可更換的元件。
3. 統一最佳化：在訓練和開發階段優化整個處理管道，而非由終端使用者自行設定。
4. 深度的檢索-生成整合：檢索系統更深入地整合到生成流程中，各元件之間有雙向的回饋，而非僵化的順序流程。

儘管有這些實作上的差異，但這些系統共享 RAG 的基本原則：透過建立一個分離 (至少在概念上) 不同處理階段的架構，以相關的外部資訊來豐富語言模型，以提高準確性和減少幻覺。

‍

彈性 IA 架構的設計原則

無論採用哪種特定的方法，都有一些通用的設計原則可以促進 AI 架構的靈活性：

模組化設計

真正靈活的人工智慧平台使用模組化架構，其中的元件可獨立升級或更換，而無需變更整個系統。AWS 和整合式人工智慧系統方法都遵循此原則，只是實作方式不同。

模型診斷方法

彈性平台可維持業務邏輯與底層 AI 實作之間的分離，允許底層 AI 元件隨著技術演進而變更。這在 AWS 架構中尤其明顯，模型可以輕易更換。

API 優先設計

最具適應性的人工智慧系統優先考量的是透過全面的 API 進行程式化的存取，而非完全著重於預先定義的使用者介面。在 AWS 架構中，每個元件都會開放定義良好的介面，方便整合與更新。

連續配送基礎架構

靈活的架構需要一個可在不中斷服務的情況下頻繁更新的基礎架構。這個原則在分散式系統 (例如 AWS 架構) 和整合式 AI 模型中都有實作，只是機制不同而已。

擴充性框架

真正靈活的平台可為客戶特定的擴充提供框架，而不需要供應商介入。這在分散式系統中最為明顯，但嵌入式 AI 模型也能提供客製化的形式。

適應性與穩定性的平衡

在強調架構彈性的同時，必須認識到商業系統也需要穩定性和可靠性。平衡這些看似矛盾的需求需要：

穩定的介面合約

雖然內部實作可能會經常改變，但對外部介面維持嚴格的穩定性保證，以及正式的版本和支援政策，卻是非常重要的。

逐步改善

新功能應盡可能透過附加變更而非取代的方式導入，讓組織能以自己的步調採用創新。

受控制的更新步調

升級應遵循可預測且受控制的時間表，以平衡持續創新與作業穩定性。

未來融合：邁向混合架構

未來的 AI 架構可能會出現 AWS RAG 所示例的分散式方法與先進 AI 模型的整合式方法之間的融合。重要的趨勢已經出現：

多模式匯流

人工智慧正快速超越單一模式的處理，轉向跨模式 (文字、影像、音訊、視訊) 無縫運作的統一模型。

專業機型激增

在一般模型不斷進步的同時，針對特定領域和任務的專門模型開發也在增加，這就需要能夠協調和整合不同模型的架構。

Continuum Edge-Cloud

人工智慧處理越來越分散在從雲端到邊緣的連續線上，分散式模式在效能、成本和資料需求上可以更有效地取得平衡。

監管協調

隨著全球人工智慧法規日漸成熟，我們預期各司法管轄區的要求將更趨一致，並可能伴隨認證架構。

‍

結論：未來的迫切需要

在人工智慧這種快速演進的領域中，平台最重要的特徵並非其目前的能力，而是其適應未來進步的能力。主要根據當前能力選擇解決方案的組織往往會發現自己限制了明天的可能性。

‍

透過模組化設計、與模型無關的方法、API 第一的思維、持續部署基礎架構和強大的可擴充性等原則，優先考量架構的彈性，組織可以建立隨著技術進步和業務需求而演進的 AI 能力。

正如 AWS 所言，「產生式人工智慧的演進速度是前所未有的」，只有真正模組化且彈性的架構，才能確保今日的投資在明日快速演進的科技環境中持續產生價值。

‍

也許未來不僅屬於那些最能預測未來的人，也屬於那些能建立適應任何出現的系統的人。