聊天模型
概述
大型语言模型 (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) 不仅限于处理文本。它们还可用于处理其他类型的数据，例如图像、音频和视频。这被称为多模态。
目前，只有少数大型语言模型支持多模态输入，几乎没有模型支持多模态输出。请查阅具体模型的文档了解详情。
上下文窗口
聊天模型的上下文窗口指的是模型一次可以处理的最大输入序列大小。虽然现代大型语言模型的上下文窗口非常大，但它们仍然存在限制，开发者在使用聊天模型时必须牢记这一点。
如果输入超过了上下文窗口，模型可能无法处理整个输入，并可能引发错误。在会话应用程序中，这一点尤其重要，因为上下文窗口决定了模型在整个对话过程中可以“记住”多少信息。开发者通常需要在上下文窗口内管理输入，以保持连贯的对话而不超出限制。有关处理对话中记忆的更多详细信息，请参阅记忆。
输入的大小以tokens（令牌）衡量，这是模型使用的处理单位。
高级主题
速率限制
许多聊天模型提供商对在给定时间段内可以发出的请求数量施加了限制。
如果您达到速率限制，您通常会收到来自提供商的速率限制错误响应，并且需要等待一段时间才能发出更多请求。
您有几种处理速率限制的方法：
- 尝试通过间隔请求来避免达到速率限制：聊天模型接受一个
rate_limiter参数，该参数可以在初始化期间提供。此参数用于控制向模型提供商发出请求的速率。当对模型进行基准测试以评估其性能时，间隔向给定模型发出请求是一种特别有用的策略。请参阅如何处理速率限制，了解有关如何使用此功能的更多信息。 - 尝试从速率限制错误中恢复：如果您收到速率限制错误，您可以等待一段时间再重试请求。每次后续的速率限制错误都可以增加等待时间。聊天模型有一个
max_retries参数，可用于控制重试次数。有关更多信息，请参阅标准参数部分。 - 回退到另一个聊天模型：如果您在使用一个聊天模型时达到速率限制，您可以切换到另一个没有速率限制的聊天模型。
缓存
聊天模型 API 可能很慢，因此一个自然的问题是是否缓存先前对话的结果。理论上，缓存可以通过减少向模型提供商发出的请求数量来帮助提高性能。在实践中，缓存聊天模型响应是一个复杂的问题，应谨慎对待。
原因是，如果依赖于缓存模型的精确输入，在对话中的第一次或第二次交互之后，不太可能命中缓存。例如，您认为多个对话以完全相同的消息开始的可能性有多大？那么完全相同的三条消息呢？
另一种方法是使用语义缓存，其中根据输入的含义而不是精确的输入本身来缓存响应。这在某些情况下可能有效，但在其他情况下可能无效。
语义缓存引入了对应用程序关键路径上的另一个模型的依赖（例如，语义缓存可能依赖于嵌入模型将文本转换为向量表示），并且不能保证准确捕获输入的含义。
但是，在某些情况下，缓存聊天模型响应可能是有益的。例如，如果您有一个用于回答常见问题的聊天模型，则缓存响应可以帮助减少模型提供商的负载、成本并缩短响应时间。
请参阅如何缓存聊天模型响应指南，了解更多详细信息。