大語言模型（LLMs），以及一般的語言模型（LMs），催生了一種新的編程方式，其中“指令”不再是明確的應用程序編程接口（APIs），而是像英語這樣的自然語言語句。該領域（一個被稱為提示工程的新領域）的專家通過組合特定的關鍵詞、提示格式，甚至認知模型來對他們的語言模型進行編程——或者從語言模型中引出特定行為。

過去兩年表明，語言模型可以產生廣泛的變革性影響，但在無縫集成到更大的程序環(huán)境方面存在固有局限。它們對事實和先前交互的記憶不完善，不能可靠地遵循邏輯結構，無法與外部環(huán)境交互或執(zhí)行計算，并且對提示方式很敏感。為解決這些局限，已經(jīng)出現(xiàn)了十多個流行的框架，它們在對語言模型之間以及與語言模型交互進行抽象時傾向于不同的理念。

本文對這些框架進行了迄今為止最全面的綜述，采用了比現(xiàn)有討論更系統(tǒng)的分類法。除了提供用于對與大型語言模型之間以及與大型語言模型交互進行抽象的框架情況的梳理之外，本文還提供了兩種分類體系，用于對抽象的各種方法和理念進行推理：

語言模型系統(tǒng)接口模型（LMSI），一種新的七層抽象，受計算機系統(tǒng)和網(wǎng)絡中的開放系統(tǒng)互連（OSI）模型啟發(fā)，用于對近幾個月出現(xiàn)的編程和交互框架進行分層。這些層在語言模型抽象的整個層次結構中從最高層抽象到最低層抽象依次呈現(xiàn)。 我們確定了五類語言模型抽象，它們在我們的綜述中執(zhí)行類似功能，對這些類別進行了分類。這些類別將大致處于相同層的庫分組，并且大致按照從較高層抽象到較低層抽象的順序呈現(xiàn)。 這兩種分類體系——語言模型系統(tǒng)接口模型（LMSI）和語言模型抽象家族分類——通過它們對抽象層級的處理方式相互關聯(lián)。語言模型抽象家族的排列形成一個譜系，大致與LMSI模型的抽象層相對應——特別是，它試圖描述向用戶或開發(fā)者暴露的細節(jié)程度。例如，在譜系的一端，較低層抽象涉及通過Python函數(shù)（例如，在LMSI的神經(jīng)網(wǎng)絡層）與大型語言模型的參數(shù)直接交互。在另一端，較高層抽象提供用于提示生成和優(yōu)化的工具，能夠對大型語言模型的響應進行遞歸式優(yōu)化，而無需深入研究基礎大型語言模型或流程的底層技術復雜性（例如，在LMSI的優(yōu)化層或應用層）。

語言模型系統(tǒng)接口模型（LMSI）

在我們對語言模型框架的研究過程中，我們觀察到一種趨勢；我們可以大致將特定框架確定為高層抽象、低層抽象或混合層抽象。然而，如果不進一步分類，在這種情況下“高”或“低”到底意味著什么并不明確。

受計算機系統(tǒng)和網(wǎng)絡中的OSI模型啟發(fā)，我們提出了這些框架可能關注的不同功能層的概念，并且重要的是，它們可以很容易地在語言模型庫和框架的層次結構中從高層到低層進行組織。我們總共確定了語言模型框架通常可操作/向用戶暴露的七層抽象。這些層表示抽象程度不斷提高，從直接與語言模型的架構、權重和參數(shù)交互——這是最低層抽象，即神經(jīng)網(wǎng)絡層，到最高層抽象，即把啟用語言模型的應用程序當作一個黑箱來處理用戶提供的一般高層任務，即用戶層。

我們認為，除了實現(xiàn)對現(xiàn)有大型語言模型抽象框架進行組織/分類的目標之外，這些層有助于確定大型語言模型框架的不同重點和特性可以在何處相互分離。就像OSI模型的情況一樣，我們希望分層能夠讓框架開發(fā)者清楚地了解在合適的層級設計他們的抽象，以便可能利用其他框架中已經(jīng)實現(xiàn)的現(xiàn)有基礎設施——有效地分離關注點，并允許框架在抽象邊界/接口處將專業(yè)工作轉移給其他框架。然而，在當前階段，雖然許多框架處于較窄的層帶內，但有些框架跨越的范圍更廣，這通常反映了一種擴展性設計，其中高層抽象可以與低層特性以一種向開發(fā)者暴露的方式進行交互。

下面列出了每層的描述和定義，而表1通過星級表示近期框架所側重的層。

