« Do not guess » : une seule phrase réduit les champs hallucinés de 71 % à 20 % sur 16 modèles frontier
🔎 Une phrase de six mots contre des milliers de données fausses
Si vous construisez des pipelines d'extraction de données avec des LLM, vous avez probablement déjà vécu ce moment : l'agent vous retourne un tableau impeccable, complet, chaque champ rempli… et la moitié des valeurs n'existent nulle part sur la page source. Le modèle a « complété » les trous par pur réflexe statistique.
C'est exactement le problème qu'attaque le benchmark « Do not guess » publié par Earn an Honest Dollar, avec une analyse complémentaire de RuntimeWire le 27 septembre 2026. Le constat est d'une simplicité déconcertante : ajouter une seule phrase au prompt — « Use null for any field whose value is not on the page. Do not guess. » — fait chuter les champs inventés de 70,7 % à 20,2 % en moyenne.
Encore plus frappant : les 16 modèles frontier testés, sans exception, hallucinent davantage sans cette phrase. De GPT-5.5 à Gemini 3.1 Pro en passant par Claude Opus 4.7, aucun n'échappe au réflexe de fabrication. Le défaut n'est donc pas celui d'un modèle particulier — c'est structurel, et il se corrige en une ligne.
Mais restons honnêtes : 20 % de champs encore inventés, c'est énorme pour une pipeline en production. Et comme le montre le protocole du benchmark, les pièges les plus efficaces ne sont pas des pages vides, mais des pages truffées d'appâts plausibles. C'est toute l'histoire de ce benchmark.
L'essentiel
- Une phrase suffit : ajouter « Use null for any field whose value is not on the page. Do not guess. » réduit les champs hallucinés de 405 sur 573 (70,7 %) à 116 sur 574 (20,2 %) en moyenne sur 16 modèles frontier.
- Tous les modèles hallucinent sans la phrase : aucun des 16 testés ne fait exception, ce qui suggère un biais d'entraînement structurel plutôt qu'un défaut ponctuel.
- Les pièges sont redoutablement efficaces : un ancien prix « Was $493.00 » est repris comme prix actuel par les 16 modèles sans l'instruction ; un seul résiste avec.
- La phrase magique a un coût : l'étude arXiv 2601.02023 montre qu'elle peut réduire le rappel sur certaines tâches — un « safety tax » mesurable, surtout en fin de contexte.
- La validation aval reste indispensable : les vérificateurs aval attrapent 23 à 38 valeurs inventées sur 49, mais ratent systématiquement les erreurs « near-miss ».
- Un fetch simple + GPT-6 Luna coûte 0,0049 $ le run et hallucine 5 champs sur 36, contre 24 pour un service d'extraction commercial sans l'instruction.
Outils recommandés
Pour mettre en pratique ces enseignements sur vos propres pipelines :
| Outil | Usage principal | Prix (septembre 2026) | Idéal pour |
|---|---|---|---|
| OpenRouter | Accès multi-modèles pour tester vos prompts sur plusieurs LLM | Facturation à l'usage, modèles gratuits disponibles | Comparer le comportement « do not guess » entre modèles |
| Hermes Agent | Configurer plusieurs providers et modèles dans un même agent | Open source | Industrialiser des pipelines d'extraction avec instructions par modèle |
| Fetch simple + LLM (scraping maison) | Extraction sans service spécialisé | ~0,005 $ le run (benchmark, septembre 2026) | Petits volumes, contrôle total du prompt |
Notez le point le plus contre-intuitif du benchmark : la solution la plus performante sur les champs inventés n'est pas un service d'extraction sophistiqué, mais un simple fetch HTTP suivi d'un appel LLM bien prompté. On y revient plus bas.
Que mesure exactement ce benchmark ?
Réponse directe : il mesure combien de champs un modèle invente quand l'information demandée n'existe pas sur la page.
Le protocole, détaillé sur la page du benchmark, repose sur 42 paires de pages web synthétiques couvrant 7 types de pages. Dans chaque paire : une page contient la réponse à la question d'extraction, l'autre non — mais les deux contiennent le même « appât » (decoy), une donnée plausible, visible, tentante, mais fausse pour la tâche demandée.
Le modèle doit extraire des champs précis. Le score compte les champs remplis alors qu'ils n'existaient pas sur la page. Deux conditions sont testées : avec et sans la phrase « Use null for any field whose value is not on the page. Do not guess. »
Les chiffres clés
| Condition | Champs inventés | Taux |
|---|---|---|
| Sans instruction | 405 / 573 champs manquants | 70,7 % |
| Avec instruction | 116 / 574 champs manquants | 20,2 % |
Les dénominateurs quasi identiques (573 vs 574) permettent une comparaison directe. La chute est de plus de 50 points de pourcentage — pour six mots ajoutés au prompt.
Les limites, dites par les auteurs de l'analyse
L'analyse de RuntimeWire apporte les nuances nécessaires : il s'agit de pages synthétiques avec des pièges conçus artificiellement, et chaque contestant n'a été évalué qu'une seule fois. Les dénominateurs comptent des réponses, pas des mesures sur des sites web réels.
Autrement dit : l'instruction claire aide massivement sur ce type de test, sans garantie absolue sur le web réel, où l'ambiguïté et la tromperie prennent des formes bien plus variées. C'est un benchmark, pas une loi universelle. Mais c'est le premier à quantifier proprement ce réflexe sur autant de modèles frontier.
Pourquoi une si petite phrase a-t-elle un si gros effet ?
Réponse directe : parce qu'un LLM est optimisé pour compléter, pas pour dire « je ne sais pas ». L'instruction court-circuite ce réflexe par défaut.
Un modèle de langage entraîné sur des données extraites du web a appris, des milliards de fois, à remplir les champs manquants. Un scraper humain qui rencontre un champ vide sur une fiche produit a souvent une « intuition » de ce que devrait contenir ce champ — et l'entraînement d'alignement a probablement renforcé ce comportement « serviable ». Sans consigne contraire, remplir est l'option par défaut. Dire « null » exige une décision explicite.
La phrase « Do not guess » transforme cette décision implicite en règle explicite. C'est un cas d'école de ce que nous appelions déjà dans notre guide du prompt engineering : les instructions négatives ciblées sur un comportement précis surpassent les consignes vagues du type « sois précis et ne hallucine pas ».
Un défaut universel, pas un défaut de modèle
Le fait que les 16 modèles testés hallucinent tous davantage sans la phrase est peut-être l'enseignement le plus important. Ce n'est pas « Gemini 3.1 Pro est fiable mais GPT-5.5 ne l'est pas » : c'est « tous les modèles frontier ont le même biais, et il se corrige côté prompt, pas côté choix du modèle ».
Pour vos pipelines, cela signifie que passer d'un modèle à l'autre ne règle pas ce problème. Changer le prompt, si. C'est cohérent avec notre article sur le prompt debugging : avant d'incriminer le modèle, il faut auditer ce qu'on lui demande — ou plutôt, ce qu'on oublie de lui demander.
Les appâts : là où le benchmark devient vraiment intéressant
Réponse directe : les pièges du benchmark sont conçus pour ressembler à des réponses légitimes, et les modèles tombent dedans à 16 sur 16.
Trois exemples du protocole méritent le détour, parce qu'ils ressemblent trait pour trait à ce que vous trouverez sur de vraies pages e-commerce ou éditoriales :
- L'ancien prix : une page affiche « Was $493.00 » barré, puis le prix actuel. Sans l'instruction, les 16 modèles rapportent 493 comme prix actuel. Avec, un seul résiste. Le formatage « Was X » est si courant que le modèle a appris à l'ignorer visuellement — mais son tokenizer, lui, ne l'ignore pas.
- Le fact-checker adjacent : un vérificateur de faits est placé près d'un champ auteur, ce qui incite le modèle à fusionner les deux entités.
- La date confondable : une date de mise à jour, placée au même endroit qu'une date de publication habituelle, se retrouve extraite comme date de publication.
Ces pièges fonctionnent parce qu'ils exploitent non pas l'ignorance du modèle, mais sa compétence. Il reconnaît des motifs d'apparence légitime et les applique au mauvais champ. C'est exactement le type d'erreur qu'une validation humaine ponctuelle ne détecte pas, parce que la valeur inventée est plausible.
L'humiliation du service d'extraction commercial
Réponse directe : Firecrawl, un service d'extraction dédié, a inventé 24 champs sur 36 — pire que 13 des 16 modèles avec la simple instruction.
Le détail est savoureux : Firecrawl a copié l'appât à chaque fois, sans exception. Pendant ce temps, un montage artisanal — fetch simple de la page + GPT-6 Luna avec l'instruction — n'a inventé que 5 champs sur 36, pour un coût total de run de 0,0049 $.
Que retenir ? Deux choses, toutes deux gênantes pour l'écosystème :
- Les services d'extraction « clés en main » n'ont pas de monopole de fiabilité. Un pipeline maison, transparent, où vous contrôlez le prompt, peut surpasser un produit commercial. C'est un argument de plus pour maîtriser sa stack, et pour configurer soi-même ses modèles et providers plutôt que de déléguer aveuglément.
- L'opacité du marketplace agent-à-agent. RuntimeWire rappelle que ce benchmark illustre la question centrale du marketplace d'Earn an Honest Dollar : un acheteur d'agent peut-il savoir quand un service bluffe ? Quand un fournisseur prétend extraire « fiablement », il ne vous dit pas si son pipeline contient l'équivalent de « Do not guess » — ni s'il a jamais testé.
Si vous voulez réduire les coûts de vos expérimentations, sachez aussi que vous pouvez tester plusieurs modèles gratuitement via OpenRouter ou Groq avant de basculer en production — le comportement anti-hallucination d'un modèle se vérifie pour quelques centimes.
Le revers de la médaille : le « safety tax »
Réponse directe : réduire les fabrications ne veut pas dire tout gagner — l'instruction anti-hallucination peut faire chuter le rappel sur des informations pourtant présentes.
C'est ce que documente l'étude arXiv 2601.02023, « Not All Needles Are Found », qui étend le benchmark needle-in-a-haystack à Gemini-2.5-flash, ChatGPT-5-mini, Claude-4.5-haiku et Deepseek-v3.2-chat. Le constat : les instructions du type « Don't Make It Up » ou « Do not guess » rendent certains modèles trop conservateurs.
Les chiffres parlent d'eux-mêmes :
| Condition | Extraction littérale (ChatGPT-5-mini) |
|---|---|
| Prompt standard | 96,4 % |
| Prompt anti-hallucination | 90,3 % |
| Anti-hallucination + contexte à capacité max (272k tokens) | 72 % |
| Faits concentrés sur certaines distributions | jusqu'à 0 % |
Ce « safety tax » s'aggrave en bout de contexte : plus le contexte est long, plus le modèle prudent refuse de sortir une information pourtant bien présente. Sur certaines distributions de faits concentrées, l'extraction s'effondre littéralement à zéro.
En pratique : la phrase magique réduit les fabrications, mais elle peut vous faire perdre des données réelles. Si votre pipeline doit maximiser le rappel (par exemple en veille concurrentielle où chaque champ manqué compte), il faut mesurer ce compromis sur vos propres données, pas le supposer.
20 % résiduels : pourquoi la validation aval reste obligatoire
Réponse directe : parce qu'une phrase de prompt ne détecte pas les hallucinations, elle en réduit la fréquence. Les 20 % restants exigent un filet de sécurité en aval.
Le benchmark a testé deux stratégies de vérification aval, avec des résultats à double tranchant :
- GPT-6 Luna attrape 38 valeurs inventées sur 49, sans rejeter aucune des 47 valeurs correctes.
- Jev 1.13 attrape 23 sur 49, sans aucun faux rejet sur 48 valeurs correctes.
Le taux de faux positifs nul est remarquable : les vérificateurs ne rejettent pas à tort des données correctes. Mais tous ratent des erreurs « near-miss » — un temps de cuisson présenté comme temps de préparation, un prix légèrement proche de la vraie valeur. Les hallucinations les plus dangereuses sont précisément celles qui ressemblent le plus à la vérité.
D'où une architecture que je recommande pour toute pipeline d'extraction sérieuse :
- Prompt avec instruction explicite (« Do not guess » ou équivalent), éventuellement adaptée à votre tolérance au rappel.
- Sortie structurée avec champ confidence ou justification : demandez au modèle de citer le passage source pour chaque champ. Un champ sans citation est un suspect.
- Vérification aval par un second modèle, avec un prompt distinct.
- Détection statistique des hallucinations — notre article sur la méthode phi-first qui détecte les hallucinations en un seul token montre qu'on peut repérer un modèle en train d'inventer avant même la fin de sa réponse, sans second appel coûteux.
La combinaison « prompt durci + détection au token + validation sémantique » coûte une fraction de seconde et quelques centimes par page. Elle transforme un taux d'erreur de 20 % en quelque chose de publiable.
Ce que ça change pour vos pipelines, concrètement
Réponse directe : ajoutez la phrase, testez-la sur vos données réelles, mesurez le compromis fabrication/rappel, et gardez la validation aval.
Un plan en cinq étapes, sans détour :
- Auditez vos prompts actuels. Si vos instructions d'extraction ne contiennent pas de consigne explicite sur les champs absents, vous payez probablement 30 à 70 % de champs inventés sans le savoir. La phrase exacte du benchmark est un bon point de départ.
- Testez sur des paires de pages avec et sans l'information. C'est le seul moyen de mesurer votre propre taux de fabrication. Un test sur vos pages types (produits, articles, fiches internes) prend une après-midi.
- Mesurez le safety tax sur vos données. Vérifiez que le rappel sur les champs réellement présents ne s'effondre pas, surtout si vos pages sont longues. Comparez avant/après instruction.
- Choisissez vos modèles en connaissance de cause. Tous les modèles frontier partagent le biais, mais leur sensibilité au safety tax diffère. Utilisez des accès multi-modèles — gratuitement dans un premier temps — pour affiner.
- Empilez les garde-fous. Prompt, détection au token, validation par second modèle. Aucun maillon ne suffit seul ; la chaîne, elle, tient.
Et si vous suivez l'actualité sécurité, notez que la défense en profondeur est aussi la logique de systèmes comme le harness multi-modèles Unit 42 de Palo Alto Networks (22 septembre), qui combine Claude Mythos 5, GPT-5.6-Cyber et modèles ouverts pour se valider mutuellement — un autre écho de la même leçon relevée par AI Weekly : un seul modèle, seul, se trompe ; plusieurs, croisés, se corrigent.
❌ Erreurs courantes
Erreur 1 : croire qu'un modèle plus cher hallucine moins
Les 16 modèles frontier testés hallucinent tous davantage sans l'instruction, y compris les plus chers et les mieux classés. Le problème est structurel, pas un effet de gamme. Solution : durcir le prompt d'abord, changer de modèle ensuite.
Erreur 2 : traiter l'absence de donnée comme une donnée
Le piège « Was $493.00 » fonctionne parce que le modèle extrait une valeur présente sur la page, mais attribuée au mauvais champ. Vos schémas d'extraction devraient distinguer « champ absent » (null) et « champ rempli avec justification source ». Un champ sans justification est suspect par défaut.
Erreur 3 : appliquer « Do not guess » partout sans mesurer
Le safety tax documenté par l'étude arXiv peut faire perdre des données réelles, surtout en long contexte. Solution : mesurez fabrication ET rappel sur vos propres pages avant de généraliser l'instruction.
Erreur 4 : s'appuyer sur un service d'extraction pour la fiabilité
Firecrawl a inventé 24 champs sur 36 en copiant l'appât systématiquement — pire que la plupart des modèles brutaux avec une phrase de prompt. Solution : demandez à vos fournisseurs leur méthodologie anti-hallucination, et testez-les sur des pages pièges comme celles du benchmark.
Erreur 5 : confondre validation aval et garantie absolue
GPT-6 Luna attrape 38 erreurs sur 49, mais rate les near-miss. Un vérificateur qui ne rejette jamais de valeurs correctes (zéro faux positif) est excellent — mais il n'est pas infaillible. Gardez un échantillonnage humain sur les champs critiques.
❓ Questions fréquentes
La phrase exacte à copier, c'est quoi ?
« Use null for any field whose value is not on the page. Do not guess. » C'est l'instruction testée par le benchmark. Vous pouvez l'adapter à votre langue et votre schéma, mais gardez la double structure : règle explicite (null si absent) puis interdiction (ne pas deviner).
Pourquoi 573 et 574 champs, et pas le même nombre ?
Les deux conditions testent des jeux quasi identiques mais pas strictement identiques ; l'écart d'un champ ne change pas la comparabilité. RuntimeWire note que ces dénominateurs comptent des réponses sur pages synthétiques, pas des mesures sur le web réel.
Ce résultat vaut-il pour les pages web réelles ?
Partiellement. Le benchmark utilise des pages synthétiques avec pièges conçus, un seul run par contestant. L'instruction aide massivement dans ce cadre contrôlé, mais le web réel est plus ambigu et plus trompeur. À valider sur vos données.
Faut-il arrêter d'utiliser des services d'extraction ?
Non, mais testez-les. Le résultat de Firecrawl (24 champs inventés sur 36) montre qu'un produit commercial peut être moins fiable qu'un fetch + LLM bien prompté à 0,0049 $ le run. Comparez sur vos cas d'usage avant d'engager.
Comment détecter les hallucinations sans double appel ?
La méthode phi-first consiste à analyser la distribution de probabilité du premier token généré pour chaque champ : un modèle hésitant avant d'inventer laisse des signatures détectables. C'est détaillé dans notre article dédié, et c'est compatible avec une pipeline à haut débit.
Est-ce que ça marche sur les modèles ouverts et gratuits ?
Le benchmark couvre des modèles frontier propriétaires, mais le mécanisme — une consigne explicite contre un réflexe d'entraînement — devrait s'appliquer aux modèles ouverts. Le biais étant universel chez les 16 testés, l'instruction est probablement bénéfique partout ; mesurez-le vous-même sur les modèles gratuits accessibles via agrégateurs.
✅ Conclusion
Une phrase de six mots fait chuter les champs hallucinés de 71 % à 20 % sur 16 modèles frontier — mais les 20 % restants, et le safety tax qu'elle peut induire, prouvent qu'aucun prompt ne remplace une validation en aval. Testez l'instruction « Do not guess » sur votre prochaine pipeline d'extraction, et lisez notre méthode pour détecter les hallucinations en un seul token pour compléter vos garde-fous.
