編者按： 大模型的出現(xiàn)為構(gòu)建更智能、更復(fù)雜的人工智能系統(tǒng)帶來了新的契機。然而，單一的大模型難以應(yīng)對現(xiàn)實世界中錯綜復(fù)雜的問題，需要與其他模塊相結(jié)合，構(gòu)建出復(fù)合人工智能系統(tǒng)（Compound AI Systems）。

本文作者深耕人工智能領(lǐng)域多年，洞見獨到。文中系統(tǒng)性地介紹了四種常見的 Compound AI Systems 部署模式：RAG 系統(tǒng)、Conversational AI 系統(tǒng)、Multi-Agent 系統(tǒng)和 CoPilot 系統(tǒng)。作者闡明了這些部署模式的工作原理、模塊間的交互方式，并深入探討了“Agentic”理念、模塊化設(shè)計的優(yōu)勢等核心概念，為讀者構(gòu)建 Compound AI Systems 提供了寶貴的理論經(jīng)驗。相信通過學習本文，讀者們能夠?qū)θ绾螛?gòu)建 Compound AI Systems 有更深入的認識，為后續(xù)的工程實踐奠定扎實的基礎(chǔ)。

作者 | Raunak Jain

編譯 | 岳揚

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

01 什么是 compound AI systems ？

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

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

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

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

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

: )

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

02 復(fù)雜系統(tǒng)中各組件間的交互機制及其構(gòu)筑途徑

Compound AI systems 通常將這些“模塊”相互連接，讓他們共同協(xié)作。這些模塊都能夠完成某一些特定任務(wù)（certain tasks），它們相互依賴，根據(jù)需求被動態(tài)地組合和調(diào)整，執(zhí)行預(yù)定義的設(shè)計模式（design patterns）。

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

圖 1 ：“模塊”的關(guān)鍵組成部分

圖 2 ：其他通用模塊

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

03 基于 LLM 的 Autonomous Agents —— Compound AI systems 中的關(guān)鍵模塊

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

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

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

Agent 能夠使用其推理能力來思考和分析問題，然后形成一系列相關(guān)的思考步驟，最終制定出一個行動計劃來解決問題或?qū)崿F(xiàn)目標任務(wù)。

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

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

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

而在企業(yè)環(huán)境中，需要的只是可靠地重復(fù)任務(wù)，并從以往的經(jīng)驗中學習，而不需要太多創(chuàng)造性能力。

3.3 這些“鸚鵡??”究竟是如何規(guī)劃任務(wù)解決流程的？

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

• 分解任務(wù)解決步驟（Task decomposition）—— 現(xiàn)實生活中的任務(wù)通常復(fù)雜且步驟繁多，給解決方案的規(guī)劃帶來了極大的困難。這種方法采用分而治之的思想，將復(fù)雜的任務(wù)分解為多個子任務(wù)，然后按順序?qū)γ總€子任務(wù)進行規(guī)劃，如 TDAG[13]。
• 生成多種備選解決方案（Multi-plan selection）—— 這種方法側(cè)重于引導(dǎo) LLM 多“思考（think）”，為目標任務(wù)生成各種備選計劃。然后采用與目標任務(wù)相關(guān)的搜索算法（比如 ReWoo），來挑選一個要執(zhí)行的方案。
• 利用外部模塊來輔助進行規(guī)劃（External module-aided planning）—— 也就是從存儲的計劃庫或歷史記錄中檢索出以前制定的計劃或解決方案（plan retrieval）。
• 反思和完善（Reflection and Refinement）—— 這種方法論強調(diào)通過反思和完善來提高方案規(guī)劃能力。鼓勵 LLM 對失敗進行反思，然后不斷完善解決方案的規(guī)劃。
• 通過額外的存儲模塊來增強解決方案的規(guī)劃。（Memory-Augmented Planning）—— 這種方法通過額外的存儲模塊（memory module）來增強解決方案的規(guī)劃能力，存儲模塊中存儲了各種有價值的信息，如常識性知識（commonsense knowledge）、以往的寶貴經(jīng)驗（past experiences）、特定垂直領(lǐng)域知識（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，將系統(tǒng)中的各種功能和能力抽象成獨立的模塊，以便于對其進行訓練、優(yōu)化和整合。）的方式，我們可以開發(fā)不同的設(shè)計模式（design patterns）來解決對話式 AI（Conversational AI）、RAG（檢索增強生成）系統(tǒng)和 CoPilot 系統(tǒng)在處理復(fù)雜問題時面臨的挑戰(zhàn)。

04 Compound AI systems 的設(shè)計模式

4.1 閱讀本節(jié)需要掌握的相關(guān)概念或相關(guān)術(shù)語

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

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

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

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

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

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

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

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

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

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

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

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

• 系統(tǒng)是否能夠通過推理（reasoning）得出結(jié)論，并采取相應(yīng)的行為（action）來執(zhí)行任務(wù)。
• 模塊之間是否可以相互影響？

