LangChain 提供一致的接口来处理来自不同提供商的聊天模型，同时提供用于监控、调试和优化使用 LLM 的应用程序性能的附加功能。

• 与许多聊天模型提供商集成（例如，Anthropic、OpenAI、Ollama、Microsoft Azure、Google Vertex、Amazon Bedrock、Hugging Face、Cohere、Groq）。具体可以去官网看一下支持哪些聊天模型：

  https://python.langchain.com/docs/integrations/chat/

• 使用 LangChain 的消息格式或 OpenAI 格式。

• 标准工具调用 API：用于将工具绑定到模型、访问模型发出的工具调用请求以及将工具结果发送回模型的标准接口。

• 通过 with_structured_output 方法构造输出的标准 API（/docs/concepts/structured_outputs）。

• 提供对异步编程、高效批处理和丰富的流式 API 的支持。

• 与 LangSmith 集成，用于监控和调试基于 LLM 的生产级应用程序。

• 其他功能，如标准化 token 使用、速率限制、缓存等。

顺便提一嘴：LangSmith 是一个一体化的开发者平台，适用于 LLM 支持的应用程序生命周期的每个步骤。我们可以用它来调试、协作、测试和监控我们的 LLM 应用程序。不过这不是必须要用的。

LangChain 有许多聊天模型集成，我们可以自由选择使用来自不同提供商的各种模型。

这些集成有两种类型：

• 官方模型：这些模型由 LangChain 和/或模型提供商正式支持。你可以在 langchain-<provider> 包中找到这些模型。比如 langchain-openai。

• 社区模型：有些模型主要由社区贡献和支持。你可以在 langchain-community 包中找到这些模型。

LangChain 聊天模型的命名约定是在其类名前加上“Chat”（例如 ChatOllama、ChatAnthropic、ChatOpenAI 等）。

可以去这里看受支持的模型列表：

https://python.langchain.com/docs/integrations/chat/

请注意：

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

LangChain 聊天模型实现了 BaseChatModel 接口。由于 BaseChatModel 还实现了 Runnable 接口，因此聊天模型支持标准流式传输接口、异步编程、优化批处理等。

关键方法

聊天模型的许多关键方法都将消息作为输入进行操作，并将消息作为输出返回。聊天模型的关键方法包括：

• invoke：与聊天模型交互的主要方法。它将消息列表作为输入并返回消息列表作为输出。

• stream：一种允许我们在聊天模型生成时以流式传输的方式返回其输出的方法。

• batch：一种允许我们将多个对聊天模型的请求批量处理以提高处理效率的方法。

• bind_tools：一种允许我们将工具绑定到聊天模型以在模型的执行上下文中使用的方法。

• with_structured_output：用于原生支持结构化输出的模型的 invoke 方法的包装器。

其他重要方法可以在 BaseChatModel API 官方文档中找到：

https://python.langchain.com/api_reference/core/language_models/langchain_core.language_models.chat_models.BaseChatModel.html

输入和输出

现代LLM通常通过聊天模型接口访问，该接口将消息作为输入并返回消息作为输出。消息通常与角色（例如“system”、“human”、“assistant”）以及一个或多个包含文本或潜在多模式数据（例如图像、音频、视频）的内容块相关联。

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

• LangChain 消息格式：LangChain 自己的消息格式，在 LangChain 内部使用。默认使用。

• OpenAI 的消息格式：OpenAI 的消息格式。

聊天模型提供了一组标准参数，可用于配置模型。这些参数通常用于控制模型的行为，例如输出的 temperature、响应中的最大 token 数以及等待响应的最大时间。

• model：想要使用的特定 AI 模型的名称或标识符（例如“gpt-3.5-turbo”或“gpt-4”）。

• temperature：控制模型输出的随机性。较高的值（例如 1.0）可使响应更具创造性，而较低的值（例如 0.1）可使响应更具确定性和针对性。

• max_tokens：限制响应中的 token 总数（单词和标点符号）。用于控制输出的长度。

• stop：指定停止序列，指示模型应何时停止生成标记。例如，你可以使用特定字符串来表示响应的结束。

