編者按：生成式人工智能的爆發有可能顛覆很多行業，其中之一就是軟件業。大語言模型（LLM）的興起讓相關應用也迎來了爆發，科技巨頭與初創企業紛紛推出了各種 LLM 應用，那麼這些應用都使用了什麼樣的工具，採取了什麼樣的設計模式呢？本文進行了總結。文章來自編譯。

圖片來源：由無界 AI 生成

大型語言模型（LLM）是開發軟件的強大的新原語。但由於 LLM 實在是太新了，並且行為與普通的計算資源實在是太不一樣了，所以怎麼使用 LLM 未必總是一目瞭然。

在這篇文章里，我們將分享新興 LLM 應用棧的參考架構。該架構將展示我們見過的人工智能初創企業與頂尖科技公司使用的最常見的系統、工具以及設計模式。這個技術棧還比較原始，可能會隨着底層技術的進步而出現重大變化，但我們希望它能為現在從事 LLM 開發的開發者提供有用的參考。

這項工作基於與人工智能初創企業的創始人以及工程師的對話。我們特別有賴於以下人員的意見：包括 Ted Benson、Harrison Chase、Ben Firshman 、Ali Ghodsi 、Raza Habib、Andrej Karpathy 、Greg Kogan、Jerry Liu、 Moin Nadeem、Diego Oppenheimer、Shreya Rajpal、Ion Stoica 、Dennis Xu、 Matei Zaharia 以及 Jared Zoneraich。感謝你們的幫助！

LLM技術棧

LLM 應用技術棧的當前版是這樣的：

灰色框是關鍵組件，帶箭頭的代表不同的數據流：黑色虛線為應用開發者提供的用於限定輸出的上下文數據，黑色實線為傳給LLM的提示既少樣本例子，藍色實線為用戶查詢，紅色實線為返回給用戶的輸出

以下是每個項目的鏈接列表，可供快速參考：

、應用棧各關鍵組件的常用工具/系統

用 LLM 進行開發的方法有很多種，包括從零開始訓練模型、微調開源模型或利用託管 API。我們在這裏展示的技術棧是基於上下文學習（in-context learning），我們觀察到大多數開發者都開始利用的這種設計模式（並且目前只能通過基礎模型實現）。

下一節將簡要解釋一下這種設計模式。

設計模式：上下文學習

上下文學習的核心思想是利用現成的 LLM（也就是不需要任何的微調），然後通過巧妙的提示和對私有“上下文”數據的調節來控制其行為。

比方說，假設你正在開發一個聊天機器人來回答有關一系列法律文件的問題。簡單的做法呢，你可以把所有文檔都粘貼到 ChatGPT 或 GPT-4 提示裏面，然後再詢問相關問題。這對於規模非常小的數據集也許適用，但沒法擴展。最大的 GPT-4 模型只能處理約 50 頁的輸入文本，當接近這個所謂的上下文窗口限制時，性能（通過推理時間和準確性來衡量）會嚴重下降。

上下文學習用一個巧妙的技巧解決了這個問題：它不是每次輸入 LLM 提示的時候都發送所有的文檔過去，而是只發送少數最相關的文檔。誰來幫助決定哪些是最相關的文檔？你猜對了……LLM。

從非常高的層面而言，這個工作流可以分為三個階段：

• 數據預處理/嵌入：該階段要將私有數據（在這裏的例子中也就是法律文檔）存儲起來以供稍後檢索。一般而言，文檔會被分成塊，傳送給嵌入模型，然後存儲在所謂的向量數據庫的專用數據庫之中。
• 提示構造/檢索：當用戶提交查詢（在本例中為法律問題）時，應用會構造一系列的提示，然後提交給該語言模型。編譯過的提示通常會與開發者硬編碼的提示模板結合；有效輸出的示例叫做少樣本示例；任何必要信息均通過外部 API 檢索獲取；以及從向量數據庫檢索到的一組相關文檔獲取。
• 提示執行/推理：一旦提示被編譯過之後，將會被提交給預訓練的 LLM 進行推理，其中包括了專有模型 API 以及開源或自訓練的模型。在此階段，部分開發者還會增加日誌記錄、緩存以及驗證等運營性的系統。