4). 系統(tǒng)的每個組件或模塊生成的結(jié)果是否可以在實際環(huán)境中進行驗證和評估？

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

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

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

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

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

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

5.1 Query的理解與重構(gòu)

Query expansion / Multi — query 技術(shù)

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

Query rewriting / Self — Query 技術(shù)

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

Entity recognition 技術(shù)

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

5.2 Query Enrichment

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

5.3 Knowledge or Intent retrieval

Multi — Document Search 技術(shù)

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

Dialogue Management 技術(shù)

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

Response Generation 技術(shù)

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

5.4 Agentic RAG

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

需要細化的關(guān)鍵步驟和關(guān)鍵組件包括：

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

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

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

相關(guān)論文：??https://arxiv.org/pdf/2210.03629.pdf??

系統(tǒng)通過對可用的搜索工具進行推理和分析，然后根據(jù)推理結(jié)果采取相應(yīng)的行為來解決問題或完成任務(wù)。

5.6 Planning based Agentic RAG 基于 Agentic RAG 的解決方案規(guī)劃方法

相關(guān)文檔：??https://blog.langchain.dev/planning-agents/??

相關(guān)論文：??https://arxiv.org/abs/2305.18323??

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

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

相關(guān)論文：??https://openreview.net/forum?id=4sajV6NEnWE??

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

相關(guān)論文：??https://arxiv.org/abs/2305.04091??

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

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

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

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

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

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

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

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

Condition — if email exists, user can subscribe

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

Tools — check_subscription, add_subscription

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

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

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

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

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

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

相關(guān)論文：??https://arxiv.org/abs/2403.03101??

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

有一些工具可以幫助規(guī)劃器（planner）以可靠的推理方式?jīng)Q定運行路徑（path），其中包括：

• 通過查看先前類似語句所觸發(fā)的運行路徑（path）和行為，規(guī)劃器（planner）可以借鑒以前的經(jīng)驗，并根據(jù)這些信息來決定當前的運行路徑（path）。
• 建立企業(yè)級的行為圖譜（Enterprise graph of actions）以及各種行為（actions）之間的依賴關(guān)系。這有助于規(guī)劃器確定某個行為是否會產(chǎn)生預(yù)期的結(jié)果，從而決定下一步該選擇采取什么行為，如此反復(fù)，遞歸地解決問題。有關(guān)知識圖譜（knowledge graphs）和行為規(guī)劃（planning）與 Neo4J 和 Langchain** 在現(xiàn)實世界中的整合，請參考閱讀此文，但不一定與行為路徑的規(guī)劃（planning paths）相關(guān)。
• 了解用戶或?qū)υ挼漠斍盃顟B(tài)可以幫助規(guī)劃器（planner）根據(jù)當前情況做出決策，并相應(yīng)地調(diào)整行為路徑或相應(yīng)的規(guī)劃。

07 部署模式 3 —— Multi — Agent

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

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

相關(guān)論文：??https://arxiv.org/abs/2401.03428??

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

在構(gòu)建面向現(xiàn)實世界應(yīng)用的協(xié)作智能體（CoPilots）系統(tǒng)時，不同的智能體/模塊是如何進行通信和協(xié)作的。??https://arxiv.org/pdf/2402.01680v1.pdf??

Multi-Agent 設(shè)計模式的優(yōu)點[21]如下：

• Separation of concerns（分工明確）：

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

• Modularity（模塊化）：

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

• Diversity（多樣性）：

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

• Reusability（可復(fù)用性）：

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

08 部署模式 4 —— CoPilot

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

8.1 CoPilot 的構(gòu)建框架介紹與 CoPilot 的實現(xiàn)方法

在構(gòu)建這些協(xié)同智能助手（CoPilot）時，最重要的是要區(qū)分構(gòu)建 CoPilot 的框架和協(xié)同智能助手的實現(xiàn)方法（如GPTPilot和Aider）。在大多數(shù)情況下，沒有任何開源的協(xié)同智能助手是基于這些框架開發(fā)的，都是從零開始開發(fā)的。

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

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

當下流行的 CoPilot 構(gòu)建框架：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 項目是一個表現(xiàn)出色的經(jīng)典案例，它以 “l(fā)ayered” flow （譯者注：將任務(wù)分解為較小的子任務(wù)，并在不同的層次或級別中處理這些子任務(wù)，逐步實現(xiàn)任務(wù)。）的方式執(zhí)行看似復(fù)雜的任務(wù)，使用具有創(chuàng)造性的提示詞來引導(dǎo)語言模型生成特定類型的模型輸出，并將多個模型的響應(yīng)拼接在一起，執(zhí)行目標任務(wù)或生成復(fù)雜的內(nèi)容輸出。

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

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

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

產(chǎn)品在部署時采用了一些很好的設(shè)計原則，這些設(shè)計原則使得該產(chǎn)品在實際運行時表現(xiàn)出色：

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

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

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??

本文經(jīng)原作者授權(quán)，由 Baihai IDP 編譯。如需轉(zhuǎn)載譯文，請聯(lián)系獲取授權(quán)。

原文鏈接：

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