一文梳理大語言模型編程框架 原創(chuàng)
大語言模型(LLMs),以及一般的語言模型(LMs),催生了一種新的編程方式,其中“指令”不再是明確的應(yīng)用程序編程接口(APIs),而是像英語這樣的自然語言語句。該領(lǐng)域(一個(gè)被稱為提示工程的新領(lǐng)域)的專家通過組合特定的關(guān)鍵詞、提示格式,甚至認(rèn)知模型來對(duì)他們的語言模型進(jìn)行編程——或者從語言模型中引出特定行為。
過去兩年表明,語言模型可以產(chǎn)生廣泛的變革性影響,但在無縫集成到更大的程序環(huán)境方面存在固有局限。它們對(duì)事實(shí)和先前交互的記憶不完善,不能可靠地遵循邏輯結(jié)構(gòu),無法與外部環(huán)境交互或執(zhí)行計(jì)算,并且對(duì)提示方式很敏感。為解決這些局限,已經(jīng)出現(xiàn)了十多個(gè)流行的框架,它們?cè)趯?duì)語言模型之間以及與語言模型交互進(jìn)行抽象時(shí)傾向于不同的理念。
本文對(duì)這些框架進(jìn)行了迄今為止最全面的綜述,采用了比現(xiàn)有討論更系統(tǒng)的分類法。除了提供用于對(duì)與大型語言模型之間以及與大型語言模型交互進(jìn)行抽象的框架情況的梳理之外,本文還提供了兩種分類體系,用于對(duì)抽象的各種方法和理念進(jìn)行推理:
語言模型系統(tǒng)接口模型(LMSI),一種新的七層抽象,受計(jì)算機(jī)系統(tǒng)和網(wǎng)絡(luò)中的開放系統(tǒng)互連(OSI)模型啟發(fā),用于對(duì)近幾個(gè)月出現(xiàn)的編程和交互框架進(jìn)行分層。這些層在語言模型抽象的整個(gè)層次結(jié)構(gòu)中從最高層抽象到最低層抽象依次呈現(xiàn)。 我們確定了五類語言模型抽象,它們?cè)谖覀兊木C述中執(zhí)行類似功能,對(duì)這些類別進(jìn)行了分類。這些類別將大致處于相同層的庫分組,并且大致按照從較高層抽象到較低層抽象的順序呈現(xiàn)。 這兩種分類體系——語言模型系統(tǒng)接口模型(LMSI)和語言模型抽象家族分類——通過它們對(duì)抽象層級(jí)的處理方式相互關(guān)聯(lián)。語言模型抽象家族的排列形成一個(gè)譜系,大致與LMSI模型的抽象層相對(duì)應(yīng)——特別是,它試圖描述向用戶或開發(fā)者暴露的細(xì)節(jié)程度。例如,在譜系的一端,較低層抽象涉及通過Python函數(shù)(例如,在LMSI的神經(jīng)網(wǎng)絡(luò)層)與大型語言模型的參數(shù)直接交互。在另一端,較高層抽象提供用于提示生成和優(yōu)化的工具,能夠?qū)Υ笮驼Z言模型的響應(yīng)進(jìn)行遞歸式優(yōu)化,而無需深入研究基礎(chǔ)大型語言模型或流程的底層技術(shù)復(fù)雜性(例如,在LMSI的優(yōu)化層或應(yīng)用層)。
語言模型系統(tǒng)接口模型(LMSI)
在我們對(duì)語言模型框架的研究過程中,我們觀察到一種趨勢(shì);我們可以大致將特定框架確定為高層抽象、低層抽象或混合層抽象。然而,如果不進(jìn)一步分類,在這種情況下“高”或“低”到底意味著什么并不明確。
受計(jì)算機(jī)系統(tǒng)和網(wǎng)絡(luò)中的OSI模型啟發(fā),我們提出了這些框架可能關(guān)注的不同功能層的概念,并且重要的是,它們可以很容易地在語言模型庫和框架的層次結(jié)構(gòu)中從高層到低層進(jìn)行組織。我們總共確定了語言模型框架通??刹僮?向用戶暴露的七層抽象。這些層表示抽象程度不斷提高,從直接與語言模型的架構(gòu)、權(quán)重和參數(shù)交互——這是最低層抽象,即神經(jīng)網(wǎng)絡(luò)層,到最高層抽象,即把啟用語言模型的應(yīng)用程序當(dāng)作一個(gè)黑箱來處理用戶提供的一般高層任務(wù),即用戶層。
我們認(rèn)為,除了實(shí)現(xiàn)對(duì)現(xiàn)有大型語言模型抽象框架進(jìn)行組織/分類的目標(biāo)之外,這些層有助于確定大型語言模型框架的不同重點(diǎn)和特性可以在何處相互分離。就像OSI模型的情況一樣,我們希望分層能夠讓框架開發(fā)者清楚地了解在合適的層級(jí)設(shè)計(jì)他們的抽象,以便可能利用其他框架中已經(jīng)實(shí)現(xiàn)的現(xiàn)有基礎(chǔ)設(shè)施——有效地分離關(guān)注點(diǎn),并允許框架在抽象邊界/接口處將專業(yè)工作轉(zhuǎn)移給其他框架。然而,在當(dāng)前階段,雖然許多框架處于較窄的層帶內(nèi),但有些框架跨越的范圍更廣,這通常反映了一種擴(kuò)展性設(shè)計(jì),其中高層抽象可以與低層特性以一種向開發(fā)者暴露的方式進(jìn)行交互。
下面列出了每層的描述和定義,而表1通過星級(jí)表示近期框架所側(cè)重的層。
- 神經(jīng)網(wǎng)絡(luò)層——直接訪問語言模型的架構(gòu)和權(quán)重/解碼組件。
- 提示層——通過應(yīng)用程序編程接口(API)、手動(dòng)聊天或其他界面向語言模型輸入文本,可能對(duì)輸入或輸出文本序列沒有限制。
- 提示約束層——對(duì)多組或多種類型的提示施加規(guī)則或結(jié)構(gòu)(例如通過模板),或者對(duì)輸出進(jìn)行約束和驗(yàn)證。
- 控制層——框架中支持控制流,如條件、循環(huán)、分發(fā)。
- 優(yōu)化層——基于某個(gè)指標(biāo)對(duì)語言模型或語言模型系統(tǒng)的某些方面進(jìn)行優(yōu)化。
- 應(yīng)用層——基于較低層構(gòu)建的庫、實(shí)用程序和應(yīng)用程序代碼,提供具有一定可配置性的通用現(xiàn)成解決方案。
- 用戶層——人機(jī)交互層,應(yīng)用程序直接根據(jù)人類指令執(zhí)行由語言模型驅(qū)動(dòng)的任務(wù)。
表1
五類語言模型框架
我們沒有按照抽象順序孤立地描述每個(gè)框架,而是確定了在我們的綜述中出現(xiàn)的幾類執(zhí)行類似功能的庫。這些類別將大致處于相同LMSI層的庫分組,并大致按照抽象程度遞增的順序呈現(xiàn)。
第一組框架是那些專注于受控生成(如Guidance和LMQL)的框架。這些框架能夠?qū)φZ言模型的輸出定義格式要求和其他約束(例如,通過正則表達(dá)式),這是圍繞語言模型構(gòu)建可靠系統(tǒng)的關(guān)鍵要素。在此基礎(chǔ)上,用于模式驅(qū)動(dòng)生成的庫(如OpenAI的函數(shù)調(diào)用模式和Marvin)允許用戶表達(dá)類型級(jí)別的輸出結(jié)構(gòu)(例如,作為Pydantic模式)。以DSPy為首的框架利用強(qiáng)大的模式和自然語言簽名抽象,專注于大型語言模型程序的編譯,圍繞將程序(其中大型語言模型調(diào)用是首要構(gòu)造)編譯為自動(dòng)生成的高質(zhì)量提示鏈展開。編譯驅(qū)動(dòng)策略與帶有預(yù)封裝模塊的提示工程工具(如LangChain和LlamaIndex)不同,在后者中,一組用于生成和解析提示的預(yù)封裝實(shí)用程序,以及用于將生成的響應(yīng)與其他語言模型調(diào)用或環(huán)境調(diào)用相連接的基本原語,可用于以更有意義的方式與語言模型交互。然而,這些工具的核心仍然依賴于手動(dòng)提示工程技術(shù)。在最高層,我們討論最具雄心的開放式代理框架(如AutoGPT和MetaGPT)和多代理聊天范式(如在CAMEL和AutoGEN中)。
表2(五類語言模型框架。注意:我們將最底層的基礎(chǔ)提示層設(shè)為灰色,并且不將其計(jì)入,因?yàn)樗皇呛?jiǎn)單地封裝了語言模型基本的文本輸入/輸出行為,沒有進(jìn)一步的抽象。點(diǎn)擊展開。)
0)基礎(chǔ)提示
我們?cè)谡Z言模型框架家族中不太愿意納入的最低層是在語言模型抽象框架出現(xiàn)之前的最先進(jìn)水平;基礎(chǔ)提示。
基礎(chǔ)提示只是描述了用戶在沒有任何額外框架的情況下一直能夠做到的事情,給定一個(gè)語言模型或語言模型的應(yīng)用程序編程接口(API),基礎(chǔ)提示可以被認(rèn)為是圍繞不同語言模型的簡(jiǎn)單包裝器,它們以統(tǒng)一的方式表達(dá)其最原始的接口(文本輸入,文本輸出)。這是OpenAI(和其他提供商)的API的核心,也是LangChain - core包中的一些主要抽象。對(duì)于某些應(yīng)用程序,這種原始形式為構(gòu)建手工制作的提示或構(gòu)建更高層抽象提供了足夠的靈活性。
1)受控生成
語言模型以統(tǒng)計(jì)上可能但不確定的方式完成文本。這意味著語言模型的響應(yīng)可能不可預(yù)測(cè),使其難以集成到其他工作流程中。一類庫通過應(yīng)用基于模板或約束的受控生成技術(shù)來緩解此類擔(dān)憂,例如Outlines、Guidance和LMQL。這些庫使用模板引擎,其中模板表達(dá)帶有“空位”的提示,以供生成內(nèi)容來填充。這些語言模型生成的內(nèi)容可以綁定到模板變量,并代入后續(xù)生成過程,引導(dǎo)輸出。這些庫還支持將輸出約束為諸如子集成員、模式和長度等限制。LMQL利用大型語言模型的解碼組件來實(shí)現(xiàn)這種過濾,而Outlines修改語言模型修改令牌概率的能力以支持輸出約束。這些框架往往跨越神經(jīng)網(wǎng)絡(luò)層到提示約束層。
@lmql.query LMQL程序是用嵌入在Python中的領(lǐng)域特定語言(DSL)表示的,其中頂級(jí)字符串(可能包含用方括號(hào)表示且?guī)в锌蛇x類型注釋的“空位”)是用于補(bǔ)全的提示,而附加約束由where語句表示。LMQL引入了急切和部分求值語義的概念,它保守地近似判斷對(duì)于特定生成,約束是否成立。利用這種語義,LMQL可以生成特定于模型的令牌掩碼,以在解碼過程中修剪搜索空間。
Outline具有類似的能力,能夠通過正則表達(dá)式有效地引導(dǎo)生成,它也能支持LMQL所支持的許多約束。在內(nèi)部,Outline將神經(jīng)文本生成表述為有限狀態(tài)機(jī)狀態(tài)之間的轉(zhuǎn)換。它在模型詞匯表上建立索引,并通過操縱模型對(duì)令牌的概率來有效地保證生成文本的結(jié)構(gòu)。該庫還具有許多基于上下文無關(guān)語法(CFG)引導(dǎo)生成的內(nèi)置特性,以實(shí)現(xiàn)更實(shí)用的用法,例如使用Jinjia模板語言進(jìn)行提示生成,或使用json和Pydantic進(jìn)行對(duì)象類型約束和模式定義。
然而,就LMQL而言,對(duì)于像GPT - 3和GPT - 4這樣的托管端點(diǎn),可能無法輕易訪問語言模型的解碼組件。此外,這些庫使用的一些“填空”策略更適合用于生成任務(wù)的語言模型,而對(duì)于聊天模型(例如GPT - 4)則不太適用。
2)模式驅(qū)動(dòng)生成
受控生成的一種更精細(xì)的抽象是模式驅(qū)動(dòng)生成。在這里,語言模型與其宿主編程接口之間的邊界受到一些預(yù)定義模式或一些對(duì)象規(guī)范語言(通常是JSON)的約束。這與Guidance和LMQL不同,在后者中,如果用戶希望得到JSON輸出,就必須指定JSON骨架及其內(nèi)部?jī)?nèi)容限制。與受控生成相比,基于模式的方法可以更容易地集成到其他現(xiàn)有的編程邏輯中。然而,對(duì)生成內(nèi)容類型的控制粒度可能更有限。這些庫位于提示約束層,因?yàn)榉夏J绞窍拗普Z言模型輸出的一種方式。
在Outlines、其他庫(如Marvin和Instructor)以及最近的LangChain和Llamaindex中,這一步驟被進(jìn)一步抽象。用戶可以使用數(shù)據(jù)驗(yàn)證庫Pydantic指定數(shù)據(jù)結(jié)構(gòu)作為某些語言模型的輸出模式(模型級(jí)抽象)。在內(nèi)部,這些庫通過預(yù)構(gòu)建提示將模式編碼為自然語言指令,要求語言模型以正確、可解析的格式輸出。然而,對(duì)于Marvin和Instructor,有一些支持來利用基礎(chǔ)語言模型供應(yīng)商提供的更高級(jí)功能(例如,OpenAI的函數(shù)調(diào)用以確保可解析性)。預(yù)計(jì)這些庫也將采用OpenAI的新JSON模式,以降低輸出不可解析的可能性。
例如,Instructor為OpenAI API提供了一個(gè)替代客戶端,它接受使用Pydantic指定的響應(yīng)模型。在其實(shí)現(xiàn)中,它支持三種查詢語言模型的模式,即json、函數(shù)調(diào)用和工具使用,每種模式都對(duì)應(yīng)于OpenAI支持的等效API。為了在解析過程中引導(dǎo)語言模型,Instructor有一些內(nèi)部提示來告知語言模型模式和輸出格式。
在LangChain中,當(dāng)偶爾出現(xiàn)驗(yàn)證錯(cuò)誤時(shí),支持更復(fù)雜的重試解析器,但輸出不是通過OpenAI的函數(shù)調(diào)用API進(jìn)行提示,而更多是通過自然語言指令。
除了輸出數(shù)據(jù)模式,一些庫在大型語言模型交互的背景下增加了對(duì)功能模式(函數(shù)級(jí)抽象)的支持,允許程序員用自然語言模式或簽名對(duì)函數(shù)進(jìn)行聲明式注釋,以表示其高層意圖。這個(gè)想法最早出現(xiàn)在2023年初的DSP項(xiàng)目中,它是DSPy框架的前身。在DSP中,用戶可以指定函數(shù)輸入和輸出的類型(在最簡(jiǎn)單的情況下:“問題,思考 -> 答案”),其中包括對(duì)參數(shù)含義和相關(guān)前綴的人類層面描述。輸入和輸出類型的集合形成了一個(gè)DSP模板,從中可以誘導(dǎo)出一個(gè)可調(diào)用的Python函數(shù)。Marvin最近通過其“AI函數(shù)”簡(jiǎn)化了這種模式,其中程序員對(duì)輸入和輸出類型以及函數(shù)文檔字符串的注釋用于根據(jù)一些運(yùn)行時(shí)輸入生成提示,以便從語言模型中提取輸出。
在DSPy中,開發(fā)者同樣可以指定自然語言簽名,以聲明式地定義大型語言模型需要解決的(子)任務(wù),這些任務(wù)是從整體任務(wù)的簡(jiǎn)短描述以及輸入和輸出字段的描述中推導(dǎo)出來的。
3)編譯大型語言模型程序
函數(shù)的自然語言規(guī)范的具體化在很大的搜索空間中可能會(huì)有所不同,這取決于所提供的示例(例如,少樣本對(duì)比零樣本)、提示策略(例如,思維鏈)、外部數(shù)據(jù)源(檢索增強(qiáng)生成,RAG),甚至是多跳方法(例如,思維程序)。在Marvin中,具體化策略是固定的,開發(fā)者通常局限于使用所提供的現(xiàn)成解決方案。然而對(duì)于DSPy來說,自然語言簽名與具體的查詢策略是分離的,這意味著要使用一個(gè)簽名,用戶必須聲明一個(gè)帶有該簽名的模塊。這些模塊還可以選擇性地帶有示例(或演示)列表。DSPy還包括許多復(fù)雜的模塊,如思維鏈(ChainOfThought)、思維程序(ProgramOfThought)、多鏈比較(MultiChainComparison)和反應(yīng)(ReAct),它們可以將這些提示或交互策略應(yīng)用于任意的DSPy簽名,而無需手動(dòng)進(jìn)行提示工程。
DSPy模塊可以像PyTorch一樣使用運(yùn)行時(shí)定義(define - by - run)接口進(jìn)行組合,允許構(gòu)建任意的流程。DSPy中的一個(gè)強(qiáng)大概念是能夠編譯一個(gè)流程,通過選擇超參數(shù)(如指令/提示或演示)甚至微調(diào)來對(duì)其進(jìn)行優(yōu)化。這個(gè)優(yōu)化過程是通過提詞器(teleprompter)進(jìn)行的,它表示一種特定的優(yōu)化策略。例如,自舉少樣本(BootstrapFewShot)提詞器從少量輸入(注意并不嚴(yán)格需要輸出)中引導(dǎo)示例到模塊流程。這個(gè)提詞器在輸入上運(yùn)行流程,并選擇滿足某些可定制啟發(fā)式的演示。
與其他技術(shù)相比,基于編譯的系統(tǒng)有幾個(gè)明顯的優(yōu)勢(shì),例如能夠在不重新定義基礎(chǔ)簽名的情況下改變不同的提示策略,以及通過優(yōu)化提高性能。然而,要獲得編譯的好處,需要涉及不少框架搭建工作,并且需要對(duì)底層的DSPy系統(tǒng)有一定的了解。對(duì)于需要大量與語言模型 - 環(huán)境交互的項(xiàng)目,或者不需要太多優(yōu)化的簡(jiǎn)單項(xiàng)目,在現(xiàn)階段采用這個(gè)系統(tǒng)可能具有挑戰(zhàn)性。
4)提示工程實(shí)用程序
另一類庫(包括LangChain和LlamaIndex)采取了一種非常不同的方法,通過大量預(yù)封裝模塊,這些庫為使用語言模型的程序形成了“開箱即用”的解決方案。與DSPy等相比,例如,這些庫往往有許多可用功能,更依賴提示工程,并專注于與大型語言模型本身的一些特定交互模型。例如,LangChain包括管理提示模板、輸出解析、內(nèi)存和檢索模型集成的實(shí)用程序。
LangChain還提供了預(yù)構(gòu)建的抽象,利用這些實(shí)用程序來提供與語言模型和外部環(huán)境進(jìn)行交互的更復(fù)雜模式。由LangChain的領(lǐng)域特定語言——LangChain表達(dá)式語言(LCEL)指定的代理(Agent)和鏈(Chain)抽象,增強(qiáng)了實(shí)用程序的功能和可復(fù)用性,以解決更復(fù)雜的任務(wù)。一般來說,LCEL允許用戶指定一組語言模型可用于與某些外部環(huán)境交互的工具或動(dòng)作,以及一個(gè)預(yù)設(shè)提示和輸出解析器來執(zhí)行編排步驟,確定要調(diào)用哪些動(dòng)作/工具以及如何將代理結(jié)果傳遞到代理循環(huán)的后續(xù)迭代。LangChain提供了大量預(yù)設(shè)提示和輸出解析器(例如用于反應(yīng)(ReAct)、思維鏈、自我詢問等),可以幫助開發(fā)者快速構(gòu)建適用于許多用例的復(fù)雜代理系統(tǒng)。然而,LCEL主要作為簡(jiǎn)單代理循環(huán)上的輕量級(jí)語法糖,雖然組件是可定制的,但在撰寫本文時(shí),它們相對(duì)于原生實(shí)現(xiàn)并沒有實(shí)現(xiàn)更高級(jí)的功能,而且代理循環(huán)本身的交互模式在某種程度上是固定的。
在提示工程領(lǐng)域,LangChain和LlamaIndex都為執(zhí)行文本提示工程提供了增強(qiáng)功能。除了基于替換的方法外,LangChain還支持一些提示優(yōu)化技術(shù)。這類優(yōu)化可能涉及選擇有效示例或?qū)Ω鞣N“超參數(shù)”進(jìn)行微調(diào)。LangChain還配備了示例選擇器(Example Selectors),它們利用相似性(可能來自向量數(shù)據(jù)庫)或更簡(jiǎn)單的度量(如n - gram重疊)等指標(biāo)來提煉可能提高整體性能結(jié)果的示例子集。然而,這個(gè)過程是獨(dú)立于語言模型和提示策略本身進(jìn)行的。此外,示例選擇器需要大量完全標(biāo)注的示例來選擇一個(gè)有益的子集。
作為一個(gè)以提示為中心的框架,LangChain還通過其LangSmith平臺(tái)開發(fā)了一個(gè)用于托管提示的生態(tài)系統(tǒng)。提示可以托管在LangSmith中以便與他人共享。當(dāng)與LCEL以及LangChain的代理和鏈抽象結(jié)合使用時(shí),提示可以通過提示重用為有趣的語言模型交互模式提供支持。
5)開放式代理/流程
我們?cè)谧詈笠徊糠謱㈤_放式代理和多代理聊天歸為一類,因?yàn)樗鼈冏鳛樵诖硐到y(tǒng)層面運(yùn)行的框架具有共同性質(zhì)。
- i)開放式代理/流程 除了預(yù)封裝實(shí)用程序外,LangChain還配備了現(xiàn)成的代理流程或“鏈”,可用于運(yùn)行帶有多種提示策略的復(fù)雜語言模型查詢,這些策略是開箱即用的。然而,與AutoGPT等其他框架相比,LangChain缺少可以調(diào)用其他外部工具的預(yù)構(gòu)建流程。相比之下,像AutoGPT這樣的框架專注于構(gòu)建在解決給定任務(wù)時(shí)需要最少人工干預(yù)的代理系統(tǒng)。在內(nèi)部,該工具可以訪問一組預(yù)先存在的工具(可能包括計(jì)算器、互聯(lián)網(wǎng)訪問、本地文件訪問等)、一組驅(qū)動(dòng)語言模型執(zhí)行指定任務(wù)的固定提示,以及短期和長期記憶的固定模型。雖然你可以為特定目的定制這些工具,但它們?cè)诳蓴U(kuò)展性方面并非設(shè)計(jì)得很方便,即你不能輕易地替換提示模式或方便地與現(xiàn)有程序集成。然而,這種不足被開箱即用的解決方案所平衡,該解決方案直接擴(kuò)展了基礎(chǔ)語言模型,集成了許多工具來高效地解決任務(wù)。
在這個(gè)類別中另一個(gè)值得注意的工具是MetaGPT,盡管這個(gè)框架在本文的其他部分也有涉及。MetaGPT以能夠?qū)ⅰ耙恍行枨蟆弊鳛檩斎氩⑤敵鐾暾绦?、研究文檔等而自豪。在內(nèi)部,它為不同的語言模型交互上下文分配角色,如軟件工程師、項(xiàng)目經(jīng)理、架構(gòu)師和質(zhì)量保證人員。與AutoGPT類似,這些角色具有內(nèi)置在工具中的固定提示和能力,開箱即可使用。MetaGPT在內(nèi)部編碼了一個(gè)標(biāo)準(zhǔn)操作程序(SOP),它呈現(xiàn)了一些想象中的致力于解決你任務(wù)的公司,并將這個(gè)SOP作為一種“算法”來編排不同角色之間的協(xié)作。MetaGPT允許通過添加新角色并定義提示、能力及其與SOP的集成來進(jìn)行擴(kuò)展。這類似于AutoGPT中的插件概念。
BabyAGI也旨在利用語言模型自動(dòng)執(zhí)行一組任務(wù)。本質(zhì)上,語言模型使用可用的執(zhí)行代理來編排如何將任務(wù)分解為子任務(wù)以及如何完成這些子任務(wù)。
- ii)多代理聊天 AutoGen和MetaGPT是兩個(gè)主要的對(duì)具有不同角色和特性的多個(gè)代理之間的聊天和通信進(jìn)行抽象的框架。在AutoGen中,基礎(chǔ)抽象由助手代理(Assistant Agents)和用戶代理(UserProxyAgents)組成,助手代理是圍繞語言模型的包裝器,用戶代理可以執(zhí)行代碼或與人類交互,允許代理系統(tǒng)與外部環(huán)境交互。為了便于多個(gè)代理交互的可能性,還可以引入群聊管理器(GroupChatManager)來管理不同聊天代理之間的交互方式。因此,鑒于能夠組合不同代理及其交互,該庫可以支持多種對(duì)話模式。MetaGPT采取了略有不同的方法。從表面上看,它只是一個(gè)用于執(zhí)行由人工智能驅(qū)動(dòng)任務(wù)的自動(dòng)化工具,但在其核心,它展示了有趣的多代理抽象。從概念上講,MetaGPT由一個(gè)標(biāo)準(zhǔn)操作程序(SOP)和一組角色(類似于AutoGen中的代理)組成。SOP包含關(guān)于管理不同角色/代理如何相互交互的指令,并封裝了將分解的子任務(wù)分配給適當(dāng)角色的分工。該框架提供了一個(gè)具有共享知識(shí)和上下文的全局環(huán)境,其中每個(gè)角色/代理可以被指定為“訂閱”被認(rèn)為相關(guān)的知識(shí)子集。
結(jié)論
近幾個(gè)月來,大語言模型編程抽象領(lǐng)域有了顯著發(fā)展,涌現(xiàn)出大量流行框架。我們提出了一個(gè)7層抽象模型來對(duì)所評(píng)估的庫進(jìn)行分類,并描繪了我們所觀察到的關(guān)注點(diǎn)分離情況。然后,我們從內(nèi)在和外在特征方面研究了五類框架。特別是,它們的內(nèi)在特征包括是否易于擴(kuò)展、它們支持哪些類型的特征以確??煽炕蚍€(wěn)定的輸出,以及它們的結(jié)構(gòu)如何以便能夠與其他庫和框架交互。外在特征包括社區(qū)和生態(tài)系統(tǒng)方面,例如,可復(fù)用的提示策略,或基于該框架構(gòu)建的可用于更豐富和更特定領(lǐng)域任務(wù)的庫。為了通過這些特征和質(zhì)量的視角對(duì)這些近期框架進(jìn)行概覽,我們?cè)诒?中列出了它們各自的實(shí)用程序/庫/生態(tài)系統(tǒng)、可靠性、性能、可移植性和可擴(kuò)展性。
譯自(有刪改):https://www.twosigma.com/articles/a-guide-to-large-language-model-abstractions
本文轉(zhuǎn)載自公眾號(hào)AIGC最前線 作者:實(shí)習(xí)小畢
