編者按： 大模型的出現為構建更智能、更復雜的人工智能系統帶來了新的契機。然而，單一的大模型難以應對現實世界中錯綜復雜的問題，需要與其他模塊相結合，構建出復合人工智能系統（Compound AI Systems）。

本文作者深耕人工智能領域多年，洞見獨到。文中系統性地介紹了四種常見的 Compound AI Systems 部署模式：RAG 系統、Conversational AI 系統、Multi-Agent 系統和 CoPilot 系統。作者闡明了這些部署模式的工作原理、模塊間的交互方式，并深入探討了“Agentic”理念、模塊化設計的優勢等核心概念，為讀者構建 Compound AI Systems 提供了寶貴的理論經驗。相信通過學習本文，讀者們能夠對如何構建 Compound AI Systems 有更深入的認識，為后續的工程實踐奠定扎實的基礎。

作者 | Raunak Jain

編譯 | 岳揚

如何使用開源工具構建可根據特定需求定制的工作流（configurable flows）和由多個不同模塊組合而成的復合人工智能系統（compound AI systems）。

01 什么是 compound AI systems ？

最近，伯克利大學（Berkeley）的研究人員撰寫了一篇文章《The Shift from Models to Compound AI Systems》，他們在這篇文章中梳理了 LLM apps 的發展進程，并強調complex pipelines 具備不斷發展和演化的特性，這些 pipelines 由多個組件共同協作來構建智能系統（intelligent systems），而非依賴于某一個閉源模型。雖然最終的 compound AI systems 可能使用的底層模型（如 GPT4）相同，但是根據不同的具體提示詞（prompting）和上下文（context），系統中的各個組件可能會被視為是不同的組件。

Compound AI systems 在現實場景的一些常見落地部署模式如下：

1. RAG（檢索（retrieval）和理解（understanding）至關重要—— 具有模擬人類思維過程或根據先前的學習產生新的想法、根據邏輯、規則或先前的知識進行推理和分析、閱讀相關背景信息的能力，他們可以 self-reflect （譯者注：分析自己的運行方式、決策過程或者與用戶交互的方式，并據此進行調整或改進）并嘗試通過分析語境、推理、模式識別等方式理解用戶的意圖，并作出相應的模型響應或行為。在這種情境下，最理想的配置或解決方案是使用 Agent Assist System 。（譯者注：利用人工智能技術，如自然語言處理、推薦算法等，來分析和理解用戶的需求，并根據這些需求為用戶提供幫助。）當與面向用戶的模型/系統（如對話模型）結合使用時，RAG 系統可以成為 Conversational AI 或 CoPilot system 的一部分。
2. Multi — Agent Problem Solvers（各個 Agent 通過扮演不同的角色進行協作來共同解決問題至關重要） —— 這些系統中的各個 Agent 都有明確定義的角色和目的，相互協作，根據彼此的輸出，自動構建解決方案。每個 Agent 都能使用自己的一套工具，并且在推理（reasoning）和規劃自己的行為時（planning it’s actions）可以承擔非常明確具體的角色。
3. Conversational AI（對話（dialogue）是關鍵）—— 自動化軟件（automation softwares）（例如客戶服務 agents）可在應用程序/生態系統（app / ecosystem）內與人類進行交互，并可根據系統接收的數據或信息、以及對這些數據的驗證執行可以反復進行的任務。這種部署模式最重要的是 conversational memory（譯者注：系統進行對話時記憶和保留的信息）和 dialogue generation（譯者注：系統能夠自動地生成對話文本，以回應用戶的 query 或提出新的對話話題），使得用戶感覺在與一個人類進行對話。對話模型（Dialogue Model）可以訪問底層的 RAG 系統或 Multi-Agent problem solver 。
4. CoPilots（人機交互界面是關鍵）—— 借助系統內提供的工具、用于分析、學習或支持決策的數據、系統具備的推理和規劃能力以及專業的配置文件，這些系統可以獨立地與人類互動，同時通過一系列固定的步驟或規則來解決有明確的、已知的解決方法的問題。要想部署一個成功的 CoPilot ，關鍵在于能否理解人類的工作環境。例如 MetaGPT Researcher: Search Web and Write Reports[1]，A measured take on Devin[2]，Let’s build something with CrewAI[3]，Autogen Studio[4]。

