Skip to main content
Open on GitHub

Chat 模型

概览​

大型语言模型 (LLMs) 是先进的机器学习模型，它们在广泛的语言相关任务中表现出色，例如文本生成、翻译、摘要、问答等等，而无需针对每种场景进行特定的任务微调。

现代 LLM 通常通过一个聊天模型接口进行访问，该接口接收一系列 消息 作为输入，并返回一个 消息 作为输出。

最新一代的聊天模型提供了额外的功能：

  • 工具调用：许多流行的聊天模型提供了原生的 工具调用 API。此 API 使开发人员能够构建丰富的应用程序，使 LLM 能够与外部服务、API 和数据库进行交互。工具调用也可用于从非结构化数据中提取结构化信息并执行各种其他任务。
  • 结构化输出：一种使聊天模型以结构化格式（例如匹配给定模式的 JSON）进行响应的技术。
  • 多模态：处理文本以外数据的能力；例如图像、音频和视频。

功能​

LangChain 提供了一个统一的接口，用于处理来自不同提供商的聊天模型，同时还提供其他功能，用于监控、调试和优化使用 LLM 的应用程序的性能。

  • 与许多聊天模型提供商集成（例如，Anthropic、OpenAI、Ollama、Microsoft Azure、Google Vertex、Amazon Bedrock、Hugging Face、Cohere、Groq）。请参阅 聊天模型集成 以获取支持模型的最新列表。
  • 使用 LangChain 的 消息 格式或 OpenAI 格式。
  • 标准 工具调用 API：用于将工具绑定到模型、访问模型发起的工具调用请求以及将工具结果发送回模型的标准接口。
  • 通过 with_structured_output 方法用于 结构化输出 的标准 API。
  • 支持 异步编程、高效批处理、丰富的流式 API。
  • 与 LangSmith 集成，用于监控和调试基于 LLM 的生产级应用程序。
  • 其他功能，如标准化的 Token 使用量、速率限制、缓存 等。

集成​

LangChain 拥有许多聊天模型集成，允许您使用来自不同提供商的各种模型。

这些集成分为两种类型：

  1. 官方模型：这些是由 LangChain 和/或模型提供商官方支持的模型。您可以在 langchain-<provider> 包中找到这些模型。
  2. 社区模型：这些模型主要是由社区贡献和支持的。您可以在 langchain-community 包中找到这些模型。

LangChain 聊天模型的命名约定是在类名前加上“Chat”（例如，ChatOllama、ChatAnthropic、ChatOpenAI 等）。

请查阅 聊天模型集成 以获取支持模型的列表。

note

名称中不包含“Chat”前缀或名称后缀为“LLM”的模型通常指的是不遵循聊天模型接口的旧模型，而是使用接受字符串输入并返回字符串输出的接口。

接口​

LangChain 聊天模型实现了 BaseChatModel 接口。由于 BaseChatModel 也实现了 Runnable 接口，因此聊天模型支持 标准流式接口、异步编程、优化的 批处理 等。请参阅 Runnable 接口 以获取更多详细信息。

聊天模型的许多关键方法都操作基于 消息 的输入并返回消息作为输出。

聊天模型提供了一组标准参数，可用于配置模型。这些参数通常用于控制模型的行为，例如输出的温度、响应中的最大 Token 数以及等待响应的最大时间。有关更多详细信息，请参阅 标准参数 部分。

note

在文档中，我们经常互换使用“LLM”和“聊天模型”这两个术语。这是因为大多数现代 LLM 都通过聊天模型接口暴露给用户。

然而，LangChain 还实现了不遵循聊天模型接口的旧 LLM 的实例，而是使用接受字符串输入并返回字符串输出的接口。这些模型通常在名称中不带“Chat”前缀（例如，Ollama、Anthropic、OpenAI 等）。 这些模型实现了 BaseLLM 接口，并且可能带有“LLM”后缀（例如，OllamaLLM、AnthropicLLM、OpenAILLM 等）。通常情况下，用户不应使用这些模型。

主要方法​

聊天模型的主要方法是：

  1. invoke：与聊天模型交互的主要方法。它接收一系列 消息 作为输入，并返回一系列消息作为输出。
  2. stream：一个允许您在聊天模型生成输出时进行流式传输的方法。
  3. batch：一个允许您将多个请求批量处理到聊天模型中以进行更有效处理的方法。
  4. bind_tools：一个允许您将工具绑定到聊天模型以在模型执行上下文中使用的 API。
  5. with_structured_output：一个包装 invoke 方法的包装器，适用于原生支持 结构化输出 的模型。

您可以在 BaseChatModel API 参考 中找到其他重要方法。

输入和输出​

现代 LLM 通常通过聊天模型接口进行访问，该接口接收 消息 作为输入，并返回 消息 作为输出。消息通常与一个角色（例如，“system”、“human”、“assistant”）和一个或多个内容块相关联，这些内容块包含文本或潜在的多模态数据（例如，图像、音频、视频）。

LangChain 支持两种消息格式来与聊天模型进行交互：

  1. LangChain 消息格式：LangChain 自有的消息格式，默认使用，并在 LangChain 内部使用。
  2. OpenAI 消息格式：OpenAI 的消息格式。

标准参数​

许多聊天模型具有可用于配置模型的标准化参数：