這些看似工作量很大，但其實通常比其他替代方案更容易實現：訓練 LLM 或微調 LLM 本身其實更難。你不需要專門的機器學習工程師團隊來進行上下文學習。你也不需要託管自己的基礎設施或從 OpenAI 購買昂貴的專用實例。這種模式有效地將人工智能問題簡化為大多數初創企業以及大公司都已經知道如何解決的數據工程問題。對於相對較小的數據集，其性能也往往優於微調，因為在 LLM 通過微調記住特定信息之前，這些信息需要在訓練集至少出現過大概 10 次，並且上下文學習還可以近乎實時地合併新數據。

上下文學習其中一個最大問題是：如果我們只是改變底層模型來增加上下文窗口的話，會發生什麼？這確實是可能的，並且這是一個活躍的研究領域。但這需要一些權衡——主要是推理的成本和時間與提示的長度呈二次方關係。如今，即便是線性縮放（最好的理論結果）對於許多應用來說成本也過高。按照當前的 API 費率，超過 10000 個頁面的單次 GPT-4 查詢將花費數百美元。因此，我們預計對基於擴展的上下文窗口的技術棧不會進行大規模地更改，但我們會在後面對此進行進一步闡述。

在本文的其餘部分中，我們將使用上面的工作流作為指導來過一遍這個技術棧。

數據處理/嵌入

數據處理/嵌入部分：通過數據管道將數據交給嵌入模型進行向量化，然後存放到向量數據庫

LLM 應用的上下文數據包括文本文檔、PDF，甚至是 CSV 或 SQL 表等結構化格式。我們訪談過的開發者各自採用的數據加載和轉換（ETL）解決方案差異很大。大多數採用傳統的 ETL 工具，比方說 Databricks 或 Airflow。有些還利用了編排框架內置的文檔加載器，比方說 LangChain （由 Unstructed 提供支持）以及 LlamaIndex （由 Llama Hub 提供支持）。不過，我們認為這個技術棧的這一部分發展相對還不夠，並且有機會專門為 LLM 應用開發數據複製解決方案。

至於嵌入，大多數開發者使用 OpenAI API，尤其是 text-embedding-ada-002 模型。這個模型很容易使用（特別是如果你已經在使用其他的 OpenAI API 的話），可以提供相當好的結果，而且價格也越來越便宜了。有些大一點的企業也在探索 Cohere，其產品工作更加聚焦於嵌入，並且在某些場景下具有更好的性能。對於喜歡開源的開發人員來說，Hugging Face 的 Sentence Transformers 庫是一個標準。還可以根據不同的用例創建不同類型的嵌入；這是當今一種比較小眾的做法，但卻是一個很有前途的研究領域。

從系統的角度來看，預處理管道裏面最重要的部分是向量數據庫。向量數據庫要負責高效存儲、比較和檢索多達數十億的嵌入（也就是向量）。我們在市場上看到的最常見的選擇是 Pinecone。它是默認設置的，因為完全是由雲託管的，因此很容易上手，並且具備大型企業在生產當中所需的許多功能（比方說，良好的規模性能、單點登錄以及正常運行時間服務等級協議）。

不過，還有大量可用的向量數據庫。值得注意的包括：

• Weaviate 、Vespa 以及 Qdrant 等開源系統：這些系統通常具有出色的單節點性能，並且可以針對特定應用進行定製，因此受到喜歡開發定製平台的經驗豐富的人工智能團隊的歡迎。
• Faiss 等本地向量管理庫：這些庫擁有豐富的開發者經驗，並且對於小型應用和開發實驗來說很容易啟動。但這些未必能大規模替代完整的數據庫。
• pgvector 之類的 OLTP 擴展：對於看到每一個數據庫形態的漏洞並嘗試插入 Postgres 的開發者，或從單個雲提供商購買大部分數據基礎設施的企業來說，這是一個很好的向量支持解決方案。從長遠來看，尚不清楚緊耦合向量與標量工作負載是否有意義。

展望未來，大多數開源向量數據庫公司都在開發雲產品。我們的研究表明，在可能用例的廣泛設計空間里，在雲端實現強大的性能是一個非常困難的問題。因此，選項集在短期內可能不會發生巨大變化，但從長遠來看可能會發生變化。關鍵問題是向量數據庫是否會跟 OLTP 和 OLAP 數據庫類似，圍繞着一兩個流行系統進行整合。