注意事項： 根據我部署完成幾個集成 LLM 的系統后獲得的經驗，我可以肯定地說，這些系統并非每個人都想要的萬能解決方案（silver bullet） 。和其他 AI System 一樣，我們需要圍繞 LLM 進行大量的工程設計，才能讓它們能夠完成基本任務，即便如此，這些系統也不能保證性能完全可靠且具備可擴展性。

光明大道： LLMs 在軟件生態系統（ecosystem）中的主要價值在于賦能機器學習的應用和發展（enable Machine Learning），即識別出系統存在的問題、缺陷或哪些地方存在進一步改進的空間，并將數據反饋回流至系統中重新學習，幫助系統不斷地優化和適應用戶需求。 想象一下，是否可以使用 LLMs 自動化標注數據或減輕標注員的工作負擔。在 closed systems （譯者注：這種系統的內部數據不與外部環境進行交換或交互。）中，我們可以測試和評估 LLM 的輸出內容，它可能在執行任務時表現出令人出乎意料的能力！但相應需要付出的代價也很大，不過這個過程會產生大量的數據，這些數據可以用來改進和訓練 LLMs 。

: )

LLMs 能夠通過不斷地分析和處理數據，并將這些數據反饋回系統，從而使系統能夠不斷地學習和改進，這是 LLMs 帶來的最大價值。

02 復雜系統中各組件間的交互機制及其構筑途徑

Compound AI systems 通常將這些“模塊”相互連接，讓他們共同協作。這些模塊都能夠完成某一些特定任務（certain tasks），它們相互依賴，根據需求被動態地組合和調整，執行預定義的設計模式（design patterns）。

此處的“模塊”指的是系統中的單個組件，這些模塊具有清晰而明確定義的功能或任務，它們能夠獨立執行這些任務，也可以在需要時在搜索引擎、LLM 等 underlying system 的支持下完成任務。一些常見的“模塊”包括數據生成器（generator）、數據檢索器（retriever）、數據排序器（ranker）、數據分類器（classifier） 等，在 NLP 領域中，它們通常統稱為 tasks 。這些都是針對特定領域的概念抽象（例如，NLP 模塊的抽象模塊可能與計算機視覺領域或推薦系統領域不同，但它們可能都依賴于相同的底層模型服務或搜索引擎）。

圖 1 ：“模塊”的關鍵組成部分

圖 2 ：其他通用模塊

在人工智能主流文化中，大家習慣使用像 “Tools[5]”、“Agents[6]”、“Components[7]” 這樣的術語，這些都可以被視為“模塊”。

03 基于 LLM 的 Autonomous Agents —— Compound AI systems 中的關鍵模塊

還有一種“模塊”的形式是 Autonomous Agent[8] （譯者注：這種 Agent 能夠自主對環境進行感知、分析和響應，無需持續的人類干預。），它可以在 LLM 的幫助下自主進行推理（reason）和規劃（plan）。Autonomous Agent 可以依賴一系列子模塊來決定在與環境交互時如何推理和規劃行為。

source: ??https://arxiv.org/pdf/2401.03428.pdf??

3.1 Autonomous Agent 子模塊的主要技能：

Agent 能夠使用其推理能力來思考和分析問題，然后形成一系列相關的思考步驟，最終制定出一個行動計劃來解決問題或實現目標任務。

• 推理（Reasoning）—— 通過觀察、提出假設并基于數據進行驗證等邏輯方法來解決問題。
• 思考（Thought）—— 是對推理（Reasoning）的應用，生成連貫的因果關系。
• 思維鏈（Chain of thought）—— 將一連串相關的思考過程串聯起來，通過逐步進行推理和邏輯分析，將整個解決方案分解為一系列有序的推理步驟。
• 規劃（Planning）—— 這是一種一種決策過程，需要制定具體的子目標，對可用的選項進行評估和比較，以確定達到目標的最佳路徑。通常需要訪問 underlying environment 以制定更有效的決策方案和行為計劃，并通過與環境的互動，從經驗中學習。點擊此處[9]了解更多有關 LLM Planning 的信息。
• 工具（Tools）—— 這是讓 Agent 能夠根據指令與外部世界（譯者注：external world，可指人類所處的自然環境、計算機程序所運行的操作系統或網絡環境、機器人所處的物理空間，或者其他外部環境。）進行交互的子模塊。
• 行為（Action）—— 顧名思義，這是 Agent 在通過規劃（Planning）實現目標時所采取的決定性步驟。在執行某個行為（Action）之前，可能需要調用一個工具（Tools）來觸發或執行該行為（Action），行為（Action）可能會影響到環境（Environment）的狀態，也可能可能會受到環境（Environment）的影響（Actions are made in the environment）。
• 環境（Environment）—— external world 是行為（Action）和獎勵（Rewards）的來源，如根據特定需求或要求定制開發的應用程序（如Microsoft Word、Coding Environment）或者游戲環境，甚至是物理世界模擬環境等。