参数描述
model您想使用的特定 AI 模型的名称或标识符（例如，“gpt-3.5-turbo”或“gpt-4”）。
temperature控制模型输出的随机性。较高的值（例如 1.0）使响应更具创意，而较低的值（例如 0.0）使其更具确定性和专注性。
timeout在取消请求之前等待模型响应的最大时间（以秒为单位）。确保请求不会无限期挂起。
max_tokens限制响应中的总 Token 数（单词和标点符号）。这控制输出的长度。
stop指定停止生成 Token 的停止序列。例如，您可以使用特定字符串来指示响应的结束。
max_retries系统在因网络超时或速率限制等问题导致请求失败时尝试重新发送请求的最大次数。
api_key访问模型提供商进行身份验证所需的 API 密钥。通常在您注册模型访问权限时发放。
base_url发送请求的 API 端点的 URL。这通常由模型提供商提供，对于定向到您的请求至关重要。
rate_limiter一个可选的 BaseRateLimiter，用于错开请求以避免超出速率限制。有关更多详细信息，请参见下文的 速率限制。

一些需要注意的重要事项：

  • 标准参数仅适用于公开了具有预期功能的参数的模型提供商。例如，某些提供商不公开最大输出 Token 的配置，因此在这些提供商上不支持 max_tokens。
  • 标准参数目前仅在具有自己集成包（例如 langchain-openai、langchain-anthropic 等）的集成中强制执行，在 langchain-community 中的模型上不强制执行。

聊天模型还接受特定于该集成的其他参数。要查找聊天模型支持的所有参数，请前往其相应的 API 参考。

工具调用​

聊天模型可以调用 工具 来执行任务，例如从数据库检索数据、发出 API 请求或运行自定义代码。请参阅 工具调用 指南了解更多信息。

结构化输出​

可以要求聊天模型以特定格式（例如 JSON 或匹配特定模式）进行响应。此功能对于信息提取任务非常有用。请在 结构化输出 指南中了解更多关于此技术的信息。

多模态​

大型语言模型 (LLMs) 不仅限于处理文本。它们还可以用于处理其他类型的数据，例如图像、音频和视频。这被称为 多模态。

目前，只有部分 LLM 支持多模态输入，几乎没有 LLM 支持多模态输出。有关详细信息，请咨询特定模型文档。

上下文窗口​

聊天模型的上下文窗口是指模型一次可以处理的最大输入序列大小。虽然现代 LLM 的上下文窗口非常大，但它们仍然是开发人员在处理聊天模型时必须牢记的限制。

如果输入超过上下文窗口，模型可能无法处理整个输入并可能引发错误。在对话应用程序中，这一点尤为重要，因为上下文窗口决定了模型在整个对话中可以“记住”多少信息。开发人员通常需要将输入管理在上下文窗口内，以在不超出限制的情况下保持连贯的对话。有关处理对话中记忆的更多详细信息，请参阅 记忆。

输入的大小以 Token 为单位，Token 是模型使用的处理单元。

高级主题​

速率限制​

许多聊天模型提供商对在给定时间段内可以发出的请求数量设置了限制。

如果您达到速率限制，通常会收到提供商的速率限制错误响应，并且需要等待一段时间才能发出更多请求。

您有几种选择来处理速率限制：

  1. 尝试通过错开请求来避免触发速率限制：聊天模型在初始化时接受一个 rate_limiter 参数。此参数用于控制请求发送到模型提供商的速率。错开对给定模型的请求是评估其性能的基准测试模型的特别有用的策略。有关如何使用此功能的更多信息，请参阅 如何处理速率限制。
  2. 尝试从速率限制错误中恢复：如果您收到速率限制错误，您可以在重试请求之前等待一段时间。等待时间可以随着后续速率限制错误的出现而增加。聊天模型具有一个 max_retries 参数，可用于控制重试次数。有关更多信息，请参阅 标准参数 部分。
  3. 切换到另一个聊天模型：如果您在某一个聊天模型上遇到了速率限制，您可以切换到另一个没有速率限制的聊天模型。

缓存​

聊天模型 API 可能很慢，因此自然会想到是否要缓存先前对话的结果。理论上，缓存可以通过减少向模型提供商发出的请求数量来提高性能。在实践中，缓存聊天模型响应是一个复杂的问题，应谨慎处理。

原因是在对话中您可能不太可能在第一次或第二次交互后命中缓存，特别是如果您依赖缓存精确的输入到模型中。例如，您认为有多少次对话会以完全相同的消息开始？有多少次对话会以完全相同的三个消息开始？

一种替代方法是使用语义缓存，即根据输入的含义而不是精确输入来缓存响应。这在某些情况下可能有效，但在其他情况下可能无效。

语义缓存会在您的应用程序的关键路径中引入对另一个模型的依赖（例如，语义缓存可能依赖于一个 嵌入模型 将文本转换为向量表示），并且不能保证准确捕获输入的含义。

但是，在某些情况下缓存聊天模型响应可能是有益的。例如，如果您有一个用于回答常见问题的聊天模型，缓存响应可以帮助减少模型提供商的负载、降低成本并提高响应时间。

有关更多详细信息，请参阅 如何缓存聊天模型响应 指南。

相关资源​

概念指南​