Chat Model聊天模型

 OpenAI 发布了 ChatGPT 端点。它在上市时进行了多项重大改进，最引人注目的是价格便宜 10 倍，而且速度更快。但它还附带了一个全新的 API 端点。我们能够快速为此端点编写一个包装器，让用户像 LangChain 中的任何普通 LLM 一样使用它，但这并没有充分利用新的基于消息的 API。在这篇博文中，我们将介绍新的 API 模式，以及我们如何调整 LangChain 以适应 ChatGPT 以及所有未来基于聊天的模型。
链接：
python 版本：https://python.langchain.com/docs/modules/model_io/models/chat/
JS/TS版本：https://js.langchain.com/docs/get_started/introduction/
https://js.langchain.com/docs/modules/chains/foundational/llm_chain
1
2
3
4
5

为什么需要新的抽象？

OpenAI 发布了一个新的 API——有什么大不了的？为什么需要新的抽象？

尽管 ChatGPT 端点在底层使用语言模型，但 API 与现有的 GPT-3 端点有很大不同。这有点简化，但现有的 GPT-3 端点有一个接口：

• Input: text
• Output: text

新的 ChatGPT 端点具有以下接口：

• Input: List of chat messages
• Output: chat message

这个新接口意味着我们对语言模型的输入/输出的一些抽象不再正确。例如，我们之前构建的提示策略都假设 PromptTemplate 的输出是字符串。然而，现在对于聊天模型，输入需要是消息列表。由于提示是许多 LangChain 实用程序和功能的核心，因此这是一个非常深入的变化。

为什么要聊天模型?

好的，现在有一种新型模型。为什么我们急于支持？它真的与现有 API 如此不同以至于值得新的抽象吗？
为了回答这个问题，值得思考为什么 OpenAI 选择以这种格式发布模型。这部分全是猜测。此 API 与之前的 GPT-3 API 之间的主要区别在于，现在用户输入有更多的结构，以不同类型的消息的形式出现。具体来说，ChatGPT API 允许区分“用户”、“助理”和“系统”消息。这种差异可以允许模型以不同的方式处理不同类型的消息，这在理论上可以提高基于这些模型构建的应用程序的安全性。例如，针对 LLM 应用程序的一种常见攻击类型是提示注入攻击(prompt injection attacks)，其中最终用户指示应用程序执行其不打算执行的操作。现在通过将这种结构添加到提示中，理论上，最终应用程序可以将所有应用程序指令放入“系统”消息中，将所有最终用户输入放入“用户”消息中，然后可以训练模型始终“服从”系统消息，不管用户消息可能告诉它什么。实际上，针对聊天模型的即时注入攻击似乎仍然存在，因此这可能无法完全解决这些问题。只有时间会给出答案。
上面的“用户”与“助理”与“系统”消息的示例也说明了为什么这种格式与现有的 API 有足够的不同，值得有自己的抽象。
还有更实际的原因。 OpenAI 尚未发布与 ChatGPT 模型相对应的“正常”LLM 端点，因此如果人们想充分利用这些模型的速度/成本，他们需要使用 ChatGPT API。还有传言称其他聊天式模型即将上市（Anthropic 的 Claude、Google 的 Bard、Cohere 的对话模型的早期传言）。尽管尚不清楚这些模型将以何种格式提供，但假设它们也将具有基于聊天的 API 选项并不疯狂。

我们使用新抽象的目标是什么？

在设计这些新的抽象时，我们考虑了三个主要目标：
1.让用户充分利用新的聊天模型界面
如上所述，聊天模型的 API 与现有的 LLM API 有很大不同。我们想让用户利用这一点。

2.允许“普通”LLM API 和基于聊天的 API 之间提示的互操作性
尽管“普通”LLM 与基于聊天的 API 的提示肯定存在差异，但我们希望尽可能无缝地（在合理范围内）在任一类型的模型中使用相同的提示。实际上，我们优先考虑了这一点，因为代码库中的大多数提示都针对 LLM 进行了优化，并且我们不希望它们对基于聊天的模型造成严重破坏。
3.使抽象变得通用，而不仅仅是 OpenAI
我们不希望我们放置的任何抽象都是特定于 OpenAI 的。如上所述，有传言称其他聊天风格的模型即将上市，我们希望确保能够无缝支持它们。

