Utiliser /probe pour détecter les hallucinations de l'IA avant d'écrire du code

Ce que fait /probe

La technique /probe force les plans générés par l'IA à sortir chaque fait affirmé sous forme d'une AFFIRMATION numérotée avec une valeur ATTENDUE. Elle exécute ensuite une commande pour sonder le système réel et capture le delta entre les résultats attendus et réels.

Exemple concret de la source

Un développeur essayait d'analyser les fichiers de session JSONL de Claude stockés sous ~/.claude/projects/.... Claude a décrit le format avec assurance, mais l'exécution de /probe a révélé quatre hallucinations :

• Affirmation 1 : L'IA a dit qu'il y avait 2 types de haut niveau (utilisateur, assistant). Réalité : 7 types incluant queue-operation, file-history-snapshot, attachment, system, permission-mode, et summary.
• Affirmation 2 : L'IA a dit que le contenu de l'assistant = texte + tool_use. Réalité : Manque les blocs de réflexion, qui représentent environ un tiers de la sortie de l'assistant en mode réflexion étendu.
• Affirmation 3 : L'IA a dit que le contenu utilisateur est toujours un tableau. Réalité : Polymorphe : chaîne OU tableau.
• Affirmation 4 : L'IA a dit que la nomination des dossiers remplace / par -. Réalité : Ajoute en fait un tiret au début, puis remplace.

Sans /probe, le filtre jq aurait échoué sur le contenu utilisateur sous forme de chaîne, aurait rejeté les blocs de réflexion comme du bruit, et aurait manqué 5 des 7 types de messages entièrement.

Comment fonctionne la sonde

L'IA écrit des affirmations comme "ATTENDU : 2 types" avant d'exécuter des commandes telles que jq -r '.type' file.jsonl | sort -u. Une sortie de sonde ressemblait à :

AFFIRMATION 1 : JSONL a 2 types de haut niveau (utilisateur, assistant)
ATTENDU : 2
COMMANDE : jq -r '.type' *.jsonl | sort -u | wc -l
RÉEL : 7
DELTA : +5 types inconnus (queue-operation, file-history-snapshot, attachment, system, permission-mode, summary)

Principales idées de la source

Les affirmations qui valent la peine d'être sondées sont souvent celles dont l'IA est la plus confiante. Quand l'IA hésite, vous savez déjà qu'il faut vérifier. Quand elle affirme catégoriquement X, vous ne le savez pas. Les affirmations à haute confiance sont là où se cachent les hallucinations.

Un autre avantage est qu'une sonde devient N tests permanents. La découverte des 7 types devient un test de schéma qui échoue en CI si un nouveau type apparaît. La découverte chaîne-ou-tableau devient un test de propriété qui explore les deux formes. Quand le format en amont change, le test échoue, vous re-sondez, et l'oracle se met à jour.

Limitations et améliorations

La sonde ne capture que les affirmations que l'IA pense à faire. Les inconnues inconnues restent invisibles. Ce qui aide :

• Exécuter jq 'keys' d'abord pour énumérer la réalité avant de générer des affirmations
• Le modèle CRISPY de Dex Horthy pousse l'IA à faire surface à sa propre liste de lacunes
• Le Spec Kit de GitHub utilise des marqueurs [NÉCESSITE UNE CLARIFICATION] dans les spécifications pour forcer l'IA à marquer les angles morts
• Une vérification humaine de la liste des affirmations est également recommandée

Contraste avec le TDD traditionnel

Le TDD traditionnel écrit des tests basés sur ce que vous PENSEZ qui devrait se passer. Le TDD piloté par sondes écrit des tests basés sur ce que vous avez exploré ou VÉRIFIÉ qui se passe. Les mocks testent votre modèle du système. La sonde teste le système lui-même.

Fichiers source

Le développeur a partagé le fichier de compétence complet /probe dans un gist avec deux fichiers :

• README.md : Explication plus longue avec l'angle REPL-comme-oracle et le contraste TDD
• probe-skill.md : Le protocole en 7 étapes chargé comme une compétence Claude Code

Le modèle est simplement "tableau d'affirmations + sonde du système réel + capture du delta" et fonctionne avec tout REPL ou outil CLI qui peut interroger le système contre lequel vous êtes sur le point de coder.