概述
LangChain 有哪些新功能?
以下功能已在 0.1.x 开发期间添加
- 通过 Event Streaming API 改进了流式传输支持。
- 标准化的工具调用支持
- 用于结构化输出的标准化接口
- @chain 装饰器,更轻松地创建 RunnableLambdas
- https://python.langchain.ac.cn/docs/expression_language/how_to/inspect/
- 在 Python 中,改进了许多核心抽象的异步支持(感谢 @cbornet!!)
- 在
AIMessage
中包含响应元数据,以便轻松访问底层模型的原始输出 - 用于可视化您的 Runnable 或您的 LangGraph 应用的工具
- 大多数提供商之间的聊天消息历史记录互操作性
- Python 中有20 多个合作伙伴包用于流行的集成
LangChain 将推出什么?
- 我们一直在努力开发 LangGraph。我们将在其基础上构建更多功能,并致力于使其成为代理架构的首选框架。
- 向量存储 V2!我们将重新审视我们的向量存储抽象,以帮助提高可用性和可靠性。
- 更好的文档和版本化文档!
- 我们计划在 7 月至 9 月之间发布一个破坏性版本 (0.3.0),以完全支持 Pydantic 2,并将取消对 Pydantic 1 的支持(包括源自 Pydantic 2 的 v1 命名空间的对象)。
有什么变化?
由于该领域发展迅速,LangChain 也迅速发展。
本文旨在高度概括地阐述了哪些内容发生了变化以及原因。
TLDR
截至 0.2.0
- 此版本通过移除
langchain
对langchain-community
的依赖,完成了我们从 0.1.0 版本开始的工作。 langchain
包不再需要langchain-community
。相反,langchain-community
现在将依赖于langchain-core
和langchain
。- 仍依赖
langchain
中已弃用导入的用户代码只要安装了langchain_community
就会继续工作。这些导入将在 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 的核心抽象、可观测性工具以及重要抽象(例如 Chat Models)的基本实现。
- langchain:包含使用
langchain-core
中定义的接口构建的通用代码。此包适用于在特定接口的不同实现之间具有良好通用性的代码。例如,create_tool_calling_agent
适用于支持工具调用功能的聊天模型。 - langchain-community:社区维护的第三方集成。包含基于 langchain-core 中定义的接口的集成。由 LangChain 社区维护。
- 合作伙伴包(例如,langchain-[partner]):合作伙伴包是专用于特别流行的集成(例如,
langchain-openai
、langchain-anthropic
等)的包。这些专用包通常受益于更好的可靠性和支持。 - langgraph:通过将步骤建模为图中的边和节点,使用 LLM 构建健壮的有状态多代理应用程序。
- 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
链/代理在很大程度上与集成无关,这使得试验不同的集成变得容易,并且在特定集成出现问题时,您的代码也具备未来适应性。
还有一个不太明显但实实在在的好处是,与集成无关迫使我们只寻找那些在各种集成中都能很好地通用的抽象和架构。考虑到基础技术能力的通用性以及该领域的快速发展,拥有通用架构是使您的应用程序具有未来适应性的一种好方法。
langchain-community
旨在包含所有尚未在单独的 langchain-{partner}
包中维护的特定于集成的组件。目前,这仍然是大多数集成和大量代码。这些代码主要由社区贡献,而 langchain
主要由核心维护者编写。所有这些集成都使用可选依赖项和条件导入,这可以防止依赖项膨胀和冲突,但意味着兼容的依赖项版本没有明确说明。鉴于 langchain-community
中集成的数量以及集成变更的速度,很难遵循 semver 版本控制,我们目前也没有遵循。
总而言之,langchain
依赖于 langchain-community
没有太大好处,反而有一些明显的缺点:langchain
中的功能无论如何都应该是与集成无关的,langchain-community
无法正确进行版本控制,并且依赖 langchain-community
会增加 langchain
的漏洞暴露面。
有关组织原因的更多背景信息,请参阅我们的博客:https://blog.langchain.ac.cn/langchain-v0-1-0/