大模型上下文協(xié)議與Spring開發(fā)集成篇——mcp-spring-webmvc原理
Fig. 1. LLM 驅(qū)動(dòng)下的 AI Agents System 概覽
復(fù)雜任務(wù)的處理通常會(huì)涉及到多個(gè)步驟，因此 AI Agents 需要預(yù)先了解并對(duì)這些步驟進(jìn)行規(guī)劃。任務(wù)規(guī)劃能力可以幫助 Agents 更好地理解任務(wù)結(jié)構(gòu)和目標(biāo)，以及在此基礎(chǔ)上如何分配資源和優(yōu)化決策，從而提高任務(wù)完成的效率和質(zhì)量。
? 思維鏈（Chain of thought）
CoT 已經(jīng)成為提升復(fù)雜任務(wù)模型性能的標(biāo)準(zhǔn)提示技術(shù)，它通過(guò)讓模型“逐步思考”，利用更多的測(cè)試時(shí)間，將困難的任務(wù)拆解為更小、更簡(jiǎn)單的步驟。CoT 能夠?qū)⒋笮腿蝿?wù)轉(zhuǎn)化為多個(gè)可管理的子任務(wù)，并揭示模型的思維鏈條，從而提高模型性能。這種技術(shù)使得模型更易于理解，也更容易獲得更好的結(jié)果。
? 思維樹（ Tree of Thoughts）
在 CoT 的基礎(chǔ)上，思維樹（ ToT ）則是通過(guò)在每一步探索多種推理可能性來(lái)擴(kuò)展模型性能。ToT 首先將問(wèn)題分解為多個(gè)思維步驟，每個(gè)步驟生成多個(gè)思維，從而創(chuàng)建一個(gè)樹狀結(jié)構(gòu)。搜索過(guò)程可以是廣度優(yōu)先搜索（BFS）或深度優(yōu)先搜索（DFS），每個(gè)狀態(tài)由分類器（通過(guò)提示）或多數(shù)票進(jìn)行評(píng)估。
在處理任務(wù)時(shí)，可以通過(guò)以下幾種方式來(lái)實(shí)現(xiàn)任務(wù)分解：
1. 通過(guò) LLM 模型進(jìn)行簡(jiǎn)單的提示，例如“Steps for XYZ.\n1.”、“What are the subgoals for achieving XYZ?”；
2. 通過(guò)使用特定于任務(wù)的指令，例如“Write a story outline”；
3. 有人工輸入。
另一種非常獨(dú)特的任務(wù)分解的方法是 LLM+P ，它利用外部經(jīng)典規(guī)劃師（External classical planner）進(jìn)行長(zhǎng)期規(guī)劃。該方法利用規(guī)劃域定義語(yǔ)言 (Planning Domain Definition Language，PDDL) 作為中間接口來(lái)描述規(guī)劃問(wèn)題。在這個(gè)過(guò)程中，LLM 需要完成以下幾個(gè)步驟：
1. 將問(wèn)題轉(zhuǎn)化為“問(wèn)題 PDDL”；
2. 請(qǐng)求經(jīng)典規(guī)劃師基于現(xiàn)有的“域 PDDL”生成 PDDL 計(jì)劃；
3. 將 PDDL 計(jì)劃翻譯回自然語(yǔ)言。
LLM+P（Large Language Models + Planning）：
LLM+P：Empowering Large Language Models with Optimal Planning Proficiency 論文中提出的一種任務(wù)解決方法，通過(guò)將 LLM 和規(guī)劃（Planning）進(jìn)行結(jié)合， 通過(guò)使用自然語(yǔ)言來(lái)描述任務(wù)規(guī)劃，進(jìn)一步生成解決方案，從而推動(dòng)問(wèn)題的解決。
在 LLM+P 中，LLM 用于將自然語(yǔ)言指令轉(zhuǎn)換為機(jī)器可理解的形式，并生成 PDDL 描述。接下來(lái)，PDDL 描述可以被 P 規(guī)劃器使用，生成合理的計(jì)劃并解決給定的任務(wù)。目前，LLM+P 方法已經(jīng)應(yīng)用于許多領(lǐng)域，例如機(jī)器人路徑規(guī)劃、自動(dòng)化測(cè)試和語(yǔ)言對(duì)話系統(tǒng)中的自然語(yǔ)言理解和生成問(wèn)題等等。
PDDL（Planning Domain Definition Language）：
PDDL 是一種標(biāo)準(zhǔn)化和通用的規(guī)劃領(lǐng)域語(yǔ)言，用于描述計(jì)劃領(lǐng)域的形式語(yǔ)言。它能夠用于描述可行動(dòng)作、初始狀態(tài)和目標(biāo)狀態(tài)的語(yǔ)言，用于幫助規(guī)劃器生成計(jì)劃。PDDL 通常被用于 AI 的自動(dòng)規(guī)劃問(wèn)題，例如機(jī)器人路徑規(guī)劃、調(diào)度問(wèn)題、資源分配等。
從本質(zhì)上講，由外部工具來(lái)完成規(guī)劃步驟被這件事在某些機(jī)器人環(huán)境中很常見，但在其他領(lǐng)域并不常見。該方法假設(shè)特定領(lǐng)域的 PDDL 和適當(dāng)?shù)囊?guī)劃師可用，可以幫助 Agents 更好地規(guī)劃和執(zhí)行任務(wù)，提高任務(wù)完成的效率和質(zhì)量。
自我反思（Self-reflection）在任務(wù)規(guī)劃中是一個(gè)重要環(huán)節(jié)，它讓 Agents 能夠通過(guò)改進(jìn)過(guò)去的行動(dòng)決策、糾正過(guò)往的錯(cuò)誤以不斷提高自身表現(xiàn)。在現(xiàn)實(shí)世界的任務(wù)中，試錯(cuò)（trial and error）是必不可少的，因而自我反思在其中扮演著至關(guān)重要的角色。
? ReAct
通過(guò)將動(dòng)作空間擴(kuò)展為任務(wù)特定的離散動(dòng)作和語(yǔ)言空間的組合，將推理和行動(dòng)融合到 LLM 中。前者（任務(wù)特定的離散動(dòng)作）使 LLM 能夠與環(huán)境進(jìn)行交互，例如使用維基百科搜索 API，而后者（語(yǔ)言空間）則促使 LLM 生成自然語(yǔ)言的推理軌跡。
ReAct 是 Auto-GPT 實(shí)現(xiàn)的基礎(chǔ)組件之一，由 Google Research Brain Team 在 ReAct：Synergizing Reasoning And Actiong In Language Models 論文中提出。在 ReAct 工作之前，大家往往將大模型的推理能力和行為決策能力分開進(jìn)行研究。而 ReAct 首次在語(yǔ)言模型中將推理和行為決策緊密結(jié)合起來(lái)，使得語(yǔ)言模型的推理能力能夠根據(jù)知識(shí)進(jìn)行計(jì)劃安排，行為決策能夠與外界工具進(jìn)行交互。
簡(jiǎn)單來(lái)說(shuō)，ReAct 方法即推理+動(dòng)作得到結(jié)果。靈感來(lái)自于作者對(duì)人類行為的一個(gè)洞察：在人類從事一項(xiàng)需要多個(gè)步驟的任務(wù)時(shí)，每一步之間往往會(huì)有一個(gè)推理過(guò)程。作者提出讓 LLM 把內(nèi)心獨(dú)白“說(shuō)”出來(lái)，然后再根據(jù)獨(dú)白做相應(yīng)的動(dòng)作，模仿人類的推理過(guò)程，以提高 LLM 答案的準(zhǔn)確性。這種方式在多種數(shù)據(jù)集上都取得了 SOTA 效果，并且更加可信，提升了 LLM 應(yīng)對(duì)“胡說(shuō)八道”的能力。
此外，作者還提出了進(jìn)一步提高 ReAct 準(zhǔn)確率的方法，即微調(diào)（fine-tuning），類似人類“內(nèi)化”知識(shí)的過(guò)程，將上千條正確的推理動(dòng)作軌跡輸入進(jìn) LLM 進(jìn)行 fine-tuning， 可以顯著提高準(zhǔn)確率。
ReAct 提示模板包含了明確的 LLM 思考步驟，大致格式如下·：
Thought: ...
Action: ...
Observation: ...
... (Repeated many times)Fig. 2. 知識(shí)密集型任務(wù)（例如 HotpotQA，F(xiàn)EVER）和決策任務(wù)（例如 AlfWorld Env，WebShop）的推理軌跡示例。
Source：ReAct 論文
在知識(shí)密集型任務(wù)和決策任務(wù)這兩類實(shí)驗(yàn)中，ReAct 的表現(xiàn)優(yōu)于僅使用 Act 的基準(zhǔn)模型。在 Act 模型中，“Thought：…”步驟被刪除了 。
? Reflexion
一個(gè)為 AI Agents 提供動(dòng)態(tài)記憶和自我反思能力，以提高推理能力的框架。該框架采用標(biāo)準(zhǔn)的強(qiáng)化學(xué)習(xí)設(shè)置，其中獎(jiǎng)勵(lì)模型提供簡(jiǎn)單的二元獎(jiǎng)勵(lì)（0/1），動(dòng)作空間遵循 ReAct 中的設(shè)置，同時(shí)基于特定任務(wù)的行動(dòng)空間，使用語(yǔ)言增強(qiáng)功能，以實(shí)現(xiàn)復(fù)雜的推理步驟。在每個(gè)動(dòng)作 at 之后，AI Agents 會(huì)計(jì)算一個(gè)啟發(fā)式值 ht，并根據(jù)自我反思的結(jié)果來(lái)選擇是否重置環(huán)境以開始新的實(shí)驗(yàn)。
Reflexion 是在今年 6 月發(fā)布的最新論文 Reflexion: Language Agents with Verbal Reinforcement Learning 中提出的新框架。在 HumanEval 編碼基準(zhǔn)上，Reflexion 框架已經(jīng)達(dá)到了 91% 的準(zhǔn)確率，超過(guò)了之前最先進(jìn)的 GPT-4（只達(dá)到了 80%）。
在 Reflexition 框架下，可以通過(guò)語(yǔ)言反饋而非更新權(quán)重的方式來(lái)強(qiáng)化 Language Agents。具體實(shí)現(xiàn)上，Reflexition agents 會(huì)通過(guò)口頭反饋信號(hào)來(lái)反映任務(wù)情況，并在情景記憶緩沖中保留自己的反射文本，這些反饋推動(dòng)著在下一次實(shí)驗(yàn)中做出更好的決策。該方法具有足夠的靈活性，可以合并各種類型（標(biāo)量值或自由形式的語(yǔ)言）和反饋信號(hào)的來(lái)源（外部或內(nèi)部模擬），并在不同的任務(wù)（順序決策、編碼、語(yǔ)言推理）中獲得比基線代理顯著的改進(jìn)。
Fig. 3. 反射框架的圖解
Source：Reflexion 論文
啟發(fā)式函數(shù)（heuristic function）用來(lái)幫助確定軌跡是否低效或者包含幻覺(jué)（hallucination），進(jìn)而決定是否要停止任務(wù)。低效的規(guī)劃是指花費(fèi)過(guò)長(zhǎng)時(shí)間而沒(méi)有成功的軌跡；幻覺(jué)是指遇到一系列連續(xù)相同的動(dòng)作，導(dǎo)致環(huán)境中出現(xiàn)相同的觀察結(jié)果。
自我反思（Self-reflection）是通過(guò)向 LLM 展示一個(gè) two-shot 的示例來(lái)創(chuàng)建的，其中每個(gè)示例都是成對(duì)出現(xiàn)的，即“失敗的軌跡——指導(dǎo)未來(lái)計(jì)劃變化的理想反映”。隨后將該反思添加到 AI Agents 的短期工作記憶（短期記憶）中，最多不超過(guò)三個(gè)，以作為查詢 LLM 的上下文。
? Chain of Hindsight
CoH 來(lái)自于 Hao Liu 等人于 2023 年 2 月發(fā)布的 Chain of Hindsight Aligns Language Models with Feedback，它的核心思想是在上下文中呈現(xiàn)順序改進(jìn)輸出的歷史，并訓(xùn)練模型順應(yīng)趨勢(shì)以產(chǎn)生更好的輸出。
CoH 通過(guò)鼓勵(lì)模型來(lái)明確展示一系列過(guò)去的輸出及對(duì)應(yīng)反饋，進(jìn)一步改進(jìn)自己的輸出。其中人類反饋數(shù)據(jù)是一個(gè)集合 Dh = {(x,yi,ri,zi)n1=1}，其中 x 是提示，每個(gè) yi 代表一個(gè)模型補(bǔ)全，ri 是人類對(duì) yi 的評(píng)分，ri、yi、zi 是相互對(duì)應(yīng)的關(guān)系，zi 代表人類對(duì)模型輸出提供的事后反饋（Hindsight feedback）。假設(shè)反饋元組按獎(jiǎng)勵(lì)排名，較好的輸出會(huì)得到更高的獎(jiǎng)勵(lì)值，如 rn≥rn-1≥…≥r1。該過(guò)程將在有監(jiān)督條件下進(jìn)行微調(diào)，數(shù)據(jù)格式為 tn=(x,zi,yi,zj,…,zn,yn)，其中 ≤i≤j≤n，以便讓模型去學(xué)習(xí)如何根據(jù)反饋序列生成更好的輸出。
模型經(jīng)過(guò)微調(diào)后，將已知的輸出序列作為訓(xùn)練數(shù)據(jù)，令模型能夠預(yù)測(cè)在給定序列前綴（sequence prefix）條件下的 yn，以便在反饋序列（feedback sequence）的基礎(chǔ)上進(jìn)行自我反思，從而產(chǎn)生更高質(zhì)量的輸出。在測(cè)試時(shí)，該模型可以選擇性地接收帶有人類注釋者的多輪指令，即人類提供的反饋?zhàn)⑨?，從而進(jìn)一步提高模型的性能和準(zhǔn)確性。
為了避免過(guò)擬合，CoH 框架添加了一個(gè)正則化項(xiàng)（Regularization Term），以最大化預(yù)訓(xùn)練數(shù)據(jù)集的對(duì)數(shù)可能性。這個(gè)正則化項(xiàng)可以幫助模型更好地泛化和適應(yīng)新的數(shù)據(jù)，避免過(guò)度擬合現(xiàn)有的數(shù)據(jù)。此外，由于反饋序列中有許多常用詞，為了避免模型在訓(xùn)練過(guò)程中依賴于這些詞，CoH 在訓(xùn)練期間隨機(jī)屏蔽了 0%-5% 的歷史 token。
正則化項(xiàng)（Regularization Term）：
正則化是機(jī)器學(xué)習(xí)中應(yīng)對(duì)過(guò)擬合的一種簡(jiǎn)單而有效的技術(shù)。它的目的是通過(guò)限制模型的復(fù)雜度來(lái)提高其泛化性能，因此在各類問(wèn)題上都得到了廣泛的應(yīng)用。過(guò)擬合意味著模型在訓(xùn)練數(shù)據(jù)集上表現(xiàn)良好，但是在未知數(shù)據(jù)上的泛化性能卻很差。
通常，正則化項(xiàng)被添加到損失函數(shù)中來(lái)懲罰模型中過(guò)多的參數(shù)，以限制模型參數(shù)的數(shù)量和大小，使得參數(shù)值更加平滑。常見的正則化項(xiàng)包括 L1 正則化和 L2 正則化。正則化項(xiàng)的系數(shù)可以通過(guò)交叉驗(yàn)證等技術(shù)來(lái)調(diào)整，以使得模型在訓(xùn)練集和測(cè)試集上的性能都達(dá)到最優(yōu)。
實(shí)驗(yàn)中的訓(xùn)練數(shù)據(jù)集來(lái)自于 WebGPT 的對(duì)比、人類反饋總結(jié)和人類偏好數(shù)據(jù)集的組合。
Fig. 4. 使用 CoH 進(jìn)行微調(diào)后，
模型可以按照指令生成按順序進(jìn)行增量改進(jìn)的輸出。
Source：CoH 論文
? 算法蒸餾（Algorithm Distillation）
?將 CoH 的思想應(yīng)用于強(qiáng)化學(xué)習(xí)任務(wù)中的跨集軌跡，其中算法被封裝在長(zhǎng)期歷史條件策略中。由于 AI Agents 能夠與環(huán)境多次進(jìn)行交互，并不斷進(jìn)步，AD 連接這種學(xué)習(xí)歷史記錄并將其饋送到模型中。這樣，就可以實(shí)現(xiàn)每一次的預(yù)測(cè)操作都比以前的試驗(yàn)帶來(lái)更好的性能。AD 的目標(biāo)是學(xué)習(xí)強(qiáng)化學(xué)習(xí)的過(guò)程，而不是訓(xùn)練特定于任務(wù)的策略本身。通過(guò)將算法封裝在長(zhǎng)期歷史條件策略中，AD 可以捕獲模型與環(huán)境交互的歷史記錄，從而使得模型能夠更好地學(xué)習(xí)和改進(jìn)自己的決策和行動(dòng)，從而提高任務(wù)完成的效率和質(zhì)量。
Fig. 5. 算法蒸餾（AD）的工作原理
Source：Algorithm Distillation 論文
In-context Reinforcement Learning with Algorithm Distillation 這篇論文認(rèn)為，任何一種生成學(xué)習(xí)歷史的算法都可以通過(guò)對(duì)動(dòng)作執(zhí)行行為的克隆，將其提煉到神經(jīng)網(wǎng)絡(luò)中。在論文中，歷史數(shù)據(jù)是由一組源策略生成的，每個(gè)策略都是為特定任務(wù)進(jìn)行訓(xùn)練的。在訓(xùn)練階段的每次強(qiáng)化學(xué)習(xí)運(yùn)行期間，都會(huì)隨機(jī)采樣一個(gè)任務(wù)，并使用多集歷史記錄的子序列進(jìn)行訓(xùn)練。這樣學(xué)習(xí)出來(lái)的策略與任務(wù)無(wú)關(guān)。
實(shí)際上，由于模型的上下文窗口長(zhǎng)度有限，因此使用的劇集（episodes） 應(yīng)該足夠短，從而方便構(gòu)建多劇集歷史數(shù)據(jù)。在強(qiáng)化學(xué)習(xí)中，通常需要 2-4 集的多情節(jié)上下文來(lái)學(xué)習(xí)接近最佳的上下文強(qiáng)化學(xué)習(xí)算法，這是因?yàn)樵谏舷挛闹?，?qiáng)化學(xué)習(xí)的發(fā)生往往需要足夠長(zhǎng)的上下文來(lái)提供背景和意義。
論文使用了三個(gè)基線進(jìn)行對(duì)比，包括 ED（專家蒸餾，使用專家軌跡而非學(xué)習(xí)歷史的行為克隆）、源策略（用于生成 UCB 蒸餾的軌跡）和 RL2（ 2017 年提出的一種在線強(qiáng)化學(xué)習(xí)算法，作為上限進(jìn)行比較）。盡管 AD 算法僅使用離線強(qiáng)化學(xué)習(xí)，但其性能仍接近作為上限對(duì)比的 RL2，并且學(xué)習(xí)速度比其他基線快得多。此外，在使用源策略的部分訓(xùn)練歷史記錄的條件下，AD 的改進(jìn)速度也比 ED 基線快得多。這些結(jié)果表明，AD 算法在上下文強(qiáng)化學(xué)習(xí)方面具有很好的性能，并且比其他基線更快地學(xué)習(xí)和改進(jìn)。
Fig. 6. 在需要內(nèi)存和探索的環(huán)境中，比較了 AD、ED、源策略和 RL2 的性能。其中，環(huán)境僅分配二元獎(jiǎng)勵(lì)（0/1）。源策略使用 A3C 算法針對(duì)“黑暗”環(huán)境進(jìn)行訓(xùn)練，使用 DQN 算法針對(duì)水迷宮進(jìn)行訓(xùn)練。
Resource：Algorithm Distillation 論文
Memory 可以定義為用于獲取、存儲(chǔ)、保留和稍后檢索信息的進(jìn)程。人類的大腦記憶可以分為以下幾類：
1. 感覺(jué)記憶（Sensory Memory）：這是記憶的最早階段，提供在原始刺激結(jié)束后保留感官信息（視覺(jué)，聽覺(jué)等）印象的能力。通常，感覺(jué)記憶只能持續(xù)幾秒鐘。子類別包括標(biāo)志性記憶（視覺(jué)）、回聲記憶（聽覺(jué)）和觸覺(jué)記憶（觸摸）。
2. 短期記憶/工作記憶（Short-Term Memory， STM/ Working Memory）：它存儲(chǔ)了我們目前知道并執(zhí)行復(fù)雜的認(rèn)知任務(wù)（如學(xué)習(xí)和推理）所需的信息。短期記憶被認(rèn)為具有大約 7 個(gè)項(xiàng)目的容量，持續(xù) 20-30 秒。
Gordon Miller 在 1956 年發(fā)表了一篇關(guān)于人類短期記憶容量的論文 The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information，論文中他提出，經(jīng)過(guò)一系列實(shí)驗(yàn)觀察發(fā)現(xiàn)，人類的短期記憶（STM）大概只能容納 7±2 個(gè)項(xiàng)目。
3. 長(zhǎng)期記憶（Long-Term Memory ，LTM）：長(zhǎng)期記憶可以在很長(zhǎng)一段時(shí)間內(nèi)保存信息，從幾天到幾十年不等，存儲(chǔ)容量基本上是無(wú)限的。LTM 又可以被分為：
? 顯式/陳述性記憶（Explicit / declarative memory）：這是對(duì)事實(shí)和事件的記憶，是指那些可以有意識(shí)地回憶起來(lái)的記憶，包括情景記憶（事件和經(jīng)歷）和語(yǔ)義記憶（事實(shí)和概念）；
??內(nèi)隱/程序記憶（Implicit / Procedural memory）：?這種類型的記憶是無(wú)意識(shí)的，涉及自動(dòng)執(zhí)行的技能和例程，例如騎自行車或在鍵盤上打字。
Fig. 7.人類記憶的分類
參考人類記憶的分類，我們可以有一個(gè)粗略的映射：
? 感覺(jué)記憶（Sensory memory）作為原始輸入的學(xué)習(xí)嵌入表示，包括文本、圖像或其他模式；
? 短期記憶（Short-term memory）作為上下文學(xué)習(xí)，但由于 Transformer 有限上下文窗口長(zhǎng)度的限制，這種記憶短暫且有限；
? 長(zhǎng)期內(nèi)存（Long-term memory）作為 AI Agents 可以在查詢時(shí)處理的外部向量存儲(chǔ)，可通過(guò)快速檢索訪問(wèn)。
外部存儲(chǔ)器可以減少有限注意力（Finite Attention Span）的限制。一種標(biāo)準(zhǔn)做法是將信息的 embedding 保存到向量存儲(chǔ)數(shù)據(jù)庫(kù)中，該數(shù)據(jù)庫(kù)支持快速最大內(nèi)積搜索（Maximum Inner Product Search，MIPS）。為了提高檢索速度，常見的方法是使用近似最近鄰（ANN）算法，以返回大約前 k 個(gè)最近鄰，以犧牲一定的精度損失來(lái)?yè)Q取巨大的加速，這種方法可以減輕模型處理大量歷史信息時(shí)的計(jì)算負(fù)擔(dān)，提高模型的效率和性能。
最大內(nèi)積搜索（Max-Inner Product Search） 算法用于在高維向量空間中搜索最相似的向量，它的基本思想是，給定一個(gè)查詢向量 q 和一個(gè)向量集合 S，目標(biāo)找到 S 中與 q 的內(nèi)積最大的向量。為了加速搜索過(guò)程，可以采用一些優(yōu)化技巧，如倒排索引、局部敏感哈希等。最大內(nèi)積搜索算法在實(shí)際問(wèn)題中有很廣泛的應(yīng)用，特別是在信息檢索、推薦系統(tǒng)、語(yǔ)義搜索等需要處理高維向量數(shù)據(jù)的領(lǐng)域。
以下是幾種常見的 ANN 算法，可用于快速的執(zhí)行 MIPS：
? 局部敏感哈希（Locality-Sensitive Hashing，LSH）
它引入了一個(gè)哈希函數(shù)，使得類似的輸入項(xiàng)以高概率映射到相同的存儲(chǔ)桶中，而存儲(chǔ)桶的數(shù)量遠(yuǎn)小于輸入的數(shù)量。這也就意味著，類似的輸入項(xiàng)在 LSH 哈希后，它們很可能會(huì)被映射到相同的存儲(chǔ)桶中，而相似度較低的輸入項(xiàng)則可能會(huì)被映射到不同的存儲(chǔ)桶中，從而提高了查找相似項(xiàng)的效率。
? 近似最近鄰搜索算法（Approximate Nearest Neighbors Oh Yeah，ANNOY ）
它的核心數(shù)據(jù)結(jié)構(gòu)是一組二叉樹構(gòu)成的隨機(jī)投影樹。在這些樹中，每個(gè)非葉節(jié)點(diǎn)代表一個(gè)超平面，將輸入空間分成兩半，每個(gè)葉子節(jié)點(diǎn)存儲(chǔ)一個(gè)數(shù)據(jù)點(diǎn)。隨機(jī)投影樹是獨(dú)立且隨機(jī)構(gòu)建的，因此在某種程度上，它模仿了哈希函數(shù)的作用。ANNOY 搜索發(fā)生在所有樹中，以迭代方式搜索最接近查詢的那一半，并將結(jié)果聚合起來(lái)。這個(gè)想法與 KD 樹非常類似，但更具可擴(kuò)展性。
KD 樹（K-Dimensional Tree）：一種將空間中點(diǎn)分開存儲(chǔ)的樹狀數(shù)據(jù)結(jié)構(gòu)。KD 樹常被用于快速查找以及高維空間下的最近鄰搜索。KD 樹通過(guò)有選擇地劃分空間，將點(diǎn)存儲(chǔ)在葉子節(jié)點(diǎn)，這使得搜索新點(diǎn)的時(shí)候能夠快速去附近的葉子節(jié)點(diǎn)找到最相似的點(diǎn)，從而在對(duì)數(shù)時(shí)間內(nèi)完成高維空間的近似最近鄰搜索。
? 分層可導(dǎo)航小世界（Hierarchical Navigable Small World，HNSW）
它的靈感來(lái)自于 Small World Networks，即網(wǎng)絡(luò)中的大多數(shù)節(jié)點(diǎn)都可以在少量步驟內(nèi)由任何其他節(jié)點(diǎn)到達(dá)。HNSW 算法主要通過(guò)分層的方式，構(gòu)建分層圖，在保證搜索質(zhì)量的同時(shí)，提升搜索速度。其中，最底層包含實(shí)際數(shù)據(jù)點(diǎn)，中間圖層創(chuàng)建快捷方式以加快搜索速度。每當(dāng)執(zhí)行搜索時(shí)，HNSW 從頂層的隨機(jī)節(jié)點(diǎn)開始向目標(biāo)導(dǎo)航。當(dāng)它不能靠近時(shí)，它會(huì)向下移動(dòng)到下一層，直到到達(dá)底層。上層的每次移動(dòng)都可能覆蓋數(shù)據(jù)空間中的很大距離，而下層的每次移動(dòng)則會(huì)細(xì)化搜索質(zhì)量。
小世界網(wǎng)絡(luò)（small world networks）是一種圖結(jié)構(gòu)，其中大多數(shù)相鄰節(jié)點(diǎn)可以通過(guò)少量躍點(diǎn)或步驟從其他節(jié)點(diǎn)到達(dá)。簡(jiǎn)單來(lái)說(shuō)，大多數(shù)節(jié)點(diǎn)可以在很少的步驟內(nèi)由任何其他節(jié)點(diǎn)到達(dá)，而且具有高聚集性，即相鄰節(jié)點(diǎn)之間的連接更密集。
小世界效應(yīng)在自然界和人類社會(huì)中都很常見，例如腦神經(jīng)元的連接、互聯(lián)網(wǎng)底層架構(gòu)分布和社交網(wǎng)絡(luò)的形成等等，最為大眾熟知的則是例如社交網(wǎng)絡(luò)中常被提及的“六度理論”。小世界網(wǎng)絡(luò)也是當(dāng)代計(jì)算機(jī)硬件中許多片上網(wǎng)絡(luò)架構(gòu)的靈感來(lái)源。在 AI 領(lǐng)域，該概念也被廣泛應(yīng)用于近似最近鄰搜索算法，如 HNSW 算法。
? Facebook AI 相似性搜索（Facebook AI Similarity Search，F(xiàn)AISS）
Facebook AI Similarity Search（FAISS）是一種基于向量量化的相似性搜索工具，它基于以下假設(shè)：在高維空間中，節(jié)點(diǎn)之間的距離遵循高斯分布，因此應(yīng)該存在數(shù)據(jù)點(diǎn)的聚類。FAISS 將向量空間劃分為簇，然后通過(guò)細(xì)化量化簇內(nèi)向量來(lái)應(yīng)用向量量化。搜索首先查找具有粗量化的聚類候選項(xiàng)，然后進(jìn)一步查找具有更精細(xì)量化的每個(gè)聚類。
? 可擴(kuò)展最近鄰（Scalable Nearest Neighbors，ScaNN）
Scalable Nearest Neighbors（ScaNN）是一種可擴(kuò)展的最近鄰搜索工具，適用于高維向量空間中的最近鄰搜索。傳統(tǒng)的向量量化方法通常選擇壁櫥量化質(zhì)心點(diǎn)，然后將數(shù)據(jù)點(diǎn)映射到最近的質(zhì)心點(diǎn)。這樣做的問(wèn)題是在高維向量空間中，由于維度災(zāi)難的存在，這些質(zhì)心點(diǎn)往往不能很好地表示數(shù)據(jù)點(diǎn)之間的真實(shí)距離，導(dǎo)致搜索質(zhì)量下降。
ScaNN 的主要?jiǎng)?chuàng)新是各向異性矢量量化（Anisotropic Vector Quantization，AVQ），即通過(guò)量化數(shù)據(jù)點(diǎn)的方向和大小來(lái)解決上述問(wèn)題，使得內(nèi)積盡可能接近原始距離，從而減少了數(shù)據(jù)點(diǎn)之間的距離誤差。這使得 ScaNN 能夠處理高維向量空間中的最近鄰搜索，并且在大型數(shù)據(jù)集中具有高效性和可擴(kuò)展性。
Fig. 8. 人類記憶的分類
Resource：ScaNN 論文
人類最顯著的特征之一是能夠使用工具。人類通過(guò)創(chuàng)造、修改和利用外部對(duì)象來(lái)完成超出我們身體和認(rèn)知極限的任務(wù)。同樣，給 LLM 配備外部工具也可以顯著擴(kuò)展大模型的功能，使其能夠處理更加復(fù)雜的任務(wù)。
Fig. 9. 海獺在水中時(shí)用巖石打開貝殼的圖片，
雖然動(dòng)物會(huì)使用工具，但復(fù)雜性無(wú)法與人類相提并論。
MRKL（Modular Reasoning, ?Knowledge and Language）即 “模塊化推理、知識(shí)和語(yǔ)言”，是一種用于自主代理 的神經(jīng)符號(hào)架構(gòu)。MRKL 架構(gòu)的設(shè)計(jì)中包含了“專家（expert）”模塊的集合，通用 LLM 將扮演路由器（router）的角色，通過(guò)查詢路由找到最合適的專家模塊。這些模塊可以是神經(jīng)模塊（Neural），例如深度學(xué)習(xí)模型，也可以是符號(hào)模塊，例如數(shù)學(xué)計(jì)算器、貨幣轉(zhuǎn)換器、天氣 API 等。
MRKL 由 AI21 Labs 的 Ehud Karpas 等人在 2022 年 5 月發(fā)布。在 MRKL Systems: A modular，neuro-symbolic architecture that combines large language models，external knowledge sources and discrete reasoning 論文中 Ehud 等人提出了一個(gè)突破 LLM 固有限制的解決方案，定義了 MRKL 結(jié)構(gòu)。
MRKL 的核心思想是，現(xiàn)有 LLM（如 GPT-3 ）等仍存在一些缺陷，包括遺忘、外部知識(shí)的利用效率低下等。為此，MRKL 將神經(jīng)網(wǎng)絡(luò)模型、外部知識(shí)庫(kù)和符號(hào)專家系統(tǒng)相結(jié)合，提升了自然語(yǔ)言處理的效率和精度。通過(guò) MRKL 系統(tǒng)，不同類型的模塊能夠被整合在一起，實(shí)現(xiàn)更高效、靈活和可擴(kuò)展的 AI 系統(tǒng)。
在測(cè)試中，MRKL 的作者團(tuán)隊(duì)對(duì)語(yǔ)言模型（7B Jurassic1-large 模型）進(jìn)行了微調(diào)，使用算術(shù)問(wèn)題作為測(cè)試用例來(lái)調(diào)用計(jì)算器。實(shí)驗(yàn)結(jié)果表明，相比于明確陳述的數(shù)學(xué)問(wèn)題，解決口頭數(shù)學(xué)問(wèn)題更加具有挑戰(zhàn)性，因?yàn)?LLM 未能可靠地提取基本算術(shù)的正確參數(shù)。這些結(jié)果強(qiáng)調(diào)了外部符號(hào)工具可靠工作的重要性，知道何時(shí)以及如何使用這些工具取決于 LLM 的功能。
TALM（工具增強(qiáng)語(yǔ)言模型 Tool Augmented Language Models）和 Toolformer 都是通過(guò)微調(diào) LM 來(lái)學(xué)習(xí)使用外部工具 API。為了提高模型的性能和準(zhǔn)確性，數(shù)據(jù)集根據(jù)新添加的 API 調(diào)用注釋是否可以提高模型輸出的質(zhì)量進(jìn)行了擴(kuò)展。（在 Lilian 的 Prompt Engineering 的文章中也提到了 External APIs 相關(guān)的內(nèi)容）。
ChatGPT 插件 Plugin 和 OpenAI API 函數(shù)調(diào)用 Function Calling 是 LLM 實(shí)踐中增強(qiáng)工具使用能力的很好例子。工具 API 的集合可以由其他開發(fā)人員來(lái)提供（例如在插件中）或自定義（例如在函數(shù)調(diào)用中）。
HuggingGPT 將 ChatGPT 作為任務(wù)計(jì)劃器，可以根據(jù)模型描述，選擇 HuggingFace 平臺(tái)中可用的模型，并根據(jù)執(zhí)行結(jié)果總結(jié)響應(yīng)。
Fig. 10. HuggingGPT 的工作原理
該系統(tǒng)包括 4 個(gè)階段：
1. 任務(wù)規(guī)劃（Task planning）：LLM 作為大腦，負(fù)責(zé)將用戶請(qǐng)求解析為多個(gè)任務(wù)。每個(gè)任務(wù)都有四個(gè)關(guān)聯(lián)的屬性：任務(wù)類型、ID、依賴項(xiàng)和參數(shù)。通過(guò)使用 Few-shot 的例子，能夠指導(dǎo) LLM 進(jìn)行任務(wù)解析和規(guī)劃。
指令如下：
The AI assistant can parse user input to several tasks: ：[{"task": task, "id", task_id, "dep": dependency_task_ids, "args": {"text": text, "image": URL, "audio": URL, "video": URL}}].
The "dep" field denotes the id of the previous task which generates a new resource that the current task relies on.
A special tag "-task_id" refers to the generated text image, audio and video in the dependency task with id as task_id.
The task MUST be selected from the following options: {{ Available Task List }}.
There is a logical relationship between tasks, please note their order.
If the user input can't be parsed, you need to reply empty JSON.
Here are several cases for your reference: {{ Demonstrations }}. The chat history is recorded as {{ Chat History }}.
From this chat history, you can find the path of the user-mentioned resources for your task planning.2. 模型選擇（ Model selection）: LLM 可以根據(jù)任務(wù)類型將請(qǐng)求分配給相應(yīng)的專家模型，這些模型一般限制為多項(xiàng)選擇題的類型。然后，LLM 提供一個(gè)可供選擇和使用的模型列表。由于上下文長(zhǎng)度的限制，LLM 需要基于任務(wù)類型進(jìn)行過(guò)濾，以確保選擇的模型能夠有效地處理請(qǐng)求。
指令如下：
Given the user request and the call command, the AI assistant helps the user to select a suitable model from a list of models to process the user request.
The AI assistant merely outputs the model id of the most appropriate model.
The output must be in a strict JSON format: "id": "id", "reason": "your detail reason for the choice".
We have a list of models for you to choose from {{ Candidate Models }}.
Please select one model from the list.3. 任務(wù)執(zhí)行 Task execution：專家模型執(zhí)行并記錄特定任務(wù)的結(jié)果。
指令如下：
With the input and the inference results, the AI assistant needs to describe the process and results.
The previous stages can be formed as - User Input: {{ User Input }}, Task Planning: {{ Tasks }}, Model Selection: {{ Model Assignment }}, Task Execution: {{ Predictions }}.
You must first answer the user's request in a straightforward manner. Then describe the task process and show your analysis and model inference results to the user in the first person.
If inference results contain a file path, must tell the user the complete file path.4. 響應(yīng)生成（Response generation）：LLM 接收?qǐng)?zhí)行結(jié)果并向用戶提供匯總結(jié)果。
要將 HuggingGPT 投入實(shí)際使用，還需要解決以下幾個(gè)挑戰(zhàn)：
? 提高效率，因?yàn)?LLM 的推理輪次和與其他模型的交互都會(huì)減慢整個(gè)過(guò)程；
? 解決長(zhǎng)上下文窗口的限制，在這一前提下，HuggingGPT 才有可能處理復(fù)雜的任務(wù)內(nèi)容；
? 提高 LLM 輸出和外部模型服務(wù)的穩(wěn)定性。
API-Bank 是用于評(píng)估工具增強(qiáng) LLM 性能的基準(zhǔn)，它包含了 53 個(gè)常用的 API 工具、一個(gè)完整的工具增強(qiáng)型 LLM 工作流程，涉及到 568 個(gè) API 調(diào)用的 264 個(gè)帶注釋的對(duì)話。
API-Bank 由阿里巴巴達(dá)摩院在 2023 年 4 月發(fā)布的 API-Bank: A Benchmark for Tool-Augmented LLMs 中提出。API-Bank 是第一個(gè)專門用于評(píng)估 LLMs 使用外部工具能力的基準(zhǔn)評(píng)估系統(tǒng) ，它采用了一種全新的、具有擴(kuò)展性的 LLMs 使用工具的范式，旨在全面評(píng)估 LLMs 在 API 規(guī)劃、檢索和正確調(diào)用方面的能力。
這些 API 的選擇非常多樣化，包括搜索引擎，計(jì)算器，日歷查詢，智能家居控制，日程安排管理，健康數(shù)據(jù)管理，帳戶身份驗(yàn)證工作流程等。由于有大量的 API，LLM 首先可以訪問(wèn) API 搜索引擎，找到合適的 API 調(diào)用，然后使用相應(yīng)的文檔進(jìn)行調(diào)用，以便更好的處理請(qǐng)求。
Fig. 11. LLM 如何在 API 銀行中進(jìn)行 API 調(diào)用的
偽代碼, Source：Li et al, 2023
在 API-Bank 的工作流程中，LLM 需要做出幾個(gè)決策，并且我們可以在每步?jīng)Q策中評(píng)估其準(zhǔn)確性。這些決策包括：
? 是否需要 API 調(diào)用；
? 確定調(diào)用的正確 API：如果效果不夠好，LLM 需要迭代修改 API 輸入，例如確定搜索引擎 API 的搜索關(guān)鍵字；
? 基于 API 結(jié)果的響應(yīng)：模型可以選擇進(jìn)行優(yōu)化，如果結(jié)果不滿意，則再次調(diào)用 API。
API-Bank 將測(cè)試分為了三個(gè)級(jí)別，以評(píng)估 AI Agents 的工具使用能力：
? Level-1 評(píng)估調(diào)用 API 的能力。通過(guò)給定 API 的描述，模型需要確定是否調(diào)用給定的 API、如何正確調(diào)用它以及正確響應(yīng) API 返回；
? Level-2 檢查檢索 API 的能力。該模型需要搜索可能解決用戶需求的 API，并通過(guò)閱讀文檔來(lái)學(xué)習(xí)如何使用它們；
? Level-3 評(píng)估在檢索和調(diào)用之外規(guī)劃 API 的能力。鑒于不明確的用戶請(qǐng)求，例如安排小組會(huì)議，預(yù)訂航班、酒店、餐廳以及旅行規(guī)劃等，模型可能要通過(guò)執(zhí)行多個(gè) API 調(diào)用才能徹底解決問(wèn)題。
ChemCrow 是 LLM 被應(yīng)用于生物技術(shù)和藥物研究的例子，LLM 增強(qiáng)了其中 13 種專家設(shè)計(jì)的工具，以完成有機(jī)合成、藥物發(fā)現(xiàn)和材料設(shè)計(jì)方面的任務(wù)。該工作流在 LangChain 中實(shí)現(xiàn)，反映了之前在 ReAct 和 MRKLs 中描述的內(nèi)容，并將 CoT 推理與與任務(wù)相關(guān)的工具相結(jié)合：
? LLM 提供了工具名稱列表、實(shí)用程序的描述以及有關(guān)預(yù)期輸入/輸出的詳細(xì)信息；
? 然后指示它在必要時(shí)使用提供的工具回答用戶給定的提示。該指令建議模型遵循 ReAct 格式，即前文中的 -Thought, Action, Action Input, Observation。
其中一個(gè)有趣的觀察結(jié)果是，基于 LLM 的評(píng)估得出的結(jié)論顯示 GPT-4 和 ChemCrow 的性能幾乎相同，但根據(jù)專家對(duì)解決方案的完成和化學(xué)正確性的人類評(píng)估表明，ChemCrow 的性能明顯優(yōu)于 GPT-4。這表明，在需要深厚專業(yè)知識(shí)的領(lǐng)域中，使用 LLM 來(lái)評(píng)估自身表現(xiàn)存在潛在的問(wèn)題。缺乏專業(yè)知識(shí)可能會(huì)導(dǎo)致 LLM 難以意識(shí)到自身缺陷，從而無(wú)法很好地判斷任務(wù)結(jié)果的正確性。
Emergent autonomous scientific research capabilities of large language models 這篇論文則研究了用于科學(xué)發(fā)現(xiàn)的 AI Agents，它被用來(lái)復(fù)雜科學(xué)實(shí)驗(yàn)的設(shè)計(jì)、規(guī)劃和性能，它能夠使用工具完成上網(wǎng)、閱讀文檔、執(zhí)行代碼、調(diào)用機(jī)器人實(shí)驗(yàn) API 并適時(shí)調(diào)用其他 LLM 等來(lái)完成任務(wù)。
例如，當(dāng)收到 “develop a novel anticancer drug” 的請(qǐng)求時(shí)，模型提出了以下推理步驟：
1. 了解當(dāng)前的抗癌藥物發(fā)現(xiàn)趨勢(shì)和最新的研究進(jìn)展；
2. 確定一個(gè)具體的目標(biāo)，例如選擇一個(gè)特定的癌癥類型或治療方法；
3. 開始尋找針對(duì)這個(gè)目標(biāo)的化合物，可能需要進(jìn)行虛擬篩選或測(cè)試；
4. 一旦找到了合適的化合物，模型會(huì)嘗試設(shè)計(jì)并合成出一種新的抗癌藥物。
在論文中，作者還討論了一些風(fēng)險(xiǎn)問(wèn)題，特別是非法藥物和生物武器的風(fēng)險(xiǎn)，并開發(fā)了一個(gè)測(cè)試裝置。
這個(gè)測(cè)試裝置中包含了一份已知化學(xué)武器制劑的清單，并要求 Agents 來(lái)合成這些制劑。在 11 個(gè)測(cè)試請(qǐng)求中，有 4 個(gè)（36%）被系統(tǒng)接受，系統(tǒng)甚至在這個(gè)過(guò)程中還查閱了文檔試圖完成整個(gè)任務(wù)流程。其余 7 個(gè)請(qǐng)求則被系統(tǒng)拒絕，其中 5 個(gè)拒絕動(dòng)作發(fā)生在進(jìn)行 Web 搜索之后，2 個(gè)則是系統(tǒng)只根據(jù) prompt 內(nèi)容就提出拒絕。
Generative Agents ?生成 AI Agents 是一項(xiàng)非常有趣的實(shí)驗(yàn)，其靈感來(lái)自模擬人生游戲。實(shí)驗(yàn)中有 25 個(gè)虛擬角色，每個(gè)角色都分別由一個(gè) AI Agent 控制，它們?cè)谏澈协h(huán)境中生活和互動(dòng)。這種生成 AI Agents 的設(shè)計(jì)可以為交互式應(yīng)用程序創(chuàng)建可信的人類行為模擬，通過(guò)將 LLM 與記憶，計(jì)劃和反思機(jī)制相結(jié)合，AI Agents 能夠根據(jù)以往的經(jīng)驗(yàn)進(jìn)行調(diào)整和改進(jìn)，并與其他 AI Agents 進(jìn)行交互。
Memory
Stream 是一種長(zhǎng)期記憶模塊，外部數(shù)據(jù)庫(kù)會(huì)以自然語(yǔ)言形式記錄 AI Agents 的完整體驗(yàn)列表。這個(gè)列表中的每個(gè)元素都代表著一個(gè)觀察（observation），也就是 AI Agents 在某個(gè)特定時(shí)間點(diǎn)發(fā)生的事件或行為。這些事件或行為可以是 AI Agents 與用戶的交互，也可以是 AI Agents 之間的通信和協(xié)作。
此外，當(dāng) Agents 之間進(jìn)行通信和協(xié)作時(shí)，這些交互可以觸發(fā)新的自然語(yǔ)言語(yǔ)句，這些語(yǔ)句也會(huì)被記錄在 Stream 中，形成新的觀察。
Retrieval
海外獨(dú)角獸
，贊91
歡迎關(guān)注海外獨(dú)角獸視頻號(hào)
獲取最前沿的科技行業(yè)資訊
根據(jù)相關(guān)性、新近度和重要性等因素顯示上下文的模型，以指導(dǎo) Agents 的行為。
? 新近度（Recency）：最近事件的得分較高；
? 重要性（Importance）：區(qū)分世俗記憶和核心記憶，這個(gè)可以通過(guò)直接問(wèn) LLM 來(lái)實(shí)現(xiàn)；
? 相關(guān)性（Relevance）：基于某個(gè)信息或概念與當(dāng)前情況或查詢的相關(guān)程度。
世俗記憶：通常指與個(gè)人日常生活和經(jīng)歷相關(guān)的常規(guī)記憶，例如某個(gè)人的姓名、生日、電話號(hào)碼、家庭住址、工作職責(zé)等等。這些信息通常與個(gè)人的身份、社交網(wǎng)絡(luò)以及日?；顒?dòng)密切相關(guān)，是人們?cè)谌粘Ｉ钪兴枰莆蘸陀洃浀男畔ⅰ?/p>
核心記憶：相較于世俗記憶，核心記憶則更多地涉及到人類共性的知識(shí)和技能，例如語(yǔ)言、數(shù)學(xué)、科學(xué)、藝術(shù)等等。這些信息通常與人類文化、歷史和智慧相關(guān)，是人類在長(zhǎng)期文化演化和認(rèn)知發(fā)展中所積累的知識(shí)和技能。
Reflection
反射機(jī)制是指隨著時(shí)間的推移，模型將記憶合成為更高層次的推理，并指導(dǎo) AI Agents 的未來(lái)行為。其中，推理是指對(duì)過(guò)去事件的更高層次的總結(jié)和摘要。需要特別注意的是，這與前文提到的自我反思（self-reflection） 有一些不同。
該機(jī)制可以提示 LLM 最近的 100 個(gè)觀察結(jié)果，并根據(jù)給定的一組觀察/陳述生成 3 個(gè)最突出的高級(jí)問(wèn)題，然后讓 LLM 回答這些問(wèn)題。
Planning & Reacting 規(guī)劃與反應(yīng) : 將反射和環(huán)境信息轉(zhuǎn)化為行動(dòng)
? 計(jì)劃本質(zhì)上是為了優(yōu)化當(dāng)前情境下的決策和行動(dòng)，以提高可信度；
? Prompt 模板：{Intro of an agent X}. Here is X’s plan today in broad strokes: 1)；
??在規(guī)劃和反應(yīng)時(shí)，AI Agents 會(huì)考慮它們之間的關(guān)系，以及一個(gè) AI Agent 對(duì)另一個(gè) AI Agent 的觀察和反饋；
??環(huán)境信息往往存在于樹狀結(jié)構(gòu)中。
Fig. 12. 生成 AI Agents 架構(gòu)
Source：Park et al，2023
這個(gè)有趣的模擬引發(fā)了一些突發(fā)的社會(huì)行為，例如信息的傳播擴(kuò)散和關(guān)系記憶等，在實(shí)驗(yàn)中出現(xiàn)了兩個(gè) AI Agents 延續(xù)對(duì)話主題的行為以及舉辦聚會(huì)、并邀請(qǐng)?jiān)S多其他人等社交事件。
AutoGPT 是一個(gè)備受關(guān)注的項(xiàng)目，它探索了以 LLM 作為主控制器來(lái)建立 AI Agents 的可能性。雖然該項(xiàng)目在自然語(yǔ)言界面的可靠性方面仍存在很多問(wèn)題，但它仍然是一個(gè)很酷的概念驗(yàn)證。在這個(gè)項(xiàng)目中，AutoGPT 使用了許多代碼來(lái)解析數(shù)據(jù)格式，以幫助 AI Agents 更好地理解和處理自然語(yǔ)言輸入。
以下是 AutoGPT 使用的系統(tǒng)消息，其中 {{…}} 是用戶輸入：
You are {{ai-name}}, {{user-provided AI bot description}}.
Your decisions must always be made independently without seeking user assistance. Play to your strengths as an LLM and pursue simple strategies with no legal complications.
GOALS:
1. {{user-provided goal 1}}
2. {{user-provided goal 2}}
3. ...
4. ...
5. ...
Constraints:
1. ~4000 word limit for short term memory. Your short term memory is short, so immediately save important information to files.
2. If you are unsure how you previously did something or want to recall past events, thinking about similar events will help you remember.
3. No user assistance
4. Exclusively use the commands listed in double quotes e.g. "command name"
5. Use subprocesses for commands that will not terminate within a few minutes
Commands:
1. Google Search: "google", args: "input": "<search>"
2. Browse Website: "browse_website", args: "url": "<url>", "question": "<what_you_want_to_find_on_website>"
3. Start GPT Agent: "start_agent", args: "name": "<name>", "task": "<short_task_desc>", "prompt": "<prompt>"
4. Message GPT Agent: "message_agent", args: "key": "<key>", "message": "<message>"
5. List GPT Agents: "list_agents", args:
6. Delete GPT Agent: "delete_agent", args: "key": "<key>"
7. Clone Repository: "clone_repository", args: "repository_url": "<url>", "clone_path": "<directory>"
8. Write to file: "write_to_file", args: "file": "<file>", "text": "<text>"
9. Read file: "read_file", args: "file": "<file>"
10. Append to file: "append_to_file", args: "file": "<file>", "text": "<text>"
11. Delete file: "delete_file", args: "file": "<file>"
12. Search Files: "search_files", args: "directory": "<directory>"
13. Analyze Code: "analyze_code", args: "code": "<full_code_string>"
14. Get Improved Code: "improve_code", args: "suggestions": "<list_of_suggestions>", "code": "<full_code_string>"
15. Write Tests: "write_tests", args: "code": "<full_code_string>", "focus": "<list_of_focus_areas>"
16. Execute Python File: "execute_python_file", args: "file": "<file>"
17. Generate Image: "generate_image", args: "prompt": "<prompt>"
18. Send Tweet: "send_tweet", args: "text": "<text>"
19. Do Nothing: "do_nothing", args:
20. Task Complete (Shutdown): "task_complete", args: "reason": "<reason>"
Resources:
1. Internet access for searches and information gathering.
2. Long Term memory management.
3. GPT-3.5 powered Agents for delegation of simple tasks.
4. File output.
Performance Evaluation:
1. Continuously review and analyze your actions to ensure you are performing to the best of your abilities.
2. Constructively self-criticize your big-picture behavior constantly.
3. Reflect on past decisions and strategies to refine your approach.
4. Every command has a cost, so be smart and efficient. Aim to complete tasks in the least number of steps.
You should only respond in JSON format as described below
Response Format:
{
"thoughts": {
"text": "thought",
"reasoning": "reasoning",
"plan": "- short bulleted\n- list that conveys\n- long-term plan",
"criticism": "constructive self-criticism",
"speak": "thoughts summary to say to user"
},
"command": {
"name": "command name",
"args": {
"arg name": "value"
}
}
}
Ensure the response can be parsed by Python json.loadsGPT-Engineer 是另一個(gè)旨在創(chuàng)建一個(gè)完整的代碼存儲(chǔ)庫(kù)，以執(zhí)行指定的自然語(yǔ)言任務(wù)的項(xiàng)目。為了實(shí)現(xiàn)這個(gè)目標(biāo)，GPT 工程師需要考慮構(gòu)建哪些較小的組件，并在必要時(shí)與用戶進(jìn)行交互以澄清問(wèn)題或獲取更多信息。也就是說(shuō)，將最接近真實(shí)意圖的自然語(yǔ)言任務(wù)轉(zhuǎn)化為可執(zhí)行的代碼，以確保任務(wù)需求得到正確理解和實(shí)現(xiàn)。
以下是發(fā)送到 GPT 工程師使用的 OpenAI ChatComplete 端點(diǎn)的任務(wù)說(shuō)明示例對(duì)話，{{user input text}} 部分是用戶輸入：
[
{
"role": "system",
"content": "You will read instructions and not carry them out, only seek to clarify them.\nSpecifically you will first summarise a list of super short bullets of areas that need clarification.\nThen you will pick one clarifying question, and wait for an answer from the user.\n"
},
{
"role": "user",
"content": "We are writing a Super Mario game in python. MVC components split in separate files. Keyboard control.\n"
},
{
"role": "assistant",
"content": "Summary of areas that need clarification:\n1. Specifics of the Super Mario game (e.g. level design, characters, gameplay mechanics)\n2. Details about the MVC components (e.g. which components are in each file)\n3. Keyboard control implementation (e.g. which keys to use, how to handle input)\n\nClarifying question:\nCan you provide more details about the Super Mario game, such as level design, characters, and gameplay mechanics?"
},
{
"role": "user",
"content": "There are 10 levels in total. The main character is a plumber named Mario, who can walk and jump. It is a classical platform game just like Super Mario. The main character moves from left to right, trying to get to the destination, where there are many obstacles and attacks from enemies in the process.\n\nIs anything else unclear? If yes, only answer in the form:\n{remaining unclear areas} remaining questions.\n{Next question}\nIf everything is sufficiently clear, only answer \"Nothing more to clarify.\"."
},
{
"role": "assistant",
"content": "Remaining unclear areas: 2 remaining questions.\nCan you provide more information about how the MVC components are split into separate files?"
},
{
"role": "user",
"content": "Make your own assumptions and state them explicitly before starting"
}
]隨后，一旦 GPT 工程師與用戶澄清了任務(wù)需求，AI Agents 會(huì)進(jìn)入代碼編寫模式，并使用不同的系統(tǒng)消息來(lái)執(zhí)行編寫代碼的任務(wù)，系統(tǒng)消息如下：
you will get instructions for code to write. You will write a very long answer. Make sure that every detail of the architecture is, in the end, implemented as code. Make sure that every detail of the architecture is, in the end, implemented as code.
Think step by step and reason yourself to the right decisions to make sure we get it right. You will first lay out the names of the core classes, functions, methods that will be necessary, as well as a quick comment on their purpose.
Then you will output the content of each file including ALL code. Each file must strictly follow a markdown code block format, where the following tokens must be replaced such that FILENAME is the lowercase file name including the file extension, LANG is the markup code block language for the code’s language, and CODE is the code:
FILENAME
CODE
You will start with the “entrypoint” file, then go to the ones that are imported by that file, and so on. Please note that the code should be fully functional. No placeholders.
Follow a language and framework appropriate best practice file naming convention. Make sure that files contain all imports, types etc. Make sure that code in different files are compatible with each other. Ensure to implement all code, if you are unsure, write a plausible implementation. Include module dependency or package manager dependency definition file. Before you finish, double check that all parts of the architecture is present in the files.
Useful to know: You almost always put different classes in different files. For Python, you always create an appropriate requirements.txt file. For NodeJS, you always create an appropriate package.json file. You always add a comment briefly describing the purpose of the function definition. You try to add comments explaining very complex bits of logic. You always follow the best practices for the requested languages in terms of describing the code written as a defined package/project.
Python toolbelt preferences:
pytest
dataclasses對(duì)話樣本如下：
[
{
"role": "system",
"content": "You will get instructions for code to write.\nYou will write a very long answer. Make sure that every detail of the architecture is, in the end, implemented as code.\nMake sure that every detail of the architecture is, in the end, implemented as code.\n\nThink step by step and reason yourself to the right decisions to make sure we get it right.\nYou will first lay out the names of the core classes, functions, methods that will be necessary, as well as a quick comment on their purpose.\n\nThen you will output the content of each file including ALL code.\nEach file must strictly follow a markdown code block format, where the following tokens must be replaced such that\nFILENAME is the lowercase file name including the file extension,\nLANG is the markup code block language for the code's language, and CODE is the code:\n\nFILENAME\n``LANG\nCODE\n`\n\nYou will start with the \"entrypoint\" file, then go to the ones that are imported by that file, and so on.\nPlease note that the code should be fully functional. No placeholders.\n\nFollow a language and framework appropriate best practice file naming convention.\nMake sure that files contain all imports, types etc. Make sure that code in different files are compatible with each other.\nEnsure to implement all code, if you are unsure, write a plausible implementation.\nInclude module dependency or package manager dependency definition file.\nBefore you finish, double check that all parts of the architecture is present in the files.\n\nUseful to know:\nYou almost always put different classes in different files.\nFor Python, you always create an appropriate requirements.txt file.\nFor NodeJS, you always create an appropriate package.json file.\nYou always add a comment briefly describing the purpose of the function definition.\nYou try to add comments explaining very complex bits of logic.\nYou always follow the best practices for the requested languages in terms of describing the code written as a defined\npackage/project.\n\n\nPython toolbelt preferences:\n- pytest\n- dataclasses\n"<br> },<br> <em># … same conversation as earlier, ended with "Make your own assumptions and state them explicitly before starting".</em><br> {<br> "role": "assistant",<br> "content": "Assumptions:\n1. Model: The model will contain the game's data, such as level information, character states, and enemy positions.\n2. View: The view will handle the game's visuals, including rendering the game objects, backgrounds, and updating the display.\n3. Controller: The controller will manage user input, such as keyboard controls, and update the model accordingly.\n\nWith these assumptions in mind, is there any specific aspect of the keyboard control implementation you would like me to clarify?"<br> },<br> {<br> "role": "user",<br> "content": "Please now remember the steps:\n\nThink step by step and reason yourself to the right decisions to make sure we get it right.\nFirst lay out the names of the core classes, functions, methods that will be necessary, As well as a quick comment on their purpose.\n\nThen you will output the content of each file including ALL code.\nEach file must strictly follow a markdown code block format, where the following tokens must be replaced such that\nFILENAME is the lowercase file name including the file extension,\nLANG is the markup code block language for the code's language, and CODE is the code:\n\nFILENAME\n`LANG\nCODE\n``\n\nPlease note that the code should be fully functional. No placeholders.\n\nYou will start with the \"entrypoint\" file, then go to the ones that are imported by that file, and so on.\nFollow a language and framework appropriate best practice file naming convention.\nMake sure that files contain all imports, types etc. The code should be fully functional. Make sure that code in different files are compatible with each other.\nBefore you finish, double check that all parts of the architecture is present in the files.\n"
}
]在研究了許多以 LLM 為中心構(gòu)建的 AI Agents 的關(guān)鍵思想和實(shí)驗(yàn)成果之后，基于 LLM 搭建 Agents 系統(tǒng)的實(shí)現(xiàn)還存在以下限制：
? 有限的上下文容量（Finite context length）
這會(huì)限制系統(tǒng)的歷史信息、詳細(xì)說(shuō)明、API 調(diào)用上下文和響應(yīng)的能力。系統(tǒng)的設(shè)計(jì)必須在這種有限的通信帶寬下工作，但這種限制使得自我反思等機(jī)制無(wú)法從很長(zhǎng)或無(wú)限的上下文窗口中受益。盡管向量存儲(chǔ)和檢索可以提供對(duì)更大的知識(shí)庫(kù)的訪問(wèn)，但它們的表示能力不如 Full Attention 機(jī)制強(qiáng)大。
? 長(zhǎng)期規(guī)劃和任務(wù)分解方面的挑戰(zhàn)（Challenges in long-term planning and task decomposition）
在漫長(zhǎng)的歷史中進(jìn)行規(guī)劃和有效探索解決方案空間仍然具有很大的挑戰(zhàn)性。盡管 LLM 能夠嘗試調(diào)整計(jì)劃來(lái)應(yīng)對(duì)意外錯(cuò)誤，但與從反復(fù)試驗(yàn)中學(xué)習(xí)的人類相比，它的魯棒性較低。
? 自然語(yǔ)言接口的可靠性挑戰(zhàn)（Reliability of natural language interface）
當(dāng)前的 Agents 系統(tǒng)依賴自然語(yǔ)言作為 LLM 與記憶、工具等外部組件的接口，然而，模型輸出的可靠性有問(wèn)題，LLM 可能會(huì)出現(xiàn)格式錯(cuò)誤、甚至在一些時(shí)候也會(huì)表現(xiàn)出叛逆行為，如拒絕遵循指令等。為了提高自然語(yǔ)言接口的可靠性，就需要進(jìn)一步改進(jìn)自然語(yǔ)言處理技術(shù)，以減少錯(cuò)誤和提高模型的魯棒性。因此，目前大部分 Agents demo 的代碼都側(cè)重于分析模型的輸出，以檢測(cè)并糾正潛在的錯(cuò)誤。
文章轉(zhuǎn)自微信公眾號(hào)@海外獨(dú)角獸
對(duì)比大模型API的內(nèi)容創(chuàng)意新穎性、情感共鳴力、商業(yè)轉(zhuǎn)化潛力
一鍵對(duì)比試用API 限時(shí)免費(fèi)
