轉自 AI大模型實驗室

LangChain 由 Harrison Chase 于 2022 年 10 月推出，是一個開源編排框架，用于使用 LLM 開發應用程序，推出后迅速脫穎而出，截至 2023 年 6 月，它是 GitHub 上增長最快的開源項目。

現在 LangChain 0.1.0 版本發布了，這意味著終于有穩定版可用于生產了！下面是關于 LangChain 0.1.0 版本發布的具體信息。

今天，我們非常激動地宣布，LangChain 0.1.0 版本正式發布了，這是我們推出的首個穩定版本。這個版本能夠兼容以前的版本，提供了 Python 和 JavaScript 兩種編程語言的支持，并通過改進功能和文檔，使得我們的產品更加專注和高效。LangChain 的這個穩定版本不僅贏得了開發者們的信任，還為我們提供了一個系統且安全地更新和完善這個軟件庫的機會。

#01介紹

LangChain 已經誕生一年多，它在成長為 LLM 應用的首選框架過程中，經歷了諸多變化。就像我們一個月前預覽的那樣，我們近期對 LangChain 的包架構做了重大調整，目的是為了更好地組織這個項目，同時也加強了它的基礎結構。

具體來說，我們進行了兩項重要的架構變革：一是分離出了 langchain-core 核心模塊；二是將合作伙伴的包分為 langchain-community 社區版或獨立的合作伙伴包。

提醒一下，langchain-core 包含了主要的抽象概念、接口和核心功能。這部分代碼已經非常穩定，并在過去一個多月里遵循了更加嚴格的版本管理政策。

但是，LangChain 本身之前一直停留在 0.0.x 版本。所有版本都處于初級階段，這帶來了一些挑戰：

用戶擔心更新后可能會遇到兼容性問題。

為了盡量避免破壞性的更新和頻繁的棄用通知，我們采取了全面維護的策略，結果卻使得 LangChain 變得龐大且不穩定。

不過，從今天開始，隨著 LangChain 0.1.0 版本的發布，所有未來的版本更新都將遵循新的版本標準。具體是：

任何對公共 API（Application Programming Interface，應用程序編程接口）造成破壞性更改的操作，都會導致次要版本號的提升（即版本號的第二位數字）。

任何錯誤修復或新增功能都會導致補丁版本號的提升（即版本號的第三位數字）。

我們期望這些結合之前的架構變革，能夠：

清晰地通報任何重大更改，讓開發者能夠放心更新

為我們提供正式淘汰及清理老舊代碼的途徑，減少代碼冗余

更加負責任地處理集成問題（這些集成的 SDK 變化通常和 LangChain 一樣迅速）

即便在我們推出 0.2 版本之后，我們依然承諾維護 0.1 版本的一個分支，但僅針對關鍵 bug 提供修補。

在我們將包結構調整為穩定的 0.1 版本的過程中，我們抓住機會與數百名開發者交流，了解他們選擇使用 LangChain 的原因和喜歡的特點。這些反饋指導了我們的發展方向和重點。我們也借此機會在下文提到的核心領域，使 Python 和 JavaScript 版本達到一致。

盡管某些集成和更特定的鏈可能針對特定語言，但核心抽象和關鍵功能在 Python 和 JavaScript 的包中均有同等實現。

我們希望分享我們的發現以及不斷完善 LangChain 的計劃。我們相信，分享這些經驗將增加我們決策和思考方式的透明度，讓更多人能更好地使用、理解并貢獻于 LangChain。畢竟，LangChain 的一大部分是我們的社區，包括廣大用戶群和 2000 多名貢獻者，我們希望每個人都能參與到這個旅程中來。

#02第三方集成

LangChain 最受用戶青睞的特點之一是其易用性，它讓人們可以輕松地在任何技術棧上開始構建應用。我們提供了近 700 種集成，涵蓋從 LLM 到向量存儲，再到 Agent 使用的各種工具。

LangChain 常被視為構建 LLM 應用所需各種組件的 “粘合劑”，因此，構建一個強大的集成生態系統對我們來說非常重要。

