【ZiDongHua 之技術文章區(qū)收錄關鍵詞:自動化引擎 機器人 自然語言 語言模型】
 
 
  大語言模型加持下的自動化引擎
 
 
  文章翻譯自Blog:https://lilianweng.github.io/posts/2023-06-23-agent/
 
  文章目錄
 
  智能體(Agent)系統(tǒng)概覽
 
  部件一:規(guī)劃
 
  任務分解
 
  自我反思
 
  部件二:記憶
 
  記憶類型
 
  最大內(nèi)積搜索(Maximum Inner Product Search, MIPS)
 
  部件三:工具使用
 
  案例研究
 
  科學發(fā)現(xiàn)智能體
 
  生成式智能體仿真
 
  概念驗證舉例
 
  挑戰(zhàn)
 
  引用
 
  參考文獻
 
  使用LLM(large language model, 大語言模型)來構建智能體的核心部件是一個非??岬母拍睢r炞C此概念的一些應用,比如:AutoGPT、GPT-Engineer以及BabyAGI等,都給出了令人鼓舞的結果。LLM的潛力不會局限于文本重寫優(yōu)化或者寫小說、發(fā)言稿和程序,它也可以用于構建一個強大的、解決一般問題的框架。
 
  智能體(Agent)系統(tǒng)概覽
 
  在LLM加持下的自動化智能體系統(tǒng)中,LLM作為智能體的大腦,它由幾個關鍵部件組成:
 
  規(guī)劃
 
  子目標分解:智能體將大的任務拆分為許多小的、可管理的小目標,以便于復雜任務的高效處理
 
  反思與改進:智能體可以基于過去的動作進行自我批評與自我反思,即從過去的錯誤中學習以來優(yōu)化未來的行為,進而最終的結果得以改善
 
  記憶
 
  短期記憶:這里我將所有情景學習(in-context learning, 參考Prompt Engineering)看作是模型學習短期記憶的過程
 
  長期記憶:這為智能體提供了保留與回憶信息的能力,這一般會通過外部向量的快速存取來實現(xiàn)
 
  工具使用
 
  智能體學會通過調(diào)用外部APIs來獲取額外的信息來彌補模型權重(通常預訓練之后很難被改變)中不會留存的信息,包括當前的上下文信息、代碼執(zhí)行能力、從一些專用的信息源獲取的信息等等
 
  
 
  LLM加持下的智能系統(tǒng)概覽
 
  部件一:規(guī)劃
 
  復雜任務通常會包含很多步驟。智能體需要知道這些步驟是什么,并提前規(guī)劃。
 
  任務分解
 
  思維鏈(Chain of thought, CoT; Wei等, 2022)已經(jīng)成為模型在復雜任務上性能加強的標準提示(prompting)技術?;诖?,模型被要求“一步一步思考”,以更多的計算時間為代價,將復雜的任務分解為較小的、更簡單的子任務。CoT將大的任務轉(zhuǎn)化為多個可管理的小任務,可以讓模型的“思考”過程更具解釋性。
 
  思維樹(Yao 等, 2023)對思維鏈進行了擴展。它在每一小步(子任務)的處理過車個鬧鐘功能,都會去探索很多合理的可能性。首先,它將問題分解為多步,而后它又為每一步生成多個子步驟,這樣就生成了一個樹形結構的任務完成流程??梢岳梅诸惼骰蛘叨鄶?shù)投票的方式來對思維樹的每個狀態(tài)進行評估,以完成對樹的深度/廣度優(yōu)先搜索。
 
  任務分解可以通過如下一些方式完成:
 
  通過對LLM輸入簡單的提示來完成,比如:XYZ的步驟\n1.或達成ZYZ的子目標是什么?
 
  通過使用特定任務相關的指令,舉例來說:如果希望寫一篇小說可以輸入提示寫一個故事的大綱。
 
  人工生成
 
  有另一個差異較大的方法叫LLM+P(Liu 等, 2023),它依賴一個傳統(tǒng)的外部規(guī)劃器來進行長期規(guī)劃。此方法使用規(guī)劃領域定義語言(Planning Domain Definition Language, PDDL)作為中間接口對問題進行描述。具體操作步驟為:
 
  LLM將問題翻譯為滿足PDDL的格式
 
  向某個經(jīng)典規(guī)劃器發(fā)起請求,生成一個基于現(xiàn)有“領域PDDL”的PDDL規(guī)劃
 
  將PDDL規(guī)劃翻譯為自然語言
 
  本質(zhì)上,此方案的規(guī)劃這一步是外包給外部工具來完成的。它假設存在一個特定領域的PDDL與一個合適的規(guī)劃器。這種設定在一些特定機器人領域是很常見的,但是在很多其它領域,這種假設很難被滿足。
 
  自我反思
 
  自我反思是一個重要的過程,它讓自動化引擎可以對過去的動作決策進行迭代改進,以修正之前的錯誤。它在現(xiàn)實任務中扮演了一個極其關鍵的角色,因為在現(xiàn)實任務中試驗與錯誤是不可避免的。
 
  ReAct(Yao 等, 2023)將因果推斷與動作空間集成到LLM中去。它將動作空間擴展為兩部分的組合:一、任務相關的離散動作空間;二、語言空間。前者讓LLM可以與環(huán)境(如:使用維基搜索的API)進行交互。而后者可以用于提示LLM以自然語言的方式生成推理軌跡。
 
  ReAct為LLM提供了顯式的提示模版,格式大致如下:
 
  想法:...
 
  動作:...
 
  觀察:...
 
  ... (重復多次)
 
  知識密集型任務的推理軌跡舉例(如HotpotQA, FEVER)以及決策任務舉例(如:AlfWorld Env, WebShop)
 
  在知識密集型任務與決策任務這兩個實驗中,ReAct的表現(xiàn)都比單獨使用Act這一基準(想法:...這一步被)表現(xiàn)要好。
 
  Reflexion(Shinn & Labash, 2023)框架使用動態(tài)記憶與自我反思能力來武裝智能體,以改進智能引擎的推理技術。Reflexion是一個標準的強化學習(Reinforcement Learning, RL)設置。它的獎勵模型是一個簡單的二值獎勵,而動作空間遵循ReAct的設置,也就是使用任務相關的動作空間與語言空間相結合的方式。這樣可以完成復雜的推理任務。在每一個動作后,智能體會計算出一個猜想,并且可以根據(jù)自我反思的結果選擇是否重置整個環(huán)境來開始新一輪的嘗試。
 
  
 
  Reflexion框架示意圖
 
  猜想函數(shù)決定了執(zhí)行路徑是否是無效的或者包含了錯覺,以決定是否需要終止。無效規(guī)劃指的是那些耗費太長時間還沒有執(zhí)行成功的路徑。錯覺定義為遇到了連續(xù)的相同動作的序列而會導致同樣環(huán)境狀態(tài)的情況。
 
  自我反思通過如下方式創(chuàng)建:給LLM喂兩個樣本,每個樣本包含一對數(shù)據(jù)(失敗的執(zhí)行路徑,用于規(guī)劃未來改變的理想想法)。而后,這些想法被添加到智能體的工作記憶中(最多可有三個),用作LLM查詢的上下文。
 
  AlfWorld Env與HotpotQA上的實驗結果。在AlfWorld的實驗中,錯覺失敗出現(xiàn)的比無效規(guī)劃要多
 
  事后反饋鏈(Chain of Hindsight, CoH; Liu 等, 2023)鼓勵模型在其自身的輸出上進行改進。它顯式地將其自身輸出與對應的反饋放到它過去的輸出序列中去。人工反饋數(shù)據(jù)是一個集合,其中是提示,是模型的填充,是對的人工評分,是事后人工反饋。假設反饋元組根據(jù)獎勵大小來排序,,那么這個真?zhèn)€過程就是監(jiān)督式微調(diào)的一個過程。使用 此作為輸入,模型可以通過使用序列前綴來預測的方式進行微調(diào),以此完成基于反饋序列來自我反思,以生成更好的輸出。在測試階段,模型可以選擇是否進行多輪的人類反饋過程。
 
  為了避免過擬合,CoH 在預測訓練數(shù)據(jù)最大似然估計之上添加了正則化項。為了防止模型耍小聰明或簡單復制(因為反饋序列中有許多常用單詞),在訓練階段,大概0% - 5%的詞(tokens)會被隨機掩蓋。
 
  實驗中,訓練所用數(shù)據(jù)集為WebGPT comparisons、人類反饋概要和人類偏好數(shù)據(jù)集的組合。
 
  使用CoH微調(diào)之后,模型可以遵循指令生成逐漸改善的輸出
 
  CoH的思想是利用特定上下文下的一系列不斷改進歷史輸出來訓練模型給出更加優(yōu)質(zhì)的結果。算法蒸餾(Algorithm Distillation, AD; Laskin 等, 2023)應用了同樣的思想,它在強化學習任務中交叉使用了不同輪的運行軌跡(cross-episode trajectories),也就是算法運算使用了一個長期歷史依賴的策略??紤]一個與環(huán)境進行多次交互的智能體,在每一輪(episode)新的交互中,它都會改進一點點。AD將這些學習歷史信息串連在一起,然后喂給模型。這樣,我們期望模型可以給出相比于之前更好的結果。算法將重點放在了強化學習的學習過程而非訓練一個任務特定的策略本身。
 
  算法蒸餾工作示意圖
 
  論文假設任何可以生成一些列歷史學習信息的算法都可以通過行為克隆的方式將其壓縮到一個神經(jīng)網(wǎng)絡中去。歷史數(shù)據(jù)可以通過一些源策略生成,這些源策略可以由某些特定的任務訓練而來。在訓練階段,每次強化學習的運行會隨機采樣一個任務,得到多輪的交互軌跡用于訓練。以此方式所習得的策略是任務無關的。
 
  實際上,模型的上下文窗口長度是有限制的。因此,每一輪交互軌跡應該要足夠短,這樣才能夠包含多輪的交互軌跡。為了可以學習到一個近乎最優(yōu)的情景(in-context)強化學習算法,訓練樣本中包含2-4輪的歷史交互軌跡是必要的。情景強化學習算法需要足夠長的上下文信息。
 
  相比于三個基線算法 ED (專家蒸餾,使用專家軌跡而非學習歷史進行行為克?。?、源策略(用于生成UCB的蒸餾軌跡)以及RL^2(Duan 等, 2017; 將其用作上界,因為它是一種在線強化學習算法),在情景強化學習中,AD使用離線強化學習策略可以達到接近在線算法RL^2的性能表現(xiàn)。此外,AD相比于其它基線算法,學習速度更快。在僅使用部分訓練歷史信息的情況下,AD算法的改進速度仍然要快于ED。
 
  AD、ED、源策略、RL^2在需要記憶與探索的環(huán)境中的性能對比
 
  部件二:記憶
 
  (非常感謝ChatGPT幫我起草本小節(jié)。在我與ChatGPT的對話中,我學習到了很多關于人類大腦以及快速MIPS的數(shù)據(jù)結構。)
 
  記憶類型
 
  記憶可以定義為用于獲取、存儲、保留以及后期檢索信息的過程。人類大腦中存在幾種記憶類型:
 
  感官記憶:這是記憶的最早階段,在最初接受感覺刺激之后,它提供了保留感官信息(視覺、聽覺等)的能力。感官記憶僅持續(xù)幾秒鐘。該分類的子類包括圖像記憶(視覺),聲音記憶(聽覺)以及觸覺記憶(觸摸)
 
  短期記憶(Short-Term Memory, STM)或者工作記憶:它存儲了我們當前注意以及處理當前復雜認知任務(如學習、推理等)所需的信息。短期記憶被認為可以同時保留大概7件事,持續(xù)大概20-30秒
 
  長期記憶(Long-Term Memory, LTM):長期記憶可以將信息存儲相當長的一段時間,范圍從幾天到幾十年不等,它的容量幾乎是無限的。LTM分為兩個子類:
 
  顯式/陳述性記憶(declarative memory):這是對事實和事件的記憶,即那些可以被主動回憶起的事,包括情景記憶(時間和經(jīng)歷)以及語義記憶(事實和概念)
 
  隱式/程序性記憶:此類記憶是無意識的,包括一些技巧以及自動執(zhí)行的流程,像騎自行車或者敲鍵盤等
 
  人類記憶分類
 
  我們可以大致考慮以下的對應關系:
 
  感官記憶對應學習原始輸入的嵌入表征,包括文本、圖片以及其它模態(tài)
 
  短期記憶對應情景學習。它是短暫且有限的,因為它受到Transformer上下文窗口長度的限制
 
  長期記憶對應外部存儲向量,智能體在查詢階段可以隨時獲取
 
  最大內(nèi)積搜索(Maximum Inner Product Search, MIPS)
 
  外部記憶可以緩解注意力范圍有限的問題。一個標準的實踐是將信息的嵌入表征保存在向量數(shù)據(jù)庫中,數(shù)據(jù)庫應支持快速最大內(nèi)積搜索(MIPS)。為了優(yōu)化信息獲取速度,常見的選擇是使用近似最近鄰(approximate nearest neighbors, ANN)算法來返回k個近似最優(yōu)解。ANN能夠以很小的準確率損失來換取巨大的搜索加速。
 
  有一些常用的快速MIPS ANN算法:
 
  本地敏感哈希(Locality-Sensitive Hashing, LSH):這是一個新的哈希函數(shù)類別,它可以將輸入相近的元素以較高概率映射到同一哈希上。不同哈希值的數(shù)量要遠小于輸入樣本的數(shù)量
 
  ANNOY(Approximate Nearest Neighbors Oh Yeah):它的核心數(shù)據(jù)結構是隨機映射樹,即一系列二分樹的集合。每一棵二分樹中的非葉子結點代表一個輸入空間的分割平面,它將輸入空間分成兩部分。樹的每個葉子結點存儲了一個數(shù)據(jù)點。樹以獨立隨機的方式生成。因此,從某種意義上來說,它模擬了一個哈希函數(shù)。ANNOY搜索使用所有的樹進行搜索,在樹的每個節(jié)點上找到與查詢向量相近的后續(xù)節(jié)點進行迭代,最后再將所有樹的結果聚合到一起。這個想法非常類似KD樹,但是擴展性要強很多
 
  HNSW(Hierarchical Navigable Small World):此算法源自小世界網(wǎng)絡理論。在小世界中,絕大部分結點都可以用很少的步驟到達其它任意一個結點,比如社交網(wǎng)絡中著名的“六度分割理論”。HNSW將這些小世界圖構建為分層結構,其中底層包含了實際的數(shù)據(jù)點。中間層創(chuàng)建了加速搜索的快捷方式。在搜索時,HNSW從頂層的一個隨機結點開始向目標導航。當其無法再更靠近的時候,它就向下層移動,直至到達底層。在上層中的每一次移動可能意味著數(shù)據(jù)空間中很大距離的移動,在底層中的每一次移動都會對搜索結果進行改善
 
  FAISS(Facebook AI Similarity Search):此算法基于這樣一個假設:在高維空間中,結點間的距離遵循高斯分布,因此,應該存在數(shù)據(jù)點的聚集。FAISS使用向量量化技術將空間分割成很多群,而后又在群內(nèi)作量化改進。搜索過程首先使用粗粒度量化尋找群,然后在群內(nèi)使用更細的量化進行進一步搜索
 
  ScaNN(Scalable Nearest Neighbors):ScaNN的主要創(chuàng)新點是各向異性向量量化。它將數(shù)據(jù)點量化為,滿足內(nèi)積與原值盡可能相近,而非選擇最近的量化質(zhì)心點
 
  MIPS算法對比,指標:recall@10
 
  查看更多MIPS算法及其性能對比:ann-benchmarks.com。
 
  部件三:工具使用
 
  工具的使用是人類的一個顯著的、具有區(qū)分性的能力。我們可以創(chuàng)建、修改以及利用外部實體來完成超出我們身體和認知極限的事情。使用外部工具武裝LLMs可以極大擴展模型的能力。
 
  一張海獺漂浮在水中時用巖石敲開貝殼的照片。其它一些動物也可以使用工具,但是復雜程度無法如人類相比
 
  MRKL(Modular Reasoning, Knowledge and Language; Karpas 等, 2022)是一個應用于自動化智能體的神經(jīng)符號架構。MRKL系統(tǒng)包含一些專家模塊,通用的LLM可以用于將查詢路由到最合適的專家模塊。這些模塊可以是基于神經(jīng)網(wǎng)絡的(如深度學習模型)或者基于符號的(比如:數(shù)學計算器、貨幣轉(zhuǎn)換器、天氣API等)。
 
  他們針對算術問題進行了一個實驗,微調(diào)LLM來調(diào)用一個計算器。他們的實驗表明,解決口頭數(shù)學問題比明確表述的數(shù)學問題更難,因為LLMs(7B Jurassic1-large model)無法為基本算術問題正確、可靠地提取參數(shù)。實驗結果強調(diào)當外部符號工具可以可靠工作時,知道何時以及如何使用工具至關重要,這些都由LLMs的能力來決定。
 
  TALM(Tool Augmented Language Models; Parisi 等, 2022)和Toolformer(Schick 等, 2023)都對LM進行了微調(diào)以學習如何使用外部工具。新添加的API注解對模型輸出的改善結果被用于對數(shù)據(jù)集進行擴展。一些細節(jié)可以參考提示工程的“外部APIs”章節(jié)。
 
  ChatGPT的插件以及OpenAI API的函數(shù)調(diào)用都是外部工具增強的LLMs的優(yōu)秀用例。工具APIs可以由其他開發(fā)者(類似插件)提供或者是自定義的(比如函數(shù)調(diào)用)。
 
  HuggignGPT(Shen 等, 2023)是一個將ChatGPT作為一個任務規(guī)劃器的框架。它使用ChatGPT來分析HuggingFace平臺上模型的描述,并選取相應模型,最后根據(jù)模型的執(zhí)行結果輸出一個概要描述。
 
  HuggingGPT工作方式示意圖
 
  系統(tǒng)由四個階段組成:
 
  任務規(guī)劃:LLM作為大腦,它將用戶的請求分解成多個任務。每個任務有四個相關的屬性:任務類型、ID、依賴以及參數(shù)。他們使用很少的樣本來引導LLM進行任務的分解與規(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.
 
  模型選擇:LLM將任務分發(fā)給專家模型,請求方式是讓模型回答一個多項選擇問題。LLM需要從模型列表中選擇出所需模型。由于上下文長度的限制,基于任務類型的過濾是必要的。 指令:
 
  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.
 
  任務執(zhí)行:專家模型工作于特定任務之上,并且記錄執(zhí)行結果。 指令:
 
  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.
 
  響應生成:LLM接受執(zhí)行結果,并且向用戶提供結果描述
 
  為了讓HuggingGPT可以在現(xiàn)實世界中可以使用,還有一些挑戰(zhàn)有待解決:
 
  效率優(yōu)化:LLM的推理迭代次數(shù)和模型間的交互都降低了響應速度
 
  在復雜的任務內(nèi)容上,它依賴于一個非常長的上下文窗口進行交流通信
 
  模型輸出以及外部模型服務的穩(wěn)定性有待改善
 
  API-Bank(Li 等, 2023)是一個衡量工具強化的LLMs性能的基準。它包含了53個常用API工具,一個完整的工具加強的LLM工作流,以及264個注解對話(涵蓋568個API調(diào)用)。APIs的選擇非常多樣化,包含搜索引擎、計算器、日歷查詢、智能家居控制、日程管理、健康數(shù)據(jù)管理、賬戶認證工作流等等。由于大量APIs的存在,LLM首先需要調(diào)用搜索引擎來找到合適的API,而后根據(jù)對應的文檔來進行正確的API調(diào)用。
 
  LLM在API-Bank中進行API調(diào)用的偽代碼
 
  在API-Bank的工作流中,LLMs需要做出一系例的決策,在每一步中我們可以評估它的決策的正確性。決策包括:
 
  是否需要一個API調(diào)用
 
  識別正確的API類型:如果不夠好,LLMs需要迭代修改API的輸入(比如:決定搜索引擎API的搜索關鍵字)
 
  根據(jù)API的返回結果進行響應:如果返回結果不夠好,模型可以選擇進行改進并在此進行API調(diào)用
 
  此基準在三個等級上評估了智能體的工具使用能力:
 
  等級一評估了正確使用API的能力。給定一個API的描述,模型需要決定是否調(diào)用給定的API,如何正確調(diào)用,如何處理API的返回結果
 
  等級二檢測其API的選取能力。模型需要搜索可以解決用戶需求的合適API,并且通過文檔的閱讀學習如何使用它們
 
  等級三進一步測量了它的規(guī)劃能力。給定一個不明確的用戶要求(比如:排定會議日程、預訂行程機票/酒店/餐館),模型可能需要調(diào)用多次API來解決問題
 
  案例研究
 
  科學發(fā)現(xiàn)智能體
 
  ChemCrow(Bran 等, 2023)是一個專用領域的智能體。它的LLM使用了13個專家工具來輔助完成任務。這些任務包括有機合成、藥物發(fā)現(xiàn)和材料設計?;?*LangChain**實現(xiàn)的工作流反應了之前在ReAct和MRKL中描述的內(nèi)容,并將CoT推理與任務相關的工具進行了整合:
 
  LLM可以獲取專家工具輸入/輸出的詳細描述,包括工具名稱、功能描述等等
 
  而后,利用專家工具,LLM被要求根據(jù)指令回答用戶指定提示的問題。指令知道模型遵循ReAct格式 - 想法,動作,動作輸入,狀態(tài)觀察
 
  一個有趣的發(fā)現(xiàn)是基于LLM的評估得到結論是GPT-4和ChemCrow的表現(xiàn)幾乎一致。而人類專家根據(jù)解決方案的完成度以及化學相關正確性的評估表明ChemCrow的表現(xiàn)要遠好于GPT-4。這揭露了使用LLM來評估其在專業(yè)領域問題上性能的一個潛在問題。缺乏專業(yè)性可能會導致LLMs缺乏其對其自身弱點的了解,這樣就無法判斷任務結果的正確性。
 
  Boiko 等, 2023同樣也對LLM智能體在科學發(fā)現(xiàn)方面的能力進行了探索,包括處理復雜科學實驗的自主設計、規(guī)劃和執(zhí)行。該智能體使用工具來瀏覽互聯(lián)網(wǎng)、閱讀文檔、執(zhí)行代碼、調(diào)用機器人實驗APIs以及利用其它LLMs。
 
  舉例來說,當被要求開發(fā)一種新的抗癌藥,模型提出以下步驟:
 
  查詢當前抗癌藥物發(fā)現(xiàn)的趨勢
 
  選擇一個目標
 
  請求這些化合物的結構
 
  一旦化合物被確定,模型便嘗試合成
 
  他們同樣也討論了風險問題,特別是非法藥物與生化武器的問題。他們做了一個涵蓋知名化學武器的列表的數(shù)據(jù)集,并請求智能體合成它們。4/11的請求(36%)被模型接收生成合成方案,智能體嘗試編輯文檔來執(zhí)行這些步驟。7/11的請求被拒絕,這7個被拒絕的請求中,有5個是模型在使用網(wǎng)絡搜索之后被拒絕的,另外兩個是僅根據(jù)前置提示而直接拒絕的。
 
  生成式智能體仿真
 
  Generative Agents(GA, Park 等, 2023)是一個有趣的實驗。在實驗中,由LLM控制的25個虛擬任務角色居住在一個沙盒環(huán)境中,彼此可以通過沙盒進行交流(受到模擬人生游戲的啟發(fā))。GA為交互式應用程序創(chuàng)建了可靠的人類行為模擬。
 
  GA的設計將LLM與記憶、規(guī)劃以及思維機制相結合,讓智能體可以基于過去的經(jīng)歷來決定其自身行為,同時也可以與其它智能體進行交互。
 
  記憶流是一個長期記憶模塊(外部數(shù)據(jù)庫),它可以使用自然語言記錄大量的智能體經(jīng)歷
 
  每條記憶是一個狀態(tài)觀察(observation),即由智能體提供的事件。智能體之間的交流可以生成新的自然語言描述
 
  檢索模型根據(jù)相關性、新近度和重要性,為智能體的行為提供上下文
 
  新近度(recency):時間越近,評分越高
 
  重要性:將核心記憶與平淡的記憶區(qū)分開來,可直接通過向LLM詢問得到
 
  相關性:基于其與當前的場景/問題的相關程度來判斷
 
  思維機制:隨著時間的推移,將記憶合成為更高層次的推論,用于指導智能體的未來行為。它們是過去事件的高層次抽象描述(<- 注意這與前文的自我反思有點不同)
 
  使用最近的100個觀察作為提示信息,并根據(jù)一組觀察結果/陳述生成三個最顯著的高級問題讓LM進行回答
 
  規(guī)劃與響應:將思考與環(huán)境信息翻譯為動作
 
  規(guī)劃本質(zhì)上是為了優(yōu)化當前即時動作的可信度
 
  提示模板:{Intro of an agent X}. Here is X's plan today in broad strokes: 1)
 
  智能體之間的關系以及另一個智能體對某個智能體的觀察都會用于規(guī)劃與響應
 
  環(huán)境信息使用樹形結構進行組織
 
  GA架構
 
  這種有趣的模擬會產(chǎn)生新的社交行為,例如信息傳播、關系記憶(比如兩個智能體持續(xù)某個對話主題)和社交活動的協(xié)調(diào)(比如舉辦聚會并邀請其他人)。
 
  概念驗證舉例
 
  AutoGPT引起了人們對建立以LLM作為主控制器的自動化智能體的廣泛關注。雖然給定自然語言處理接口,該方案仍然存在著非常多的可靠性問題,但其仍不失為一個非常酷的概念驗證應用。AutoGPT中的很多代碼都是關于格式轉(zhuǎn)換的。
 
  下面是一個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": ""

 
  2. Browse Website: "browse_website", args: "url": "", "question": ""

 
  3. Start GPT Agent: "start_agent", args: "name": "", "task": "", "prompt": ""

 
  4. Message GPT Agent: "message_agent", args: "key": "", "message": ""
 
  5. List GPT Agents: "list_agents", args:
 
  6. Delete GPT Agent: "delete_agent", args: "key": ""
 
  7. Clone Repository: "clone_repository", args: "repository_url": "", "clone_path": ""
 
  8. Write to file: "write_to_file", args: "file": "", "text": ""
 
  9. Read file: "read_file", args: "file": ""
 
  10. Append to file: "append_to_file", args: "file": "", "text": ""
 
  11. Delete file: "delete_file", args: "file": ""
 
  12. Search Files: "search_files", args: "directory": ""
 
  13. Analyze Code: "analyze_code", args: "code": ""
 
  14. Get Improved Code: "improve_code", args: "suggestions": "", "code": ""
 
  15. Write Tests: "write_tests", args: "code": "", "focus": ""
 
  16. Execute Python File: "execute_python_file", args: "file": ""
 
  17. Generate Image: "generate_image", args: "prompt": ""
 
  18. Send Tweet: "send_tweet", args: "text": ""
 
  19. Do Nothing: "do_nothing", args:
 
  20. Task Complete (Shutdown): "task_complete", args: "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.loads
 
  GPT-Engineer是另一個工程,它以自然語言描述的任務作為輸入,創(chuàng)建一個完整的代碼倉庫。GPT-Engineer被指示考慮一些待構建的小組件列表,并在必要的時候要求用戶澄清其問題。
 
  下面是一個GPT-Engineer所使用的用于任務澄清的對話樣本,該樣本會發(fā)送給OpenAI ChatCompletion 終端。用戶輸入被包含在{{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}}"
 
  }
 
  ]
 
  在這些澄清之后,智能體使用一個不同的系統(tǒng)消息來切換到代碼編輯模式。系統(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
 
  對話舉例:
 
  [
 
  {
 
  "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"
 
  },
 
  #  … same conversation as earlier, ended with "Make your own assumptions and state them explicitly before starting".
 
  {
 
  "role": "assistant",
 
  "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?"
 
  },
 
  {
 
  "role": "user",
 
  "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"
 
  }
 
  ]
 
  挑戰(zhàn)
 
  在對構建以LLM為中心的智能體的核心思想以及應用示范過了一遍之后,我發(fā)現(xiàn)一些局限性:
 
  有限的上下文長度:上下文容量的局限會限制可以包含的歷史信息、細節(jié)指令、API調(diào)用上下文以及響應。系統(tǒng)的設計必須考慮工作在此通信帶寬限制之上。如果有更長的或者無限的上下文窗口,類似從過去錯誤中學習的自我反思之類的機制就可以收獲更大。雖然向量數(shù)據(jù)的存取與檢索可以提供一個更大的知識池,它們的表示能力還是無法和全注意力機制相提并論
 
  長期規(guī)劃與任務分解中的挑戰(zhàn):在一段跨度很長的歷史信息上進行規(guī)劃以及解決方案空間的高效探索都是非常具有挑戰(zhàn)性的。LLMs在面對異常錯誤的時候很難對規(guī)劃進行調(diào)整,這與從試錯中學習的人類相比還是遠不夠看
 
  自然語言接口的可靠性:當前的智能系統(tǒng)還依賴于自然語言作為LLMs與外部組件(如記憶與工具)的接口。然而,模型輸出的可靠性還是一個問題。LLMs可能會犯格式化錯誤,并且偶爾也會犯?。ū热缇芙^遵循指令)。結果,大量的智能體示例都在重點關注如何轉(zhuǎn)換模型的輸出
 
  引用
 
  引用格式:
 
  “
 
  Weng, Lilian. (Jun 2023). LLM-powered Autonomous Agents". Lil’Log. https://lilianweng.github.io/posts/2023-06-23-agent/.
 
  ”
 
  或者
 
  @article{weng2023prompt,
 
  title   = "LLM-powered Autonomous Agents"",
 
  author  = "Weng, Lilian",
 
  journal = "lilianweng.github.io",
 
  year    = "2023",
 
  month   = "Jun",
 
  url     = "https://lilianweng.github.io/posts/2023-06-23-agent/"
 
  }