3.2 這種技術是不是只是“Stochastic Parrots（隨機鸚鵡??）”

注意：雖然有很多理論研究都在探討 LLMs 缺乏推理和規劃能力這一問題，可以參考這兩篇文章[10][11]，但很明顯，大語言模型可以很好地像鸚鵡一樣學舌，說出“解決問題的方法”。這意味著，如果給定一個要解決的問題，并給出一些以前關于這個問題的解決方案，那么 LLM 就可以很好地復制這個邏輯思考過程。至于這樣能否實現泛化，在此我們就不關心了，但正如 Yann Le Cunn 所說，自回歸模型是注定要失敗的[12]！

而在企業環境中，需要的只是可靠地重復任務，并從以往的經驗中學習，而不需要太多創造性能力。

3.3 這些“鸚鵡??”究竟是如何規劃任務解決流程的？

根據這篇 survey [9]，LLM 似乎能夠通過以下方式有效地為 Autonomous Agents 賦能：

• 分解任務解決步驟（Task decomposition）—— 現實生活中的任務通常復雜且步驟繁多，給解決方案的規劃帶來了極大的困難。這種方法采用分而治之的思想，將復雜的任務分解為多個子任務，然后按順序對每個子任務進行規劃，如 TDAG[13]。
• 生成多種備選解決方案（Multi-plan selection）—— 這種方法側重于引導 LLM 多“思考（think）”，為目標任務生成各種備選計劃。然后采用與目標任務相關的搜索算法（比如 ReWoo），來挑選一個要執行的方案。
• 利用外部模塊來輔助進行規劃（External module-aided planning）—— 也就是從存儲的計劃庫或歷史記錄中檢索出以前制定的計劃或解決方案（plan retrieval）。
• 反思和完善（Reflection and Refinement）—— 這種方法論強調通過反思和完善來提高方案規劃能力。鼓勵 LLM 對失敗進行反思，然后不斷完善解決方案的規劃。
• 通過額外的存儲模塊來增強解決方案的規劃。（Memory-Augmented Planning）—— 這種方法通過額外的存儲模塊（memory module）來增強解決方案的規劃能力，存儲模塊中存儲了各種有價值的信息，如常識性知識（commonsense knowledge）、以往的寶貴經驗（past experiences）、特定垂直領域知識（domain-specific knowledge）等。

《Understanding the planning of LLM agents: A survey》[9]

如何訓練前文提到的各種能力，特別是針對 RAG 這種模式？欲了解更多，請參閱《Fine-tuning LLMs for Enterprise RAG — A design perspective》[14]，深入了解。

通過 module abstraction （譯者注：module abstraction，將系統中的各種功能和能力抽象成獨立的模塊，以便于對其進行訓練、優化和整合。）的方式，我們可以開發不同的設計模式（design patterns）來解決對話式 AI（Conversational AI）、RAG（檢索增強生成）系統和 CoPilot 系統在處理復雜問題時面臨的挑戰。

04 Compound AI systems 的設計模式

4.1 閱讀本節需要掌握的相關概念或相關術語

由于當下人工智能領域存在著一種類似于 “pop culture”（譯者注：更加通俗化、商業化、娛樂化，并被大眾廣泛接受和追捧的文化形態，貼近普通大眾的生活方式和審美趣味。） 的氛圍，導致一些術語被曲解和誤解，因此在進一步討論之前需要先澄清、闡明一些概念。

1). 什么是 “Agentic” 模式？

Autonomous Agent 的核心優勢在于它可以自行決定采取何種流程來完成任務。如果我們必須手動定義任務流程（manually define a flow）或進行決策（decisions），那么它只是一個 intelligent workflow （譯者注：與傳統的工作流程相比，intelligent workflow 能夠根據輸入的數據和條件自動進行決策，并且可以根據反饋和學習不斷優化和改進執行過程。）。但如果系統的處理流程沒有被預先定義，而是通過利用前面提到的那些能力（分解任務解決步驟、生成多種備選解決方案等），綜合使用各種工具（tools）和行為（actions），實現自主決策，那就屬于 “Agentic” 模式。 例如，在 Agentic RAG 中，模塊可以訪問搜索工具，并自動生成復雜的搜索流程，而無需任何預定義的處理步驟。