大約一個月前，我們開始實施一些改變，旨在提高集成的健壯性、穩定性、可擴展性以及整體開發者體驗。我們把所有第三方集成都移到了 langchain-community 中，這樣我們就能集中處理與集成相關的工作。同時，我們也開始將個別集成分離到它們自己的包中。

到目前為止，我們已經對約 10 個包進行了這樣的處理，包括 OpenAI、Google 和 Mistral 等。這樣做的好處之一是能更好地管理依賴關系 —— 之前所有依賴都是可選的，這在安裝特定版本時可能會帶來問題。現在，將集成放入各自的包中，我們可以對它們的要求進行更嚴格的版本控制，從而簡化安裝過程。另一個好處是版本控制。第三方集成有時會變更，可能需要進行重大更改。現在，這些更改可以在獨立的集成包中得到適當的版本反映。

#03可觀測性

構建 LLM 應用時，系統核心將會是一個非確定性組件。這些模型時常會產生出乎意料的結果，因此，清楚地了解系統中正在發生的情況是很重要的。

我們希望使 LangChain 盡可能地易于觀測和調試，無論是通過我們的架構設計，還是我們所開發的工具。

我們以幾種方式實現了這一目標。

主要方法之一是開發了 LangSmith。LangSmith 的一個核心優勢是為你的 LLM 應用提供一流的調試體驗。我們詳細記錄了正在執行的每個步驟、每個步驟的輸入、輸出、所需時間等數據。我們以用戶友好的方式展示這些信息，讓你能夠識別哪些步驟耗時最長，進入一個調試區域來處理 LLM 意外反饋的問題，追蹤 Token 使用情況等。

即便在私有測試階段，LangSmith 就已經受到了極大的歡迎，我們正在大量投入資源以提高其可擴展性，以便未來幾個月發布公共測試版，并最終普及它。我們還支持企業版本，為那些對數據隱私要求嚴格的企業提供虛擬專用云（VPC）內部署服務。

我們還通過其他途徑增強了可觀測性。長期以來，我們為整個處理流程提供了詳細和調試模式，支持不同級別的日志記錄。最近，我們還引入了一種新方法，可以可視化用戶所創建的鏈條，并獲取鏈條中使用的所有提示信息。

#04可組合性

盡管預先構建的鏈條有助于快速入門，但我們常見團隊希望突破現有架構，定制屬于自己的鏈條。這種定制不僅限于提示，還包括編排的各個部分。

在過去幾個月里，我們大力投資于 LangChain 表達式語言（LCEL）。LCEL 允許自由組合各種序列，為數據工程流程帶來了類似于數據編排工具的諸多好處，如批處理、并行處理和回退策略。

LCEL 還提供了一些特定于 LLM 工作負載的獨特好處，主要包括之前提到的 LLM 專用的可觀測性，以及稍后將在本文中介紹的流處理功能。

LCEL 的核心組件位于 langchain-core 中。我們已經開始在 LangChain 中為特定鏈條創建更高級別的入口點。這些新的入口點將逐步取代現有的（現稱為 “遺留”）鏈條，因為基于 LCEL 構建的鏈條將自帶流處理、易于定制、可觀測性、批處理和重試等功能。我們的目標是實現平滑過渡。以前你可能需要這樣做：

ConversationalRetrievalChain.from_llm(llm,…)

而現在，我們希望簡化為：

create_conversational_retrieval_chain(llm,…)

在底層，它將創建一個特定的 LCEL 鏈條并返回。如果你想修改邏輯，也沒問題！因為一切都是用 LCEL 編寫的，修改其中一部分而無需繼承類或覆蓋方法變得很容易。

LangChain 中有許多鏈條被廣泛使用。在有替代構造函數存在且經過使用和充分測試之前，我們不會棄用遺留版本的鏈條。

#05流式處理

LLM 有時反應較慢。向最終用戶展示正在進行的工作，而不是讓他們盯著空白屏幕，十分重要。這可以通過從 LLM 流式傳輸 Token，或者流式傳輸更長時間運行的鏈條或 Agent 的中間步驟來實現。

