LLM之LangChain：LangChain 0.1.0 版本发布的简介、安装和使用方法、案例应用之详细攻略-Toy模板网

这篇具有很好参考价值的文章主要介绍了LLM之LangChain：LangChain 0.1.0 版本发布的简介、安装和使用方法、案例应用之详细攻略。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

LLM之LangChain：LangChain 0.1.0 版本发布的简介、安装和使用方法、案例应用之详细攻略

导读：2024年1月8日，今天，我们很高兴宣布发布 langchain 0.1.0，这是我们的第一个稳定版本。它完全向后兼容，提供了 Python 和 JavaScript 两个版本，并通过功能和文档的双重改进来提高焦点。LangChain 的稳定版本有助于赢得开发者的信任，并使我们能够有系统地和安全地演进该库。

本文主要总结了 LangChain 0.1.0 版本的发布以及它解决的一些核心问题。由于历史版本 LangChain 0.0.x 杂乱无章，没有明确的版本规范，给用户带来不确定性。无论更新是功能还是修复，都有可能带来breaking change，给用户使用和维护带来困难。

LangChain 0.1.0 版本的发布，将 LangChain 拆分为核心库 langchain-core 和不同组件，明确功能边界。LangChain 0.1.0 起正式采用语义版本号规范管理，明确breaking更改规范。提供 LangChain Expression Language (LCEL)，支持用户高度定制各种组件间交互流程。引入 LangSmith 提供全流程观测能力，帮助开发调试。

核心特点:

>> 提供丰富的第三方组件整合能力。

>> 支持学习模型检索与调用存储的数据能力。

>> 支持基于学习模型进行复杂任务的智能代理能力。

>> 通过LCEL等支持学习模型结果解析和自定义工作流能力。

>> 支持学习模型结果流式处理，提升用户体验。

优势:

>> 简化学习模型项目开发，提高开发效率。

>> 帮助开发者快速排查问题和进行调试。

>> 采用语义版本号明确更新规范，减少breaking change风险。

>> 提供丰富的核心组件和定制能力，满足各种复杂需求。

>> 积极开源并与开发者社区互动，共同提升产品。

Py之Langchain：Langchain(LLM大型语言模型应用程序框架/将LLMs个体进行flow的能力)的简介、安装、使用方法之详细攻略

LangChain 0.1.0 版本发布的简介

1、第三方集成

2、可观察性

3、可组合性

4、流式传输

5、输出解析

6、检索

7、代理

8、LangChain 0.2

9、One More Thing

10、Conclusion

LangChain 0.1.0 版本的安装和使用方法

LangChain 0.1.0 版本的案例应用

Py之Langchain：Langchain(LLM大型语言模型应用程序框架/将LLMs个体进行flow的能力)的简介、安装、使用方法之详细攻略

https://yunyaniu.blog.csdn.net/article/details/127779588

LangChain 0.1.0 版本发布的简介

LangChain 已经存在了一年多，随着它发展成为构建 LLM 应用程序的默认框架，它发生了很多变化。正如我们在一个月前预览的那样，我们最近决定对 LangChain 软件包架构进行重大更改，以更好地组织项目并加强基础。

具体而言，我们进行了两个重大的架构更改：将 langchain-core 和合作伙伴软件包（或者是放入 langchain-community 中，或者是独立的合作伙伴软件包）从 langchain 中分离出来。

作为提醒，langchain-core 包含主要的抽象、接口和核心功能。这段代码是稳定的，已经遵循了一个多月的更严格的版本控制政策。

然而，langchain 本身仍然保持在 0.0.x 版本上。将所有版本都放在次要版本 0 上创建了一些挑战：

>> 用户无法确信更新不会有破坏性的变化

>> 随着我们采取“维护一切”的方式以减少破坏性变化和弃用通知，langchain 变得臃肿且不稳定

然而，从今天开始发布 langchain 0.1.0，所有未来的发布都将遵循一个新的版本标准。具体而言：

>> 对公共 API 的任何破坏性更改将导致次要版本号的提升（第二位数）

>> 任何错误修复或新功能将导致修补版本号的提升（第三位数）

我们希望这一点，再加上之前的架构更改，将：

>> 明确传达是否进行了破坏性更改，使开发者可以放心地更新

>> 为正式弃用和删除旧代码提供途径，减少冗余

>> 更负责任地处理集成（它们的 SDK 通常与 LangChain 一样迅速变化）

即使在发布 0.2 版本之后，我们仍然承诺维护 0.1 的分支，但仅修补关键的错误。在本文的最后，您可以了解更多关于我们的计划。