2). 什么是 "工作流（workflow）"？

簡單地說，workflow 就是指在執行之前，已經事先編寫并手動指定了所有的步驟、決策和操作，以可預測和可重復的方式解決問題。

3). 什么是 "multi-agent"？

在一個 AI 系統中，不同的模塊承擔不同的角色和責任，相互影響，根據彼此的輸出結果協同解決問題[15]。

4.2 選擇合適的設計模式前的需要考慮的因素

要抽象出并定義可用于開發 RAG 、 Conversational AI （對話式人工智能）、CoPilots （譯者注：協作式的人工智能系統，能夠輔助人類完成工作的伙伴或助手。）和Complex Problem Solvers （譯者注：具有一定智能和學習能力的系統或 Agent ，能夠處理各種復雜的現實世界問題，并提供有效的解決方案。），我們需要提出以下問題：

1). 模塊之間的工作流程是明確預先定義好的（well defined）還是由系統自主決定的（autonomous）？即為 Engineered flow（譯者注：經過工程化設計的工作流程，可能是根據先前的實踐經驗進行規劃和優化的） vs Agent System（譯者注：由多個 Agent 組成的系統，這些 Agent 之間可能相互交互、協作或競爭，為了實現某個目標或解決某個問題共同奮斗。）。

2). 工作流程是定向的（directional）還是通過“消息傳遞機制（message passing）”進行通信和協作的？系統中各模塊是合作性的（co-operative）還是競爭性的（competitive）？參考Agent Modulo[10]

3). 工作流程是否可自學習（self learnable）？自我反思（self-reflection）和修正（correction）功能是否重要？

• 系統是否能夠通過推理（reasoning）得出結論，并采取相應的行為（action）來執行任務。
• 模塊之間是否可以相互影響？

4). 系統的每個組件或模塊生成的結果是否可以在實際環境中進行驗證和評估？

5). 在工作流程的執行過程中是否會保存一些信息或上下文，并且用戶的輸入可能會影響工作流程的執行路徑或執行結果。

05 部署模式 1 —— RAG / 對話式 RAG

下面這張圖片展示了 RAG 系統 / 對話式 RAG 系統中各模塊的主要功能職責。RAG / 對話式 RAG 過去被歸類為信息檢索（IR）領域，最初通過神經搜索（Neural Search）、知識圖譜（Knowledge Graphs）進行改進，后面才是基于 generative loop（譯者注：通過反復生成文本或其他類型的輸出，并根據生成結果的反饋進行調整改進，不斷提高系統性能。） 的方法（使用 LLMs）進一步提升。Conversational IR[16] 是當信息檢索（IR）和對話系統（Dialogue systems）融合在一起時，這種系統的另一個視角。在這種視角下，queries（譯者注：用戶想要獲取所需信息或服務時向系統發出的請求或命令。） 被視為在對話過程中會發生變化的上下文對象（contextual objects）。

要讓 RAG 系統取得成功，關鍵是要理解用戶的 query ，并將其映射到底層知識（結構化的或非結構化的），然后將其與合適的指令性指導內容（instructions）一起反饋給生成器（Generator）/對話管理器（Dialogue Manager）。 這些都可以使用明確定義的工作流程來執行，或者使用 Agent 模塊，由其動態決定要執行哪些步驟（在下一節中將更詳細地闡述）。

RAG 的工作流程，與對話管理器（Dialogue Manager）交接 —— 如果對話管理器是一個 Agent，RAG 就可以算做是一項工具

讓我們來看一些中間模塊 / 工具（intermediate modules / tools），它們可以讓 Agent 在這個復雜的 RAG 世界中游刃有余。

5.1 Query的理解與重構

Query expansion / Multi — query 技術

當使用傳統的倒排索引和查詢-文檔匹配方法的檢索器和基于統計模型的檢索器（sparse and statistical retrievers）時，利用 LLMs 來擴展 query[17] 可以改善檢索結果。

Query rewriting / Self — Query 技術

