读：迈向LangChain 0.1：LangChain-Core和LangChain-Community

LangChain 的目标始终是让LLMs能够尽可能轻松地开发上下文感知推理应用程序。LangChain 最初是作为一个副项目，纯粹作为一个 Python 包。在过去的一年里，它有了巨大的增长。这种增长迫使人们重新思考软件包的架构。我们一直在倾听社区的意见，并宣布将软件包重新架构为多个软件包（以完全向后兼容的方式完成），这是一条通往稳定版本的道路0.1，并借此机会强调已经出现的生态系统围绕浪链。

长话短说：

我们将旧langchain包拆分为三个独立的包以改善开发人员体验

1. langchain-core包含已作为标准出现的简单核心抽象，以及作为将这些组件组合在一起的方式的 LangChain 表达式语言。该软件包现已发布0.1，所有重大更改都将伴随着次要版本更新。

2. langchain-community包含所有第三方集成。我们将与合作伙伴合作，在下个月将关键集成拆分为独立的软件包。

3. langchain包含更高级别和特定于用例的链、代理和检索算法，它们是应用程序认知架构的核心。我们的目标是在一月初推出稳定0.1版本。langchain

这样做是为了支持围绕langchainLangChain Templates、LangServe、LangSmith 以及构建在其之上的其他软件包的新兴生态系统。

一切都以向后兼容的方式完成。

浪链SDK

LangChain Python和JavaScript SDK包含三个主要部分：

1. 构建 LLM 应用程序所需的通用组件的基本接口集以及将这些组件连接在一起的方法
2. 这些组件的集成和/或实现
3. 将这些组件组合在一起以完成特定用例的预配置方法
   以前，这三个部分都是同一个库的一部分。虽然这在一开始是有效的，但随着集成和用例的数量随着时间的推移而增加，复杂性已经变得不可持续。重新架构的一个主要部分是将它们分成不同的包：langchain-core、langchain-community和langchain。同时，我们希望意识到浪链庞大的用户基础，并尝试以向后兼容的方式做到这一点。

💡
我们的两个主要考虑因素是长期稳定性和可扩展性，以及短期向后兼容性。

浪链核心

langchain-core由核心抽象和将这些组件连接在一起的运行时（LangChain 表达式语言）组成。

简单和模块化的抽象

LangChain的基本抽象被设计为尽可能模块化和简单。这些抽象的示例包 language models, document loaders, embedding models, vectorstores, retrievers(括语言模型、文档加载器、嵌入模型、向量存储、检索器)等。拥有这些抽象的好处是任何提供者都可以实现所需的接口，然后轻松地在 LangChain 的其余部分中使用。

这些不是高级或端到端的抽象。它们只是代表必要组件的通用接口。例如：LLMs只是文本输入、文本输出。检索器输入文本，输出文档。

💡

这些低级且灵活的抽象使 LangChain 成为提供商和合作伙伴如何向整个 GenAI 生态系统公开其服务的标准，迄今为止已实现了 700 多种不同的集成。

许多框架和应用程序要么构建在这些抽象之上，要么可以与这些抽象进行互操作。这包括funcchain、langchain-decorators、gpt-researcher、gpt-engineer、llama-index、pandas-ai和CrewAI等框架。集成 LangChain 是确保您的工具与生态系统的大部分兼容的最有效方法。此外，超过3万个应用程序构建在LangChain之上。其中一些需要实现自定义组件。通过使我们的抽象变得简单和模块化，我们使这一切变得简单且轻松。

浪链表达语言

最初的 LangChain 版本并没有真正将这些基本组件连接在一起的通用方法。虽然口号是“通过可组合性构建LLM应用程序”，但最初的LangChain实际上并不是那么可组合。

💡
在过去的五个月里，我们努力添加一个可组合的运行时： LangChain表达式语言。
该运行时允许用户将任意序列组合在一起，并获得构建 LLM 应用程序时非常重要的几个好处。我们将这些序列称为“可运行序列”。