• 神經(jīng)網(wǎng)絡層——直接訪問語言模型的架構和權重/解碼組件。
• 提示層——通過應用程序編程接口（API）、手動聊天或其他界面向語言模型輸入文本，可能對輸入或輸出文本序列沒有限制。
• 提示約束層——對多組或多種類型的提示施加規(guī)則或結構（例如通過模板），或者對輸出進行約束和驗證。
• 控制層——框架中支持控制流，如條件、循環(huán)、分發(fā)。
• 優(yōu)化層——基于某個指標對語言模型或語言模型系統(tǒng)的某些方面進行優(yōu)化。
• 應用層——基于較低層構建的庫、實用程序和應用程序代碼，提供具有一定可配置性的通用現(xiàn)成解決方案。
• 用戶層——人機交互層，應用程序直接根據(jù)人類指令執(zhí)行由語言模型驅動的任務。

表1

五類語言模型框架

我們沒有按照抽象順序孤立地描述每個框架，而是確定了在我們的綜述中出現(xiàn)的幾類執(zhí)行類似功能的庫。這些類別將大致處于相同LMSI層的庫分組，并大致按照抽象程度遞增的順序呈現(xiàn)。

第一組框架是那些專注于受控生成（如Guidance和LMQL）的框架。這些框架能夠對語言模型的輸出定義格式要求和其他約束（例如，通過正則表達式），這是圍繞語言模型構建可靠系統(tǒng)的關鍵要素。在此基礎上，用于模式驅動生成的庫（如OpenAI的函數(shù)調用模式和Marvin）允許用戶表達類型級別的輸出結構（例如，作為Pydantic模式）。以DSPy為首的框架利用強大的模式和自然語言簽名抽象，專注于大型語言模型程序的編譯，圍繞將程序（其中大型語言模型調用是首要構造）編譯為自動生成的高質量提示鏈展開。編譯驅動策略與帶有預封裝模塊的提示工程工具（如LangChain和LlamaIndex）不同，在后者中，一組用于生成和解析提示的預封裝實用程序，以及用于將生成的響應與其他語言模型調用或環(huán)境調用相連接的基本原語，可用于以更有意義的方式與語言模型交互。然而，這些工具的核心仍然依賴于手動提示工程技術。在最高層，我們討論最具雄心的開放式代理框架（如AutoGPT和MetaGPT）和多代理聊天范式（如在CAMEL和AutoGEN中）。

表2（五類語言模型框架。注意：我們將最底層的基礎提示層設為灰色，并且不將其計入，因為它只是簡單地封裝了語言模型基本的文本輸入/輸出行為，沒有進一步的抽象。點擊展開。）

0）基礎提示

我們在語言模型框架家族中不太愿意納入的最低層是在語言模型抽象框架出現(xiàn)之前的最先進水平；基礎提示。

基礎提示只是描述了用戶在沒有任何額外框架的情況下一直能夠做到的事情，給定一個語言模型或語言模型的應用程序編程接口（API），基礎提示可以被認為是圍繞不同語言模型的簡單包裝器，它們以統(tǒng)一的方式表達其最原始的接口（文本輸入，文本輸出）。這是OpenAI（和其他提供商）的API的核心，也是LangChain - core包中的一些主要抽象。對于某些應用程序，這種原始形式為構建手工制作的提示或構建更高層抽象提供了足夠的靈活性。

1）受控生成

語言模型以統(tǒng)計上可能但不確定的方式完成文本。這意味著語言模型的響應可能不可預測，使其難以集成到其他工作流程中。一類庫通過應用基于模板或約束的受控生成技術來緩解此類擔憂，例如Outlines、Guidance和LMQL。這些庫使用模板引擎，其中模板表達帶有“空位”的提示，以供生成內容來填充。這些語言模型生成的內容可以綁定到模板變量，并代入后續(xù)生成過程，引導輸出。這些庫還支持將輸出約束為諸如子集成員、模式和長度等限制。LMQL利用大型語言模型的解碼組件來實現(xiàn)這種過濾，而Outlines修改語言模型修改令牌概率的能力以支持輸出約束。這些框架往往跨越神經(jīng)網(wǎng)絡層到提示約束層。

@lmql.query LMQL程序是用嵌入在Python中的領域特定語言（DSL）表示的，其中頂級字符串（可能包含用方括號表示且?guī)в锌蛇x類型注釋的“空位”）是用于補全的提示，而附加約束由where語句表示。LMQL引入了急切和部分求值語義的概念，它保守地近似判斷對于特定生成，約束是否成立。利用這種語義，LMQL可以生成特定于模型的令牌掩碼，以在解碼過程中修剪搜索空間。