還有一個問題懸而未決，隨着大多數模型可用上下文窗口的擴大，嵌入和向量數據庫將會如何演變。你很容易會說嵌入會變得不那麼重要，因為上下文數據可以直接放進提示裏面。不過，專家對這個主題的反饋表明情況恰恰相反——隨着時間的推移，嵌入管道可能會變得更加重要。大上下文窗口確實是強大工具，但也需要大量的計算成本。因此，有效利用這個窗口成為當務之急。我們可能會開始看到不同類型的嵌入模型變得流行，會直接針對模型相關性進行訓練，還會出現旨在實現和利用這一點的向量數據庫。

提示構建與獲取

提示構建與獲取

提示 LLM 並整合上下文數據的策略變得越來越複雜，而且也被用作產品差異化的來源，其作用也越來越重要。大多數開發者通過實驗簡單提示來開始新項目，這些提示包括直接指令（零樣本提示）或可能含部分示例的輸出（少樣本提示）。這些提示通常能生成好的結果，但達不到生產部署所需的準確性水平。

下一級別的提示技巧旨在讓模型響應是基於某些事實來源的，並提供模型未受訓練過的外部上下文。 《提示工程指南》列出了不少於 12 (!) 種更高級的提示策略，包括思維鏈、自洽、生成知識、思維樹、方向性刺激等等。可以結合使用這些策略，從而支持不同的 LLM 用例，比方說文檔問答、聊天機器人等。

這就是類似 LangChain 以及 LlamaIndex 這樣的編排框架的用武之地。這些框架把提示鏈的許多細節都給抽象出來；與外部 API 進行交互（包括確定何時需要 API 調用）；從向量數據庫檢索上下文數據；並在跨多個 LLM 的調用過程中維護好記憶。它們還為上述許多常見應用提供模板。其輸出是提交給語言模型的一個提示或一系列提示。這些框架獲得了業餘愛好者以及希望開發應用的初創企業的廣泛使用，其中 LangChain 是領先者。

LangChain 仍然是一個相對較新的項目（目前版本為 0.0.201），但我們已經開始看到用它開發的應用投入生產了。部分開發者，尤其是 LLM 的早期採用者，更喜歡在生產環境下切換成原始 Python，以消除額外的依賴性。但我們預計，對於大多數用例來說，這種 DIY 的做法會逐步減少，就像傳統的 Web 應用技術棧一樣。

眼尖的讀者會注意到編排框裏面有一個看似奇怪的條目：ChatGPT。在正常情況下，ChatGPT 屬於一個應用，而不是開發者工具。但它也可以作為 API 加以訪問。而且，如果你仔細觀察，它會執行一些與其他編排框架相同的功能，比方說：抽象出對定製提示的需求；維護狀態；通過插件、API 或其他來源檢索上下文數據。雖然 ChatGPT 不是此處列出的其他工具的直接競爭對手，但可以將其視為替代解決方案，並且最終可能成為提示構建可行、簡單的替代方案。

提示執行/推理

提示執行/推理

如今，OpenAI 已成為語言模型領域的領導者。幾乎我們採訪過的每一位開發者都用 OpenAI API 推出過新的 LLM 應用，通常它們用的是 gpt-4 或 gpt-4-32k 模型。這為應用性能提供了最佳用例場景，並且易於使用，因為它可以使用廣泛的輸入域，並且通常不需要微調或自託管。

一旦項目投入生產並開始規模化時，更廣泛的一系列選項就可以發揮作用。我們聽到的一些常見問題包括：

• 切換到 gpt-3.5-turbo：這個要比 GPT-4 便宜約 50 倍，而且速度明顯更快。許多應用並不需要 GPT-4 級別的準確性，但對於低延遲推理以及為免費用戶提供經濟有效的支持確實剛需。
• 用其他專有供應商（尤其是 Anthropic 的 Claude 模型）做實驗：Claude 提供了快速推理、GPT-3.5 級別的準確性、針對大客戶提供更多定製選項，還有高達 100k 的上下文窗口（儘管我們發現準確性會隨輸入長度的增加而降低）。
• 對開源模型的部分請求進行分類：這對於搜索或聊天等大容量 B2C 用例尤其有效，因為這些用例的查詢複雜性存在很大差異，並且需要以低廉的成本為免費用戶提供服務：

1）這個通常跟對開源基礎模型進行微調結合起來是最有意義的。我們不會在本文深入探討這個工具棧，但有越來越多的工程團隊正在使用 Databricks、 Anyscale 、Mosaic、Modal 以及 RunPod 等平台。

