Onlangs ontving ik een e-mail van een getalenteerde onderzoeker die vroeg hoe Botpress samenwerkt met LLM's.
Hij was bezig met een artikel over het vermijden van vendor lock-in en wilde weten of wij misschien een framework zoals LangChain of Haystack gebruikten.
Ik vertelde hem graag dat we onze eigen abstracties hebben ontwikkeld waarmee Botpress-bouwers kunnen koppelen met LLM's.
Omdat er veel interesse is in dit onderwerp, wil ik deze informatie graag openbaar maken. Het kan nuttig zijn voor andere ontwikkelaars of gebruikers van ons platform. Hopelijk vind je het net zo interessant als ik het vond om het te bouwen.
Twee manieren waarop Botpress met LLM's werkt
Botpress heeft eigen abstracties ontwikkeld die op twee manieren werken:
1. Integraties
Integraties werken met acties die specifieke input- en outputtypen hebben.
We hebben open-source componenten op het platform, zodat de community eigen integraties kan maken die privé of openbaar beschikbaar kunnen zijn.
Dus LLM-aanbieders – OpenAI, Anthropic, Groq, enzovoort – hebben elk een eigen integratie. Dat is één manier waarop onze gebruikers ermee kunnen werken.
2. LLM-integratie-interfaces
Bovenop het concept van integraties hebben we “interfaces” toegevoegd.
Dit zijn gewoon standaard schema-definities die integraties kunnen uitbreiden. We hebben een standaardschema voor LLM's gemaakt.
Zolang een integratie dit schema uitbreidt, wordt de integratie gezien als een LLM-provider. Het werkt dus direct in Botpress.
Hier zijn enkele voorbeelden van Botpress-integraties voor verschillende LLM-aanbieders:
We hebben vergelijkbare interfaces voor text2image, image2text, voice2text, text2voice, enzovoort.
Modelconfiguraties
Binnen Botpress Studio hebben we twee algemene configuraties: het "Beste model" en het "Snelle model". We merkten dat de meeste taken goed binnen een van deze twee modi passen.
Maar naast alleen modelselectie merkten we dat de verschillende aanbieders te veel verschilden in tool-calling en berichtformaten om eenvoudig van model te wisselen en toch goede prestaties te verwachten.
De Botpress inference engine
Daarom hebben we onze eigen inference engine ontwikkeld, LLMz, die met elk model werkt zonder (of met minimale) aanpassing van prompts. Het biedt bovendien veel betere tool-integratie en vaak betere prestaties qua tokenkosten en LLM-verzoeken.
Deze engine werkt achter de schermen met typescript-typen voor tool-definities, markdown voor het bericht- en code-uitvoerformaat, en een LLM-native uitvoeringssandbox voor inference.
LLMz biedt veel optimalisaties en debugmogelijkheden die nodig zijn voor geavanceerde toepassingen, zoals:
- Invoertoken-compressie
- Slimme token-afkapping
- Token-geoptimaliseerd geheugen-naar-context
- Parallelle & samengestelde tool-calling
- Combinatie van meerdere berichten + tool-calls in één LLM-aanroep
- Volledig type-veilige tools (input & output)
- Langdurige sessies via sandbox-serialisatie
- Tool-mocking, wrapping en tracing
- Volledige uitvoeringsisolatie in lichtgewicht V8-isolaten (maakt het mogelijk om duizenden gelijktijdige uitvoeringen snel en zeer goedkoop uit te voeren)
- Automatische iteraties en foutafhandeling
Al deze zaken waren nodig voor onze toepassingen. Maar ze waren onmogelijk of erg lastig met standaard tool-calling.
Waarom we geen lichte routermodellen gebruiken
We hebben lang overwogen om een lichtgewicht routermodel te bouwen dat bovenop bestaande modellen zit en automatisch het juiste model kiest voor de taak.
Maar we hebben besloten dit niet te doen, om meerdere redenen:
1. Voorspelbaarheid
De meeste van onze klanten willen – begrijpelijk – betrouwbare en voorspelbare resultaten.
Het idee van een dynamische modelrouter is dus wat spannend voor high-level agents. Het voegt een extra laag onvoorspelbaarheid toe aan LLM's.
2. Snelheid
Latency is erg belangrijk voor onze toepassingen. Om de router snel te laten zijn, moet het model heel klein zijn (en waarschijnlijk minder slim) dan de modellen waarnaar gerouteerd wordt – waarschijnlijk een traditionele classifier.
Hoewel deze doorgaans goed presteren wanneer ze getraind zijn op specifieke taken, zijn a) hun korte contextlengtes een probleem bij lange prompts en b) generaliseren ze niet goed naar andere prompts buiten waarop ze getraind zijn.
3. Modeldominantie of modelgelijkheid
Hoewel benchmarks soms anders aangeven, zien we in de praktijk zelden modellen die beter presteren dan GPT-4o (tot nu toe).
Het is nog onduidelijk of LLM's op termijn echt beter zullen presteren op taak X dan op taak Y, of dat alle LLM's uiteindelijk overal goed in worden. In dat laatste geval is modelkeuze de moeite niet waard.
LLM's toekomstbestendig maken met feedback
LLM's zullen over een paar jaar een standaardproduct zijn en modelkeuze zal dan nauwelijks nog een rol spelen.
Om die redenen hebben we ervoor gekozen om te investeren in een goed mechanisme om LLM's van voorbeelden te voorzien.
We hebben dus een systeem gebouwd om feedback vast te leggen. Het slaat "learnings" op voor toekomstige uitvoeringen. En het levert bij elke prompt automatisch de meest relevante learnings aan, zodat de prestaties betrouwbaar en continu kunnen verbeteren.
Naarmate LLM's steeds beter worden, zijn wij klaar en enthousiast om er het maximale uit te halen voor onze gebruikers.
.webp)
