← 所有文章

建構 AI 系統：從 RAG 到 Agent

3分鐘閱讀

大多數團隊從 RAG 開始，發現其局限後再加上微調。兩者都能解決檢索和推理問題，但都無法解決編排問題：決定何時行動、產生多少 Agent、何時停止，以及共識的定義。我建構了一個多 Agent 討論系統（3,500 行 Python、86 個 Hook、141 個測試），同時處理這三個問題。

摘要

RAG 在查詢時檢索文件。微調則修改模型權重以納入領域資料。兩者都是檢索和推理工具，但都無法處理編排：協調多個 Agent、驗證共識，或判斷一項任務需要一次模型呼叫還是十二次。我在建構部落格品質系統時遇到了這個瓶頸——該系統需要對 33 篇文章進行平行檢查、深度評分、引用驗證和 LLM 評估。解決方案是一個 Agent 編排層，具備信心觸發的討論機制、產生預算管理和四重共識驗證。本文先探討 RAG 與微調的決策，接著深入大多數指南止步之處：當您需要 Agent 時該怎麼做。

第一部分：RAG vs 微調

2024 年 Databricks 的一項研究發現，78% 的企業 AI 團隊優先選擇 RAG，但其中 34% 後來發現微調才是更好的方案，平均浪費了 3.2 個月的實作時間。1

這個決策不是二選一，而是將技術與問題正確配對。

RAG 的優勢場景

頻繁變動的知識。 RAG 在查詢時檢索最新文件。當知識庫每天更新（產品文件、客服文章、法規申報），RAG 無需重新訓練即可提供即時資訊。2

來源引用需求。 RAG 能引用特定文件，因為檢索過程會產生明確的來源清單。在受監管的產業（醫療、金融、法律），來源引用往往是合規要求。3

大型知識庫。 一個涵蓋 1,000 萬份文件的 RAG 系統，只要檢索品質穩定，其表現與涵蓋 100 萬份文件的系統相當。微調模型則受限於模型大小的容量上限。4

微調的優勢場景

領域專屬推理模式。 RAG 提供資訊，微調提供能力。一個在醫療診斷對話上微調的模型會學習鑑別診斷模式：如何權衡症狀、何時考慮罕見疾病、如何制定追問問題。RAG 能提供醫學知識，但推理模式需要透過權重調整來實現。5

嚴格的輸出格式要求。 微調在強制結構化輸出（JSON、XML、特定 Schema）方面比提示工程更可靠。對於格式錯誤會導致下游問題的系統，微調能提供更高的可靠性。6

延遲敏感的應用。 RAG 會增加檢索延遲：嵌入查詢、搜尋向量資料庫、檢索文件、注入提示。對於目標回應時間在 200 毫秒以下的應用，透過微調消除檢索步驟可能是必要的。7

比較矩陣

維度 RAG 微調 兩者結合
知識即時性 數小時 數週至數月 數小時
建置成本 低至中 中至高 高
每次查詢成本 較高（檢索 + 生成） 較低（僅生成） 最高
來源引用 原生支援 困難 部分支援
輸出格式控制 中等 高 高
領域推理 弱 強 強
知識庫規模 無限 受模型限制 無限
延遲 較高 較低 最高
幻覺控制 較好（基於文件） 因情況而異 最好

結合兩種方法

大多數正式環境系統會結合兩種技術。在領域推理模式和輸出格式上微調模型，使用 RAG 在查詢時提供即時、可引用的知識。微調後的模型知道如何對領域進行推理，RAG 系統則提供推理的對象。8

第二部分：何時需要 Agent

RAG 和微調處理檢索與推理，但都無法處理編排：判斷一項任務需要一次模型呼叫還是十二次、何時產生平行工作者、如何驗證其輸出，以及何時升級給人類處理。

我在建構部落格品質基礎設施時遇到了這個瓶頸。我有 33 篇部落格文章需要評估、修正和驗證。每篇文章單次模型呼叫不夠用。每篇都需要檢查（12 個模組）、深度評分（5 個訊號）、可讀性分析、引用驗證和 LLM 評估。循序執行太慢，平行執行但缺乏協調則會產生衝突和不一致的結果。

解決方案不是更多的 RAG 或更好的微調，而是一個 Agent 編排層。

Agent 編排的需求