2）開源模型可以使用多個推理選項，包括 Hugging Face 與 Replicate 的簡單 API 接口；來自主要雲提供商的原始計算資源；以及像上面列舉的有更明確偏好的雲產品（opinionated cloud）。

目前，開源模型落後於專有產品，但差距正在開始縮小。Meta 的 LLaMa 模型為開源的準確性設定了新的標準，並催生了一系列的變體。由於 LLaMa 只被授權用於研究用途，許多新的提供商已經開始訓練替代的基礎模型（比方說 Together、Mosaic、Falcon、Mistral）。Meta 還在討論要不要推出 LLaMa 2 的真正開源版。

當（不是如果）開源 LLM 達到與 GPT-3.5 相當的準確度水平時，我們預計會看到文本也會出現自己的 Stable Diffusion 時刻，會有大規模實驗、共享以及微調模型的投入生產。像 Replicate 這樣的託管公司已經開始添加工具，好讓軟件開發人員更容易使用這些模型。開發人員越來越相信，更小的、經過微調的模型可以在範圍很窄的用例中達到最先進的精度。

我們採訪過的大多數開發者還沒有深入了解 LLM 的操作工具。緩存相對常見（通常基於 Redis），因為這可以縮短應用響應時間並降低成本。 Weights & Biases 與 MLflow （從傳統機器學習移植過來）或 PromptLayer 與 Helicone （專為LLM構建）等工具也得到相當廣泛的使用。這些工具可以記錄、跟蹤和評估 LLM 的輸出，通常是為了改進提示構造、調整管道或選擇模型的目的。還有許多用於驗證 LLM 輸出（比方說 Guardrails）或檢測提示注入攻擊（比方說 Rebuff）的新工具正在開發中。大多數這些操作工具都鼓勵使用自己的 Python 客戶端來執行 LLM 調用，因此了解這些解決方案會如何隨着時間推移而共存將會很有趣。

最後，LLM 應用的靜態部分（也就是模型以外的所有其他內容）也需要託管在某個地方。到目前為止，我們看到的最常見的解決方案是 Vercel 或主要雲提供商等標準選項。然而，正在出現兩個新的類別。像 Steamship 這樣的初創企業為 LLM 應用提供了端到端的託管，包括編排 ( LangChain )、多租戶數據上下文、異步任務、向量存儲以及密鑰管理等。Anyscale 與 Modal 等公司可讓開發者將模型和 Python 代碼託管在一個地方。

代理呢？

這個參考架構裏面缺少了一個最重要的組件，那就是人工智能代理框架。 大家對 AutoGPT 的評價是“一個讓 GPT-4 完全自動化的實驗性開源嘗試”，今年春天，它成為史上增長最快的 Github 庫，當今幾乎每個人工智能項目或初創企業都會納入某種形式的代理進去。

跟我們交談過的大多數開發者對代理的潛力都感到非常興奮。我們在這篇文章中描述的上下文學習模式可以有效解決幻覺和數據新鮮度問題，從而更好地支持內容生成任務。另一方面，代理為人工智能應用提供了一系列的全新功能：解決複雜問題，對外部世界採取行動，以及從部署后的經驗中學習。這是通過將高級推理/規劃、工具使用以及記憶/遞歸/自我反思想結合來做到這一點的。

因此，代理有潛力成為 LLM 應用架構的核心部分（或者甚至接管整個技術棧，如果你相信遞歸自我改進的話）。像 LangChain 這樣的現有框架已經融入了部分代理概念。只有一個問題：代理還沒有真正發揮作用。現如今，大多數代理框架都還處在概念驗證階段，雖然能夠提供令人難以置信的演示，但還不能夠可靠地、可重複地執行任務。我們正在密切關注代理在不久的將來如何發展。

展望未來

預訓練的人工智能模型是自互聯網以來最重要的軟件架構變化的體現。它們讓個人開發者能夠在幾天內開發出令人難以置信的人工智能應用，其能力甚至超越了過去大型團隊需要數月才能開發出來的有監督機器學習項目。

我們在這裏列出的工具和模式可能是整合 LLM 的起點，而不是最終狀態。在發生了重大變化（比方說，向模型訓練轉變）時，我們還會進行更新，並在有意義的地方發布新的參考架構。