Outline具有類似的能力，能夠通過正則表達式有效地引導生成，它也能支持LMQL所支持的許多約束。在內部，Outline將神經(jīng)文本生成表述為有限狀態(tài)機狀態(tài)之間的轉換。它在模型詞匯表上建立索引，并通過操縱模型對令牌的概率來有效地保證生成文本的結構。該庫還具有許多基于上下文無關語法（CFG）引導生成的內置特性，以實現(xiàn)更實用的用法，例如使用Jinjia模板語言進行提示生成，或使用json和Pydantic進行對象類型約束和模式定義。

然而，就LMQL而言，對于像GPT - 3和GPT - 4這樣的托管端點，可能無法輕易訪問語言模型的解碼組件。此外，這些庫使用的一些“填空”策略更適合用于生成任務的語言模型，而對于聊天模型（例如GPT - 4）則不太適用。

2）模式驅動生成

受控生成的一種更精細的抽象是模式驅動生成。在這里，語言模型與其宿主編程接口之間的邊界受到一些預定義模式或一些對象規(guī)范語言（通常是JSON）的約束。這與Guidance和LMQL不同，在后者中，如果用戶希望得到JSON輸出，就必須指定JSON骨架及其內部內容限制。與受控生成相比，基于模式的方法可以更容易地集成到其他現(xiàn)有的編程邏輯中。然而，對生成內容類型的控制粒度可能更有限。這些庫位于提示約束層，因為符合模式是限制語言模型輸出的一種方式。

在Outlines、其他庫（如Marvin和Instructor）以及最近的LangChain和Llamaindex中，這一步驟被進一步抽象。用戶可以使用數(shù)據(jù)驗證庫Pydantic指定數(shù)據(jù)結構作為某些語言模型的輸出模式（模型級抽象）。在內部，這些庫通過預構建提示將模式編碼為自然語言指令，要求語言模型以正確、可解析的格式輸出。然而，對于Marvin和Instructor，有一些支持來利用基礎語言模型供應商提供的更高級功能（例如，OpenAI的函數(shù)調用以確保可解析性）。預計這些庫也將采用OpenAI的新JSON模式，以降低輸出不可解析的可能性。

例如，Instructor為OpenAI API提供了一個替代客戶端，它接受使用Pydantic指定的響應模型。在其實現(xiàn)中，它支持三種查詢語言模型的模式，即json、函數(shù)調用和工具使用，每種模式都對應于OpenAI支持的等效API。為了在解析過程中引導語言模型，Instructor有一些內部提示來告知語言模型模式和輸出格式。

在LangChain中，當偶爾出現(xiàn)驗證錯誤時，支持更復雜的重試解析器，但輸出不是通過OpenAI的函數(shù)調用API進行提示，而更多是通過自然語言指令。

除了輸出數(shù)據(jù)模式，一些庫在大型語言模型交互的背景下增加了對功能模式（函數(shù)級抽象）的支持，允許程序員用自然語言模式或簽名對函數(shù)進行聲明式注釋，以表示其高層意圖。這個想法最早出現(xiàn)在2023年初的DSP項目中，它是DSPy框架的前身。在DSP中，用戶可以指定函數(shù)輸入和輸出的類型（在最簡單的情況下：“問題，思考 -> 答案”），其中包括對參數(shù)含義和相關前綴的人類層面描述。輸入和輸出類型的集合形成了一個DSP模板，從中可以誘導出一個可調用的Python函數(shù)。Marvin最近通過其“AI函數(shù)”簡化了這種模式，其中程序員對輸入和輸出類型以及函數(shù)文檔字符串的注釋用于根據(jù)一些運行時輸入生成提示，以便從語言模型中提取輸出。

在DSPy中，開發(fā)者同樣可以指定自然語言簽名，以聲明式地定義大型語言模型需要解決的（子）任務，這些任務是從整體任務的簡短描述以及輸入和輸出字段的描述中推導出來的。

3）編譯大型語言模型程序

