概述
LangChain 有什么新内容?
在0.1.x版本的开发过程中,新增了以下功能:
- 通过Event Streaming API提供更好的流支持。
- 标准化工具调用支持
- 用于结构化输出的标准化接口
- @chain decorator 更轻松地创建 RunnableLambdas
- https://python.langchain.com/docs/expression_language/how_to/inspect/
- 在Python中,对许多核心抽象提供了更好的异步支持(感谢@cbornet!!)
- 在
AIMessage
中包含响应元数据,以便轻松访问底层模型的原始输出 - 工具用于可视化your runnables或your langgraph app
- 大多数提供商之间的聊天消息历史的互操作性
- Over 20+ partner packages in python 用于流行的集成
LangChain 即将推出什么?
- 我们一直在努力开发langgraph。我们将在其基础上构建更多功能,并致力于使其成为代理架构的首选框架。
- Vectorstores V2!我们将重新审视我们的向量存储抽象,以帮助提高可用性和可靠性。
- 更好的文档和版本化文档!
- 我们计划在7月至9月之间发布一个重大更新版本(0.3.0),以升级到完全支持Pydantic 2,并将停止对Pydantic 1的支持(包括源自Pydantic 2的
v1
命名空间的对象)。
发生了什么变化?
由于该领域的快速发展,LangChain 也迅速发展。
本文档旨在从高层次概述发生了哪些变化及其原因。
太长不看
截至0.2.0版本:
- 此版本完成了我们在0.1.0版本中开始的工作,通过移除
langchain
对langchain-community
的依赖。 langchain
包不再需要langchain-community
。相反,langchain-community
现在将依赖于langchain-core
和langchain
。- 只要安装了
langchain_community
,仍然依赖从langchain
中弃用的导入的用户代码将继续工作。这些导入将在0.4.x版本中开始引发错误。
截至0.1.0版本:
langchain
被拆分为以下组件包:langchain-core
、langchain
、langchain-community
、langchain-[partner]
,以提高在生产环境中使用 langchain 代码的可用性。您可以在我们的 博客 上阅读更多相关信息。
生态系统组织
到0.1.0版本发布时,LangChain已经发展成为一个拥有许多集成和庞大社区的大型生态系统。
为了提高LangChain在生产中的可用性,我们将单一的langchain
包拆分为多个包。这使我们能够为LangChain生态系统创建一个良好的基础架构,并提高langchain
在生产中的可用性。
以下是生态系统的高级分解:
- langchain-core: 包含涉及LangChain Runnables的核心抽象、用于可观察性的工具以及重要抽象的基础实现(例如,聊天模型)。
- langchain: 包含使用
langchain-core
中定义的接口构建的通用代码。此包适用于在特定接口的不同实现中普遍适用的代码。例如,create_tool_calling_agent
适用于支持工具调用功能的聊天模型。 - langchain-community: 社区维护的第三方集成。包含基于langchain-core中定义的接口的集成。由LangChain社区维护。
- 合作伙伴包(例如,langchain-[partner]):合作伙伴包是专门为特别流行的集成(例如,
langchain-openai
,langchain-anthropic
等)而设计的包。这些专用包通常受益于更好的可靠性和支持。 langgraph
: 通过将步骤建模为图中的边和节点,使用LLMs构建健壮且有状态的多参与者应用程序。langserve
: 将LangChain链部署为REST API。
在0.1.0版本中,langchain-community
被保留为langchain
的必需依赖项。
这允许向量存储、聊天模型和其他集成的导入继续通过langchain
工作,而不是强迫用户将所有导入更新为langchain-community
。
对于0.2.0版本,我们正在移除langchain
对langchain-community
的依赖。这是我们自0.1版本以来一直计划要做的事情,因为我们相信这是正确的包架构。
只要安装了langchain-community
,旧的导入将继续有效。这些导入将在0.4.0版本中被移除。
为了理解为什么我们认为打破langchain
对langchain-community
的依赖是最好的,我们应该理解每个包的用途。
langchain
旨在包含高级链和代理架构。这些逻辑应在抽象级别(如 ChatModel
和 Retriever
)上指定,不应特定于任何单一集成。这有两个主要好处:
-
langchain
相当轻量。以下是所需依赖项的完整列表(拆分后)python = ">=3.8.1,<4.0"
langchain-core = "^0.2.0"
langchain-text-splitters = ">=0.0.1,<0.1"
langsmith = "^0.1.17"
pydantic = ">=1,<3"
SQLAlchemy = ">=1.4,<3"
requests = "^2"
PyYAML = ">=5.3"
numpy = "^1"
aiohttp = "^3.8.3"
tenacity = "^8.1.0"
jsonpatch = "^1.33" -
langchain
chains/agents 在很大程度上是与集成无关的,这使得可以轻松地尝试不同的集成,并在某个特定集成出现问题时,使您的代码具有未来兼容性。
还有第三个不那么具体的好处,那就是与集成无关迫使我们只找到那些非常通用的抽象和架构,这些抽象和架构在集成中能够很好地泛化。鉴于基础技术的能力有多么通用,以及这个领域发展得有多快,拥有通用的架构是未来保护应用程序的好方法。
langchain-community
旨在包含所有尚未在单独的 langchain-{partner}
包中维护的集成特定组件。目前,这仍然是大多数集成和大量代码。这些代码主要由社区贡献,而 langchain
主要由核心维护者编写。所有这些集成都使用可选依赖项和条件导入,这防止了依赖膨胀和冲突,但也意味着兼容的依赖版本没有明确说明。鉴于 langchain-community
中集成的数量和集成变化的速度,很难遵循语义化版本控制,我们目前也没有这样做。
所有这些都表明,langchain
依赖于langchain-community
并没有大的好处,反而有一些明显的缺点:langchain
的功能应该是与集成无关的,langchain-community
无法正确地进行版本控制,并且依赖于langchain-community
会增加langchain
的漏洞暴露面。
有关组织原因的更多背景信息,请参阅我们的博客:https://blog.langchain.dev/langchain-v0-1-0/