Le chatbot d’assistance de ShopEasy peut répondre à la question « Où est ma commande ? » en appelant une fonction backend telle que lookup_order, puis en transformant le résultat en une phrase utile que l’utilisateur peut lire.
Une façon simple de définir un modèle de langage étendu (LLM) dans le cadre de ce cours est de dire qu’il prend le texte que nous lui envoyons et prédit le texte suivant à renvoyer ; c’est un peu comme une fonction de saisie semi-automatique très puissante capable de générer des paragraphes entiers.
Même pour cette simple question concernant une commande, ShopEasy utilise déjà plusieurs types d’entrées distinctes. L’instruction système (system prompt) est une consigne interne que ShopEasy envoie avec chaque requête ; par exemple : « Vous êtes le service d’assistance de ShopEasy. Soyez concis. Demandez le numéro de commande s’il est manquant. » L’historique de la conversation est le relevé des échanges précédents que ShopEasy inclut pour garantir la cohérence du modèle. L’entrée utilisateur correspond au nouveau message, comme « Où est ma commande ? ». Les outils sont des fonctions côté serveur que ShopEasy peut exécuter (comme lookup_order et request_refund) lorsque le chatbot a besoin de données ou doit effectuer une action.
Une fois ces éléments réunis, le traitement d’une requête suit un cycle répétable. Un message utilisateur parvient à l’API de ShopEasy, et l’application élabore une instruction (prompt) pour le modèle en concaténant l’instruction système, l’historique de la conversation et la nouvelle entrée utilisateur. L’application envoie cette instruction à un fournisseur de LLM, qui renvoie une réponse du modèle : soit un texte direct, soit une proposition d’appel d’outil accompagnée d’arguments.
Lorsque le modèle propose un appel d’outil, le code de l’application ShopEasy décide s’il convient de l’exécuter, puis lance une fonction concrète telle que lookup_order (pour récupérer le statut de livraison) ou request_refund (pour initier un remboursement). ShopEasy renvoie ensuite le résultat de l’outil au modèle sous forme de nouveau message afin que celui-ci puisse rédiger la réponse finale destinée à l’utilisateur ; seule cette réponse finale est transmise à l’utilisateur. Un détail est important pour la sécurité et le débogage ultérieur : le modèle ne dispose pas de mémoire intégrée entre les appels. ShopEasy doit donc renvoyer l’historique de la conversation à chaque fois, faute de quoi le modèle réagirait comme s’il n’avait jamais vu l’utilisateur auparavant. Illustrons ce cycle par un schéma du parcours de la requête.
Ce schéma met en évidence la frontière de confiance. Les entrées de l’utilisateur ne sont pas considérées comme sûres, car n’importe quel appelant peut saisir un texte arbitraire ; de même, les résultats des outils ne sont pas fiables, car un outil peut renvoyer un contenu inattendu qui sera ensuite réinjecté dans le modèle.
Une conséquence importante de cette boucle en matière de sécurité est que le modèle ne lit pas la base de données, n’effectue pas de remboursements et n’applique pas de règles métier. Le modèle se contente de générer du texte suggérant la marche à suivre, tandis que le code applicatif de ShopEasy est le composant qui exécute réellement les actions et renvoie des données via les outils.
Cette distinction ne reste claire que si l’on maintient la séparation entre trois identités. L’utilisateur final est le client qui se renseigne sur une commande ; ses permissions doivent limiter les commandes qu’il peut consulter et les actions qu’il peut demander. Le service ShopEasy correspond à notre backend lui-même, qui dispose de capacités plus étendues, telles que l’accès à la base de données et la possibilité d’exécuter la fonction request_refund. Les identifiants du fournisseur de LLM (clé API ou jeton de service) sont utilisés par ShopEasy pour appeler le point de terminaison du modèle ; ces identifiants autorisent uniquement l’utilisation du modèle, et non les actions des clients. Confondre ces identités peut entraîner des défaillances où le backend dépense de l’argent, divulgue des données ou exécute des actions pour le compte d’un utilisateur qui n’aurait pas dû pouvoir les déclencher. En cas de problème, quel élément est réellement en mesure d’appliquer les règles : le texte du prompt, le LLM ou le code applicatif de ShopEasy ?