LangChain：模型I/O之Chat模型包装器

LangChain为不同供应商的Chat模型提供了统一的接口，同时集成了监控、调试与性能优化功能，助力基于大语言模型（LLMs）的应用程序开发。

官方资料：Chat models(聊天模型)，All chat models(支持的聊天语言模型)。

Chat大语言模型

当前大语言模型通常通过聊天模型接口进行访问，该接口以消息列表作为输入，并返回一条消息作为输出。

增强能力

新一代聊天模型具备以下增强能力：

1. 工具调用（Tool calling）
   许多主流聊天模型提供原生的工具调用API接口。该功能允许开发者构建功能丰富的应用程序，使LLM能够与外部服务、API和数据库进行交互。工具调用还可用于从非结构化数据中提取结构化信息，以及执行其他多样化任务。
2. 结构化输出（Structured output）
   一种使聊天模型以结构化格式（例如符合指定模式的JSON格式）生成响应的技术。
3. 多模态能力（Multimodality）
   支持处理文本以外的数据类型，例如图像、音频和视频。

Chat模型装包器

LangChain为不同供应商的聊天模型提供了统一的交互接口，同时集成了监控、调试及性能优化等额外功能，助力基于大语言模型（LLMs）的应用程序高效开发与部署。

重要提示：除非特殊兼容性需求，开发者应优先使用基于聊天模型接口的现代LLM实现方案。

from langchain.chat_models import init_chat_model

llm = init_chat_model(
    model="deepseek-chat",
    model_provider="deepseek",
    api_key="xxxxxxxxx",
    base_url="https://api.deepseek.com",
    temperature=0.7,
    max_tokens=500
)
response = llm.invoke("请问现在三进制计算机在研发有最新消息吗")
print(response.content)

核心能力

1. 多平台模型集成
   支持Anthropic、OpenAI、Ollama、微软Azure、Google Vertex、亚马逊Bedrock、Hugging Face、Cohere、Groq等主流聊天模型供应商（完整支持列表请参阅最新版聊天模型集成文档）。

2. 灵活格式兼容
   支持使用LangChain原生消息格式或OpenAI格式进行交互。

3. 标准化工具调用API：too calling API，提供统一接口实现以下功能

   • 将外部工具绑定至模型
   • 获取模型触发的工具调用请求
   • 向模型回传工具执行结果、

4. 结构化输出支持

   通过with_structured_output方法实现标准化结构化输出（如指定JSON格式的响应生成）。

5. 高效开发增强特性

   • 异步编程支持
   • 高效批处理能力
   • 功能丰富的流式API
   • 与LangSmith平台深度集成，提供LLM生产级应用的监控与调试能力

6. 企业级扩展功能

   • 标准化的令牌使用统计
   • 速率限制管理
   • 缓存优化
   • 其他高级生产环境支持特性

集成方案

LangChain提供了丰富的聊天模型集成方案，支持接入来自不同供应商的多样化模型。其集成模型主要分为两种类型：

1. 官方认证模型（Official models）
   • 由LangChain和/或模型供应商官方提供支持
   • 集成在langchain-<provider>格式的专属包中（例如langchain-openai）
2. 社区贡献模型（Community models）
   • 主要由开发者社区贡献和维护
   • 统一集成在langchain-community综合包中

LangChain聊天模型的命名有一个约定，即在类名前加上chat前缀（例如，ChatOllama、ChatAnthropic、ChatOpenAI等）。请查看聊天模型集成以获取支持的模型列表。

注意：
名称中不包含前缀Chat或名称中包含后缀LLM的型号通常是指不遵循聊天模型接口的旧型号，
而是使用一个以字符串为输入并返回字符串作为输出的接口。

接口实现

LangChain的聊天模型基于BaseChatModel接口实现。由于BaseChatModel同时实现了Runnable接口，因此聊天模型原生支持以下功能：

• 标准流式接口
• 异步编程
• 优化批处理
  其他特性细节请参阅Runnable接口文档。

核心方法逻辑：聊天模型的关键方法大多以消息（Messages）为输入，并返回消息作为输出。

标准化参数配置：聊天模型提供一组通用参数用于模型行为控制，包括：

• 输出随机性调节（temperature）
• 响应最大令牌数限制（max_tokens）
• 最大等待响应时长
  完整参数说明详见标准参数配置章节。

关键方法

LangChain 聊天模型的核心方法包括：

1. invoke：与聊天模型交互的主要方法。接收消息列表作为输入，并返回消息列表作为输出。
2. stream：支持实时流式输出生成的方法，适用于需要逐步获取模型响应的场景。
3. batch：批量处理请求的优化方法，通过合并多个请求提升处理效率。
4. bind_tools：将外部工具绑定到聊天模型的方法，扩展模型在运行上下文中调用工具的能力。
5. with_structured_output：针对原生支持结构化输出的模型，提供对invoke方法的封装包装（通过with_structured_output方法实现结构化格式响应）。

其他重要方法详见BaseChatModel API参考文档。

输入输出

当前大语言模型（LLMs）通常通过聊天模型接口进行交互，该接口以消息（Messages）作为输入并返回消息作为输出。消息通常包含以下结构要素：

• 角色（Role）：标识消息来源（如”system”系统指令、”human”用户输入、”assistant”模型回复）
• 内容块（Content Blocks）：可包含文本或扩展支持多模态数据（如图像、音频、视频等）

LangChain支持两种消息格式与聊天模型交互：

1. LangChain原生消息格式
   • 默认使用的消息格式
   • LangChain内部处理的核心数据格式
