我最近收到一封來自一位才華橫溢的學者的電子郵件，詢問如何Botpress 與介面LLMs 。
他正在寫一篇關於避免供應商鎖定的論文，並想知道我們是否可能使用像 LangChain 或 Haystack 這樣的框架。
我非常高興與他分享，我們創造了自己的抽象，允許Botpress 與建構器交互LLMs 。
鑑於人們對這個主題更廣泛的興趣，我想公開這些資訊。它可能對其他開發人員或我們平台的用戶有用。我希望你會發現它像我發現它一樣有趣。
兩種方式Botpress 與介面LLMs
Botpress 創造了自己的抽象，其工作方式有兩種：
1. 集成
整合具有具有特定輸入和輸出類型的操作的概念。
我們在平台上擁有開源元件，因此社群可以創建自己的集成，這些集成可以是私有的，也可以供公共使用。
所以LLM 提供者 – OpenAI 、Anthropic、Groq 等 – 各有一個整合。這是我們的用戶與他們互動的一種方式。
2. LLM 整合介面
在整合概念之上，我們新增了「介面」。
這些只是整合可以擴展的標準模式定義。我們為LLMs創建了一個標準模式。
只要整合擴展了此架構，該整合就被視為LLM 提供者。所以它可以開箱即用Botpress 。
以下是一些範例Botpress 針對不同的集成LLM 提供者：
我們有類似的介面用於text2image、image2text、voice2text、text2voice等。
型號配置
裡面的Botpress Studio，我們有兩個通用配置：「最佳模型」和「快速模型」。我們發現，一般來說，大多數任務很容易適合這兩種模式之一。
但除了純粹的模型選擇之外，我們發現不同的提供者在工具呼叫和訊息格式方面存在很大差異，以至於無法輕鬆地將一種模型交換到另一種模型並期望獲得良好的效能。
這Botpress 推理機
因此，我們創建了自己的推理引擎，稱為 LLMz，它適用於任何模型，無需（或極少）提示更改。它提供了更好的工具調用，並且在代幣成本和成本方面通常也提供了更好的性能。 LLM 往返。
該引擎在幕後使用打字稿類型來進行工具定義、訊息和程式碼輸出格式的降價以及LLM - 用於推理的本機執行沙箱。
LLMz 提供了高級用例所需的許多最佳化和偵錯功能，例如：
- 輸入令牌壓縮
- 智能令牌截斷
- 令牌優化的記憶體到上下文
- 並行和複合工具調用
- 多個訊息+工具調用混合在一個中LLM 稱呼
- 完全類型安全的工具（輸入和輸出）
- 透過沙箱序列化實現長期會話
- 工具模擬、包裝和追蹤
- 輕量級 V8 隔離中的完全執行隔離（允許快速運行數千個並發執行且成本非常低）
- 自動迭代和錯誤恢復
所有這些對於我們的用例來說都是必要的。但對於常規的工具呼叫來說，這些任務要不是不可能，就是很難做到。
反對輕量級路由器模型的案例
我們長期以來一直在考慮建立一個輕量級路由器模型，該模型將位於現有模型之上，並自動為手頭上的任務選擇正確的模型。
但出於多種原因，我們決定不這麼做：
1. 可預測性
我們的大多數客戶（可以理解）都希望獲得可靠且可預測的結果。
所以動態模型路由器的想法對於高階代理來說有點可怕。它帶來了另一層不可預測性LLMs 。
2. 速度
延遲對於我們的用例非常重要。為了使路由器更快，模型必須比它將路由到的模型（可能是傳統的分類器）非常小（並且可以說更愚蠢）。
雖然這些在接受特定任務訓練時通常表現良好，但a）它們的短上下文大小對於長提示來說是一個問題，b）它們無法推廣到它們所訓練的內容之外的其他提示。
3. 模型至上或模型平等
儘管基準測試可能會給出相反的結果，但在野外，我們很少看到模型表現優於其他模型GPT -4o（到目前為止）。
目前還不清楚是否LLMs 隨著時間的推移，任務 X 確實會比任務 Y 表現得更好，或者如果所有LLMs 最終會在大多數事情上表現得非常出色。在後者的情況下，模型選擇不值得付出努力。
面向未來LLMs 有回饋
LLMs 幾年後就會成為一種商品，型號選擇將不再是一件真正的事情。
基於這些原因，我們決定投入精力提供一個好的機制來提供LLMs 並舉例說明。
因此，我們建立了一個系統來捕捉回饋。它儲存“學習”以供將來執行。它還動態地為未來的執行及時提供最相關的學習內容，以確保隨著時間的推移進行可靠和持續的改進。
作為LLMs 每個構建都朝著越來越高的性能發展，我們已準備好並很高興為我們平台的用戶充分利用它們。
.svg)
.webp)