自查詢檢索器（self-querying retriever）顧名思義，就是具有 query itself 能力的檢索器（譯者注：這種檢索器能夠使用自然語言構建 query 并使用，而非依賴于外部數據源或其他系統。）。具體而言，對于任何自然語言 query ，檢索器都會使用語言模型來理解 query ，并將其轉換為結構化的 query ，然后將該結構化的 query 應用于其底層 VectorStore（譯者注：用于存儲這些向量表征的數據結構）。這樣，檢索器不僅能使用用戶輸入的 query 與存儲文檔的內容進行語義相似性比較，還能從用戶 query 中提取出存儲文檔元數據的過濾條件（filters），并使用這些過濾條件（filters）對存儲的文檔進行篩選。

Entity recognition 技術

（譯者注：能夠從自然語言文本中識別出實體并進行分類，如人名、地名、組織機構名等。有助于理解用戶意圖，為后續的信息提取、關系抽取等任務提供幫助。）

5.2 Query Enrichment

（譯者注：利用外部知識源（如知識庫、語料庫）來補充和擴展原始 query，從而獲得更豐富、更具語義的 query ，從而更好地匹配文檔庫中的內容，并提高搜索結果的相關性和準確性。）

5.3 Knowledge or Intent retrieval

Multi — Document Search 技術

（譯者注：能夠同時跨越多個語料文檔進行復合檢索，獲取更全面的信息，應對復雜的 query 。）

Dialogue Management 技術

（譯者注：對話管理模塊需要追蹤對話狀態、上下文，決策對話的下一步走向，盡可能保證交互的自然與連貫。）

Response Generation 技術

（譯者注：生成高質量、連貫的自然語言響應，回答用戶的 query 。包括從事先定義的模板中選擇合適的回復、使用自然語言生成模型生成文本、基于規則或模式匹配生成模型響應等方法。）

5.4 Agentic RAG

Agentic RAG 是一種設計模式，這種模式擁有一個由 LLM 驅動的模塊，能夠根據其可用的工具集來推理和規劃如何回答問題。在具有更多挑戰和復雜性的情況下，我們還可以連接多個 Agent ，以創造性的方式解決 RAG 問題，這些 Agent 不僅可以檢索內容，而且還具有驗證（verify）、總結（summarize）等功能。有關此內容的更多信息，請參閱 Multi — agent 部分。

需要細化的關鍵步驟和關鍵組件包括：

• 規劃（Plan）應基于推理（reasoning）、將大任務分解為子任務，并系統性地安排執行順序。
• 根據自身的知識和相關約束條件，檢查輸出結果是否與事實存在矛盾或不一致的地方（self-consistency），并進行自我校正，生成多條備選路徑并融入規劃機制（planning）的 RAG 方法（如ReWoo和Plan+）工作效果更優于單純依賴推理（reasoning）但缺乏規劃（planning）的方法（如ReAct）。
• 根據執行情況動態調整的能力，體現一種去中心化、模塊化、動態交互的 “multi-agent” 設計理念。

通常使用下文所述模式（patterns）來執行這些操作。

5.5 Reasoning based Agentic RAG 基于 Agentic RAG 的推理方法

相關論文：??https://arxiv.org/pdf/2210.03629.pdf??

系統通過對可用的搜索工具進行推理和分析，然后根據推理結果采取相應的行為來解決問題或完成任務。

5.6 Planning based Agentic RAG 基于 Agentic RAG 的解決方案規劃方法

相關文檔：??https://blog.langchain.dev/planning-agents/??

相關論文：??https://arxiv.org/abs/2305.18323??

與 ReAct 方法相比，ReWoo 這種 RAG 方法在生成輸出時能夠產生更精簡、高效的 token 序列，有效提高計算效率、避免冗余，但信息量可能會有所折損。

有關 ReAct 為何比 ReWoo 糟糕的更多詳情，請參閱此文[18]。

相關論文：??https://openreview.net/forum?id=4sajV6NEnWE??

它由兩部分組成：首先制定解決方案，將整個任務劃分為較小的子任務，然后按照規劃的解決方案執行子任務。

相關論文：??https://arxiv.org/abs/2305.04091??

06 部署模式 2 —— 對話式人工智能（Conversational AI）