2. OpenAI消息格式
   • 兼容OpenAI API定义的消息结构
   • 便于与OpenAI生态工具链集成

标准参数

大多数聊天模型提供以下标准化参数用于配置模型行为：

参数	描述
mode	指定调用的AI模型名称或标识符 （例如"gpt-3.5-turbo"或"gpt-4"）。
api_key	模型供应商的API密钥， 用于身份验证（通常在注册服务时获取）。
base_url	模型API请求的目标端点URL，由供应商提供。
temperature	控制模型输出的随机性。 值越高（如1.0）结果越具创造性， 值越低（如0.0）结果越确定和集中。
timeout	请求模型响应的最长等待时间（秒）， 避免请求无限期挂起。
max_tokens	限制响应内容的总令牌数（单词与标点）， 控制生成文本的最大长度。
stop	定义停止序列（特定字符串）， 当模型生成到这些序列时终止输出。
max_retries	因网络超时或速率限制等问题导致失败时， 系统尝试重新发送请求的最大次数。
rate_limiter	可选的基础速率限制器（BaseRateLimiter）， 用于控制请求间隔以避免超出速率限制。 详情参见速率限制说明。

注意事项：

1. 标准参数适用范围
   标准参数仅对明确开放对应功能配置的模型供应商生效。例如，部分供应商未开放最大输出令牌数(max_tokens)的配置，因此该参数在此类模型中不可用。
2. 参数执行范围限制
   当前标准参数仅对拥有独立集成包的模型（如langchain-openai、langchain-anthropic等）生效，而在langchain-community社区包中的模型不受这些参数约束。

聊天模型还支持与特定集成平台相关的其他参数。要获取某款聊天模型完整的支持参数列表，请查阅该模型对应的API参考文档。

工具调用

聊天模型能够调用工具执行多样化任务，例如：

• 从数据库获取数据
• 发起API请求
• 运行自定义代码

详细信息请参阅工具调用指南以深入了解实现方式。

结构化输出

可要求聊天模型以特定格式生成响应（例如JSON格式或符合指定模式的结构化数据）。该特性在信息提取任务中极为实用。详细技术实现方法请参阅结构化输出指南。

多模态能力

大语言模型（LLMs）的能力不仅限于处理文本，还可扩展至处理其他类型的数据（如图像、音频、视频等），这一特性被称为多模态能力。

目前仅有部分LLMs支持多模态数据输入，几乎所有模型尚不支持生成多模态内容。

具体模型的兼容性细节请查阅对应模型文档以获取最新信息。

上下文窗口

聊天模型的上下文窗口指模型单次可处理的输入序列最大长度。尽管现代大语言模型（LLMs）的上下文窗口已显著增大，开发者仍需注意其存在的局限性。

关键影响

• 输入超限处理：若输入超出上下文窗口，模型可能无法完整处理内容并引发错误。
• 对话记忆限制：在对话式应用中，上下文窗口决定了模型在整个会话中可以记住多少历史信息，这会直接影响多轮对话的连贯性。开发人员通常需要在上下文窗口中管理输入，以保持连贯的对话，而不会超出限制。

计量单位
输入长度以令牌（token）为基本单位进行统计（token是模型处理文本的最小单元）。

高级主题

限流

多数聊天模型供应商会对特定时间段内的请求数量设定上限。

触发限制的后果

• 若触发速率限制，通常会收到供应商返回的速率限制错误响应。
• 并且需等待一段时间后才能继续发起请求。

处理策略

1. 主动规避速率限制

   • 通过间隔请求来避免触发速率限制：聊天模型支持在初始化时传入rate_limiter参数（速率限制器），用于调节请求发送速率。控制请求频率是一种非常有用的策略，该策略在模型性能基准测试场景中尤为重要。具体用法参见速率限制处理指南。

2. 错误恢复机制

   • 如果收到速率限制错误后，可指数退避重试（即每次重试前等待时间逐步增加）。
   • 通过max_retries参数控制最大重试次数（详见标准参数章节）

3. 模型回退策略

   • 如果你在某一款聊天模型触发速率限制时，你可以增加功能实现自动切换至未受限的其他模型以保障服务连续性。

缓存

聊天模型API可参存在响应延迟，但直接缓存历史对话结果并非理想解决方案。

理论上缓存能通过减少重复请求提升性能，但实际应用中缓存聊天模型响应是一个复杂的问题，应该谨慎处理以下复杂性：

1. 传统缓存机制的局限

   依赖完全相同的输入匹配进行缓存命中，但在多轮对话场景中，连续3条消息完全相同的概率极低。

   不同对话都以完全相同的消息开始的可能性极小，连续三条消息完全重复的情况更为罕见。

2. 语义缓存方案（Semantic caching）

   基于输入语义相似度而非严格文本匹配进行缓存。在部分场景有效（如FAQ高频问题回答），但在其他情况下无效。

   需在关键路径中引入其他模型依赖（例如，依赖嵌入模型将文本转换为向量表示），无法完全保证语义捕捉的准确性。

然而，在某些场景下，缓存聊天模型响应可能适用的。例如，高频重复问题应答（如客服常见问题库），缓存响应可以帮助减少模型提供者的负载、成本并缩短响应时间。

详细实现策略请参阅聊天模型响应缓存指南。

相关资料

• How-to guides on using chat models: how-to guides.
• List of supported chat models: chat model integrations.
• Messages
• Tool calling
• Multimodality
• Structured outputs
• Tokens