我最近收到一位優秀學者的來信，詢問 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)
