Onlangs ontving ik een e-mail van een getalenteerde wetenschapper die vroeg hoe Botpress aansluit op LLMs.
Hij schreef een artikel over het vermijden van vendor lock-in en wilde weten of we misschien een framework zoals LangChain of Haystack gebruikten.
Ik was meer dan verheugd om met hem te kunnen delen dat we onze eigen abstracties hebben gemaakt waarmee Botpress bouwers kunnen interfacen met LLMs.
Gezien de bredere interesse in het onderwerp, wilde ik deze informatie openbaar maken. Het kan nuttig zijn voor andere ontwikkelaars of gebruikers van ons platform. Ik hoop dat je het net zo interessant vindt als ik het vond om het te maken.
Twee manieren waarop Botpress communiceert met LLMs
Botpress heeft zijn eigen abstracties gemaakt die op twee manieren werken:
1. Integraties
Integraties hebben het concept van acties die specifieke invoer- en uitvoertypes hebben.
We hebben open source componenten op het platform, zodat de community zijn eigen integraties kan maken die zowel privé als openbaar kunnen worden gebruikt.
Dus LLM aanbieders - OpenAI, Anthropic, Groq, enz. - hebben allemaal een integratie. Dat is één manier waarop onze gebruikers met hen kunnen communiceren.
2. LLM integratie-interfaces
Bovenop het concept van integraties hebben we "interfaces" toegevoegd.
Dit zijn gewoon standaardschemadefinities die integraties kunnen uitbreiden. We hebben een standaardschema gemaakt voor LLMs.
Zolang een integratie dit schema uitbreidt, wordt de integratie beschouwd als een LLM provider. Het werkt dus out-of-the-box in Botpress.
Hier zijn enkele voorbeelden van de Botpress integraties voor verschillende LLM providers:
We hebben vergelijkbare interfaces voor text2image, image2text, voice2text, text2voice, enz.
Modelconfiguraties
In Botpress Studio hebben we twee algemene configuraties: het "Beste model" en het "Snelle model". We hebben gemerkt dat over het algemeen de meeste taken gemakkelijk in een van deze twee modi passen.
Maar naast pure modelselectie vonden we dat de verschillende aanbieders te veel verschilden op het gebied van tool calling en berichtformaten om gemakkelijk het ene model te kunnen verwisselen met het andere en goede prestaties te verwachten.
De inferentiemotor Botpress
Daarom hebben we onze eigen inferentie-engine gemaakt, LLMz genaamd, die met elk model werkt zonder dat er iets aan de prompt hoeft te worden veranderd. En het biedt veel betere tool calling en vaak veel betere prestaties in termen van tokenkosten en LLM roundtrips.
Deze engine werkt met typescript achter de schermen voor de gereedschapsdefinities, markdown voor het bericht- en code-uitvoerformaat en een LLM-native execution sandbox voor inferentie.
LLMz biedt veel optimalisaties en debugfuncties die nodig zijn voor geavanceerd gebruik, zoals:
- Invoer tokens compressie
- Slimme tokenafbreking
- Token-geoptimaliseerd geheugen-naar-tekst
- Parallel en samengesteld gereedschap aanroepen
- Mix van meerdere berichten + tooloproepen in een enkele LLM oproep
- Volledig typeveilige gereedschappen (invoer en uitvoer)
- Langlevende sessies door sandbox serialisatie
- Gereedschap spiegelen, omwikkelen en traceren
- Volledige uitvoeringsisolatie in lichtgewicht V8-isolaten (maakt het mogelijk om duizenden gelijktijdige uitvoeringen snel en zeer goedkoop uit te voeren)
- Automatische iteraties en foutherstel
Al deze dingen waren nodig voor onze use-cases. Maar ze waren ofwel onmogelijk ofwel zeer moeilijk uit te voeren met gewone gereedschappen.
De argumenten tegen lichtgewicht routermodellen
We hebben lang nagedacht over het bouwen van een lichtgewicht router model dat bovenop bestaande modellen zou zitten en automatisch het juiste model voor de taak zou kiezen.
Maar we hebben om meerdere redenen besloten dat niet te doen:
1. Voorspelbaarheid
Het is begrijpelijk dat de meeste van onze klanten betrouwbare en voorspelbare resultaten willen.
Het idee van een dynamische modelrouter is dus een beetje eng voor agents op hoog niveau. Het brengt nog een laag onvoorspelbaarheid naar LLMs.
2. Snelheid
Latency is erg belangrijk voor onze use-cases. Om de router snel te laten zijn, moet het model erg klein zijn (en aantoonbaar dommer) dan de modellen waarnaar het zal routeren - waarschijnlijk een traditionele classifier.
Hoewel deze over het algemeen goed presteren wanneer ze getraind zijn op specifieke taken, a) zijn hun korte contextgroottes een probleem voor lange prompts en b) generaliseren ze niet naar andere prompts buiten datgene waarop ze getraind zijn.
3. Model suprematie of model gelijkheid
Hoewel benchmarks anders beweren, hebben we in het wild zelden modellen gezien die beter presteren dan GPT-4o (tot nu toe).
Het is nog onduidelijk of LLMs na verloop van tijd echt beter zal presteren op taak X dan op taak Y, of dat alle LLMs uiteindelijk extreem goed zullen zijn in de meeste dingen. In het laatste geval is het uitzoeken van modellen niet de moeite waard.
Toekomstbestendigheid LLMs met feedback
LLMs zal over een paar jaar een commodity zijn en modelselectie zal niet echt een ding zijn.
Om die redenen hebben we besloten om te investeren in een goed mechanisme om LLMs van voorbeelden te voorzien.
Dus hebben we een systeem gebouwd om feedback vast te leggen. Het slaat "lessen" op voor toekomstige uitvoeringen. En het biedt dynamisch de meest relevante learnings op het juiste moment voor toekomstige uitvoeringen, om betrouwbare en voortdurende verbeteringen in de loop van de tijd te garanderen.
Naarmate LLMs steeds betere prestaties levert, zijn we er klaar voor en enthousiast om er het beste van te maken voor de gebruikers van ons platform.
.webp)
