聊天模型
概览
大型语言模型(LLMs)是先进的机器学习模型,它们在广泛的与语言相关的任务中表现出色,例如文本生成、翻译、摘要、问答等,而无需为每个场景进行特定任务的微调。
现代大型语言模型(LLMs)通常通过聊天模型接口访问,该接口接收一个 消息 列表作为输入,并返回一条 消息 作为输出。
最新一代的聊天模型提供了额外的功能:
- 工具调用: 许多流行的聊天模型都提供原生的 工具调用 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 集成,用于监控和调试基于大语言模型的面向生产的应用程序。
- Additional features like standardized 令牌使用, 速率限制, 缓存 and more.
集成
LangChain 拥有众多聊天模型集成,允许您使用来自不同提供商的广泛模型。
这些集成分为两种类型:
- 官方模型: 这些是由 LangChain 和/或模型提供商正式支持的模型。您可以在
langchain-<provider>包中找到这些模型。 - 社区模型:这些模型主要由社区贡献和支持。你可以在
langchain-community包中找到这些模型。
LangChain 聊天模型的命名遵循一种约定,即在类名前添加“Chat”前缀(例如:ChatOllama、ChatAnthropic、ChatOpenAI等)。
请查看 聊天模型集成 以获取支持的模型列表。
名称中不包含前缀"Chat"或在后缀中包含"LLM"的模型通常指的是较旧的模型,它们不遵循聊天模型接口,而是使用一种接受字符串作为输入并返回字符串作为输出的接口。
接口
LangChain 聊天模型实现了 BaseChatModel 接口。由于 BaseChatModel 也实现了 可运行接口 (Runnable Interface),因此聊天模型支持 标准流式接口、异步编程、优化的 批处理 等特性。更多详情请参见 可运行接口 (Runnable Interface)。
聊天模型的大多数关键方法以消息作为输入并返回消息作为输出。
Chat 模型提供一组标准参数,可用于配置模型。这些参数通常用于控制模型的行为,例如输出的温度、响应中的最大令牌数以及等待响应的最长时间。有关更多详细信息,请参阅 标准参数 部分。
在文档中,我们通常会交替使用“LLM”和“聊天模型”这两个术语。这是因为大多数现代大语言模型都是通过聊天模型接口向用户提供的。
然而,LangChain 也提供了针对较旧大语言模型(LLM)的实现,这些模型不遵循聊天模型接口,而是采用一种接收字符串作为输入并返回字符串作为输出的接口。这些模型的名称通常不带“Chat”前缀(例如:Ollama、Anthropic、OpenAI等)。
这些模型实现了BaseLLM接口,其名称可能带有
关键方法
聊天模型的关键方法包括:
- invoke: 与聊天模型交互的主要方法。它接收一个 消息 列表作为输入,并返回一个消息列表作为输出。
- 流式传输: 一种方法,允许您随着聊天模型生成内容而实时流式传输其输出。
- batch: 一种允许您将多个请求批量发送到聊天模型的方法,以实现更高效的处理。
- bind_tools: 一种允许您将工具绑定到聊天模型的方法,以便在模型的执行上下文中使用。
- with_structured_output: 针对原生支持结构化输出的模型,对
invoke方法的封装。
其他重要方法可在 BaseChatModel API 参考 中找到。
输入和输出
现代大型语言模型(LLMs)通常通过聊天模型接口进行访问,该接口接收消息作为输入并返回消息作为输出。消息通常与一个角色(例如“系统”、“人类”、“助手”)相关联,并包含一个或多个内容块,这些内容块可包含文本或潜在的多模态数据(例如图像、音频、视频)。
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 参考。
工具调用
Chat 模型可以调用 工具 来执行任务,例如从数据库获取数据、发起 API 请求或运行自定义代码。有关更多信息,请参阅 工具调用 指南。
结构化输出
聊天模型可以被要求以特定格式(例如 JSON 或匹配特定模式)进行响应。此功能对于信息提取任务极其有用。请阅读 结构化输出 指南以了解更多关于该技术的细节。
多模态
大型语言模型(LLMs)不仅限于处理文本。它们也可以用于处理其他类型的数据,例如图像、音频和视频。这被称为多模态。
目前,仅部分大语言模型支持多模态输入,而几乎没有任何模型支持多模态输出。详细信息请查阅具体模型的文档。
上下文窗口
聊天模型的上下文窗口指的是模型一次能够处理的最大输入序列大小。虽然现代大型语言模型的上下文窗口相当大,但在与聊天模型一起工作时,它们仍然构成了开发者必须牢记的限制。
如果输入超过上下文窗口,模型可能无法处理整个输入并可能引发错误。在对话应用中,这一点尤为重要,因为上下文窗口决定了模型在整个对话过程中能够“记住”多少信息。开发人员通常需要在上下文窗口内管理输入,以维持连贯的对话而不超出限制。有关处理对话记忆的更多详细信息,请参阅 memory。
输入的大小以 令牌 为单位进行测量,这是模型使用的处理单元。
高级主题
Rate-limiting
许多聊天模型提供商会对给定时间段内可发出的请求数量施加限制。
如果您遇到速率限制,通常会收到来自提供商的速率限制错误响应,并且需要等待一段时间后再发出更多请求。
您可以通过以下几种方式处理速率限制:
- 为避免触发速率限制,请间隔发送请求:聊天模型接受一个
rate_limiter参数,可在初始化时提供。该参数用于控制向模型提供者发送请求的速率。在基准测试模型以评估其性能时,间隔发送对特定模型的请求是一种特别有用的策略。有关如何使用此功能的更多信息,请参阅 如何处理速率限制。 - 尝试从速率限制错误中恢复:如果您收到速率限制错误,可以在重试请求之前等待一定的时间。每次后续遇到速率限制错误时,可以逐渐增加等待时间。聊天模型有一个
max_retries参数可用于控制重试次数。有关更多信息,请参阅标准参数部分。 - 回退到另一个聊天模型:如果您遇到某个聊天模型的速率限制,可以切换到另一个未受速率限制的聊天模型。
缓存
Chat model APIs 可能较慢,因此一个自然的问题是是否应该缓存之前对话的结果。理论上,缓存可以通过减少对模型提供者的请求次数来提高性能。在实践中,缓存聊天模型响应是一个复杂的问题,应谨慎处理。
原因是,如果依赖缓存模型的精确输入,在对话的一两次交互之后获得缓存命中是极不可能的。例如,您认为多次对话以完全相同的信息开始的概率有多大?完全相同的三条消息呢?
另一种方法是使用语义缓存,即根据输入的含义而非确切的输入本身来缓存响应。这在某些情况下可能有效,但在其他情况下则不然。
语义缓存会在应用程序的关键路径上引入对另一个模型的依赖(例如,语义缓存可能依赖于嵌入模型将文本转换为向量表示),并且无法保证准确捕捉输入的含义。
然而,在某些情况下缓存聊天模型响应可能是有益的。例如,如果您有一个用于回答常见问题的聊天模型,缓存响应可以帮助减轻模型提供方的负载、降低成本并提高响应速度。
请查看有关如何缓存聊天模型响应的指南以获取更多详细信息。