Le problème
Un modèle de langage ne ment pas exprès. Il prédit la suite la plus probable et, quand une information lui manque, il la remplace par quelque chose de vraisemblable. Dans une simple conversation, cela donne une erreur de détail. Dans un assistant qui agit, les conséquences sont plus concrètes : un itinéraire qui prend pour destination le nom « Alexandre Dupont » lui-même, ou une explication inventée comme « ton agenda n'est pas configuré », qui te fait chercher une panne qui n'existe pas. Dite avec assurance, une telle erreur est plus dangereuse qu'un simple « je ne sais pas », parce que tu agis dessus.
Ce que je voulais
Je voulais une règle simple : LIA ne te présente comme un fait que ce qu'elle a reçu d'un outil, lu dans la conversation ou calculé. Ce qui peut être réparé sans deviner ton intention est réparé. Le reste est refusé, avec un message qui aide le modèle à se corriger.
Avant d'agir
- Les options inventées sont retirées. Si le modèle ajoute à un outil une option qui n'existe pas, comme un tri que l'outil ne connaît pas, elle est enlevée avant l'appel, et le plan suit son cours.
- Les nombres sont ramenés dans leurs bornes. Demander cent résultats à un outil qui en accepte vingt en donne vingt. Une valeur qu'on ne peut corriger sans inventer, comme une date dans un format illisible, reste une erreur signalée.
- Un nom n'est pas une adresse. Les paramètres qui attendent une adresse ou un e-mail sont contrôlés juste avant l'appel. S'ils contiennent le nom d'une personne mentionnée dans la conversation, l'appel est bloqué avant toute dépense, avec une consigne claire : récupère d'abord l'adresse du contact. Dans le doute, le contrôle laisse passer, pour ne pas gêner une demande légitime.
- Une valeur absente reste absente. Quand une étape répète une action sur une liste et qu'un élément n'a pas le champ attendu, le paramètre est laissé vide : l'outil ne reçoit pas le mot « null » écrit en toutes lettres, et il applique son propre défaut.
- Le plan est relu pour ce qui manque. Un relecteur voit bien ce qu'un plan contient, beaucoup moins ce qu'il oublie. Celui de LIA commence donc par lister chaque chose que ta demande exige, puis vérifie qu'une étape couvre chacune, avant de rendre son avis.
Dans la réponse
Quand LIA te donne une heure, une date, un nombre, un nom ou une adresse, cette valeur doit figurer dans les données du tour, dans les éléments consultés récemment ou, mot pour mot, dans un message précédent. Sinon, elle te dit que l'information manque et propose d'aller la chercher. Les éléments qu'elle vient de lire restent à sa disposition pendant quelques tours : une question de suivi comme « et il commence à quelle heure ? » s'appuie ainsi sur la donnée elle-même.
Ce qui doit être exact est calculé. Un modèle prédit du texte, il ne fait pas d'arithmétique. Un pourcentage, le nombre de jours avant une date ou une conversion de devise passent par des outils dédiés : un calcul en décimal exact qui dit quand il a dû arrondir, une durée comptée entre deux instants réels, changement d'heure compris, et le taux de référence de la Banque centrale européenne, avec sa date.
Quand quelque chose échoue
Quand un outil échoue, LIA le dit au modèle par un seul canal, qui nomme l'outil et donne le nombre exact d'étapes en échec. Le modèle n'a donc pas à deviner ce qui s'est passé. Un plan à moitié réussi te rend ce qui a marché et dit ce qui n'a pas marché.
Deux autres règles vont dans le même sens. L'avis d'un relecteur ne suffit pas à annoncer un blocage : une capacité n'est dite bloquée que si elle n'a pas été lancée du tout. Et une demande préparée, une confirmation en attente et un changement enregistré sont trois états différents, que LIA ne confond pas dans son compte rendu.
Quand LIA enchaîne les outils elle-même, en mode ReAct, chaque information qu'elle est partie chercher finit obtenue ou déclarée manquante, avec ce qu'elle a essayé. Un outil qui ne comprend pas une valeur la refuse en expliquant le format attendu.
Les limites
- Ces protections réduisent les inventions sans les supprimer. Un modèle peut encore mal reformuler une donnée qu'il a bien reçue.
- Le contrôle des noms ne connaît que les personnes identifiées pendant le tour. Les actions importantes passent de toute façon par ta confirmation.
- Si ton administrateur les active, des étiquettes sur tes e-mails (catégorie, urgence, soupçon d'arnaque) restent des indications : l'absence d'alerte ne prouve pas qu'un message est sûr.
Pour approfondir : Garder la main sans être dérangé : comment LIA te demande ton accord ; Les consignes de LIA, écrites et relues comme du code.