我們在這兩方面都進行了大量投資。所有用 LCEL 構建的鏈條均提供標準的 stream 和 astream 方法，我們還做了大量工作，確保流處理不僅限于 LLM 調用階段（比如在輸出解析器中也實現了流處理）。所有鏈條還提供了一個標準的 astream_log 方法，用于流式傳輸 LCEL 鏈條中的所有步驟。這樣就可以輕松過濾這些步驟，獲取中間步驟和其他信息。

流式處理（包括 Token 和中間步驟）是大多數 LLM 應用中非常重要的用戶體驗部分，而通過 LangChain，你可以輕松實現這一功能。

#06輸出解析

LangChain 的一個主要功能是 “工具使用”，即利用 LLM 來操作其他工具。

確保 LLM 返回的信息格式適合后續應用并便于操作，這對于 LLM 的實際應用非常重要。

我們圍繞這一需求，提出了 “輸出解析器” 的概念，并致力于提升開發者的體驗。

實現這一目標的關鍵方式之一是通過 OpenAI 的函數調用功能。我們不僅簡化了指定輸出格式的過程 —— 可以選擇使用 Pydantic、JSON schema 或特定的函數，還方便了開發者處理模型的響應。

對于不支持 OpenAI 函數調用的模型，我們還支持多種編碼方法（如 JSON、XML、Yaml），以便在使用提示進行操作時，能夠更靈活地處理。使用提示時，還需要精確的指令來引導 LLM 作出恰當的回應 —— 所有的輸出解析器都配備了一個 get_format_instructions 方法，用于獲取這些指令。

我們還對輸出解析器引入了更高級的功能，例如允許它們在生成過程中實時傳輸部分結果，以此提升用戶體驗。這包括從 JSON、XML 和 CSV 等結構化格式中實時傳輸部分結果。但輸出解析有時頗具挑戰性，例如要解析一個 JSON 數據塊，大多數 JSON 解析器需要完整的數據塊。我們的許多輸出解析器都內置了處理這種部分解析的邏輯。

#07檢索

我們發現開發者正在構建的主流應用類型之一是能與他們自己的私有數據進行交互的應用。

將個人數據與 LLM 結合起來，是 LangChain 的一個核心特性。

這通常涉及兩個環節：數據攝取（準備數據）和數據檢索（獲取數據），我們已經開發了相應的功能。

在數據攝取方面，關鍵步驟之一是將待處理的文本分割成小塊。雖然這聽起來簡單，但實際上如何分割取決于文檔的類型，這需要細致的考量。我們提供了 15 種不同的文本分割器，針對特定類型的文檔（如 HTML 和 Markdown）進行了優化，使開發者能更好地控制這一過程。

需要注意的是，相關數據可能會頻繁變化，我們的數據攝取系統適用于大規模的應用。我們設計了一個索引 API，允許重新攝取內容，同時忽略那些未發生變化的部分，這樣可以為處理大量數據節省時間和成本。

在檢索方面，我們不僅開發了更加先進、適合生產環境的檢索方法，還實現了一系列來自學術界的高級檢索策略，如 FLARE 和 Hyde，以及我們自創的方法，如 Parent Document 和 Self-Query。我們還參考了其他行業的解決方案，如 Multi-Query（這是一種在搜索中常用的查詢擴展方法）。

此外，我們特別關注生產環境中的需求，比如為每個用戶單獨檢索數據，這對于存儲多用戶文檔的應用來說至關重要。

重要的是，盡管 LangChain 提供了構建高級檢索系統所需的一切組件，但我們并不限制使用方式。這就激發了其他許多庫在 LangChain 基礎上發展，提供更加專業化的檢索方法，例如 EmbedChain 和 GPTResearcher。

#08Agent

LangChain 最初因其在代理性工作負載方面的表現而受到關注。這主要體現在兩個方面：

工具使用：讓 LLM 調用某個函數或工具。

推理：優化 LLM 的使用方式，使其能夠合理決定是否多次調用工具，以及調用的順序。

在工具使用方面，我們重點覆蓋了以下幾個關鍵組件：

與眾多第三方工具的集成。

確保 LLM 的響應能夠匹配這些工具的輸入要求。

提供靈活的方式來定制工具的調用方式（LCEL）。

