Un logiciel ordinaire casse bruyamment. Un modèle de langue fait plus étrange : il produit une réponse assurée et bien formée, qu'il en ait une ou non. Voici où cela mord, et ce qui l'attrape.
Quand un logiciel ordinaire ne sait pas faire quelque chose, il le dit. Une formule de tableur pointée sur du texte renvoie une erreur. Un script qui ne peut pas ouvrir un fichier s'arrête avec un message. La panne est bruyante, immédiate, impossible à confondre avec une réussite.
Un modèle de langue ne se comporte pas ainsi, et comprendre pourquoi constitue l'essentiel de ce qu'il faut savoir pour s'en servir sans danger au travail.
Un modèle génératif produit la suite qui correspond le mieux au motif de ce que vous lui avez donné. C'est toute l'opération. Il ne consulte rien, et il n'existe aucune étape séparée ou il vérifierait qu'une réponse existe avant d'en produire une.
Donc, quand vous lui demandez quelque chose auquel il ne peut pas répondre, il ne s'arrête pas. Il produit ce qui a la forme d'une réponse, puisque produire une sortie bien formée est exactement ce qu'il a appris. Fluidité et exactitude sont deux propriétés distinctes, et seule la première est garantie.
C'est pourquoi le mot hallucination trompe. Il suggère un rate dans une mémoire par ailleurs fiable, une défaillance occasionnelle. Il n'y a pas de mémoire à défaillir. Le système fonctionne normalement dans les deux cas, et il ne peut pas vous dire dans lequel vous êtes, puisque de l'intérieur c'est la même opération.
La référence plausible. Une citation, une norme, un nom de document, un numéro d'article. Ces objets ont une forme très régulière, ce qui les rend faciles à produire et difficiles à repérer comme inventés. Ils passent l'inspection visuelle précisément parce qu'ils ont l'air corrects.
Le raisonnement cohérent qui tombe à côté. Chaque étape découle de la précédente, l'argument se tient, et la conclusion est fausse parce qu'une prémisse initiale était inventée. La cohérence ne prouve rien ici, et elle est très convaincante pour qui lit en diagonale.
Le presque juste sur votre propre matière. Vous collez un document et demandez un résumé. Le résumé est exact sur les passages dont vous vous souvenez, donc vous lui faites confiance, et il manque discrètement la seule clause que vous n'aviez pas lue attentivement. La confiance construite sur les parties vérifiables se transfère aux parties non vérifiées, ce qui est exactement l'inverse de ce qu'il faudrait.
L'entrée de forme imprévue. Une étape qui fonctionne sur des entrées bien formées en reçoit une qui ne l'est pas. Au lieu d'échouer, elle produit quelque chose de plausible à partir de ce qu'elle en tire, et le transmet. Rien dans la chaîne ne signale un problème.
La sensibilité à la formulation. Poser la même question de deux façons peut donner deux réponses différentes sur le fond. Aucune n'est signalée comme moins sûre. Si vous n'avez demandé qu'une fois, vous ignorez laquelle vous avez obtenue.
Le réflexe est d'écrire de meilleurs prompts. La formulation aide sur la forme de la sortie, et elle ne crée pas un savoir qui n'était pas là. Ces pannes précises demandent des contrôles, pas des tournures.
Vérifiez contre quelque chose d'extérieur au modèle. Pour tout élément factuel, la référence, le chiffre, la clause, le contrôle doit venir d'une source qui n'est pas ce que l'on contrôle. Demander au modèle s'il est sûr n'est pas un contrôle : il produira une réponse assurée sur sa propre confiance exactement comme il a produit la première.
Vérifiez les parties dont vous ne vous souvenez pas, pas celles dont vous vous souvenez. Cela inverse l'instinct naturel. On survole ce qui est familier et on fait confiance pour le reste. Faites l'inverse : c'est dans la matière inconnue qu'une erreur peut survivre.
Demandez deux fois, autrement. Pour tout ce qui porte à conséquence, posez la question sous deux formulations différentes. Deux réponses qui divergent vous disent que le terrain est meuble. Cela coûte une minute et c'est le contrôle de fiabilité le moins cher qui existe.
Contraignez la forme et validez-la. Quand une sortie alimente une autre étape, exigez une structure fixe et vérifiez-la avant de continuer. De la prose libre arrivant dans un champ prévu pour une valeur est une panne détectable automatiquement, ce qui vaut mieux qu'une panne détectée dans un mois.
Autorisez l'étape à dire non. Une tâche obligée de toujours produire une réponse en produira une. Quand c'est possible, faites de pas de réponse une sortie acceptable, et renvoyez-la vers un humain. Ce seul changement transforme une classe d'erreurs silencieuses en une petite file d'attente visible.
Après avoir utilise un de ces outils sur du travail réel pendant un moment, la plupart des gens développent un flair pour l'endroit où il dérape sur leur matière. Cette intuition à une vraie valeur et mérite d'être construite volontairement : gardez les sorties écartées et regardez-les comme un ensemble. Le motif de vos rebuts dessine la carte des défaillances de cet outil sur votre travail.
Mais cette intuition à une limite qu'il faut nommer. Elle est bâtie sur les erreurs que vous avez attrapées. Celles que vous n'avez pas attrapées en sont, par construction, absentes, et ce sont les plus importantes. C'est pourquoi les contrôles restent en place même quand on est devenu bon à repérer les problèmes, et pourquoi les tâches qui valent la peine d'être automatisées restent celles où se tromper coûte peu et se voit.
La plupart des conseils partent d'un outil et cherchent un usage. Partez plutôt de la tâche, et faites-la passer par trois questions. Deux portent sur la vérification, et ce n'est pas un hasard.
Lire l'articleUn e-mail quand un article paraît. Pas d'outil de la semaine, pas de liste d'affiliation, aucune transmission de votre adresse à qui que ce soit.
