聊天模型
概述
大型语言模型(LLMs)是先进的机器学习模型,擅长处理各种语言相关任务,如文本生成、翻译、摘要、问答等,且无需针对每种场景进行特定任务的微调。
现代的大型语言模型通常通过聊天模型接口访问,该接口接收一系列消息作为输入,并返回一条消息作为输出。
最新一代的聊天模型提供了额外的功能:
- Tool calling: 许多流行的聊天模型提供了原生的工具调用 API。该API允许开发者构建丰富的应用程序,使LLMs能够与外部服务、API和数据库进行交互。工具调用还可以用于从非结构化数据中提取结构化信息,并执行各种其他任务。
- 结构化输出: 一种使聊天模型以结构化格式(如符合给定模式的JSON)响应的技术。
- Multimodality: 处理非文本数据的能力;例如,图像、音频和视频。
功能
LangChain 提供了一个一致的接口,用于与来自不同提供商的聊天模型合作,同时提供额外的功能来监控、调试和优化使用LLM的应用程序的性能。
- 与许多聊天模型提供商的集成(例如,Anthropic、OpenAI、Ollama、Microsoft Azure、Google Vertex、Amazon Bedrock、Hugging Face、Cohere、Groq)。请参阅聊天模型集成以获取支持模型的最新列表。
- 使用LangChain的messages格式或OpenAI格式。
- 标准 tool calling API:用于将工具绑定到模型的标准接口,访问模型发出的工具调用请求,并将工具结果发送回模型。
- 通过
with_structured_output
方法结构化输出的标准API。 - 提供对异步编程、高效批处理、丰富的流式API的支持。
- 与LangSmith集成,用于监控和调试基于LLM的生产级应用程序。
- 附加功能,如标准化的token使用、速率限制、缓存等。
集成
LangChain 有许多聊天模型集成,允许您使用来自不同提供商的多种模型。
这些集成属于以下两种类型之一:
- 官方模型: 这些是由LangChain和/或模型提供商正式支持的模型。你可以在
langchain-
包中找到这些模型。 - 社区模型: 这些模型主要由社区贡献和支持。你可以在
langchain-community
包中找到这些模型。
LangChain聊天模型的命名规则是在类名前加上“Chat”前缀(例如,ChatOllama
、ChatAnthropic
、ChatOpenAI
等)。
请查看聊天模型集成以获取支持的模型列表。
名称中不包含前缀“Chat”或包含后缀“LLM”的模型通常指的是较旧的模型,这些模型不遵循聊天模型接口,而是使用一个将字符串作为输入并返回字符串作为输出的接口。
接口
LangChain聊天模型实现了BaseChatModel接口。因为BaseChatModel
也实现了Runnable Interface,聊天模型支持标准流式接口、异步编程、优化的批处理等。更多详情请参见Runnable Interface。
聊天模型的许多关键方法操作消息作为输入并返回消息作为输出。
聊天模型提供了一组标准参数,可用于配置模型。这些参数通常用于控制模型的行为,例如输出的温度、响应中的最大令牌数以及等待响应的最长时间。详情请参阅标准参数部分。
在文档中,我们经常会交替使用术语“LLM”和“聊天模型”。这是因为大多数现代LLM都是通过聊天模型界面暴露给用户的。
然而,LangChain 也实现了较旧的 LLM,这些模型不遵循聊天模型接口,而是使用一个将字符串作为输入并返回字符串作为输出的接口。这些模型通常不以 "Chat" 前缀命名(例如,Ollama
、Anthropic
、OpenAI
等)。
这些模型实现了 BaseLLM 接口,并且可能以 "LLM" 后缀命名(例如,OllamaLLM
、AnthropicLLM
、OpenAILLM
等)。通常,用户不应使用这些模型。
关键方法
聊天模型的关键方法是:
- invoke: 与聊天模型交互的主要方法。它接受一个消息列表作为输入,并返回一个消息列表作为输出。
- stream: 一种方法,允许您在生成聊天模型的输出时进行流式传输。
- batch: 一种允许你将多个请求批量发送到聊天模型以进行更高效处理的方法。
- bind_tools: 一种方法,允许你将工具绑定到聊天模型,以便在模型的执行上下文中使用。
- with_structured_output: 一个围绕
invoke
方法的包装器,适用于原生支持结构化输出的模型。
其他重要的方法可以在BaseChatModel API 参考中找到。
输入和输出
现代的大型语言模型通常通过聊天模型接口访问,该接口接收消息作为输入并返回消息作为输出。消息通常与一个角色(例如,“系统”、“人类”、“助手”)相关联,并包含一个或多个内容块,这些内容块包含文本或可能的多模态数据(例如,图像、音频、视频)。
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,请求被发送到该URL。这通常由模型的提供者提供,并且是定向您的请求所必需的。 |
rate_limiter | 一个可选的 BaseRateLimiter,用于间隔请求以避免超过速率限制。有关更多详细信息,请参阅下面的 rate-limiting。 |
一些需要注意的重要事项:
- 标准参数仅适用于暴露具有预期功能的参数的模型提供者。例如,一些提供者不暴露最大输出标记的配置,因此在这些提供者上无法支持max_tokens。
- 标准参数目前仅在有自己集成包的集成中强制执行(例如
langchain-openai
、langchain-anthropic
等),在langchain-community
中的模型上不强制执行。
聊天模型还接受特定于该集成的其他参数。要查找聊天模型支持的所有参数,请前往该模型的API参考。
工具调用
聊天模型可以调用工具来执行任务,例如从数据库获取数据、发出API请求或运行自定义代码。请参阅工具调用指南以获取更多信息。
结构化输出
可以要求聊天模型以特定格式(例如,JSON 或匹配特定模式)进行响应。此功能对于信息提取任务非常有用。请阅读更多关于该技术的信息在结构化输出指南中。
多模态
大型语言模型(LLMs)不仅限于处理文本。它们还可以用于处理其他类型的数据,如图像、音频和视频。这被称为多模态。
目前,只有一些LLMs支持多模态输入,几乎没有一个支持多模态输出。详情请查阅具体模型的文档。
上下文窗口
聊天模型的上下文窗口指的是模型一次可以处理的输入序列的最大大小。尽管现代大型语言模型(LLMs)的上下文窗口相当大,但它们仍然存在一个限制,开发者在处理聊天模型时必须牢记这一点。
如果输入超出了上下文窗口,模型可能无法处理整个输入并可能引发错误。在对话应用中,这一点尤其重要,因为上下文窗口决定了模型在整个对话中可以“记住”多少信息。开发人员通常需要管理上下文窗口内的输入,以保持连贯的对话而不超出限制。有关在对话中处理内存的更多详细信息,请参阅memory。
输入的大小以tokens为单位进行测量,这是模型使用的处理单位。
高级主题
速率限制
许多聊天模型提供商对在给定时间段内可以发出的请求数量施加了限制。
如果你触发了速率限制,通常会从提供商那里收到一个速率限制错误响应,并且需要等待一段时间才能发出更多请求。
您有几种处理速率限制的选项:
- 尝试通过间隔请求来避免达到速率限制:聊天模型接受一个
rate_limiter
参数,该参数可以在初始化时提供。此参数用于控制向模型提供商发出请求的速率。在评估模型性能时,间隔对特定模型的请求是一个特别有用的策略。请参阅如何处理速率限制以获取有关如何使用此功能的更多信息。 - 尝试从速率限制错误中恢复:如果您收到速率限制错误,可以在重试请求之前等待一段时间。每次后续的速率限制错误都可以增加等待的时间。聊天模型有一个
max_retries
参数,可以用来控制重试次数。更多信息请参见标准参数部分。 - 回退到另一个聊天模型:如果您遇到一个聊天模型的速率限制,您可以切换到另一个没有速率限制的聊天模型。
缓存
聊天模型API可能会很慢,所以一个自然的问题是是否要缓存之前的对话结果。理论上,缓存可以通过减少向模型提供商发出的请求数量来帮助提高性能。实际上,缓存聊天模型响应是一个复杂的问题,应该谨慎处理。
原因是,如果依赖于缓存模型的确切输入,那么在对话的第一次或第二次交互后,获得缓存命中的可能性很小。例如,你认为有多少次对话会以完全相同的消息开始?那么完全相同的三条消息呢?
另一种方法是使用语义缓存,即根据输入的含义而不是确切的输入本身来缓存响应。这在某些情况下可能有效,但在其他情况下则不然。
语义缓存引入了对应用程序关键路径上另一个模型的依赖(例如,语义缓存可能依赖于嵌入模型将文本转换为向量表示),并且不能保证准确捕捉输入的含义。
然而,在某些情况下,缓存聊天模型的响应可能是有益的。例如,如果您有一个用于回答常见问题的聊天模型,缓存响应可以帮助减少模型提供者的负载、降低成本并提高响应时间。
请参阅如何缓存聊天模型响应指南以获取更多详细信息。