Comment Botpress interagit avec les LLM

J'ai récemment reçu un email d'un chercheur talentueux me demandant comment Botpress s'interface avec les LLM.

Il rédigeait un article sur la façon d'éviter le verrouillage propriétaire et voulait savoir si nous utilisions un framework comme LangChain ou Haystack.

J'ai été ravi de lui expliquer que nous avons créé nos propres abstractions permettant aux utilisateurs de Botpress de s'interfacer avec les LLM.

Comme le sujet intéresse beaucoup de monde, j’ai voulu partager ces informations publiquement. Cela pourra être utile à d’autres développeurs ou utilisateurs de notre plateforme. J’espère que vous trouverez cela aussi intéressant que moi en le concevant.

Deux façons dont Botpress interagit avec les LLM

Botpress a mis en place ses propres abstractions qui fonctionnent de deux manières :

1. Intégrations

Les intégrations reposent sur le concept d’actions avec des types d’entrée et de sortie spécifiques.

Nous proposons des composants open source sur la plateforme, ce qui permet à la communauté de créer ses propres intégrations, privées ou publiques.

Ainsi, chaque fournisseur de LLM – OpenAI, Anthropic, Groq, etc. – dispose de son intégration. C’est une première façon pour nos utilisateurs d’interagir avec eux.

2. Interfaces d’intégration LLM

En plus du concept d’intégrations, nous avons ajouté les « interfaces ».

Il s'agit simplement de définitions de schémas standards que les intégrations peuvent étendre. Nous avons créé un schéma standard pour les LLMs.

Tant qu'une intégration étend ce schéma, elle est considérée comme un fournisseur de LLM. Elle fonctionne donc immédiatement dans Botpress.

Voici quelques exemples d’intégrations Botpress pour différents fournisseurs de LLM :

• Anthropic
• OpenAI
• Groq
  

Nous avons des interfaces similaires pour text2image, image2text, voice2text, text2voice, etc.

Configurations des modèles

Dans Botpress Studio, nous proposons deux configurations générales : le « Meilleur modèle » et le « Modèle rapide ». Nous avons constaté que la plupart des tâches correspondent facilement à l’un de ces deux modes.

‍

Mais au-delà du simple choix du modèle, nous avons constaté que les différents fournisseurs divergeaient trop sur l’appel d’outils et les formats de messages pour pouvoir remplacer facilement un modèle par un autre tout en conservant de bonnes performances.

Le moteur d’inférence Botpress

C'est pourquoi nous avons développé notre propre moteur d'inférence appelé LLMz, qui fonctionne avec n'importe quel modèle sans (ou avec très peu de) modification de prompt. Il offre également une bien meilleure gestion des appels d'outils et souvent de meilleures performances en termes de coût en tokens et de nombre d'échanges avec le LLM.

Ce moteur utilise des types typescript en arrière-plan pour la définition des outils, du markdown pour le format des messages et du code, et un bac à sable natif LLM pour l’inférence.

LLMz propose de nombreuses optimisations et fonctionnalités de débogage nécessaires pour des cas d’usage avancés comme :

• Compression des tokens d’entrée
• Tronquage intelligent des tokens
• Mémoire optimisée pour le contexte selon les tokens
• Appel d’outils en parallèle et composite
• Combinaison de plusieurs messages et appels d’outils en une seule requête LLM
• Outils totalement typés (entrée et sortie)
• Sessions longues grâce à la sérialisation du bac à sable
• Simulation, encapsulation et traçage des outils
• Isolation complète de l’exécution dans des isolats V8 légers (permet d’exécuter des milliers de traitements concurrents rapidement et à moindre coût)
• Itérations automatiques et reprise sur erreur
  

Toutes ces fonctionnalités étaient nécessaires pour nos cas d’usage. Mais elles étaient impossibles ou très difficiles à réaliser avec l’appel d’outils classique.

Pourquoi nous n’utilisons pas de modèles routeurs légers

Nous avons longtemps envisagé de créer un modèle routeur léger qui se placerait au-dessus des modèles existants et choisirait automatiquement le modèle adapté à chaque tâche.

Mais nous avons décidé de ne pas le faire pour plusieurs raisons :

1. Prédictibilité

La plupart de nos clients souhaitent – à juste titre – des résultats fiables et prévisibles.

L’idée d’un routeur de modèles dynamique est donc un peu inquiétante pour des agents de haut niveau. Cela ajoute une couche d’imprévisibilité aux LLM.

2. Rapidité

La latence est très importante pour nos cas d'usage. Pour que le routeur soit rapide, le modèle doit être très petit (et sans doute moins performant) que les modèles vers lesquels il va router – probablement un classificateur traditionnel.

Même si ces modèles fonctionnent généralement bien sur des tâches spécifiques, a) leur contexte court pose problème pour les prompts longs et b) ils ne généralisent pas bien sur des prompts différents de ceux sur lesquels ils ont été entraînés.

3. Suprématie ou égalité des modèles

Même si les benchmarks disent parfois le contraire, dans la pratique, nous avons rarement vu des modèles surpasser GPT-4o (jusqu’à présent).

On ne sait pas encore si les LLM seront vraiment meilleurs sur une tâche X que sur une tâche Y à long terme, ou si tous finiront par être très performants sur la plupart des sujets. Dans ce cas, le choix du modèle n’aura plus vraiment d’intérêt.

Préparer l’avenir des LLM grâce aux retours

Les LLM deviendront une commodité dans quelques années et le choix du modèle ne sera plus vraiment un enjeu.

Pour ces raisons, nous avons choisi de concentrer nos efforts sur la mise à disposition d'un bon mécanisme pour fournir des exemples aux LLM.

Nous avons donc mis en place un système de collecte de retours. Il stocke les « apprentissages » pour les exécutions futures et fournit dynamiquement les plus pertinents au moment du prompt, afin de garantir des améliorations fiables et continues dans le temps.

À mesure que les LLM atteignent des niveaux de performance toujours plus élevés, nous sommes prêts et enthousiastes à l’idée d’en tirer le meilleur pour les utilisateurs de notre plateforme.