聊天模型
概述
大型语言模型 (LLM) 是先进的机器学习模型，擅长各种与语言相关的任务，例如文本生成、翻译、摘要、问答等等，而无需为每个场景进行特定任务的微调。
现代 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 的生产级应用程序。
- 其他功能，如标准化的 令牌使用情况、速率限制、缓存 等。
集成
LangChain 有许多聊天模型集成，允许您使用来自不同提供商的各种模型。
这些集成有两种类型
- 官方模型：这些模型是 LangChain 和/或模型提供商官方支持的模型。您可以在
langchain-<provider>包中找到这些模型。 - 社区模型：这些模型主要由社区贡献和支持。您可以在
langchain-community包中找到这些模型。
LangChain 聊天模型以一种约定命名，即在其类名称前加上 "Chat" 前缀（例如，ChatOllama、ChatAnthropic、ChatOpenAI 等）。
请查看 聊天模型集成 以获取受支持模型的列表。
名称中不包含 "Chat" 前缀或名称中包含 "LLM" 后缀的模型通常指的是较旧的模型，这些模型不遵循聊天模型接口，而是使用接受字符串作为输入并返回字符串作为输出的接口。
接口
LangChain 聊天模型实现了 BaseChatModel 接口。由于 BaseChatModel 也实现了 Runnable 接口，因此聊天模型支持 标准流式传输接口、异步编程、优化的 批处理 等。有关更多详细信息，请参阅 Runnable 接口。
聊天模型的许多关键方法都对 消息 进行操作，作为输入并返回消息作为输出。
聊天模型提供了一组标准参数，可用于配置模型。这些参数通常用于控制模型的行为，例如输出的温度、响应中的最大令牌数以及等待响应的最大时间。有关更多详细信息，请参阅 标准参数 部分。
在文档中，我们经常互换使用术语 "LLM" 和 "聊天模型"。这是因为大多数现代 LLM 通过聊天模型接口向用户公开。
但是，LangChain 也有不遵循聊天模型接口的旧版 LLM 的实现，而是使用接受字符串作为输入并返回字符串作为输出的接口。这些模型通常在名称中没有 "Chat" 前缀（例如，Ollama、Anthropic、OpenAI 等）。这些模型实现了 BaseLLM 接口，并且可能以 "LLM" 后缀命名（例如，OllamaLLM、AnthropicLLM、OpenAILLM 等）。一般来说，用户不应使用这些模型。
主要方法
聊天模型的主要方法是
- invoke：与聊天模型交互的主要方法。它接受 消息 列表作为输入，并返回消息列表作为输出。
- stream：一种允许您在生成聊天模型输出时对其进行流式传输的方法。
- batch：一种允许您将对聊天模型的多个请求批量处理在一起以提高处理效率的方法。
- bind_tools：一种允许您将工具绑定到聊天模型以在模型的执行上下文中使用的方法。
- with_structured_output：
invoke方法的包装器，适用于原生支持 结构化输出 的模型。
其他重要方法可以在 BaseChatModel API 参考文档 中找到。
输入和输出
现代 LLM 通常通过聊天模型接口访问，该接口接受 消息 作为输入，并返回 消息 作为输出。消息通常与角色（例如，“系统”、“人类”、“助手”）和一个或多个内容块相关联，这些内容块包含文本或可能的多模态数据（例如，图像、音频、视频）。
LangChain 支持两种消息格式与聊天模型交互
- LangChain 消息格式：LangChain 自己的消息格式，默认使用，并在 LangChain 内部使用。
- OpenAI 的消息格式：OpenAI 的消息格式。
标准参数
许多聊天模型都有标准化的参数，可用于配置模型
| 参数 | 描述 |
|---|---|
model | 您要使用的特定 AI 模型的名称或标识符（例如，"gpt-3.5-turbo" 或 "gpt-4"）。 |
temperature | 控制模型输出的随机性。较高的值（例如 1.0）使响应更具创造性，而较低的值（例如 0.0）使响应更具确定性和重点性。 |
timeout | 在取消请求之前等待模型响应的最长时间（以秒为单位）。确保请求不会无限期挂起。 |
max_tokens | 限制响应中的令牌（单词和标点符号）总数。这控制了输出的长度。 |
stop | 指定停止序列，指示模型应何时停止生成令牌。例如，您可以使用特定的字符串来表示响应的结束。 |
max_retries | 如果由于网络超时或速率限制等问题导致请求失败，系统将尝试重新发送请求的最大次数。 |
api_key | 与模型提供商进行身份验证所需的 API 密钥。这通常在您注册访问模型时颁发。 |
base_url | 发送请求的 API 端点的 URL。这通常由模型提供商提供，并且对于指导您的请求是必要的。 |
rate_limiter | 可选的 BaseRateLimiter，用于间隔请求以避免超出速率限制。有关更多详细信息，请参阅下面的 速率限制。 |
一些重要的注意事项
- 标准参数仅适用于公开具有预期功能的参数的模型提供商。例如，某些提供商不公开最大输出令牌的配置，因此在这些提供商上不支持 max_tokens。
- 标准参数目前仅在具有自己集成包的集成（例如
langchain-openai、langchain-anthropic等）上强制执行，它们不在langchain-community中的模型上强制执行。
聊天模型还接受特定于该集成的其他参数。要查找聊天模型支持的所有参数，请访问该模型的相应 API 参考文档。
工具调用
聊天模型可以调用 工具 来执行任务，例如从数据库获取数据、发出 API 请求或运行自定义代码。有关更多信息，请参阅 工具调用 指南。
结构化输出
可以请求聊天模型以特定格式（例如，JSON 或匹配特定模式）进行响应。此功能对于信息提取任务非常有用。请在 结构化输出 指南中阅读有关该技术的更多信息。
多模态
大型语言模型 (LLM) 不仅限于处理文本。它们还可用于处理其他类型的数据，例如图像、音频和视频。这被称为 多模态。
目前，只有一些 LLM 支持多模态输入，几乎没有模型支持多模态输出。请查阅具体的模型文档以了解详细信息。
上下文窗口
聊天模型的上下文窗口是指模型一次可以处理的最大输入序列大小。虽然现代 LLM 的上下文窗口非常大，但它们仍然存在开发人员在使用聊天模型时必须牢记的限制。
如果输入超过上下文窗口，则模型可能无法处理整个输入并可能引发错误。在对话应用程序中，这一点尤其重要，因为上下文窗口决定了模型在整个对话过程中可以“记住”多少信息。开发人员通常需要管理上下文窗口内的输入，以保持连贯的对话而不会超出限制。有关处理对话中记忆的更多详细信息，请参阅 记忆。
输入的大小以 令牌 衡量，令牌是模型使用的处理单位。
高级主题
速率限制
许多聊天模型提供商对在给定时间段内可以发出的请求数量施加了限制。
如果您达到速率限制，您通常会收到来自提供商的速率限制错误响应，并且需要等待才能发出更多请求。
您有以下几种选择来处理速率限制
- 尝试通过间隔请求来避免达到速率限制：聊天模型接受可在初始化期间提供的
rate_limiter参数。此参数用于控制向模型提供商发出请求的速率。在对模型进行基准测试以评估其性能时，间隔对给定模型的请求是一种特别有用的策略。有关如何使用此功能的更多信息，请参阅 如何处理速率限制。 - 尝试从速率限制错误中恢复：如果您收到速率限制错误，您可以等待一段时间再重试请求。每次后续速率限制错误都可以增加等待时间。聊天模型具有
max_retries参数，可用于控制重试次数。有关更多信息，请参阅 标准参数 部分。 - 回退到另一个聊天模型：如果您在一个聊天模型上达到速率限制，您可以切换到另一个未受速率限制的聊天模型。
缓存
聊天模型 API 可能会很慢，因此一个自然的问题是是否缓存以前对话的结果。从理论上讲，缓存可以通过减少向模型提供商发出的请求数量来帮助提高性能。实际上，缓存聊天模型响应是一个复杂的问题，应谨慎对待。
原因是，如果依赖于缓存模型的确切输入，则在对话的第一次或第二次交互后，不太可能获得缓存命中。例如，您认为有多少对话以完全相同的消息开始？完全相同的三条消息呢？
另一种方法是使用语义缓存，您可以在其中根据输入的含义而不是确切的输入本身来缓存响应。这在某些情况下可能有效，但在其他情况下则不然。
语义缓存引入了对应用程序关键路径上的另一个模型的依赖（例如，语义缓存可能依赖于 嵌入模型 将文本转换为向量表示），并且不能保证准确捕获输入的含义。
但是，在某些情况下，缓存聊天模型响应可能是有益的。例如，如果您有一个聊天模型用于回答常见问题，则缓存响应可以帮助减少模型提供商的负载、成本并缩短响应时间。
有关更多详细信息，请参阅 如何缓存聊天模型响应 指南。