• max_retries：如果由于网络超时或速率限制等问题导致请求失败，系统重新发送请求的最大尝试次数。

• api_key：OpenAI、阿里等模型提供商的接口密钥。

• base_url：发送请求的 API 端点的 URL。

• rate_limiter：用于分隔请求以避免超出速率限制。这是可选的。

需要注意的一些重要事项：

• 标准参数仅适用于公开具有预期功能的参数的模型提供程序。例如，某些提供程序不公开 max_tokens 的配置，因此这些提供程序不支持 max_tokens。

• 标准参数目前仅在具有自己的集成包（例如 langchain-openai、langchain-anthropic 等）的集成中强制执行，而不会在 langchain-community 中的模型中强制执行。

• ChatModel 还接受特定于该集成的其他参数。要查找 ChatModel 支持的所有参数，请转到该模型的 API 参考。

在以后的文章中，我们经常会交替使用术语“LLM”和“聊天模型”。这是因为大多数现代 LLM 都是通过聊天模型接口向用户公开的。

但是，LangChain 还实现了较旧的 LLM，这些 LLM 不遵循聊天模型接口，而是使用以字符串为输入并返回字符串作为输出的接口。这些模型通常不以“Chat”前缀命名（例如，Ollama、Anthropic、OpenAI 等）。这些模型实现了 BaseLLM 接口，可能以“LLM”后缀命名（例如，OllamaLLM、AnthropicLLM、OpenAILLM 等）。一般来说，我们不应使用这些模型。

聊天模型的上下文窗口（Context Window）是指模型一次可以处理的输入序列的最大大小。虽然现代 LLM 的上下文窗口非常大，但它们仍然存在开发人员在使用聊天模型时必须牢记的限制。

如果输入超出上下文窗口，模型可能无法处理整个输入并可能引发错误。在对话应用程序中，这一点尤其重要，因为上下文窗口决定了模型在整个对话过程中可以“记住”多少信息。开发人员通常需要在上下文窗口内管理输入，以保持连贯的对话而不超出限制。

输入的大小以 token 为单位，token 是模型使用的处理单位。

许多聊天模型提供商对给定时间段内可以发出的请求数量施加了限制。

如果达到速率限制，我们通常会收到提供商发出的速率限制错误响应，并且需要等待一段时间才能发出更多请求。

有几种处理速率限制的选项：

• 尝试通过间隔请求来避免达到速率限制：聊天模型接受可以在初始化期间提供的 rate_limiter 参数。此参数用于控制向模型提供商发出请求的速率。在对模型进行基准测试以评估其性能时，将请求间隔开到给定模型是一种特别有用的策略。有关如何使用此功能的更多信息，请参阅如何处理速率限制。

• 尝试从速率限制错误中恢复：如果你收到速率限制错误，你可以等待一段时间再重试请求。每次后续速率限制错误都可以增加等待的时间。聊天模型有一个 max_retries 参数，可用于控制重试次数。

• 回退到另一个聊天模型：如果一个聊天模型达到了速率限制，则可以切换到另一个不受速率限制的聊天模型。

聊天模型 API 可能很慢，因此一个自然的问题是是否要缓存以前对话的结果。从理论上讲，缓存可以通过减少对模型提供者的请求数量来帮助提高性能。实际上，缓存聊天模型响应是一个复杂的问题，应谨慎处理。

原因是，如果依赖于将精确的输入缓存到模型中，则在对话中的第一次或第二次交互后不太可能获得缓存命中。例如，你认为多个对话以完全相同的消息开始的可能性有多大？完全相同的三条消息呢？

另一种方法是使用语义缓存，你可以根据输入的含义而不是确切的输入本身来缓存响应。这在某些情况下可能有效，但在其他情况下则无效。

语义缓存在应用程序的关键路径上引入了对另一个模型的依赖（例如，语义缓存可能依赖于嵌入模型将文本转换为矢量表示），并且不能保证准确捕获输入的含义。

但是，在某些情况下，缓存聊天模型响应可能会有所帮助。例如，如果你有一个用于回答常见问题的聊天模型，则缓存响应可以帮助减少模型提供者的负载并缩短响应时间。