Le brief IA que les pros lisent chaque soir
Les 7 actus IA du jour, décryptées en 5 min. Gratuit.
Inclus dès l'inscription : notre sélection des meilleurs guides & comparatifs IA.
Choisis ton rythme
Gratuit · Pas de spam · Désabonnement en 1 clic
L'illusion de la reformulation des prompts
Lorsqu'une fonctionnalité de modèle de langage (LLM) échoue en production, la tentation est souvent de modifier le prompt dans l'espoir de résoudre le problème. Ce réflexe est courant, mais il s'avère souvent inefficace. Dans le cadre du développement d'un assistant de production destiné aux conseillers financiers, un registre a été tenu pour chaque échec lié au LLM, ainsi que pour les solutions qui ont réellement fonctionné. Il est apparu que la plupart des problèmes ne pouvaient pas être corrigés simplement en ajustant les prompts. Les solutions efficaces étaient d'ordre architectural. En fait, la seule tentative de résoudre un problème complexe par la reformulation du prompt a empiré la situation, nécessitant un retour en arrière.
Les défis du routage
Le routage des questions posait un problème majeur, se révélant instable d'une manière que la simple modification des prompts ne pouvait pas résoudre. Lors de différentes exécutions, la même question pouvait être traitée de manières différentes, sans aucun changement de code. La précision du routage, dans les cas ambigus, variait entre 56 et 64 %, et les résultats étaient imprévisibles d'une exécution à l'autre. Par exemple, une demande de classification des ménages par actifs sous gestion (AUM) pouvait être interprétée comme une demande de clarification lors d'une exécution et recevoir une réponse confiante lors de la suivante.
L'idée initiale était d'améliorer le prompt de routage en ajoutant des instructions détaillées pour distinguer les catégories. Cependant, cette approche a rendu le classificateur encore plus instable, ce qui a conduit à la suppression de ces ajouts. Le problème était plus profond que de simples erreurs aléatoires. L'instabilité était due à une structure défaillante qui s'aggravait à chaque ajout de domaine. Le processus de routage impliquait d'abord une supposition sur une catégorie abstraite, suivie d'un mappage vers un outil concret. Cette étape intermédiaire était sujette à des erreurs, rendant l'outil approprié inaccessible lorsque la supposition était incorrecte, sans possibilité de correction.
Une solution architecturale efficace
Pour résoudre ce problème, il a été décidé de supprimer la catégorie abstraite. Le routage a été simplifié en une seule étape, choisissant directement un outil concret dans le catalogue, avec la portée déterminée par l'outil sélectionné plutôt que devinée à l'avance. Chaque décision a été restreinte pour discriminer parmi un nombre limité d'outils, plutôt que l'ensemble complet. Des énoncés d'exemple ont été ancrés sous forme de données structurées, et non de texte dans le prompt. Cette refonte a permis de passer d'une précision instable de 98 % avec l'ancien design à une régression temporaire à 72 % après la réécriture, pour finalement atteindre 100 % de précision sur les deux suites d'évaluation une fois l'ancrage en place.
L'amélioration est venue de la réduction des décisions que le modèle devait prendre. Cela a établi un modèle pour la suite : retirer du travail au modèle chaque fois que le code peut le faire, et capturer ce qui reste dans des garde-fous déterministes.
Les erreurs de modèle et les options manquantes
Un autre échec apparent était dû à une décision erronée du modèle, mais en réalité, il s'agissait d'une option manquante. Lorsqu'il était demandé de "montrer le premier compte", le modèle choisissait l'outil le plus proche disponible, une recherche de participations, car aucun outil de liste de comptes n'existait. Le modèle inventait un ordinal pour rendre la réponse conforme. La solution a été de créer l'outil nécessaire, plutôt que de modifier un prompt pour s'excuser de l'absence.
La méfiance envers les valeurs inventées
Les modèles de langage ont tendance à remplir les vides avec assurance, ce qui peut être dangereux. Par exemple, une demande de "créer une tâche pour 14h" a inséré "14h" dans un champ où le code attendait un horodatage calculé. Le parseur a échoué à interpréter "14h" comme un instant ISO, entraînant une erreur générique du serveur pour l'utilisateur. Ce problème ne se manifestait qu'avec la sortie réelle du modèle, alors que tous les tests hors ligne réussissaient avec une carte d'arguments vide, qui ne déclenchait jamais le bug.
L'importance de la validation
Le principe fondamental est de ne jamais faire confiance à une valeur générée par le modèle comme si elle était saisie ou calculée. Chaque réponse contenant des chiffres doit être soumise à un contrôle de validation déterministe. Cela implique de comparer les nombres dans la réponse avec ceux réellement retournés par l'outil. Si un chiffre est cité sans support, la réponse est retenue avec un message indiquant qu'elle n'a pas pu être vérifiée complètement.
