概览
LangChain 有什么新动态?
在 0.1.x 版本开发过程中已添加以下功能:
- 通过 事件流式传输 API 获得更好的流式传输支持。
- 标准化工具调用支持
- 用于 结构化输出 的标准接口
- @chain 装饰器以更轻松地创建RunnableLambdas
- https://python.langchain.com/docs/expression_language/how_to/inspect/
- 在 Python 中,许多核心抽象的异步支持得到了更好的改进(感谢 @cbornet!!)
- 在响应元数据中包含
AIMessage,以便轻松访问底层模型的原始输出 - 工具用于可视化 您的可运行组件 或 您的 LangGraph 应用
- 大多数提供商的聊天消息历史记录互操作性
- 20 多个 Python 合作伙伴包,用于流行集成
LangChain 即将推出什么?
- 我们一直在努力开发 langgraph。我们将在此基础上构建更多功能,并致力于使其成为智能体架构的首选框架。
- Vectorstores V2!我们将重新审视我们的向量存储抽象,以提高可用性和可靠性。
- 更好的文档和版本化文档!
- 我们计划于7月至9月期间的某个时间发布一个重大版本(0.3.0),以全面支持 Pydantic 2,并将停止对 Pydantic 1 的支持(包括源自 Pydantic 2
v1命名空间的对象)。
发生了什么变化?
由于该领域发展迅速,LangChain 也在快速演进。
本文件旨在概述发生了哪些变化及其原因,从高层次进行说明。
TLDR
截至 0.2.0:
- 本次发布完成了我们从 0.1.0 版本开始的工作,通过移除
langchain对langchain-community的依赖关系。 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" -
langchainchains/agents 在很大程度上与集成无关,这使得实验不同的集成变得容易,并且如果特定集成出现问题,您的代码也能得到未来保障。
还有一个不那么明显的第三大好处是,与集成无关的要求迫使我们只寻找那些能够很好地跨集成泛化的非常通用的抽象和架构。鉴于基础技术的通用能力以及该领域的发展速度,拥有通用架构是使您的应用面向未来的好方法。
langchain-community 旨在包含所有尚未在单独的 langchain-{partner} 包中维护的特定集成组件。目前,这仍然是大多数集成和大量代码的来源。这些代码主要由社区贡献,而 langchain 则主要由核心维护者编写。所有这些集成都使用可选依赖项和条件导入,这防止了依赖项膨胀和冲突,但也意味着兼容的依赖项版本未被明确指定。鉴于 langchain-community 中集成的数量以及集成变化的速度,很难遵循语义化版本控制(semver),因此我们目前并未这样做。
所有这些都说明,langchain 依赖 langchain-community 并没有显著的好处,反而存在一些明显的缺点:langchain 中的功能本应独立于集成方式,langchain-community 无法进行适当的版本控制,而依赖 langchain-community 会增加 langchain 的 漏洞暴露面。
有关该组织原因的更多背景信息,请查看我们的博客:https://blog.langchain.dev/langchain-v0-1-0/