在重新架构软件包以迈向稳定的 0.1 版本的过程中，我们抓住机会与数百名开发者交流，了解他们为何使用 LangChain 以及他们喜欢其中的哪些方面。这些意见指导了我们的方向和重点。我们还利用这个机会在下面概述的核心领域中为 Python 和 JavaScript 版本带来了一致性。

虽然某些集成和更为辅助的链可能是特定于语言的，但核心抽象和关键功能在 Python 和 JavaScript 软件包中都得到了相同的实现。

我们想分享我们听到的意见以及我们不断改进 LangChain 的计划。我们希望通过分享这些经验，增加透明度，让其他人更好地使用、理解和为 LangChain 做出贡献。毕竟，LangChain 的一个巨大部分是我们的社区——包括用户群体和2000多名贡献者——我们希望每个人都能参与其中。

文章地址：LangChain v0.1.0

文档地址：langchain 0.1.0 — 🦜🔗 LangChain 0.1.0

Python GitHub 讨论，地址：LangChain v0.1.0 · langchain-ai/langchain · Discussion #15712 · GitHub

Python v0.1.0 指南，地址：GitHub - hwchase17/langchain-0.1-guides at blog.langchain.dev

JS v0.1.0 指南，地址：GitHub - bracesproul/langchainjs-0.1-guides at blog.langchain.dev

YouTube 演示，地址：https://www.youtube.com/watch?v=Fk_zZr2DbQY&list=PLfaIDFEXuae0gBSJ9T0w7cu7iJZbH3T31&pp=gAQBiAQB&ref=blog.langchain.dev

1、第三方集成

人们最喜欢 LangChain 的一点是我们如何轻松地让他们在任何堆栈上开始构建。我们有近700个集成，从LLMs到向量存储到工具，供代理使用。

LangChain 通常被用作将构建 LLM 应用程序所需的所有不同组件“粘合”在一起的工具，因此优先考虑强大的集成生态系统对我们非常重要。

大约一个月前，我们开始进行一些变更，我们认为这些变更将改善集成的稳健性、稳定性、可扩展性和一般的开发者体验。我们将所有第三方集成都拆分到 langchain-community 中——这使我们能够集中处理与集成相关的工作。我们还开始将各个集成拆分到它们自己的软件包中。到目前为止，我们已经为约10个软件包执行了此操作，包括 OpenAI、Google 和 Mistral。这样做的一个好处是更好的依赖管理——以前，所有依赖项都是可选的，尝试安装特定版本时可能会导致一些麻烦。现在，如果集成位于自己的软件包中，我们可以更严格地版本化它们的要求，从而更容易安装。另一个好处是版本控制。通常，第三方集成会发生变化，需要进行破坏性变更。现在，可以在独立的集成软件包中以适当的版本控制反映这些变化。

2、可观察性

构建 LLM 应用程序涉及将一个非确定性组件放在系统的中心。这些模型通常会输出意外的结果，因此对系统中发生的事情进行可见性是至关重要的。

我们希望使 langchain 尽可能可观察和可调试，无论是通过架构决策还是通过我们在一旁构建的工具。

我们以几种方式着手解决这个问题。

我们解决这个问题的主要方式是通过构建 LangSmith。 LangSmith 提供的主要价值主张之一是为您的 LLM 应用程序提供最佳的调试体验。我们记录确切发生的每个步骤，每个步骤的输入是什么，每个步骤的输出是什么，每个步骤需要多长时间等数据。我们以用户友好的方式显示这些数据，使您能够识别哪些步骤花费的时间最长，进入一个游乐场以调试意外的 LLM 响应，跟踪令牌使用情况等等。即使在私人测试版中，对 LangSmith 的需求也是压倒性的，我们正在大力投资于可伸缩性，以便在未来几个月内发布公共测试版，然后使其普遍可用。我们还已经支持企业版本，为那些有严格数据隐私政策的企业提供了在 VPC 内部署的选项。

我们还以其他方式解决了可观察性的问题。我们长期以来一直在管道的不同日志级别中内置了冗长和调试模式。我们最近引入了可视化您创建的链以及获取所有使用的提示的方法。

3、可组合性

虽然有预构建的链以帮助入门，但我们经常看到团队超越这些架构并希望自定义他们的链——不仅仅是自定义提示，还包括自定义协调的不同部分。

在过去的几个月里，我们在 LangChain 表达语言（LCEL）上进行了大量投资。这使得可以组合任意序列，提供与数据工程管道（批处理、并行化、回退）相同的许多好处。

