我最近收到一位優秀學者的來信,詢問 Botpress 如何與 LLM 介接。
他正在撰寫一篇關於避免供應商綁定的論文,想知道我們是否使用像 LangChain 或 Haystack 這樣的框架。
我很高興地告訴他,我們自行建立了抽象層,讓 Botpress 的開發者可以與 LLM 互動。
考量到這個主題受到廣泛關注,我決定將這些資訊公開。這或許對其他開發者或我們平台的使用者有所幫助。希望你們覺得這跟我開發時一樣有趣。
Botpress 與 LLM 介接的兩種方式
Botpress 創建了自己的抽象層,主要有兩種方式:
1. 整合
整合有動作(actions)的概念,每個動作都有特定的輸入與輸出型態。
我們在平台上有開源元件,因此社群可以自行開發整合,這些整合可以是私人使用,也可以公開給大家使用。
所以 LLM 供應商——像 OpenAI、Anthropic、Groq 等——各自都有一個整合。這是我們用戶與他們介接的一種方式。
2. LLM 整合介面
在整合的概念之上,我們又加上了「介面」的設計。
這些只是整合可以擴充的標準結構定義。我們為大型語言模型(LLM)建立了一個標準結構。
只要整合擴展了這個架構,該整合就會被視為 LLM 供應商,因此可以直接在 Botpress 中使用。
以下是 Botpress 針對不同 LLM 供應商的整合範例:
我們也有類似的介面,支援 text2image、image2text、voice2text、text2voice 等等。
模型設定
在 Botpress Studio 內,我們有兩種通用設定:「最佳模型」和「快速模型」。我們發現大多數任務都可以歸類到這兩種模式之一。


但除了單純選擇模型外,我們發現不同供應商在工具呼叫和訊息格式上差異太大,無法輕易互換模型並期待有良好表現。
Botpress 推論引擎
因此,我們開發了自己的推論引擎 LLMz,它可以支援任何模型,幾乎不需要修改提示詞(或只需極少修改)。同時,它在工具調用上表現更佳,並且在權杖成本和 LLM 往返次數方面,通常也有更好的效能。
這個引擎在背後使用 typescript 型別來定義工具,訊息和程式碼輸出格式採用 markdown,並有 LLM 原生的執行沙盒來進行推論。
LLMz 提供許多優化和除錯功能,適合進階應用情境,例如:
- 輸入 token 壓縮
- 智慧 token 截斷
- 針對 token 最佳化的記憶體至上下文處理
- 平行與組合工具呼叫
- 單次 LLM 呼叫中混合多則訊息與工具呼叫
- 完全型別安全的工具(輸入與輸出)
- 透過沙盒序列化實現長效會話
- 工具模擬、包裝與追蹤
- 在輕量級 V8 隔離環境中完全執行隔離(可快速且低成本地同時執行數千次)
- 自動反覆執行與錯誤修復
這些功能對我們的應用來說都很必要,但用傳統工具呼叫方式要做到這些,要嘛不可能,要嘛非常困難。
不採用輕量級路由模型的理由
我們曾經考慮過要不要做一個輕量級路由模型,架在現有模型之上,自動為每個任務挑選最合適的模型。
但我們最終沒有這麼做,原因有幾個:
1. 可預測性
我們的大多數客戶——這是可以理解的——都希望獲得可靠且可預測的結果。
所以動態模型路由的想法,對高階代理來說有點令人擔憂。它會讓 LLM 多一層不可預測性。
2. 速度
延遲對我們的應用場景非常重要。為了讓路由器運作快速,模型必須非常小(而且可能比它要路由到的模型更簡單),通常會是傳統的分類器。
這類模型在針對特定任務訓練時通常表現還可以,但 a) 它們的上下文長度太短,對長提示詞有問題,b) 無法泛化到訓練範圍以外的提示。
3. 模型優勢或模型平等
雖然基準測試可能顯示不同,但實際上我們很少看到有模型能超越 GPT-4o(目前為止)。
目前還不確定 LLM 未來是否會在某些任務上表現更好,還是所有 LLM 最終都能把大多數事情做得很好。如果是後者,選模型就不值得花力氣了。
用回饋讓 LLM 更具未來適應性
幾年後,LLM 會變成一種標準商品,模型選擇將不再是重點。
基於這些原因,我們決定專注於提供一套良好的機制,讓 LLM 能夠有效利用範例。
我們建立了一套回饋收集系統。它會儲存「學習內容」給未來的執行使用,並在提示時動態提供最相關的學習內容,確保隨著時間推移,結果能持續穩定進步。
隨著各家 LLM 持續提升效能,我們已經準備好,也很期待能為平台用戶充分發揮這些優勢。





.webp)