傳統上，對話流程（conversational flows）的高度腳本化的“機器人說”->“人類說”->“機器人說”......這種形式，假設可能發生的各種不同現實場景（hypothetical real world scenarios），Rasa 開發人員稱之為“故事（Stories）”。根據用戶的狀態和互動情況，每個用戶的意圖都可以表達為上百個“故事（Stories）”（譯者注：Stories 指預定義的對話場景或交互模式），機器人會采取相應的行為（actions）執行定義的故事（story），并以預制的回復進行回應。例如，如果用戶想訂閱一份時事通訊（newsletter），可能會出現兩種情況：

• 用戶已訂閱
• 用戶未訂閱

source: ??https://rasa.com/blog/designing-rasa-training-stories/??

如果用戶輸入 “How do I subscribe to the newsletter（如何訂閱通訊）” 被機器人識別而觸發了預定義的用戶意圖（intent），機器人需要檢查用戶是否已經訂閱，然后采取合適的下一步措施。這種 “what to do next（下一步應該做什么）” 的決策是人工預先設置的一條 path （譯者注：用于引導系統如何處理用戶的不同意圖或請求，以及如何生成相應的模型響應。）。如果偏離了這條路徑，機器人應該說，“Sorry, I am still learning, I can help you with xyz..（抱歉，我還在學習中，我可以幫你處理 xyz..）”。

構建和維護機器人真正需要耗費的成本來自于這些“stories”（譯者注：預定義的對話場景或交互模式）。之所以要采用上述這種繁瑣乏味的模式，是為了讓機器人能夠應對各種多樣的現實世界場景，并且可以有組織的、有條不紊地添加新的路徑 path （譯者注：用于引導系統如何處理用戶的不同意圖或請求，以及如何生成相應的模型響應。）。但是，path 的編寫者始終將一些“需要檢查的條件”、“需要執行的操作”和“發起對話時希望達到的最終狀態或結果”放在腦海中，從而有目的性地執行腳本。

有了 LLMs，我們可以嘗試使用 LLMs 的“推理（Reasoning）”和“規劃（Planning）”能力來自動化完成腳本的編寫或行為路徑的規劃（[19]可以了解更多信息），并在 loop system（譯者注：系統不斷地接收用戶的輸入并生成相應的模型響應，然后等待下一輪用戶輸入。這種系統可以用于持續地對話交互，直到達到預設的結束條件或目標。） 中加入強大的人工智能。

假設你是一個用于客戶服務的 Agent，一位用戶向你提出同樣的請求 —— “我該如何訂閱你們的服務？”，你會如何決定接下來應該采取什么行為？是否可以在沒有明確定義的約束條件下進行？很可能不行，但為了控制成本，也不能像上面那樣大量編寫腳本。如果我交代給你如下內容：

Condition — if email exists, user can subscribe

（如果輸入的電子郵件是存在的，用戶可以訂閱）

Tools — check_subscription, add_subscription

（檢查訂閱功能、添加訂閱功能）

如果你有能力和信心思考出解決方案并付諸行動，你應該能夠在腦海中編織出像下面這樣的 stories ：

• 用戶想要訂閱服務：基于用戶的陳述 — “我要如何訂閱？”
• 詢問用戶的電子郵件信息：“請問您的電子郵件是什么？”
• 如果他提供了有效的電子郵件，觸發調用工具 —— check_subscription
• 如果該用戶尚未訂閱，則觸發調用 add_subscription
• 反饋訂閱成功或訂閱失敗。

這就是我們希望 LLM 做的事情，即生成 "計劃"，將其作為藍圖并在系統運行時執行。有關 planning 和 reasoning 的更多信息，請點擊此處[18]了解。

回過頭看看該模塊化系統的藍圖，讓我們看看規劃器（planner）是什么樣子的：

上面的規劃器（planner）可以在設計時或運行時使用工具（tools）和約束條件（conditions）來構建 plans 或 stories。讓我們看看研究中的一個真實例子：

相關論文：??https://arxiv.org/abs/2403.03101??

KnowAgent: Knowledge-Augmented Planning for LLM-Based Agents, ??https://arxiv.org/pdf/2403.03101.pdf??

有一些工具可以幫助規劃器（planner）以可靠的推理方式決定運行路徑（path），其中包括：