傳統的 ML 流程假設線性流程：資料、預處理、模型、評估、部署。9 Agent 系統是非線性的。一個 Agent 可能會：

  1. 評估自身信心程度，決定是否需要協助
  2. 產生 5 個具有不同專長的平行子 Agent
  3. 收集並排序它們的輸出
  4. 偵測 Agent 是否過快趨同（群體思維）
  5. 根據品質門檻驗證共識
  6. 生成最終建議

每一步都需要 RAG 和微調無法提供的基礎設施。

第三部分：我建構了什麼

架構

我的討論系統橫跨 12 個模組，共 3,500 行 Python 程式碼：

Deliberation System
├── confidence.py       Triggers deliberation based on ambiguity/complexity/stakes
├── state_machine.py    Workflow: idle → research → ranking → consensus
├── agents.py           5+ persona templates (Architect, Security, Performance...)
├── context_isolation.py  RLM L0-L3 layers prevent context contamination
├── ranking.py          Stack ranking with weighted consensus calculation
├── spawner.py          Parallel agent spawning via Task API
├── conformity.py       Detects groupthink and premature convergence
├── mailbox.py          Multi-round debate protocol
├── memory.py           Cross-session learning and persona tracking
├── scaling.py          Dynamic agent count based on complexity
├── prd_generator.py    Converts decisions into product requirements
└── observability.py    Session metrics and audit replay

該系統建立在 86 個 Hook 之上，在六個生命週期節點（PreToolUse、PostToolUse、Stop 以及其他三個）攔截操作。每次 Agent 產生、每次檔案寫入、每次 Git 指令都經過驗證。

信心觸發機制

並非每項任務都需要五個 Agent 進行討論。我建構了一個信心評分演算法，評估四個維度：

  1. 模糊性 — 查詢是否有多種合理的解讀？（模式匹配：「最佳方式」、「是否應該」、「比較」、「優缺點」）
  2. 領域複雜度 — 是否需要專業知識？（模式匹配：「架構」、「安全性」、「效能」、「資料庫 Schema」）
  3. 風險程度 — 決策是否可逆？（模式匹配：「正式環境」、「破壞性變更」、「刪除」、「安全漏洞」）
  4. 脈絡依賴性 — 是否需要理解更廣泛的系統？

分數對應三個等級：

  • 高（0.85 以上）： 無需討論直接執行
  • 中（0.70-0.84）： 執行但記錄信心備註
  • 低（0.70 以下）： 觸發完整的多 Agent 討論

門檻根據任務類型調整。安全決策需要 85% 共識，文件變更只需 50%。這能避免對簡單任務過度設計，同時確保高風險決策獲得充分審查。

產生預算問題

我的初版實作使用基於深度的遞迴限制：深度 0 的 Agent 產生深度 1，深度 1 產生深度 2，深度 3 時被阻擋。這立刻失敗了。討論 Agent 需要平行執行，而非串列執行。深度 1 的五個 Agent 不是深度遞迴，而是廣度協作。

修正方案：產生預算模型。根 Agent 獲得一個預算（最多 12 個 Agent），然後花費該預算產生平行工作者。工作者繼承剩餘預算，但不能超支。這既防止了失控的連鎖反應，又允許討論所需的平行執行。

實際測試是在翻譯部落格文章時執行 10 個審查 Agent。遞迴保護機制阻擋了第 4 到第 10 個 Agent，因為它將產生計為深度遞增。切換到預算模型後，全部 10 個 Agent 成功執行。深度從未超過 1，寬度則擴展以配合任務需求。10

共識驗證

Agent 完成後，一個後討論 Hook 執行四項檢查：

  1. 階段就緒性 — 討論是否已從研究階段進入排序階段？
  2. Agent 法定人數 — 是否有至少 2 個 Agent 完成？（可按任務類型設定）
  3. 共識門檻 — 一致性是否達到要求的水準？（基準 70%，安全性為 85%）
  4. 異議記錄 — 如果 Agent 之間有分歧，是否記錄了相關疑慮？

第 4 項是我意料之外的洞察。早期執行產生的「共識」只是 Agent 簡單地同意第一個回應。從眾偵測器現在會標記過早趨同：如果所有 Agent 在第一輪就以高相似度分數達成一致，系統會強制進行第二輪對抗性分析。

從實戰中學到的教訓

原子檔案寫入很重要。 多個 Agent 同時寫入同一個狀態檔案會損壞 JSON。修正方案：先寫入 .tmp 檔案，再用 mv 進行原子操作。作業系統保證同一檔案系統上的 mv 是原子操作。這個一行程式碼的改動消除了一整類競態條件。

