
我最近收到一封來自一位優秀學者的電子郵件,詢問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 。