Kürzlich erhielt ich eine E-Mail von einem talentierten Wissenschaftler, der wissen wollte, wie Botpress mit LLMs interagiert.
Er schrieb an einer Arbeit über die Vermeidung von Anbieterabhängigkeit und wollte wissen, ob wir vielleicht ein Framework wie LangChain oder Haystack verwenden.
Ich habe ihm gerne mitgeteilt, dass wir eigene Abstraktionen entwickelt haben, die es Botpress-Entwicklern ermöglichen, mit LLMs zu interagieren.
Da das Thema auf breites Interesse stößt, möchte ich diese Informationen öffentlich machen. Sie könnten für andere Entwickler oder Nutzer unserer Plattform nützlich sein. Ich hoffe, Sie finden es genauso spannend wie ich bei der Entwicklung.
Zwei Wege, wie Botpress mit LLMs interagiert
Botpress hat eigene Abstraktionen entwickelt, die auf zwei Arten funktionieren:
1. Integrationen
Integrationen haben das Konzept von Aktionen mit bestimmten Eingabe- und Ausgabetypen.
Wir haben Open-Source-Komponenten auf der Plattform, sodass die Community eigene Integrationen erstellen kann – privat oder öffentlich nutzbar.
LLM-Anbieter – OpenAI, Anthropic, Groq usw. – haben jeweils eine Integration. So können unsere Nutzer mit ihnen interagieren.
2. LLM-Integrationsschnittstellen
Zusätzlich zum Integrationskonzept haben wir „Schnittstellen“ eingeführt.
Dies sind einfach standardisierte Schemadefinitionen, die von Integrationen erweitert werden können. Wir haben ein Standardschema für LLMs erstellt.
Solange eine Integration dieses Schema erweitert, gilt sie als LLM-Anbieter. Sie funktioniert also direkt in Botpress.
Hier einige Beispiele für Botpress-Integrationen verschiedener LLM-Anbieter:
Wir haben ähnliche Schnittstellen für text2image, image2text, voice2text, text2voice usw.
Modellkonfigurationen
Im Botpress Studio gibt es zwei allgemeine Konfigurationen: das „Beste Modell“ und das „Schnellste Modell“. Wir haben festgestellt, dass die meisten Aufgaben in der Regel in eine dieser beiden Kategorien passen.
Aber neben der reinen Modellauswahl haben wir festgestellt, dass sich die Anbieter bei Tool-Aufrufen und Nachrichtenformaten zu stark unterscheiden, um einfach ein Modell gegen ein anderes auszutauschen und dabei gute Ergebnisse zu erwarten.
Die Botpress-Inferenz-Engine
Deshalb haben wir unsere eigene Inferenz-Engine namens LLMz entwickelt, die mit jedem Modell funktioniert, ohne (oder mit sehr minimalen) Änderungen am Prompt. Sie bietet zudem deutlich bessere Tool-Aufrufe und oft eine bessere Performance hinsichtlich Token-Kosten und LLM-Anfragen.
Diese Engine nutzt im Hintergrund Typescript-Typen für die Tool-Definitionen, Markdown für Nachrichten- und Codeausgaben sowie eine LLM-native Ausführungsumgebung für die Inferenz.
LLMz bietet viele Optimierungen und Debugging-Funktionen, die für fortgeschrittene Anwendungsfälle erforderlich sind, wie zum Beispiel:
- Komprimierung der Eingabetokens
- Intelligente Token-Kürzung
- Token-optimierter Speicher-zu-Kontext
- Parallele & kombinierte Tool-Aufrufe
- Kombination mehrerer Nachrichten + Tool-Aufrufe in einem einzigen LLM-Aufruf
- Vollständig typisierte Tools (Eingabe & Ausgabe)
- Langfristige Sitzungen durch Sandbox-Serialisierung
- Tool-Mocking, -Wrapping und -Tracing
- Vollständige Ausführungstrennung in leichten V8-Isolaten (ermöglicht tausende gleichzeitige Ausführungen schnell und kostengünstig)
- Automatische Iterationen und Fehlerbehebung
All dies war für unsere Anwendungsfälle notwendig. Mit herkömmlichen Tool-Aufrufen war das entweder unmöglich oder sehr schwierig umzusetzen.
Das Problem mit leichten Router-Modellen
Wir haben lange darüber nachgedacht, ein leichtgewichtiges Router-Modell zu bauen, das über bestehenden Modellen sitzt und automatisch das passende Modell für die jeweilige Aufgabe auswählt.
Wir haben uns jedoch aus mehreren Gründen dagegen entschieden:
1. Vorhersehbarkeit
Die meisten unserer Kunden wünschen sich – verständlicherweise – zuverlässige und vorhersehbare Ergebnisse.
Die Idee eines dynamischen Modell-Routers ist für anspruchsvolle Agenten etwas riskant. Sie bringt eine weitere Unwägbarkeitsebene in die LLMs.
2. Geschwindigkeit
Latenz ist für unsere Anwendungsfälle sehr wichtig. Damit der Router schnell ist, muss das Modell sehr klein (und vermutlich weniger leistungsfähig) sein als die Modelle, zu denen es weiterleitet – wahrscheinlich ein klassischer Klassifizierer.
Solche Modelle funktionieren zwar meist gut, wenn sie auf bestimmte Aufgaben trainiert sind, aber a) ihre geringe Kontextgröße ist problematisch bei langen Prompts und b) sie können schlecht auf andere Prompts außerhalb ihres Trainingsbereichs übertragen.
3. Modellüberlegenheit oder -gleichheit
Auch wenn Benchmarks etwas anderes sagen: In der Praxis haben wir bisher selten Modelle gesehen, die GPT-4o übertreffen.
Es ist noch unklar, ob LLMs auf Aufgabe X langfristig wirklich besser abschneiden als auf Aufgabe Y oder ob letztlich alle LLMs in den meisten Bereichen sehr gut werden. Falls Letzteres eintritt, lohnt sich die Modellauswahl kaum.
LLMs zukunftssicher machen durch Feedback
LLMs werden in ein paar Jahren zur Standardware und die Modellauswahl wird dann kaum noch eine Rolle spielen.
Aus diesen Gründen haben wir uns entschieden, unsere Bemühungen darauf zu konzentrieren, einen guten Mechanismus bereitzustellen, um LLMs mit Beispielen zu versorgen.
Wir haben ein System entwickelt, das Feedback sammelt. Es speichert „Learnings“ für zukünftige Ausführungen und stellt diese zum Prompt-Zeitpunkt dynamisch bereit, um über die Zeit verlässliche und kontinuierliche Verbesserungen zu ermöglichen.
Während LLMs immer leistungsfähiger werden, sind wir bereit und freuen uns darauf, das Beste für die Nutzer unserer Plattform herauszuholen.
.webp)
