Je fais tourner un jumeau numérique sur mon site web. Il répond à des questions sur ma vie et mes compétences. Je lui ai donné une règle stricte : ne jamais inventer de choses. Si quelqu'un pose une question sur une compétence que je n'ai pas, il doit admettre qu'il ne sait pas. Pendant des mois, j'ai cru que le système fonctionnait. Je l'ai testé manuellement ici et là, et les réponses semblaient solides. Puis, j'ai construit un véritable système d'évaluation. Les chiffres ont été brutaux. Sur 35 questions, neuf contenaient des mensonges flagrants. Sur huit questions conçues pour être sans réponse, le modèle n'en a refusé que quatre. Mon prompt anti-hallucination a échoué environ un quart du temps. J'étais en train de commercialiser un produit qui mentait à ses utilisateurs.
Une configuration de récupération ultra-simple
Je n'ai pas déployé Pinecone ou une base de données vectorielle lourde. Toute la configuration repose sur un simple fichier JSON. Mon code divise mon profil en sections distinctes. Lorsqu'une question arrive, le système calcule la similitude cosinus entre la requête et chaque fragment de texte, sélectionne les correspondances les plus proches et les injecte dans le prompt comme contexte. Le modèle génère ensuite une réponse en se basant strictement sur ce qu'il voit dans cette fenêtre.
Pour un petit site personnel servant un ensemble restreint de faits, cette approche est rapide et ne coûte presque rien. Il n'y a pas d'aller-retour réseau vers un magasin vectoriel distant, pas de surcharge d'indexation, et pas d'orchestration complexe. Vous lisez le fichier, évaluez les fragments, construisez le prompt, et c'est tout. Mais la simplicité du backend ne garantit pas l'honnêteté du résultat. Un pipeline léger peut tout de même produire de graves problèmes lorsque le modèle décide d'improviser. L'écart entre « voici le contexte » et « voici ce que je vais en dire » est l'endroit même où les hallucinations se logent. Vous pouvez donner au modèle un paragraphe sur votre parcours professionnel et recevoir en retour une invention assurée concernant un langage de programmation que vous n'avez jamais touché.
Les chiffres qui ont brisé ma confiance
Pendant des mois, j'ai considéré que les vérifications manuelles ponctuelles étaient suffisantes. J'ouvrais le chat, posais une question dont je connaissais déjà la réponse, et acquiesçais quand la réponse semblait correcte. C'était ma stratégie de test. Cela semblait approfondi parce que j'utilisais moi-même l'interface. Ce n'était pas le cas.
Quand j'ai enfin écrit un système d'évaluation capable de fonctionner de manière systématique, le tableau a changé. La suite de tests a soumis 35 questions au jumeau. Neuf réponses contenaient des mensonges. J'ai également inclus huit questions qui n'avaient aucune réponse dans mon profil. Le modèle aurait dû toutes les décliner. Il n'en a refusé que quatre. Mon prompt anti-hallucination soigneusement élaboré, celui qui incluait un langage absolu sur le fait de ne jamais inventer de choses, a échoué environ 25 % du temps. Une fois sur quatre. Ce n'est pas une erreur d'arrondi. C'est un produit défaillant.
Arrêtez de tester avec des questions amicales
On ne trouve pas de bugs en utilisant simplement son propre produit. On les trouve en essayant de le casser. Mes tests manuels étaient trop complaisants. Je ne posais que des questions dont je connaissais la réponse exacte, ce qui signifie que je guidais inconsciemment le modèle vers un terrain sûr. Je n'ai jamais sondé les limites. Je n'ai jamais posé de questions sur des compétences que j'aurais aimé avoir, ou sur des expériences qui ne se sont jamais produites.
Un véritable test nécessite une intention adverse. Vous devez concevoir des questions destinées à faire échouer l'IA. Vous voulez qu'elle trébuche en laboratoire pour qu'elle ne trébuche pas devant un visiteur. Une suite de tests qui ne fait que confirmer ce que vous croyez déjà n'est qu'une démo déguisée. Si vous ne fabriquez pas activement des cas limites et des questions pièges, vous ne testez pas. Vous espérez.
Les deux erreurs qui comptaient
Le prompting n'est pas une garantie. Une instruction longue et détaillée disant à une IA de ne pas halluciner n'est qu'une suggestion déguisée en commande. Le modèle peut la suivre la plupart du temps, mais il ignorera l'instruction dès que la pression statistique le poussera ailleurs. La température, la probabilité des tokens et la forme des données d'entraînement pèsent plus lourd qu'une phrase dans votre prompt système. Vous devez mesurer l'obéissance avec des données, pas avec de l'espoir. Une instruction forte n'est pas un fait vérifié. C'est une requête, et les requêtes peuvent être refusées. Si toute votre stratégie de sécurité repose sur la fermeté de la formulation de votre prompt, vous avez construit un garde-fou en papier de soie. Vous avez besoin d'un système d'évaluation qui compte combien de fois le modèle obéit, dans quelles conditions, et pourquoi il échoue lorsqu'il échoue. Les chiffres se moquent de votre ton.
La boucle d'évaluation était défaillante. Voici un piège subtil dans lequel j'ai failli tomber. Mon outil de test initial exécutait le processus de récupération deux fois. La première exécution récupérait le contexte pour le comparer à la vérité terrain. La seconde exécution récupérait le contexte pour la génération réelle de la réponse. En pratique, cela signifiait que les segments vus par le juge pouvaient différer de ceux vus par le modèle. Le juge évaluait la réponse par rapport à des données que l'IA n'avait peut-être jamais reçues. Une évaluation qui note la mauvaise entrée est pire qu'une absence d'évaluation. Elle procure un faux sentiment de sécurité. Vous regardez le score, voyez un taux de réussite élevé, et vous vous détendez. Pendant ce temps, vos utilisateurs sont