• 通過查看先前類似語句所觸發的運行路徑（path）和行為，規劃器（planner）可以借鑒以前的經驗，并根據這些信息來決定當前的運行路徑（path）。
• 建立企業級的行為圖譜（Enterprise graph of actions）以及各種行為（actions）之間的依賴關系。這有助于規劃器確定某個行為是否會產生預期的結果，從而決定下一步該選擇采取什么行為，如此反復，遞歸地解決問題。有關知識圖譜（knowledge graphs）和行為規劃（planning）與 Neo4J 和 Langchain** 在現實世界中的整合，請參考閱讀此文，但不一定與行為路徑的規劃（planning paths）相關。
• 了解用戶或對話的當前狀態可以幫助規劃器（planner）根據當前情況做出決策，并相應地調整行為路徑或相應的規劃。

07 部署模式 3 —— Multi — Agent

multi-agent 的配置、優化目標是：為那些由大語言模型驅動的生成器模塊（generators）明確定義其角色和職責，并為不同的 Agent 模塊提供定制化的功能支持，使它們能夠協同工作，最終給出智能的答復/解決方案（answer / solution）。

由于角色設定（roles）和基礎模型（underlying models）定義明確，每個 Agent 都可以將某一個子目標或“行為規劃”的一部分委托給“專家”（譯者注：Expert，指系統中在特定領域或任務上具有專業知識或專長的某個模塊、算法或特定功能），然后使用輸出結果來決定下一步該做什么。更多相關詳細信息，請參考文章結尾處的 GPTPilot 示例。

相關論文：??https://arxiv.org/abs/2401.03428??

上面提到的那些模式（patterns），是通過使用以下的通信模式（communication patterns）來執行的，這些通信模式控制著在行為執行鏈（chain of execution）中定義下一行為步驟的權限。更多詳情，請參閱 “協調代理系統”（Orchestrating Agentic Systems）[20]。

在構建面向現實世界應用的協作智能體（CoPilots）系統時，不同的智能體/模塊是如何進行通信和協作的。??https://arxiv.org/pdf/2402.01680v1.pdf??

Multi-Agent 設計模式的優點[21]如下：

• Separation of concerns（分工明確）：

每個智能體模塊（agent）都可以擁有自己專門的指導性指令（instructions）和只包含少量樣本的示例數據集（few-shot examples），他們由獨立微調過的語言模型驅動，同時還擁有各種工具的配套支持。每個 Agent 模塊都被賦予了明確的分工，只需專注于自身的特定任務，而不需要從大量的輔助資源和工具中進行選擇和調配。

• Modularity（模塊化）：

Multi-agent 這種設計模式允許將復雜的問題分解為易于管理的工作單元，由專門的智能體和語言模型來處理。 這種設計模式能讓我們對每個智能體單獨進行評估和改進，而不會干擾整個應用程序。將工具和職責進行分組可以帶來更好的結果。當智能體專注于某項特定任務時，更有可能取得成功。

• Diversity（多樣性）：

在構建智能體團隊（agent-teams）時，應當確保團隊內部存在足夠的多樣性，包括不同的模型、知識源、任務視角等。 多樣性有助于團隊從不同角度思考問題，相互印證和完善結果，降低系統產生幻覺或偏見的風險。這與人類團隊中應該擁有多元背景和觀點的理念是一致的，體現了這種設計模式的人性化特征。

• Reusability（可復用性）：

一旦構建了智能體，就有機會將這些智能體在不同的使用場景中重復使用，并可以嘗試構建一個智能體生態系統，通過合適的編排/協調框架（如 AutoGen、??Crew.ai?? 等）共同解決問題。

08 部署模式 4 —— CoPilot

在我看來，CoPilot系統通過與外界（用戶、測試工具...）的互動獲取新知識這一點，是它與其他 AI 系統最大的區別和優勢所在。

8.1 CoPilot 的構建框架介紹與 CoPilot 的實現方法

在構建這些協同智能助手（CoPilot）時，最重要的是要區分構建 CoPilot 的框架和協同智能助手的實現方法（如GPTPilot和Aider）。在大多數情況下，沒有任何開源的協同智能助手是基于這些框架開發的，都是從零開始開發的。

回顧一下當下流行的 CoPilot 實現方法：OpenDevin（??https://github.com/OpenDevin/OpenDevin）??? 、 GPT Pilot（??https://github.com/Pythagora-io/gpt-pilot/tree/main）??

回顧一下當下流行的相關研究論文：AutoDev（??https://arxiv.org/pdf/2403.08299.pdf）??? 、AgentCoder（??https://arxiv.org/pdf/2312.13010.pdf）??

