我最近收到一封來自一位優秀學者的電子郵件，詢問Botpress 如何與LLMs接。
他正在撰寫一篇有關避免廠商鎖定的論文，並想知道我們是否可能使用 LangChain 或 Haystack 之類的架構。
我很高興能與他分享，我們建立了自己的抽象，讓Botpress 建立者能與LLMs 連線。
鑑於大家對這個主題有廣泛的興趣，我希望公開這些資訊。它可能對其他開發人員或我們平台的使用者有用。希望您能像我創作時一樣覺得有趣。
Botpress 與LLMs接觸的兩種方式
Botpress 創造了自己的抽象，以兩種方式運作：
1.整合
整合具有特定輸入和輸出類型的動作概念。
我們在平台上有開放原始碼的元件，因此社群可以建立他們自己的整合，這些整合可以是私人的，也可以供大眾使用。
因此LLM 供應商 -OpenAI、Anthropic、Groq 等。- 都有整合。這也是我們的使用者可以與他們連線的一種方式。
機型配置
在Botpress Studio 中，我們有兩種一般配置：「最佳模式」和「快速模式」。我們發現，一般而言，大多數任務都很容易符合這兩種模式中的一種。
但除了純粹的模型選擇之外，我們發現不同的供應商在工具呼叫和訊息格式上有太多的差異，因此無法輕鬆地將一個模型交換到另一個模型，並期待有好的表現。
Botpress 推理引擎
正因為如此，我們創造了自己的推論引擎，稱為 LLMz，它可以與任何模型搭配使用，不需要（或只需要極少的）提示變更。而且它能提供更好的工具呼叫，在代幣成本和LLM 往返次數方面通常也有更好的表現。
這個引擎在幕後使用 typescript 種類來處理工具定義，以 markdown 來處理訊息和程式碼輸出格式，並使用LLM執行沙箱來進行推論。
LLMz 提供許多進階用例所需的最佳化與除錯功能，例如：
- 輸入字元壓縮
- 智慧型符記截斷
- 代號優化的記憶體到上下文
- 平行與複合工具呼叫
- 在單一LLM 呼叫中混合多個訊息 + 工具呼叫
- 完全類型安全工具（輸入和輸出）
- 透過沙箱序列化的長效會話
- 工具模擬、包裝和描繪
- 輕量級 V8 隔離器中的完整執行隔離（允許以非常低廉的價格快速執行數以千計的並發執行）
- 自動迭代和錯誤恢復
所有這些事情對於我們的使用個案都是必要的。但使用一般的工具調用是不可能或很難做到的。
反對輕量級路由器機型的理由
我們很早就想建立一個輕量級的路由器模型，它可以置於現有模型之上，並自動挑選適合手邊工作的模型。
但基於多種原因，我們決定不這麼做：
1.可預測性
我們的大多數客戶都希望得到可靠且可預測的結果，這是可以理解的。
所以動態模型路由器的想法對於高階代理來說有點可怕。它為LLMs 帶來了另一層不可預測性。
2.速度
延遲對我們的用例非常重要。為了讓路由器快速，模型必須比它要路由的模型 - 可能是傳統分類器 - 非常小（也可以說是非常笨）。
雖然這些軟體在特定任務上接受訓練時表現一般，但 a) 較短的上下文大小對於較長的提示來說是個問題，而且 b) 它們無法泛化到已接受訓練以外的其他提示。
3.模型至上或模型平等
雖然基準測試可能有不同的說法，但在實際使用中，我們很少看到有機型的效能優於GPT（到目前為止）。
目前仍不清楚，隨著時間的推移LLMs 是否真的會在任務 X 上表現優於任務 Y，或是所有LLMs 最終都會在大多數事情上表現極佳。如果是後者，就不值得花那麼多心思挑選模型。
透過回饋使LLMs 面向未來
LLMs 再過幾年就會成為商品，而模型選擇也不會真的成為一回事。
基於這些原因，我們決定投入心力，提供一個良好的機制，為LLMs 提供範例。
因此，我們建立了一個系統來捕捉回饋。它可以儲存「學到的知識」以供未來執行之用。它可以動態地為未來的執行提供最相關的學習，以確保可靠和持續的改進。
隨著LLMs 效能愈來愈高，我們已經準備好，也很高興能為我們平台的使用者充分利用LLMs 。
.webp)