它还提供了一些对 LLM 工作负载独特的好处，主要是 LLM 特定的可观察性（上面已涵盖），以及本文后面将要介绍的流式传输。

LCEL 的组件位于 langchain-core 中。我们已经开始为 LangChain 中的特定链创建更高级别的入口点。这些将逐渐替换先前的（现在称为“Legacy”）链，因为使用 LCEL 构建的链将获得流式传输、易于定制、可观察性、批处理、自动重试等功能。我们的目标是使这个过渡变得无缝。以前可能是这样做的：

ConversationalRetrievalChain.from_llm(llm, …)

我们希望简单地做成这样：

create_conversational_retrieval_chain(llm, …)

在底层，它将创建一个特定的 LCEL 链并返回它。如果要修改逻辑——没问题！因为它全部都是用 LCEL 编写的，所以可以轻松地修改其中的一部分，而无需子类化任何内容或覆盖任何方法。

LangChain 中有很多链，其中许多都被广泛使用。在替代构造函数存在并被使用和经过良好测试之前，我们不会弃用链的旧版本。

4、流式传输

LLMs 有时可能需要一段时间才能响应。向最终用户显示正在执行工作而不是盯着空白屏幕非常重要。这可以采用从 LLM 流式传输令牌或流式传输中间步骤（如果链或代理运行时间更长）的形式。

我们在这两方面都投入了大量资源。所有使用 LCEL 构建的链都公开了标准的 stream 和 astream 方法，我们在流式传输方面进行了大量工作，确保不仅仅在 LLM 调用中进行流式传输（例如，在输出解析器中也进行）。所有链还公开了一个标准的 astream_log 方法，该方法在 LCEL 链中流式传输所有步骤。然后，可以过滤这些步骤以轻松获取中间步骤和其他信息。

对于大多数 LLM 应用程序而言，流式传输（令牌和中间步骤）是关键的用户体验组成部分，使用 LangChain 可以轻松实现这一点。

5、输出解析

LangChain 的主要用途之一是“工具使用”——使用 LLMs 调用其他工具。

确保 LLM 以可以在下游应用程序中使用的结构化格式返回信息对于启用 LLM 执行操作至关重要。

我们在这方面进行了大量工作，引入了输出解析器的概念，以提供良好的开发体验。

LangChain的主要用例之一是“工具使用” - 使用LLMs调用其他工具。

确保LLM以结构化格式返回信息，以便在下游应用中使用对于使LLMs能够采取行动至关重要。

我们在这方面投入了大量工作，引入了输出解析的概念，以提供良好的开发人员体验。

实现这一目标的主要方式之一是通过OpenAI函数调用。我们不仅使指定输出格式变得简单（使用Pydantic、JSON模式甚至是函数），而且还轻松处理响应。我们还支持几种不同的编码方法（JSON、XML、Yaml），用于在您想要使用不支持OpenAI函数调用的模型时进行提示。当您需要使用提示时，您还需要适当的指令告诉LLM如何响应 - 所有输出解析器都配备了一个get_format_instructions方法来获取这些指令。

我们还在输出解析器方面投资了更高级的功能，如允许它们在生成时通过部分结果进行流式处理以改善用户体验。这包括从结构化格式（如JSON、XML和CSV）中流式处理部分结果。对于输出解析，有时可能会有些棘手 - 为了解析JSON blob，大多数JSON解析器需要一个完整的JSON blob。许多我们的输出解析器包含内置逻辑，以执行部分解析。

6、检索

我们看到开发人员构建的主要类型的应用程序之一是与其私有数据交互的应用程序。

能够轻松地将您的数据与LLMs结合使用是LangChain的一个非常重要的部分。这通常涉及两个不同的组件 - 摄取（准备数据）和检索（检索数据），我们都已经构建出来了。

在摄取方面，摄取的一个重要部分是将您正在处理的文本分割成块。尽管这可能看似微不足道，但通常最好的方法往往是微妙的，而且通常特定于您正在处理的文档类型。我们有15种不同的文本拆分器，一些经过优化以适应特定文档类型（如HTML和Markdown），以使开发人员在此过程中具有最大的控制权。相关数据通常会发生变化，而我们的摄取系统设计用于生产规模的应用程序。我们提供了一个索引API，允许您重新摄入内容，同时忽略未更改的部分 - 为大量工作负载节省时间和成本。

在检索方面，我们投资于更先进的方法，同时使检索更具生产力。我们实施了来自学术界的先进检索策略（如FLARE和Hyde），创建了我们自己的策略（如Parent Document和Self-Query），并从其他行业解决方案中借鉴了一些（如Multi-Query - 源自搜索中常用的查询扩展）。我们还确保支持生产关注点，如每用户检索 - 对于存储多个用户的文档的任何应用程序都至关重要。