在推理方面，我們開發了幾種不同的 “Agent” 方法。這些方法大致上是讓 LLM 在一個循環中運行，每次循環中決定是否需要調用某個工具，然后觀察該工具的執行結果。我們從一開始就整合了 ReAct 這種早期的提示策略，并迅速加入了多種類型，包括使用 OpenAI 函數調用、使用新的工具調用 API、優化對話等等。

通過靈活、可擴展的工具支持和先進的推理能力，LangChain 已成為 LLM 能夠采取行動的首選方法。

與檢索功能類似，雖然 LangChain 提供了構建 Agent 的基礎模塊，但我們也看到了一些更具主見的框架在其基礎上發展，例如 CrewAI，它在 LangChain 基礎上發展，為處理多 Agent 工作負載提供了更簡便的界面。

#09LangChain 0.2

雖然我們剛發布了 LangChain 0.1 版本，但我們已經開始著手準備 0.2 版本。我們關注的一些重點包括：

使用 LCEL 重構遺留的鏈條，使其支持更高效的流處理和調試

引入新類型的鏈條和 Agent

提升我們的生產數據攝取能力

移除舊的和不常用的功能

值得注意的是，盡管我們渴望去除一些舊代碼，使 LangChain 更加精簡和專注，但我們也想為仍在使用舊版本的用戶提供支持。因此，我們將把 0.1 版本作為一個穩定分支保留至少三個月（在此期間將修復關鍵錯誤）。我們計劃對每個穩定版本都采取這種策略。

如果你一直想參與貢獻，現在是個絕佳的時機。我們最近在 GitHub 上添加了一些適合新手入門的問題，可以作為你的起點。

#10其他

LangChain v0.1.0 的重點是提升穩定性，并專注于核心領域。現在我們已經確定了用戶喜歡 LangChain 的方面，我們可以在這些領域添加更先進、更完善的工具。

LangChain 受歡迎的主要原因之一是它對 Agent 的支持。大多數 Agent 主要是在某種循環中運行 LLM。目前，我們使用的唯一方法是 AgentExecutor。我們為 AgentExecutor 添加了許多參數和功能，但它仍然只是運行循環的一種方式。

我們很高興宣布，我們將發布 langgraph，這是一個新的庫，旨在創建語言 Agent 的圖形表示。

這將使用戶能夠創建更加定制化的循環行為。用戶可以定義明確的規劃步驟、反思步驟，或者輕松設置優先調用某個特定工具。

langgraph 的靈感來自于 Pregel 和 Apache Beam。它目前提供的接口風格類似于 NetworkX，功能和表現形式如下：

romlanggraph.graphimportEND,Graph

workflow=Graph()

workflow.add_node("agent",agent)
workflow.add_node("tools",execute_tools)

workflow.set_entry_point("agent")

workflow.add_conditional_edges(
"agent",
should_continue,
{
"continue":"tools",
"exit":END
}
)

workflow.add_edge('tools','agent')

chain=workflow.compile()

我們過去六個月一直在開發并與用戶進行測試。它目前支持 OpenGPT，并在未來幾周將添加更多示例和文檔。我們對此感到非常興奮！

#11結論

隨著生態系統的發展，LangChain 也取得了明顯的進步。我們非常感謝我們的社區和用戶的推動和共建。通過這次 0.1 版本的發布，我們深入了解了用戶在 LLM 框架中的需求，并保持致力于滿足這些需求。隨著社區需求的變化（或者如果我們遺漏了什么），我們期待聽到你的反饋，以便做出改進。千里之行，始于足下，讓我們從 0.1 版本開始。

LangChain 是一個開源編排框架，用于使用 LLM 開發應用程序。LangChain 的工具和 API 在基于 Python 和 Javascript 的庫中使用，可以簡化構建聊天機器人和虛擬代理等 LLM 驅動型應用程序的過程。LangChain 由 Harrison Chase 于 2022 年 10 月推出，推出后迅速脫穎而出：截至 2023 年 6 月，它是 Github 上增長最快的開源項目。現在 LangChain 0。1。0 版本發布了，這意味著終于有穩定版可用于生產了！下面是關于 LangChain 0。1。

審核編輯：湯梓紅