Skip to main content

LangChain 随时间变化

LangChain 中的新特性

在 0.1.x 的开发过程中添加了以下功能:

LangChain 将迎来哪些新功能?

  • 我们一直在努力开发 langgraph。我们将会在此基础上构建更多功能,并专注于使其成为代理架构的首选框架。
  • Vectorstores V2!我们将重新审视我们的 vectorstores 抽象,以帮助提高可用性和可靠性。
  • 更好的文档和版本化文档!
  • 我们计划在七月至九月之间发布一个重大版本(0.3.0),以 升级到对 Pydantic 2 的全面支持,并将停止对 Pydantic 1 的支持(包括源自 Pydantic 2 的 v1 命名空间的对象)。

有什么变化?

由于快速发展的领域,LangChain 也快速发展。

本文档旨在高层次概述发生了什么变化以及原因。

TLDR

截至 0.2.0:

  • 此版本完成了我们在 0.1.0 版本中开始的工作,通过移除 langchainlangchain-community 的依赖。
  • langchain 包不再需要 langchain-community。相反,langchain-community 现在将依赖于 langchain-corelangchain
  • 仍然依赖于 langchain 中已弃用导入的用户代码,只要安装了 langchain_community,就会继续工作。这些导入将在 0.4.x 版本中开始引发错误。

截至 0.1.0:

  • langchain 被拆分为以下组件包:langchain-corelangchainlangchain-communitylangchain-[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-openailangchain-anthropic等)。专用包通常受益于更好的可靠性和支持。
  • langgraph: 通过将步骤建模为图中的边和节点,构建健壮的有状态多参与者应用程序。
  • langserve: 将LangChain链部署为REST API。

在0.1.0版本中,langchain-community作为langchain的必要依赖项被保留。

这使得向langchain的向量存储、聊天模型和其他集成的导入能够继续工作,而无需强迫用户更新所有导入到langchain-community

在0.2.0版本中,我们将移除langchainlangchain-community的依赖。这是我们自0.1版本以来一直计划做的事情,因为我们相信这是正确的包架构。

只要安装了langchain-community,旧的导入将继续有效。这些导入将在0.4.0版本中移除。

要理解我们为什么认为打破langchainlangchain-community的依赖是最好的,我们需要了解每个包的目的。

langchain旨在包含高层次的链和代理架构。这些逻辑应在ChatModelRetriever等抽象层面上指定,而不应特定于任何一个集成。这有两个主要好处:

  1. 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"
  2. langchain链/代理在很大程度上与集成无关,这使得尝试不同集成变得容易,并且在某个特定集成出现问题时可以保障代码的未来兼容性。

还有第三个不太具体的好处,即与集成无关迫使我们找到那些在集成间良好通用的非常通用的抽象和架构。考虑到基础技术的能力是多么通用,以及这个领域发展得多么迅速,拥有通用架构是保障应用程序未来兼容性的好方法。

langchain-community旨在包含尚未在单独的langchain-{partner}包中维护的所有特定于集成的组件。今天,这仍然是大多数集成和大量代码。这些代码主要由社区贡献,而langchain则主要由核心维护者编写。所有这些集成都使用可选依赖项和条件导入,这防止了依赖膨胀和冲突,但意味着兼容的依赖版本没有明确说明。鉴于langchain-community中的集成数量以及集成变化的速度,遵循语义版本控制非常困难,而我们目前并没有做到。

所有这些意味着langchain依赖于langchain-community没有大的好处,而且有一些明显的缺点:langchain中的功能应该与集成无关,langchain-community无法正确版本化,而依赖于langchain-community增加了langchain脆弱性表面

有关组织原因的更多背景信息,请参阅我们的博客:https://blog.langchain.dev/langchain-v0-1-0/


此页面是否有帮助?


您还可以留下详细的反馈 在 GitHub 上