所有可运行对象都使用单一、批处理、流式传输和异步方法公开相同的接口。这种设计很有用，因为在构建 LLM 应用程序时，仅有一个同步接口是不够的。需要批处理才能有效处理许多输入。需要流式传输（以及中间步骤的流式传输）来向用户展示正在取得的进展。异步接口在投入生产时非常有用。LangChain 表达式语言允许您编写一次可运行程序并以多种不同的方式调用它，而不必为所有这些编写多个实现。

我们还编写了可运行程序来编排常见（但烦人）的任务。所有可运行对象都公开一个.map方法，该方法将该可运行对象并行应用于列表的所有元素。所有可运行对象还公开了一个.with_fallbacks方法，允许您定义后备以防可运行对象出现错误。这些是构建 LLM 应用程序时常见且有用的编排任务。

这些可运行程序也比以前的“链”更易于检查和定制。以前的链主要是langchain源代码中的自定义类。这使得理解它们内部发生的事情（包括使用了哪些提示）变得非常困难，并且更难以更改更改的行为（而不完全重写它们）。我们已经使用可运行对象重写了几个链（并且将来会重写更多）。Runnables 以声明性方式定义，这使得更容易理解逻辑和修改部分。

最后，可运行对象通过与LangSmith无缝集成而具有一流的可观察性。 LLM 应用程序的调试非常棘手。了解步骤的确切顺序是什么、输入到底是什么以及输出到底是什么可以大大提高您的提示速度。我们建立了 LangSmith 来极大地促进这一点——稍后会详细介绍。

单独包装的好处

这些抽象和运行时非常稳定，每当我们进行更改时，我们基本上都是以向后兼容的方式进行的。尽管如此，由于这些对 LangChain 生态系统至关重要，我们希望对这些抽象的更改特别小心并进行沟通。截至今天，这些抽象是langchain-core刚刚发布的0.1版本的一部分。也就是说langchain-core，0.1未来的任何重大更改都将伴随着次要版本的提升。这为这些核心抽象创造了稳定性，这将使其他人有信心在它们之上进行构建。

浪链社区

浪链很大一部分是我们的合作伙伴。我们有近 700 个集成，从文档加载器到 LLM、矢量存储到工具包。在所有情况下，我们都努力使添加集成尽可能容易，并感谢社区和我们的合作伙伴与我们合作。

尽管大量的集成选择为开发人员提供了支持，但它也有其缺点。通过如此多的集成，我们使所有依赖项都成为可选的（以使 LangChain 变得轻量级）。不幸的是，这使得了解给定集成需要哪些依赖项变得令人困惑。在同一个包中拥有如此多的集成也使得几乎不可能对它们进行正确的版本控制。底层集成本身正在快速变化（考虑到该领域的变化速度，这是必然的现实）。这导致了这些集成的不稳定，因为很难知道何时发生了变化。由于这些集成与 LangChain 的其他部分捆绑在一起，因此导致了整个包的不稳定。有了如此多的集成，这些集成自然具有广泛的可靠性和稳健性。如果它们都在一个包中，那么开发人员就无法可靠地知道哪些集成得到了良好的支持和良好的测试。

我们很高兴地宣布对 LangChain 架构进行一些更改，以解决这些问题。

首先，在最近的版本中，我们已将所有集成移至单独的langchain-community包中。这将有助于分离和区分集成代码——这通常需要不同的设置、不同的测试实践和不同的维护。同样，这是以完全向后兼容的方式完成的。

特定于集成的包

