聊天模型
概览
大型语言模型(LLMs)是先进的机器学习模型,擅长处理各种语言相关任务,例如文本生成、翻译、摘要、问答等,而无需为每种场景进行特定任务的微调。
现代大型语言模型通常通过聊天模型接口访问,该接口以消息列表作为输入并返回一条消息作为输出。
最新一代的聊天模型提供了额外的功能:
- 工具调用: 许多流行的聊天模型提供原生的 工具调用 API。此API允许开发者构建丰富的应用程序,使大型语言模型能够与外部服务、API和数据库进行交互。工具调用还可用于从非结构化数据中提取结构化信息,并执行各种其他任务。
- 结构化输出: 一种技术,用于让聊天模型以结构化格式响应,例如与给定模式匹配的JSON。
- 多模态: 除了文本之外,还能处理其他类型数据的能力;例如,图像、音频和视频。
特性
LangChain 提供了一种一致的接口,用于与来自不同提供商的聊天模型进行交互,同时提供了额外的功能,用于监控、调试和优化使用大语言模型的应用程序的性能。
- 与许多聊天模型提供商的集成(例如,Anthropic、OpenAI、Ollama、Microsoft Azure、Google Vertex、Amazon Bedrock、Hugging Face、Cohere、Groq)。请参阅 聊天模型集成 获取最新的受支持模型列表。
- 使用 LangChain 的 messages 格式或 OpenAI 格式。
- 标准 工具调用API: 用于将工具绑定到模型的标准接口,访问模型发出的工具调用请求,并将工具结果发送回模型。
- 通过
with_structured_output方法实现输出结构化的标准 API。 - 提供对 异步编程、高效批处理、丰富的流式API 的支持。
- 与 LangSmith 集成,用于基于大型语言模型的生产级应用程序的监控和调试。
- 其他功能,如标准化的 令牌使用、速率限制、缓存 等。
集成
LangChain 提供了许多聊天模型集成,使您能够使用来自不同提供商的多种模型。
这些集成分为两种类型:
- 官方模型: 这些是由LangChain和/或模型提供商正式支持的模型。您可以在
langchain-<provider>包中找到这些模型。 - 社区模型: 这些模型主要由社区贡献和支持。您可以在
langchain-community包中找到这些模型。
LangChain聊天模型的命名遵循一种规范,即在其类名前加上“Chat”(例如,ChatOllama、ChatAnthropic、ChatOpenAI 等)。
请查看 聊天模型集成 以了解受支持的模型列表。
名称中不包含前缀“Chat”或名称后缀包含“LLM”的模型通常指较旧的模型,这些模型不遵循聊天模型接口,而是使用以字符串作为输入并返回字符串作为输出的接口。
界面
LangChain聊天模型实现了 BaseChatModel 接口。由于 BaseChatModel 也实现了 Runnable Interface,聊天模型支持 标准流式接口、异步编程、优化的 批处理 等功能。更多详情请参见 Runnable Interface。
聊天模型的许多关键方法以消息作为输入,并返回消息作为输出。
聊天模型提供了一组标准参数,可用于配置模型。这些参数通常用于控制模型的行为,例如输出的温度、响应中的最大标记数以及等待响应的最大时间。有关更多详细信息,请参阅 标准参数 部分。
在文档中,我们通常会交替使用“LLM”和“Chat Model”这两个术语。这是因为大多数现代大型语言模型都是通过聊天模型接口向用户提供的。
然而,LangChain 还实现了不遵循聊天模型接口的较旧的大语言模型,这些模型使用的是以字符串作为输入并返回字符串作为输出的接口。这些模型通常没有“Chat”前缀(例如 Ollama、Anthropic、OpenAI 等)。
这些模型实现了 BaseLLM 接口,可能以“LLM”后缀命名(例如 OllamaLLM、AnthropicLLM、OpenAILLM 等)。通常情况下,用户不应使用这些模型。
关键方法
聊天模型的关键方法包括:
- invoke: 与聊天模型交互的主要方法。它接受一个 消息 列表作为输入,并返回一个消息列表作为输出。
- 流式传输: 一种方法,允许您在聊天模型生成过程中实时流式传输输出。
- 批量: 一种方法,可让您将多个请求批处理到聊天模型中,以实现更高效的处理。
- bind_tools: 一种方法,允许您将工具绑定到聊天模型,以便在模型的执行环境中使用。
- with_structured_output: 一个包装器,用于调用原生支持结构化输出的模型的
invoke方法。
有关其他重要方法,请参见 BaseChatModel API 参考。
输入和输出
现代大型语言模型通常通过聊天模型接口进行访问,该接口以消息作为输入并返回消息作为输出。消息通常与角色(例如“系统”、“人类”、“助手”)相关联,并包含一个或多个内容块,这些内容块可能包含文本或多种模态数据(例如图像、音频、视频)。
LangChain 支持两种消息格式,用于与聊天模型进行交互:
- LangChain消息格式: LangChain自身的消息格式,默认使用,并在LangChain内部使用。
- OpenAI的消息格式: OpenAI的消息格式。
标准参数
许多聊天模型都具有标准化的参数,可用于配置模型:
| 参数 | 描述 |
|---|---|
model | The name or identifier of the specific AI model you want to use (e.g., "gpt-3.5-turbo" or "gpt-4"). |
temperature | Controls the randomness of the model's output. A higher value (e.g., 1.0) makes responses more creative, while a lower value (e.g., 0.0) makes them more deterministic and focused. |
timeout | The maximum time (in seconds) to wait for a response from the model before canceling the request. Ensures the request doesn’t hang indefinitely. |
max_tokens | Limits the total number of tokens (words and punctuation) in the response. This controls how long the output can be. |
stop | Specifies stop sequences that indicate when the model should stop generating tokens. For example, you might use specific strings to signal the end of a response. |
max_retries | The maximum number of attempts the system will make to resend a request if it fails due to issues like network timeouts or rate limits. |
api_key | The API key required for authenticating with the model provider. This is usually issued when you sign up for access to the model. |
base_url | The URL of the API endpoint where requests are sent. This is typically provided by the model's provider and is necessary for directing your requests. |
rate_limiter | An optional BaseRateLimiter to space out requests to avoid exceeding rate limits. See rate-limiting below for more details. |
需要注意的一些重要事项:
- 标准参数仅适用于提供具有所需功能参数的模型提供商。例如,某些提供商不提供最大输出令牌的配置,因此这些提供商不支持 max_tokens。
- 标准参数目前仅对具有独立集成包的集成(例如
langchain-openai、langchain-anthropic等)强制执行,它们在langchain-community中的模型上不会被强制执行。
聊天模型还接受特定于该集成的其他参数。要查找聊天模型支持的所有参数,请前往该模型的相应 API 参考。
工具调用
聊天模型可以调用 工具 来执行任务,例如从数据库中获取数据、发起API请求或运行自定义代码。请参阅 工具调用 指南以了解更多信息。
结构化输出
聊天模型可以被请求以特定格式进行响应(例如 JSON 或匹配特定模式)。此功能在信息提取任务中非常有用。请阅读 结构化输出 指南以了解该技术的更多信息。
多模态
大型语言模型(LLMs)不仅限于处理文本。它们还可以用于处理其他类型的数据,例如图像、音频和视频。这被称为 多模态。
目前,仅有一些大型语言模型支持多模态输入,几乎没有任何模型支持多模态输出。请查阅具体模型的文档以获取详细信息。
上下文窗口
聊天模型的上下文窗口指的是该模型一次能够处理的最大输入序列长度。尽管现代大型语言模型的上下文窗口已经相当大,但开发者在使用聊天模型时仍需牢记这一限制。
如果输入超过上下文窗口,模型可能无法处理整个输入并可能引发错误。在对话应用程序中,这一点尤其重要,因为上下文窗口决定了模型在整个对话过程中能够“记住”的信息量。开发者通常需要管理输入以保持对话连贯性,同时不超过限制。有关如何处理对话中的记忆的更多详情,请参阅 存储。
输入的大小以标记为单位进行衡量,这是模型处理时使用的单位。
高级主题
Rate-limiting
许多聊天模型提供商对每个时间段内可发出的请求数量设有限制。
如果你达到速率限制,通常会从服务商那里收到一个速率限制错误响应,你需要等待一段时间后才能继续发送请求。
处理速率限制有几种选择:
- 通过分散请求来避免触发速率限制:聊天模型在初始化时接受一个
rate_limiter参数。此参数用于控制向模型提供商发送请求的频率。在对模型进行基准测试以评估其性能时,分散对特定模型的请求是一种特别有用的方法。有关如何使用此功能的更多信息,请参阅 如何处理速率限制。 - 尝试从速率限制错误中恢复:如果收到速率限制错误,可以在重试请求之前等待一段时间。每次后续的速率限制错误发生时,可以增加等待时间。聊天模型有一个
max_retries参数,可用于控制重试次数。有关更多信息,请参阅 标准参数 部分。 - 回退到另一个聊天模型:如果你在使用某个聊天模型时遇到速率限制,可以切换到另一个未受速率限制的聊天模型。
缓存
聊天模型的API可能会很慢,因此一个自然的问题是:是否应该缓存之前对话的结果。理论上,缓存可以减少向模型提供商发出的请求数量,从而提升性能。但在实际应用中,缓存聊天模型的响应是一个复杂的问题,应当谨慎处理。
原因是,如果仅依赖缓存输入到模型的精确内容,在对话的第一次或第二次交互之后获得缓存命中是不太可能的。例如,你认为多个对话以完全相同的初始消息开始的可能性有多大?三个完全相同的消息呢?
另一种方法是使用语义缓存,即根据输入的含义而非输入本身来缓存响应。这种方法在某些情况下可能有效,但在其他情况下则不然。
语义缓存会在应用程序的关键路径上引入对另一个模型的依赖(例如,语义缓存可能依赖于一个嵌入模型将文本转换为向量表示),并且无法保证能准确捕捉输入的含义。
然而,在某些情况下,缓存聊天模型的响应是有益的。例如,如果你有一个用于回答常见问题的聊天模型,缓存响应可以帮助减少对模型提供商的负载和成本,并提高响应速度。
请参阅 如何缓存聊天模型响应 指南以获取更多详细信息。