原文 | Mark Brown
翻譯 | 鄭子銘
隨着對智能應用程序的需求不斷增長，開發人員越來越多地轉向人工智能（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 創建智能應用程序和服務。
在這裏開始您的旅程！
- 在 GitHub 上下載並探索我們的 Azure Cosmos DB + ChatGPT 示例應用
- 申請 Azure OpenAI 服務接入
- 獲取免費的 Azure Cosmos DB 試用版
- Open AI 平臺文檔
原文鏈接
Build Intelligent Applications using ChatGPT & Azure Cosmos DB
本作品採用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協議進行許可。
歡迎轉載、使用、重新發布，但務必保留文章署名 鄭子銘 （包含鏈接： http://www.cnblogs.com/MingsonZheng/ ），不得用於商業目的，基於本文修改後的作品務必以相同的許可發佈。
如有任何疑問，請與我聯繫 ([email protected])