在接下来的几周内，我们将致力于与一些最大的受众和最关键的功能进行分离集成。这些将存在于独立的包中以进行特定的集成。例如：langchain-openai、langchain-anthropic等。这些包将驻留在 LangChain monorepo 中或位于它们自己的单独存储库中（取决于集成合作伙伴的意愿）。这将带来几个好处。它将让我们自己对这些软件包进行版本控制，如果发生重大更改，它们可以通过适当的版本升级来反映。它将简化测试过程，增加这些关键集成的测试覆盖范围。它将使我们能够使这些包所需的第三方依赖项，使安装更容易。对于拆分到自己的存储库中的软件包，它将让其他公司拥有自己的集成。

💡
LangChain 的最大优势之一是提供了大量的集成。这一步让周围的开发者体验变得更好。

LangChain

包中剩下的langchain将是链、代理、高级检索方法以及构成应用程序认知架构的其他通用编排部分。

其中一些将是旧的遗留链，例如ConversationalRetrievalChain，这是我们最受欢迎的用于检索增强生成的链之一。我们将继续支持和维护这些类型的连锁店。不过，我们将越来越多地转向使用 LangChain 表达式语言构建的链。

由于上一节中列出的许多原因，我们默认使用 LangChain 表达式语言。最重要的是创建新链的便捷性、所涉及步骤的透明度、编辑这些步骤的便捷性以及流式传输、批处理和异步接口的易用性。

在过去的几个月里，我们主要致力于让 LangChain 表达式语言langchain-core处于一个稳固的位置。既然我们相信情况确实如此，我们将更加关注更高层次的抽象和链（全部由 LangChain 表达式语言提供支持）。

例子

让我们看看这在实践中是什么样子的！为此，我们可以查看最近添加的用于回复电子邮件的模板。让我们看一下导入，看看我们从每个包中导入了什么：

from langchain_core.messages import AIMessage, HumanMessage
from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder
from langchain_core.tools import tool

我们正在从中langchain_core进口一些东西。首先，我们导入诸如AIMessage和HumanMessage之类的消息类型，我们将使用它们来抽象不同模型提供者如何处理这些对象。接下来，将导入ChatPromptTemplate和MessagesPlaceholder。这些是一种封装获取用户输入并生成传递给聊天模型的消息列表所需逻辑的方法。最后，我们将导入tool. 这是一个装饰器，我们可以放在任何函数上，自动将其变成 LangChain 工具对象。所有这些对象都是使用 LangChain 的核心。

from langchain_community.chat_models import ChatOpenAI
from langchain_community.tools.gmail import (
    GmailCreateDraft,
    GmailGetMessage,
    GmailGetThread,
    GmailSearch,
    GmailSendMessage,
)

我们langchain_community正在导入第三方集成。首先，对于 OpenAI，我们将使用他们的聊天模型。接下来，我们导入一堆用于使用Gmail. 这些是基础 LangChain 抽象的具体实例（分别为ChatModel和Tool）。

from langchain.agents import AgentExecutor
from langchain.agents.format_scratchpad import format_to_openai_function_messages
from langchain.agents.output_parsers import OpenAIFunctionsAgentOutputParser
from langchain.tools.render import format_tool_to_openai_function

我们从中langchain进口一些东西。首先，我们导入AgentExecutor. 这是运行代理和工具的特定认知架构。接下来，我们导入 utils 以使用特定类型的代理（使用 OpenAI Functions 的代理）。这包括 (a) 将消息（代理可能采取的中间步骤）格式化agent_scratchpad为传递给聊天模型的逻辑，(b) 将 LLM 的输出解析为代理操作的输出解析器，以及 © 函数将工具列表转换为 OpenAI 函数期望的格式。

以前，所有这些都是从同一个langchain包导入的，尽管它们代表三种不同类型的导入（基本逻辑、第三方集成和认知架构）。拆分的部分价值langchain在于让人们更清楚如何思考每种类型的模块。

Python 和 JS 的对等

我们收到了很多关于 Python 和 JS 包以及它们如何相互关联的问题。以这种方式拆分包（langchain-core、langchain-community和langchain）可以解释我们的哲学。