脈絡隔離防止群體思維。 每個 Agent 透過四個層級接收獨立的脈絡（L0：基礎知識、L1：任務特定、L2：角色特定、L3：輪次特定）。沒有隔離時，Agent 會趨向第一個看似合理的答案，而非探索解決方案空間。有了隔離，安全 Agent 和效能 Agent 會得出真正不同的結論，因為它們的出發假設不同。

測試 Agent 基礎設施比測試應用程式碼更難。 系統有 141 個測試：48 個 Bash 整合測試用於 Hook 行為、81 個 Python 單元測試用於程式庫模組，以及 12 個端對端流程模擬。我的專案記憶中每一個失敗案例（產生預算阻擋、引號偵測誤報、部落格計畫檔案被意外當成文章提供）都在修復後成為測試案例。Agent 的錯誤比應用程式錯誤更難重現，因為它們取決於時序、順序和並行狀態。

人類與 Agent 的分工

人類的職責 Agent 的職責
問題定義 流程執行
信心門檻設定 在門檻內執行
共識要求 共識運算
品質關卡標準 品質關卡執行
錯誤分析 錯誤偵測
架構決策 架構選項提供
領域脈絡注入 文件生成

模式：人類負責需要組織脈絡、倫理判斷或策略方向的決策。Agent 負責需要在大量可能性空間中進行運算搜尋的決策。11 我在 Agent 架構分析中進一步探討了這種分工。

智能 ML 工程師不再手動編寫流程，而是定義目標、約束條件和評估標準。Agent 負責實作迴圈：提案、執行、評估、迭代。人類的角色從建造者轉變為架構師：設定護欄、審查輸出，並做出需要 Agent 所缺乏的領域脈絡的判斷。12

重點摘要

給開始建構 AI 系統的工程師： - 對於涉及頻繁變動知識或來源引用需求的使用場景，請從 RAG 開始；RAG 能在數天內提供可運作的基準，而微調需要數週的資料準備 - 當應用需要領域推理和即時知識時，結合 RAG 與微調 - 如果每項任務需要不止一次模型呼叫，您就需要 Agent 編排——這與 RAG 或微調是完全不同的工程問題

給建構 Agent 系統的團隊： - 在建構 Agent 之前先建構信心評分；大多數任務不需要討論，而知道何時使用 Agent 的系統比 Agent 本身更有價值 - 對於平行 Agent 架構，使用產生預算而非深度限制；深度限制會阻擋 Agent 討論所需的廣度協作模式 - 測試共識品質，而非僅測試共識是否存在；過早的一致比沒有一致更糟糕，因為它會產生虛假的信心

參考文獻

  1. Databricks, “State of Enterprise AI Architecture,” Databricks Research, 2024. ↩

  2. Lewis, Patrick et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,” NeurIPS 2020. ↩

  3. Gao, Luyu et al., “Precise Zero-Shot Dense Retrieval without Relevance Labels,” ACL 2023. ↩

  4. Borgeaud, Sebastian et al., “Improving Language Models by Retrieving from Trillions of Tokens,” ICML 2022. ↩

  5. Singhal, Karan et al., “Large Language Models Encode Clinical Knowledge,” Nature, 620, 172-180, 2023. ↩

  6. Hu, Edward J. et al., “LoRA: Low-Rank Adaptation of Large Language Models,” ICLR 2022. ↩

  7. Miao, Xupeng et al., “Towards Efficient Generative LLM Serving: A Survey from Algorithms to Systems,” arXiv:2312.15234, 2023. ↩

  8. Anthropic, “RAG + Fine-Tuning: A Practical Architecture Guide,” Anthropic Cookbook, 2024. ↩

  9. Sculley, D. et al., “Hidden Technical Debt in Machine Learning Systems,” NeurIPS 2015. ↩

  10. Author’s experience building multi-agent deliberation infrastructure, documented in project MEMORY.md. 86 hooks, 141 tests, 12 Python modules. ↩

  11. Sambasivan, Nithya et al., “‘Everyone Wants to Do the Model Work, Not the Data Work’: Data Cascades in High-Stakes AI,” CHI 2021, ACM. ↩

  12. Hollmann, Noah et al., “Large Language Models for Automated Machine Learning,” arXiv:2402.08355, 2024. ↩