當下流行的 CoPilot 構建框架：Fabric（??https://github.com/danielmiessler/fabric）??? 、LangGraph（??https://python.langchain.com/docs/langgraph）、??? DSPy（??https://github.com/stanfordnlp/dspy）??? 、CrewAI（??https://github.com/joaomdmoura/crewAI）??? 、AutoGen（??https://microsoft.github.io/autogen/docs/Getting-Started/）?? 、MetaGPT、SuperAGI等

09 Deep Dive — apps

9.1 GPT Pilot

GPT Pilot 項目是一個表現出色的經典案例，它以 “layered” flow （譯者注：將任務分解為較小的子任務，并在不同的層次或級別中處理這些子任務，逐步實現任務。）的方式執行看似復雜的任務，使用具有創造性的提示詞來引導語言模型生成特定類型的模型輸出，并將多個模型的響應拼接在一起，執行目標任務或生成復雜的內容輸出。

系統中的不同配置文件（profiles）或角色以分層通信的方式工作，請瀏覽下面的綠色矩形框：

??https://www.reddit.com/r/MachineLearning/comments/165gqam/p_i_created_gpt_pilot_a_research_project_for_a/??

系統中各個獨立的 Agent 以一種分層的方式相互交互，各agent按順序相繼被觸發，在整個系統中不存在中心決策的agent。

產品在部署時采用了一些很好的設計原則，這些設計原則使得該產品在實際運行時表現出色：

1. 將復雜的任務分解成更簡單、更易管理的部分，每個部分都可以通過 LLM 生成相應的實現代碼。
2. 采取了Test driven development"（TDD）開發方法，從人類用戶處收集優質產品需求和功能期望，以便并在開發過程中準確驗證和迭代產品。
3. 上下文回溯（譯者注：Context rewinding，在處理任務或生成代碼時，回顧先前的上下文。）和代碼摘要（譯者注：Code summarization，將一段代碼或代碼塊簡化為其核心要點，使得 LLM 可以生成更具概括性和易讀性的代碼，而不是生成冗長或復雜的代碼。）。

盡管本文介紹的提示詞工程和工作流設計都很復雜，但對每個 Agent 進行微調，對于降低使用成本和提高 AI 系統準確性的好處是不言而喻的。

Thanks for reading!

Raunak Jain

Seeking patterns and building abstractions

END

參考資料

[1]??https://docs.deepwisdom.ai/main/en/guide/use_cases/agent/researcher.html??

[2]??https://www.youtube.com/watch?v=m8VSYcLqaLQ??

[3]??https://www.youtube.com/watch?v=8R7QOJgGyIQ??

[4]??https://www.youtube.com/watch?v=Cl19yWHhc2g??

[5]??https://python.langchain.com/docs/modules/tools/??

[6]??https://microsoft.github.io/autogen/docs/Use-Cases/agent_chat??

[7]??https://docs.haystack.deepset.ai/docs/components??

[8]??https://www.sciencedirect.com/science/article/abs/pii/B0080430767005349??

[9]??https://arxiv.org/pdf/2402.02716.pdf??

[10]??https://arxiv.org/abs/2402.01817??

[11]??https://aiguide.substack.com/p/can-large-language-models-reason??

[12]??https://www.ece.uw.edu/wp-content/uploads/2024/01/lecun-20240124-uw-lyttle.pdf??

[13]??https://arxiv.org/abs/2402.10178??

[14]??https://medium.com/@raunak-jain/fine-tuning-llms-for-enterprise-rag-8c1eb3ac6b32??

[15]??https://arxiv.org/abs/1612.01294??

[16]??https://arxiv.org/abs/2201.05176??

[17]??https://arxiv.org/pdf/2305.03653.pdf??

[18]??https://medium.com/@raunakjain_25605/path-to-production-for-llm-agents-f0a9cafd2398??

[19]??https://medium.com/@raunak-jain/llm-driven-planning-and-reasoning-for-enterprise-ai-09bf6b5e1965??

[20]??https://medium.com/@raunak-jain/orchestrating-agentic-systems-eb945d305083??

[21]??https://abvijaykumar.medium.com/multi-agent-architectures-e09c53c7fe0d??

本文經原作者授權，由 Baihai IDP 編譯。如需轉載譯文，請聯系獲取授權。

原文鏈接：

??https://medium.com/@raunak-jain/design-patterns-for-compound-ai-systems-copilot-rag-fa911c7a62e0??