langchain-core两种语言之间的功能已经非常接近了。保持 Python 和 JavaScript 包功能对等是我们的首要任务。我们正在研究可序列化语法（我们已经在某些地方使用了）；维护核心功能的跨语言支持非常重要。

关于langchain-community（及其自己的软件包）中的集成，其中大部分将由任一语言自行决定，并且预计不会全部移植。我们有兴趣实现一些关键的功能平等（目前主要是LLMs提供商）。

langchain处于中间的某个位置 - 它并不像现在那样接近功能对等langchain-core，但它比langchain-community.

LangChain实验

langchain-experimental将继续作为放置更多实验工具、chain和Agent的地方。“实验性”可以有多种含义。目前，大多数实现langchain-experimental要么是（1）更新、更“新颖”的想法，我们希望鼓励人们使用和尝试，但不确定它们是否是正确的抽象，或者（2）潜在的有风险，可能会引入 CVE（Python REPL，编写和执行 SQL）。我们将这些工具、链和代理分开，以向最终用户传达它们的实验性质。

LangChain模板

两个月前，我们推出了LangChain 模板，作为开始构建 GenAI 应用程序的最简单方法。这些是可以使用 LangServe 轻松部署的端到端应用程序。langchain它们在一些方面与库中的链和代理不同。

首先，它们不是 Python 库的一部分，而是下载的代码和应用程​​序的一部分。这有一个巨大的好处，因为它们很容易修改。随着时间的推移，我们观察到的主要事情之一是，当用户将 LangChain 应用程序投入生产时，他们必须对他们开始的链或代理进行一些定制。至少他们必须编辑所使用的提示，而且通常他们必须修改链的内部结构，即数据如何流动。通过将此逻辑（提示和编排）作为应用程序的一部分 - 而不是作为库源代码的一部分 - 它的可修改性要高得多。

第二个大区别是它们预先配置了各种集成。虽然连锁店和代理商通常要求您传递 LLM 或 VectorStore 才能使其正常工作，但模板已经准备就绪。由于不同的LLMs可能需要不同的提示策略，并且不同的向量库可能有不同的参数，这使我们能够与集成合作伙伴合作，提供最能利用其特定技术的模板。

💡
我们已经添加了 50 多个不同的模板 - 请在此处查看。链接

语言服务

三个月前，我们推出了LangServe，作为部署 LangChain 应用程序的最佳方式。LangServe 是一个开源 Python 库，它本质上包装了 FastAPI，以自动添加 LangChain 对象的端点。它会自动添加多个端点（流式传输、批处理），并自动推断这些端点的输入/输出——所有这些都是因为我们非常了解底层的 LangChain 对象。这也使我们能够自动为这些链和代理启动简单的 UI。这使得向最终用户公开特定的链以进行试用变得很容易。

💡
我们发现最好的团队会快速迭代他们的LLMs申请。这意味着尽快向最终用户展示，收集反馈，然后进行相应调整。LangServe 的目标是让所有团队都能轻松做到这一点。此外，它与 LangSmith 无缝集成（见下文），使反馈收集和迭代过程变得更加容易。
（我们还在开发 LangServe 的托管版本，允许一键部署 LangChain 应用程序 -在此处注册等候名单）

LangSmith

LangChain 生态系统的最后一部分是 LangSmith - LLM 应用程序的控制中心。

💡
LangSmith是一个在整个旅程的所有步骤中补充 GenAI 开发体验的平台。它与 LangChain 无缝集成，但本身也很容易使用。它仍处于私人测试阶段（我们正在努力实现 GA），您可以在此处进入候补名单。
LangSmith 具有一流的调试体验，可以派上用场。通过记录链和代理的所有步骤，您可以轻松：

准确查看采取了哪些步骤以及按什么顺序进行
查看这些步骤的确切输入是什么
查看这些步骤的确切输出是什么
输入给定步骤的游乐场，您可以在其中修改输入并查看输出如何改变
当您构建这些复杂的Chain和Agent时，其中主要部分是这种非确定性语言模型，这种类型的可观察性至关重要。从您开始构建的那一刻起，LangSmith 将大幅提高您的迭代速度。

