Les LLM divulguent leur raisonnement dans les sorties structurées malgré des instructions explicites

Le problème : les passes de validation LLM laissent fuir le raisonnement

Un développeur créant un outil qui effectue des appels API parallèles à Claude et analyse la sortie structurée par appel a rencontré un problème intermittent. Chaque appel renvoie du contenu entre des marqueurs spécifiques comme [COUVERTURE], [DIAPO 1], [LEGENDE], etc. Une deuxième passe LLM valide la sortie par rapport aux règles et réécrit tout ce qui échoue.

Le prompt de validation indique explicitement : "renvoie UNIQUEMENT le texte corrigé dans le format exact. Pas de commentaire. Pas de raisonnement. Pas de liste de violations."

Malgré cela, le modèle de validation produit parfois son raisonnement avant le contenu corrigé. Par exemple : "Je dois vérifier ce texte pour les violations... Ces phrases forment une paire dramatique empilée utilisée uniquement pour l'effet. Voici la réécriture :" suivi du texte corrigé réel.

Conséquences en aval

Ce texte de raisonnement est transmis directement à l'analyseur. L'analyseur s'attend à un contenu commençant par [COUVERTURE] mais reçoit plutôt des méta-commentaires. Cela provoque un désalignement des champs en aval. Dans un cas, le texte de raisonnement du validateur s'est retrouvé dans un champ de prompt d'image parce que l'analyseur a consommé le raisonnement comme contenu principal, décalant tout de quelques lignes.

Le simple renforcement du prompt n'a pas résolu le problème. Rendre les instructions plus explicites, ajouter "votre sortie DOIT commencer par le premier marqueur de contenu" et ajouter "n'incluez jamais de raisonnement" a réduit la fréquence mais ne l'a pas éliminée. Le modèle ignore parfois les instructions, surtout quand il trouve des violations à corriger—il veut montrer son travail.

La solution : une défense à deux couches

La solution qui a fonctionné implique deux couches :

• Couche 1 : Renforcement du prompt. Cela vaut toujours la peine car cela réduit la fréquence du problème.
• Couche 2 : Une fonction de nettoyage défensive qui s'exécute sur chaque sortie de validation avant toute analyse. Pour les formats structurés, elle s'ancre au premier marqueur reconnu et supprime tout ce qui le précède. Pour les formats texte brut, elle supprime les lignes correspondant à des modèles de commentaires connus du validateur (comme "Laissez-moi vérifier ce texte" ou "Cela viole la contrainte").

L'ordre nettoyage-avant-analyse est crucial. Chaque analyseur en aval opère sur une sortie déjà assainie. Cela évite de maintenir une logique de nettoyage par champ ou de jouer à la taupe avec de nouveaux formats de raisonnement.

Considérations d'implémentation

Pour les modèles de nettoyage en texte brut, une conception minutieuse est nécessaire. Une expression régulière qui capture "C'est une violation" pourrait aussi capturer "C'est une erreur courante" dans un contenu légitime. Les modèles doivent être resserrés pour ne correspondre qu'au langage spécifique du validateur, comme "Cela viole la/une règle/contrainte" plutôt que des correspondances larges sur "C'est" ou "Cela utilise". Chaque modèle doit être audité par rapport à du contenu réel avant déploiement.

Si vous analysez une sortie structurée d'un LLM, traitez les instructions du prompt comme une première passe de bonne volonté et ayez toujours une défense au niveau du code avant l'analyseur. Le modèle se conformera 95 % du temps, mais les 5 % où il ne le fait pas casseront la logique en aval de manière difficile à reproduire car c'est intermittent.