函數(shù)的自然語言規(guī)范的具體化在很大的搜索空間中可能會有所不同，這取決于所提供的示例（例如，少樣本對比零樣本）、提示策略（例如，思維鏈）、外部數(shù)據(jù)源（檢索增強生成，RAG），甚至是多跳方法（例如，思維程序）。在Marvin中，具體化策略是固定的，開發(fā)者通常局限于使用所提供的現(xiàn)成解決方案。然而對于DSPy來說，自然語言簽名與具體的查詢策略是分離的，這意味著要使用一個簽名，用戶必須聲明一個帶有該簽名的模塊。這些模塊還可以選擇性地帶有示例（或演示）列表。DSPy還包括許多復雜的模塊，如思維鏈（ChainOfThought）、思維程序（ProgramOfThought）、多鏈比較（MultiChainComparison）和反應（ReAct），它們可以將這些提示或交互策略應用于任意的DSPy簽名，而無需手動進行提示工程。

DSPy模塊可以像PyTorch一樣使用運行時定義（define - by - run）接口進行組合，允許構建任意的流程。DSPy中的一個強大概念是能夠編譯一個流程，通過選擇超參數(shù)（如指令/提示或演示）甚至微調來對其進行優(yōu)化。這個優(yōu)化過程是通過提詞器（teleprompter）進行的，它表示一種特定的優(yōu)化策略。例如，自舉少樣本（BootstrapFewShot）提詞器從少量輸入（注意并不嚴格需要輸出）中引導示例到模塊流程。這個提詞器在輸入上運行流程，并選擇滿足某些可定制啟發(fā)式的演示。

與其他技術相比，基于編譯的系統(tǒng)有幾個明顯的優(yōu)勢，例如能夠在不重新定義基礎簽名的情況下改變不同的提示策略，以及通過優(yōu)化提高性能。然而，要獲得編譯的好處，需要涉及不少框架搭建工作，并且需要對底層的DSPy系統(tǒng)有一定的了解。對于需要大量與語言模型 - 環(huán)境交互的項目，或者不需要太多優(yōu)化的簡單項目，在現(xiàn)階段采用這個系統(tǒng)可能具有挑戰(zhàn)性。

4）提示工程實用程序

另一類庫（包括LangChain和LlamaIndex）采取了一種非常不同的方法，通過大量預封裝模塊，這些庫為使用語言模型的程序形成了“開箱即用”的解決方案。與DSPy等相比，例如，這些庫往往有許多可用功能，更依賴提示工程，并專注于與大型語言模型本身的一些特定交互模型。例如，LangChain包括管理提示模板、輸出解析、內存和檢索模型集成的實用程序。

LangChain還提供了預構建的抽象，利用這些實用程序來提供與語言模型和外部環(huán)境進行交互的更復雜模式。由LangChain的領域特定語言——LangChain表達式語言（LCEL）指定的代理（Agent）和鏈（Chain）抽象，增強了實用程序的功能和可復用性，以解決更復雜的任務。一般來說，LCEL允許用戶指定一組語言模型可用于與某些外部環(huán)境交互的工具或動作，以及一個預設提示和輸出解析器來執(zhí)行編排步驟，確定要調用哪些動作/工具以及如何將代理結果傳遞到代理循環(huán)的后續(xù)迭代。LangChain提供了大量預設提示和輸出解析器（例如用于反應（ReAct）、思維鏈、自我詢問等），可以幫助開發(fā)者快速構建適用于許多用例的復雜代理系統(tǒng)。然而，LCEL主要作為簡單代理循環(huán)上的輕量級語法糖，雖然組件是可定制的，但在撰寫本文時，它們相對于原生實現(xiàn)并沒有實現(xiàn)更高級的功能，而且代理循環(huán)本身的交互模式在某種程度上是固定的。

在提示工程領域，LangChain和LlamaIndex都為執(zhí)行文本提示工程提供了增強功能。除了基于替換的方法外，LangChain還支持一些提示優(yōu)化技術。這類優(yōu)化可能涉及選擇有效示例或對各種“超參數(shù)”進行微調。LangChain還配備了示例選擇器（Example Selectors），它們利用相似性（可能來自向量數(shù)據(jù)庫）或更簡單的度量（如n - gram重疊）等指標來提煉可能提高整體性能結果的示例子集。然而，這個過程是獨立于語言模型和提示策略本身進行的。此外，示例選擇器需要大量完全標注的示例來選擇一個有益的子集。

作為一個以提示為中心的框架，LangChain還通過其LangSmith平臺開發(fā)了一個用于托管提示的生態(tài)系統(tǒng)。提示可以托管在LangSmith中以便與他人共享。當與LCEL以及LangChain的代理和鏈抽象結合使用時，提示可以通過提示重用為有趣的語言模型交互模式提供支持。

5）開放式代理/流程

我們在最后一部分將開放式代理和多代理聊天歸為一類，因為它們作為在代理系統(tǒng)層面運行的框架具有共同性質。

