翻译 | 郑子铭
随着对智能应用程序的需求不断增长,开发人员越来越多地转向人工智能(AI)和机器学习(ML),以增强其应用程序的功能。聊天机器人已经成为提供对话式人工智能的最流行方式之一。ChatGPT是OpenAI开发的大型语言模型(LLM),是构建能够理解自然语言并提供智能响应的聊天机器人的强大工具。自 2022 年 11 月首次发布以来,OpenAI 的 ChatGPT 在全球范围内广受欢迎。
在这篇博文中,我和同事Sandeep Nair通过创建一个模仿其功能的Cosmos DB+ChatGPT示例应用程序(尽管程度较低),介绍了我们学习大型语言模型的经验,该模型为OpenAI的ChatGPT服务和API提供动力。我们的样本结合了OpenAI的ChatGPT和Azure Cosmos DB。具体来说,我们将结合这两个服务来构建大多数用户所熟悉的,消费者ChatGPT服务(chat.openai.com)。在这篇博文中,随着我们对样本的了解,我们还将探讨在构建智能应用时,结合Azure Cosmos DB这样的数据库来提升用户体验的其他方式。
要运行此示例应用程序,您需要有权访问 Azure OpenAI 服务。要在您的 Azure 订阅中获得访问权限,请在此处申请 Azure OpenAI 服务。
示例应用程序
让我们来看看这个应用程序。我们的应用程序试图模仿人们所熟悉的ChatGPT服务的一些功能。左手边是一个对话或 "聊天会话 "的列表。你点击其中的每一个,就可以看到一个不同的聊天会话。您还可以重命名或删除它们。每个聊天会话中都有 "聊天信息"。每条信息都有一个 "发件人 "的标识,即人类或人工智能。信息按时间顺序升序排列,并带有UTC时间戳。底部的文本框用于输入新的提示,以添加到会话中。
- Azure Cosmos DB + Azure OpenAI ChatGPT 用户界面
在走得太远之前,先了解一些定义。在与 ChatGPT 等大型语言模型 (LLM) 服务交互时,您通常会提出一个问题,该服务会给您一个答案。为了将这些变成白话,用户提供“提示”,服务提供“完成”。对于此处的示例,我们使用了 text-davinci-003 模型。当前的 ChatGPT 基于更新的模型 gpt-35-turbo。
下面是我们示例的架构。前端是托管在 Azure App Service 中的 Blazor Web 应用程序。这连接到 Azure Cosmos DB 作为数据库和托管大型语言模型的 Azure OpenAI 服务。为了尽可能轻松地部署我们的示例应用程序,请在 GitHub 上的示例自述文件中查找“部署到 Azure”按钮。 ARM 模板将处理所有连接信息,因此您不必复制和粘贴密钥。这是一个完全零接触的部署。
- Azure Cosmos DB + OpenAI ChatGPT 架构
这是我们应用程序的数据模型。非常简单,只有两个类,聊天会话和聊天消息。一切都存储在一个容器中。
- 聊天会话模型
聊天会话存储聊天会话 ID 和聊天会话名称。在应用程序中,此类还将一组聊天消息存储为本地缓存。但是,在容器中,会话和消息存储为单独的文档。 Type 属性用于区分它们。
容器的分区键是聊天会话 ID。在每个逻辑分区键值中,有一个聊天会话文档及其所有聊天消息文档。这种设计是最佳的,因为聊天消息总是通过聊天会话 ID 检索。
除了聊天会话 ID 和类型属性之外,聊天消息还包括聊天消息的时间戳、发送者属性和聊天消息本身的文本。
- 聊天消息模型
新的聊天消息将始终包含聊天会话 ID、发件人和消息本身。时间戳被生成并且 Type 属性被硬编码类似于聊天会话以区分它们。
给予 ChatGPT 记忆
如果您在 chat.openai.com 上使用过 ChatGPT,您可能已经注意到,除了回答单个提示外,您还可以与其进行对话。 ChatGPT 为您提供答案,您在没有任何其他上下文的情况下提出后续问题,ChatGPT 以上下文正确的方式做出响应,就好像您正在与它进行对话一样。
在使用底层 text-davinci-003 LLM 设计我们的示例应用程序时,我最初的假设是这个 LLM 有一些聪明的方法来保留完成之间的用户上下文,这在某种程度上是 Azure 上可用的 LLM 的一部分。我想看看它的实际效果,所以我根据输入的提示测试了该服务的 API。但是,该服务什么都不记得了。完成完全脱节。
我来给你展示。在下面的聊天中,我询问了西雅图 Lumen Field 的座位容量。然而,在我的后续问题“道奇体育场更大吗?”中,它给出了上下文不正确且实际上毫无意义的响应。看起来我们的应用程序要么有短期记忆丧失的情况,要么正在回答其他人提出的类似问题。
- 没有对话记忆的 Cosmos DB + ChatGPT
这里到底发生了什么?好吧,事实证明我的假设是不正确的。底层的 text-davinci-003 LLM 没有一些巧妙的机制来维护上下文以启用对话。这是你需要提供的东西,这样 LLM 才能做出适当的回应。
一种方法是将之前的提示和完成发送回服务,并附加最新的提示以供响应。有了对话的完整历史记录,它现在拥有必要的信息,可以根据上下文和事实做出正确的回应。当我们问“那比道奇体育场大吗?”时,它现在可以推断出我们的意思。
让我们看看我在后续发送之前的提示和完成时的同一个聊天。
- 有对话记忆的 Cosmos DB + ChatGPT
很明显,响应现在与对话的其余部分在上下文中保持一致。示例应用程序现在能够为用户模仿 ChatGPT 的对话体验。
一些实际考虑
虽然提供聊天记录是一个简单的解决方案,但也有一些限制。这些大型语言模型限制了您可以在请求中发送多少文本。这是由“令牌”门控的。代币是计算货币的一种形式,其价值可以从一个字符到一个单词的长度不等。它们由服务根据已部署模型的每个请求分配。此外,允许的最大数量因型号而异。目前,对于此示例所基于的“text-davinci-003”,每个请求的最大令牌数为 4000。在我们构建的示例中,我们测试了令牌的各种值。以下是构建此类应用程序时需要考虑的一些事项。
首先,令牌在请求和响应中都被消耗。如果您使用 4000 个令牌在 HTTP 请求中发送完整的历史记录,您将不会在响应中得到任何返回信息,因为您的令牌全部用于处理您在请求中发送的所有文本。
其次,抛开令牌限制,在每个请求上发送大量文本并不是你真正想要做的事情。它在客户端成本高昂,消耗大量带宽,并增加整体延迟。
我们如何实现内存
为了处理这些实际考虑,我们通过仅发送该对话的最新提示和完成来限制内存量。这将允许它主要响应进行对话所需的上下文。但是,如果对话随着时间的推移明显偏离,上下文就会越来越多地丢失,并且对旧提示的后续问题可能会再次导致上下文不正确的响应。不过,这已经足够好了。
我们如何实现它非常简单。首先,我们为发送到服务的对话设置了最大长度。我们首先设置一个请求可以使用的最大令牌数。我们将其设置为 3000 以保持保守。然后我们将 maxConversationLength 计算为最大令牌值集的一半。
当对我们的示例发出请求时,整个对话的长度将与 maxConversationLength 进行比较。如果它较大,则该值将用于子字符串函数中以去除最旧的字节,仅在对话中留下最新的提示和响应。
- 我们如何限制对话长度
让 ChatGPT 做到这一点
还有另一种维护对话上下文的方法,我已经看到其他人建议过,你可以考虑一下。您可以通过首先要求 LLM 总结对话来维护对话的上下文,然后使用它而不是在每个请求中发送对话的全部或部分历史记录。好处当然是大大减少了维护该上下文所需的文本量。
然而,我对这项技术有一些问题,我没有抽出时间来完全回答。例如,我应该多久刷新一次该摘要?我将如何进行后续刷新以保持保真度?我能否在仅存储有限字节的长对话中保持保真度?在思考这些问题和其他问题之后,我们决定,至少现在,不值得为此付出努力。我们的示例应用程序的实现对于大多数用例来说已经足够好了。我们稍后会回来试试这个。
然而,我们确实最终使用了这种方法,但是为了一些不同的东西。如果您最近使用过 ChatGPT,您可能会注意到它会使用您所问内容的摘要重命名聊天。我们决定做同样的事情,并要求我们的应用程序根据第一个提示是什么来总结聊天会话。这是我们如何做到的。
- 我们如何让 ChatGPT 为 UX 总结聊天
我们在这里也尝试了一堆不同的提示。但事实证明,只要告诉它你想要什么以及为什么效果最好。
指导聊天模型
事实证明,我在为 LLM 提供记忆中所描述的是围绕提示的更大概念的一部分,这些提示为模型提供了与用户交互所需的更大上下文。还有不同类型的提示。除了用于提供对话上下文的用户提示外,您还可以使用启动或系统提示来指示聊天模型以特定方式运行。这可以包括很多东西,从是否 "友好和帮助 "或 "事实和简明",甚至 "俏皮和尖刻"。
探索可能性
编写示例应用程序的过程让我思考了很多。我们的目的是创建一个简单的智能聊天应用程序,它具有一些 ChatGPT 功能,使用 Cosmos DB 来存储聊天消息。但这让我开始思考如何将像 Azure Cosmos DB 这样的数据库与像 text-davinvi-003 这样的大型语言模型结合起来。没多久我就想到了各种情景。
例如,如果我正在构建聊天机器人零售体验,我可以使用启动提示来加载用户网络会话的用户配置文件信息。这可能包括有关产品或其他建议的信息。 “嗨马克,你妈妈的生日是下个月,你想看看一些礼物创意吗?”有无限的可能性。
- 用于零售的示例智能机器人。
更进一步
提示非常适合提供信息并为聊天机器人提供一些简单的信息。但是,您可以向提示中输入多少数据是有限制的。如果您想构建一个可以访问数百万客户数据或产品推荐或其他数据点的智能聊天怎么办?您不能将 GB 的数据塞入提示中。对于这种情况,您需要通过微调来自定义模型,以更大的规模和深度训练模型。这不仅会产生更好的响应,而且还可以节省令牌并减少来自较小请求有效负载的延迟。
这一切都始于您数据库中的数据!
我们在这里展示了您可以用一个简单的例子做什么,我们将进一步研究。在这个领域期待我们提供更多示例和博客文章,这些示例和博客文章详细介绍了我们在踏上这一旅程时正在学习的内容,使用户能够使用 Azure OpenAI 和 Azure Cosmos DB 创建智能应用程序和服务。
标签:示例,DB,应用程序,会话,聊天,Azure,ChatGPT From: https://blog.51cto.com/u_12517860/6149631