OpenGPTs 是什麼呢？不久前，在 OpenAI 開發那日推出的 OpenGPTs：一種可能的開源 GPT 商店形態。它由 LangGraph 的一個早期版本驅動， LangGraph 是 LangChain 的一個擴展，旨在構建作為圖(graphs)的代理。兩周之前發佈的 LangGraph，上周末又將 OpenGPTs 更新為完全使用 LangGraph（還新增了一些功能）。

在這篇博客中，我們將討論：

1. 消息圖 MessageGraph：OpenGPTs 所運行的一種特殊圖
2. 認知架構 Cognitive architectures：OpenGPTs 支持的三種不同類型的認知架構，以及它們的區別
3. 持久性 Persistence：如何通過 LangGraph 檢查點在 OpenGPTs 中加入持久性
4. 配置 Configuration：如何使用 LangChain 原始模型配置所有這些不同的機器人
5. 新模型 Configuration：支持的新模型
6. 新工具 New tools：支持的新工具
7. astream_events：如何使用這種新方法來流式傳輸令牌和中間步驟

消息圖 MessageGraph

OpenGPTs 運行在 MessageGraph 上，它是在 LangGraph 中引入的一種特殊圖。這個圖特殊的地方在於，每個節點都接受一個消息列表，並返回要添加到消息列表的消息。這種“消息傳遞”有幾個有趣的點：

• 它與新的“聊天完成”模型的 I/O 密切相關，其接受一個消息列表並返回一個消息
• 消息傳遞是分佈式系統中常見的通信方式
• 這種方式可以更容易地可視化正在進行的工作，因為每個工作單元的類型都是常見的
• 它與 OpenAI 引入的助手 API 密切相關（其中消息添加到線程上）
• 它在概念上似乎可以擴展到多代理系統（每個代理隻將消息添加到消息列表）

通過使用 MessageGraph，我們對創建的代理的輸入和輸出做了假設，但顯著的是，我們對這些代理的認知架構沒有做任何假設。正如我們下面看到的，這可以支持各種各樣的認知架構。

認知架構 Cognitive architectures

作為對 OpenGPTs 的這次更新的一部分，用戶創建機器人時可以選擇以下三種不同的認知架構。

• 助手(Assistants)：這些可以分配任意數量的工具，使用 LLM 決定何時使用它們
• RAG：這些配備了一個略取器(retriever)
• 聊天機器人(ChatBot)：這些隻是由一個自定義的系統消息參數化

助手(Assistants)

助手可以分配任意數量的工具，並使用 LLM 決定何時使用它們。這使得它們成為最靈活的選擇，但是，它們在模型較少的情況下工作得不是很好，並且可能不那麼可靠。

當創建一個助手時，要指定一些事情。

首先，你選擇要使用的語言模型。目前可供使用的隻有幾種語言模型：GPT-3.5、GPT-4、Claude和Gemini。

其次，你選擇要使用的工具。這些可以是預定義的工具，也可以是從上傳的文件構建的檢索器，你可以選擇你想要的任何數量。

然後，可以將認知架構看作是一個循環。首先，LLM 被調用，以確定要采取什麼樣的行動（如果有的話）。如果決定采取行動，那麼執行這些行動並返回循環。如果沒有決定采取任何行動，那麼 LLM 的響應就是結束循環。

這可以是一個非常強大而靈活的架構。這可能與我們人類的操作方式最接近。然而，這些可能並不總是非常可靠，一般隻有在性能更強的模型中才有效（即使是在這些模型中，他們也可能出錯）。因此，我們可以看一些更簡單的架構。

RAG

GPT 商店的一個大案例是上傳文件並使機器人了解這些文件。如果我們制作一個更專註於這個用例的架構，會是什麼樣的結果呢？

我們添加了一個 RAG 機器人 - 一個以獲取為中心的 GPT，具有簡單的架構。首先，檢索一套文件。然後，這些文件在系統消息中傳遞給語言模型，以便語言模型可以作出回應。

與助手相比，它的結構更緊密（但功能更少）。它總是會尋找一些東西，如果你知道你想尋找一些東西，這是好的，但如果用戶隻是試圖進行正常對話，可能會有些浪費。並且重要的是，這個架構隻會查找一次東西 - 所以如果它沒有找到正確的結果，就會產生糟糕的結果（與助手相比，後者可能決定再次查找東西）。

盡管這是一個更簡單的架構，它有幾個好處。首先，因為它更簡單，所以它可以很好地使用各種各樣的模型（包括大量的開源模型）。其次，如果你有一個用例，你不需要助手的靈活性（例如，你知道用戶每次都會查找信息），那麼它可以更專註。第三，與下面的最終架構相比，它可以使用外部知識。

聊天機器人 (ChatBot)

最後的架構非常簡單 - 隻是對語言模型的調用，由一個系統消息參數化。這使得 GPT 可以扮演不同的角色和人物。肯定地說，它明顯比助手或 RAGBot（它們可以訪問外部數據或計算的來源）要弱得多。但是，它仍然有價值！大多數受歡迎的 GPT 最終都隻是系統消息，盡管在很大程度上隻是系統消息，CharacterAI也做得非常成功。

持久性 (Persistence)

從一開始，OpenGPTs 就需要有持久性，特別是聊天消息的持久性。與其為此構建一個特別的解決方案，不如將此功能作為 LangGraph 的一部分加入。具體來說，當創建一個圖時，可以傳遞一個 CheckPoint 對象。然後，每次調用一個節點，這個檢查點對象將保存當前圖的狀態。

對於 OpenGPT，我們創建了一個 RedisCheckPointer，它將結果保存到 Redis。目前，這種持久性隻是用於顯示過去對話的消息，但我們很快就會以更高級的方式使用這種持久性。

配置

OpenGPTs 的另一個需求是配置。我們需要用戶能夠選擇使用哪種 LLM，哪種系統消息，哪種工具等。我們還需要保存該配置，以便他們將來可以再次使用該聊天機器人。

LangChain 的一個被低估的特性是可以將某些字段標記為可配置的。你可以對任何鏈的字段進行此操作，然後在運行時傳入配置選項。

這使我們能夠以模塊化和一致的方式輕松完成配置。首先，我們將不同的字段標記為可配置的，為了支持不同的架構，我們甚至給整個鏈提供了可配置的替代方案。然後，當用戶創建一個 GPT 時，我們會保存配置。最後，與該 GPT 進行聊天時，我們將使用保存的配置來調用鏈。

查看 OpenGPT 源代碼可以找到如何執行此操作的一些高級示例，但是請記住，所有的 LangChain 對象都可以這樣做！

新模型

隨著此次更新，還希望引入一些新模型。首先，我們集成了 Google 的 Gemini 模型。這個模型效果非常好，支持函數調用，因此我們將其添加為助手的一個選項。

添加了 Mixtral（通過 Fireworks）作為 ChatBot 和 RAGBot 的一種選項。在這些較簡單的架構下，它的工作效果非常好！

同時還更新了 OpenAI 代理，改為使用工具調用而不是函數調用。

新工具

引入了一個新工具 - Robocorp 的 Action Server。Robocorp 的 Action Server 是定義和運行任意 Python 函數作為工具的一種簡單方法。因此，即使這隻是單一的工具，也可以用它來定義許多不同的工具！

請留意我們在本周後期深入研究這一點。

astream_events

值得一提的是，我們正在使用新 astream_events 方法輕松地將所有事件（新令牌以及函數調用和函數結果）流回並向用戶顯示。我們對這個流進行了一些過濾，以獲取相關的消息或消息塊，然後在用戶界面中對它們進行漂亮的呈現。