• i）開放式代理/流程 除了預封裝實用程序外，LangChain還配備了現(xiàn)成的代理流程或“鏈”，可用于運行帶有多種提示策略的復雜語言模型查詢，這些策略是開箱即用的。然而，與AutoGPT等其他框架相比，LangChain缺少可以調用其他外部工具的預構建流程。相比之下，像AutoGPT這樣的框架專注于構建在解決給定任務時需要最少人工干預的代理系統(tǒng)。在內部，該工具可以訪問一組預先存在的工具（可能包括計算器、互聯(lián)網(wǎng)訪問、本地文件訪問等）、一組驅動語言模型執(zhí)行指定任務的固定提示，以及短期和長期記憶的固定模型。雖然你可以為特定目的定制這些工具，但它們在可擴展性方面并非設計得很方便，即你不能輕易地替換提示模式或方便地與現(xiàn)有程序集成。然而，這種不足被開箱即用的解決方案所平衡，該解決方案直接擴展了基礎語言模型，集成了許多工具來高效地解決任務。

在這個類別中另一個值得注意的工具是MetaGPT，盡管這個框架在本文的其他部分也有涉及。MetaGPT以能夠將“一行需求”作為輸入并輸出完整程序、研究文檔等而自豪。在內部，它為不同的語言模型交互上下文分配角色，如軟件工程師、項目經(jīng)理、架構師和質量保證人員。與AutoGPT類似，這些角色具有內置在工具中的固定提示和能力，開箱即可使用。MetaGPT在內部編碼了一個標準操作程序（SOP），它呈現(xiàn)了一些想象中的致力于解決你任務的公司，并將這個SOP作為一種“算法”來編排不同角色之間的協(xié)作。MetaGPT允許通過添加新角色并定義提示、能力及其與SOP的集成來進行擴展。這類似于AutoGPT中的插件概念。

BabyAGI也旨在利用語言模型自動執(zhí)行一組任務。本質上，語言模型使用可用的執(zhí)行代理來編排如何將任務分解為子任務以及如何完成這些子任務。

• ii）多代理聊天 AutoGen和MetaGPT是兩個主要的對具有不同角色和特性的多個代理之間的聊天和通信進行抽象的框架。在AutoGen中，基礎抽象由助手代理（Assistant Agents）和用戶代理（UserProxyAgents）組成，助手代理是圍繞語言模型的包裝器，用戶代理可以執(zhí)行代碼或與人類交互，允許代理系統(tǒng)與外部環(huán)境交互。為了便于多個代理交互的可能性，還可以引入群聊管理器（GroupChatManager）來管理不同聊天代理之間的交互方式。因此，鑒于能夠組合不同代理及其交互，該庫可以支持多種對話模式。MetaGPT采取了略有不同的方法。從表面上看，它只是一個用于執(zhí)行由人工智能驅動任務的自動化工具，但在其核心，它展示了有趣的多代理抽象。從概念上講，MetaGPT由一個標準操作程序（SOP）和一組角色（類似于AutoGen中的代理）組成。SOP包含關于管理不同角色/代理如何相互交互的指令，并封裝了將分解的子任務分配給適當角色的分工。該框架提供了一個具有共享知識和上下文的全局環(huán)境，其中每個角色/代理可以被指定為“訂閱”被認為相關的知識子集。

結論

近幾個月來，大語言模型編程抽象領域有了顯著發(fā)展，涌現(xiàn)出大量流行框架。我們提出了一個7層抽象模型來對所評估的庫進行分類，并描繪了我們所觀察到的關注點分離情況。然后，我們從內在和外在特征方面研究了五類框架。特別是，它們的內在特征包括是否易于擴展、它們支持哪些類型的特征以確保可靠或穩(wěn)定的輸出，以及它們的結構如何以便能夠與其他庫和框架交互。外在特征包括社區(qū)和生態(tài)系統(tǒng)方面，例如，可復用的提示策略，或基于該框架構建的可用于更豐富和更特定領域任務的庫。為了通過這些特征和質量的視角對這些近期框架進行概覽，我們在表3中列出了它們各自的實用程序/庫/生態(tài)系統(tǒng)、可靠性、性能、可移植性和可擴展性。

譯自（有刪改）:https://www.twosigma.com/articles/a-guide-to-large-language-model-abstractions

本文轉載自公眾號AIGC最前線  作者：實習小畢

原文鏈接：??https://mp.weixin.qq.com/s/1ei4Vns2VTbHBco7DF2BEQ???