这些新的抽象是什么？

虽然看起来我们在代码库中引入了过多的抽象，但它们都是为了让添加到代码库中的任何内容都能与这些新模型一起工作。 LangChain 的目标之一始终是允许语言模型提供商之间的互操作性，我们希望这对此有所帮助。

聊天信息

我们正在为不同类型的聊天消息添加抽象

• HumanMessage：从人类的角度发送的消息
• AIMessage：从人类正在与之交互的人工智能的角度发送的消息
• SystemMessage： 设定人工智能应遵循的目标的消息
• ChatMessage：允许任意设置角色的消息

Chat Model（聊天模型）

我们还为聊天模型添加了抽象。这些类型的模型期望的接口与底层 ChatGPT API 非常相似 - 它接收聊天消息列表并返回聊天消息。

Chat Message Templates

由于大多数应用程序不会对要发送的消息进行硬编码，而是利用“PromptTemplates”的思想（接受用户输入并返回提示），因此我们添加了相应的聊天消息提示模板。

• HumanMessagePromptTemplate：公开一个方法来接受用户输入并返回 HumanMessage 的类
• AIMessagePromptTemplate：公开接受用户输入并返回 AIMessage 的方法的类
• SystemMessagePromptTemplate：公开一个方法来接受用户输入并返回 SystemMessage 的类
• ChatMessagePromptTemplate：公开接受用户输入并返回 ChatMessage 的方法的类

Prompt Values

为了实现“普通”LLM API 和基于聊天的 API 之间提示的互操作性，我们添加了 PromptValue 的概念。这是一个具有以下方法的类：

• to_string: converts the PromptValue into a string, to be used in “normal” LLM APIs
• to_messages: converts the PromptValue into a list of messages, to be used in chat-based APIs

为此，我们还向 BaseLLM 和 BaseChatModel 类添加了方法，这些方法接收 PromptValues，分别将它们转换为字符串或 ChatMessages，然后将它们传递给模型。

这些如何与我们的目标保持一致？

让我们确保这些抽象符合我们设定的目标

#1：让用户充分利用新的聊天模型界面

我们涵盖了 ChatGPT 界面中的所有功能。有些东西我们没有明确地进行抽象（例如名称参数），但它们仍然可用，并且如果它们变得更加相关，我们可能会在将来添加更好的支持。

#2：允许“普通”LLM API 和基于聊天的 API 之间提示的互操作性

PromptValue 抽象应该允许这一点。我们有非常简单的方法将字符串转换为消息（使其成为单个 HumanMessage）并将消息转换为字符串（只需将整个列表转换为字符串）。这些（尤其是消息到字符串的方法）绝对可以改进。

#3：使抽象变得通用，而不仅仅是 OpenAI

我们相信，通过添加人类/人工智能/系统消息的明确概念，而不是依赖具有“角色”键的字典，我们已经将自己设置为与模型 API 无关。这样，如果另一个模型提供者有不同的命名约定（例如，他们将 AI 称为“AI”而不是 OpenAI 的“助手”），我们可以轻松映射到模型包装器中的这些命名约定。

Next steps（下一步）

希望这有助于澄清我们对引入的抽象的一些想法。我们希望得到有关这些抽象的反馈。在不到一周的时间内对一个全新的概念进行抽象总是令人恐惧，因此我们非常感谢任何建议和评论。

我们还将致力于继续围绕聊天模型添加更多功能。例如，更好的消息到字符串支持、更好的少数示例支持以及更好的聊天记忆支持。

由于这次意外的发布，我们还积累了大量积压的物品，因此感谢您在我们尝试筛选这些物品时的耐心等待。

最后，非常感谢 Anthropic 团队（特别是 Mike Lambert）对其中一些抽象进行了思考，并确保它们在 ChatGPT API 之外具有通用性。当只有一个实例可供查看时，尝试概括抽象总是很困难，因此我们非常欣赏他们的智慧。