LangSmith 还包含一套附加工具，旨在将您的应用程序从原型转变为生产。这包括：

反馈收集 – 对于了解用户如何与您的产品交互非常重要
数据集和测试 - 请参阅我们最近 使用此进行评估的工作
监控 – 使用情况、反馈分数、延迟、令牌
数据标注队列——用于快速标注数据
Hub – 用于根据提示进行协作
有关所有这些功能的更多信息，请查看我们最近发布的YouTube 亮点系列。

路线图

我们已经思考、研究和讨论这个路线图一个多月了。以下是我们已采取的步骤以及尚未采取的步骤的摘要：

[11/8 - 完成] 分裂langchain-core

[12/11 - 完成] 将所有集成拆分为langchain-community, 发布langchain-core v0.1

[12/11-1/5] 将主要集成拆分为独立包

[1/9] 发布langchain v0.1

该langchain v0.1版本预计将与现有版本完全兼容。我们今天不发布 0.1 的原因是我们知道我们想要添加更多功能，并且我们还想评估langchain迁移到langchain-core.

这可以实现什么

这使得 GenAI 生态系统蓬勃发展。LLMs的用例似乎有无数个。我们需要的是对这些用例进行更多的探索和优化，而不是担心必须支持流、多模型、跟踪等。

该包的这种架构不仅为应用程序而且为在 LangChain 之上构建或与 LangChain 集成的其他库和框架铺平了道路。我们已经在 GPT Researcher、CrewAI、LlamaIndex、PandasAI 等框架中看到这种情况的发生。

这也为集成合作伙伴不仅能够更完全地拥有其集成，而且还能够更完全地拥有其集成周围的框架铺平了道路。Datastax 团队及其RAGStack框架就是一个很好的例子。它建立在 LangChain 之上，但重点关注 (1) 一流的 AstraDB 和 CassandraDB 集成，以及 (2) 对最适合 CassandraDB 的方式进行更固执的看法。这使得 Datastax 能够为其软件用户提供尽可能最佳的体验，同时还能与 LangChain 生态系统的其他部分无缝集成，这样他们就不必重新设计 LLM 集成、文档加载器、跟踪等。

结论

我们对 GenAI 领域的主要看法是，它仍然处于非常早期且变化非常快的阶段。随着空间的发展，整个Langchain生态系统也会随之发展。浪链已经不再是一年前，甚至三个月前了。langchain-core我们相信，最近的变化和引入langchain-community对于奠定坚实的基础以推动我们所有人前进至关重要。我们期待看到您构建的内容 🙂

常见问题解答

问：我应该从哪个套餐开始？

答：如果你想从头开始，浪链可能仍然是最好的起点。它在底层使用langchain-core和，因此公开了最大的功能集合。langchain-community

问：这三个软件包之间是否有兼容性考虑，或者版本是否可以互操作？

A：目前，我们有当前版本的LangChain依赖于langchain-core>=0.1,<0.2.

问：LangChain 的链和代理（例如 ConversationalRetrievalQA 链）会发生什么？

答：它们一直作为一种开始特定用例的简单方法而存在！我们将让越来越多的用户在后台使用 LCEL（或创建 LCEL 等效项）以获得 LCEL 的优势，但这些更高级别的接口将始终存在（并且是我们下个月的重点）。

问：我应该升级到哪个版本？

答：langchain>=0.0.350有所有更新！

问：我需要升级吗？

答：你不需要！所有这些更改都是以向后兼容的方式完成的，因此您可以放心地选择忽略。

问：我是 LangChain 集成的贡献者，想创建一个单独的包。我怎样才能这样做呢？

答：我们将在接下来的几天内添加说明和 CLI 来帮助解决这一问题 - 请关注 GitHub 的讨论。