重要的是，尽管LangChain提供了构建先进检索系统所需的所有组件，但我们在如何实现这一目标上并不过于武断。这导致许多其他库构建在LangChain之上，以提供更具意见的检索方法 - 例如EmbedChain和GPTResearcher。

7、代理

LangChain最早因其代理工作负载而闻名。这可能意味着两件事：

>> 工具使用：使LLM调用函数或工具

>> 推理：如何最好地使LLM多次调用工具，以及以何种顺序（或根本不调用工具！）

在工具使用方面，我们主要涵盖了我们认为至关重要的组件：

>> 与大量第三方工具的集成

>> 以适应这些工具的输入模式的方式结构LLMs的响应

>> 以LCEL指定这些工具应该被调用的自定义方式的灵活方式

在推理方面，我们有一些不同的“代理”方法，可以基本上被视为在循环中运行的LLM，每次迭代决定它需要调用哪个（如果有的话）工具，然后观察该工具的结果。我们从一开始就引入了ReAct（一种早期的提示策略），并迅速添加了许多其他类型，包括使用OpenAI函数调用的类型，使用它们的新工具调用API的类型，优化对话的类型等等。

通过灵活和可扩展的工具支持和先进的推理功能，LangChain已成为使LLMs能够采取行动的默认方式。

与检索类似，尽管LangChain提供了代理的构建块，但我们还看到了一些更具意见的框架构建在其上。一个很好的例子是CrewAI，它基于LangChain构建，提供了一个更容易的界面，用于多代理工作负载。

8、LangChain 0.2

尽管我们刚刚发布了LangChain 0.1，但我们已经在思考0.2。对我们来说，一些重要的事情是：

>> 用LCEL重写传统链（具有更好的流式处理和调试支持）

>> 添加新类型的链

>> 添加新类型的代理

>> 提高我们的生产摄取能力

>> 删除旧的和未使用的功能

重要的是，即使我们对删除一些旧的和遗留的代码以使langchain更加精简和专注感到兴奋，我们也希望维护对仍在使用旧版本的人的支持。这就是为什么我们将保持0.1作为一个稳定的分支（修复关键错误）至少在0.2发布后的3个月内。我们计划在今后的每个稳定发布中执行此操作。

如果您一直想要开始贡献，现在是个好时机。我们最近在GitHub上添加了一个很好的入门问题，如果您正在寻找一个开始的地方。

9、One More Thing

LangChain v0.1.0的一个很大的部分是稳定性和专注于上述核心区域。现在我们已经确定了人们喜欢LangChain的方面，我们可以开始在那些方面添加更先进和完整的工具。

人们喜欢LangChain的主要原因之一是它对代理的支持。大多数代理基本上被定义为在某种循环中运行LLM。到目前为止，我们进行这种操作的唯一方式是使用AgentExecutor。我们向AgentExecutor添加了许多参数和功能，但它仍然只是运行循环的一种方式。

我们很高兴地宣布langgraph的发布，这是一个允许创建语言代理作为图形的新库。

这将允许用户创建更自定义的循环行为。您可以定义显式的规划步骤、显式的反思步骤，或者轻松地将其硬编码，使得特定工具始终首先被调用。

它受Pregel和Apache Beam的启发。当前公开的接口是受NetworkX启发的，看起来像这样：

Explain
from langgraph.graph import END, Graph

workflow = Graph()

workflow.add_node("agent", agent)
workflow.add_node("tools", execute_tools)

workflow.set_entry_point("agent")

workflow.add_conditional_edges(
    "agent",
    should_continue,
    {
        "continue": "tools",
        "exit": END
    }
)

workflow.add_edge('tools', 'agent')

chain = workflow.compile()

我们过去六个月一直在进行这方面的工作，与用户进行了测试。它目前支持OpenGPTs。在接下来的几周内，我们将添加更多示例和文档 - 我们对此感到非常激动！

在这里尝试一下。

10、Conclusion

随着生态系统的发展，LangChain已经发生了显著变化。我们非常感谢我们的社区和用户一直以来的支持和建设。通过这个0.1版本，我们花时间了解您在LLM框架中想要和需要什么，并承诺继续构建它。随着社区需求的演变（或者如果我们遗漏了什么），我们希望听取您的反馈，以便我们可以解决它。人们说：“千里之行始于足下。” - 或者在我们的情况下，版本0.1。