Qu'est-ce qui casse lorsque vous analysez la sortie d'un LLM en production ?

Ce sont généralement les hypothèses de votre code sur le formatage, et non la réponse du modèle, qui posent problème. Trois bugs récurrents : du JSON valide encadré par des balises markdown qu'un parseur strict rejette, des légendes de tokens du prompt copiées dans la sortie, et des validateurs qui considèrent comme fatale une mise en forme réparable. Validez strictement, normalisez avec parcimonie, et conservez la sortie brute.

Pourquoi un JSON valide issu d'un LLM échoue-t-il à être analysé ?

Les modèles encadrent souvent le JSON avec des balises de code markdown pour la lisibilité, donc un appel strict à json.loads sur le texte brut échoue même si le contenu est valide. Supprimez exactement une balise extérieure avant l'analyse, conservez le texte original pour l'audit, et rejetez toujours les textes en prose ou les balises imbriquées comme des sorties réellement invalides.

Pourquoi le modèle copie-t-il la légende des tokens de mon prompt dans la sortie ?

Si un prompt explique un espace réservé avec une légende, par exemple un token suivi d'un signe égal et d'une description, les modèles reproduisent parfois ce format dans le résultat. Indiquez clairement au modèle que les tokens doivent être seuls sur leur propre ligne, et supprimez les étiquettes préfixées par un symbole ou entre parenthèses lorsque vous injectez le contenu réel.

Quels problèmes de sortie un validateur doit-il rejeter, et lesquels doit-il réparer ?

Rejetez ce qui rend la sortie structurellement incorrecte : champs obligatoires manquants, prose au lieu de JSON, espaces réservés non remplacés. Réparez ce qui est cosmétique et sans risque : une balise entourante, des espaces blancs superflus, une étiquette décorative. Décidez au cas par cas, documentez-le, et consignez ce qui a été réparé pour suivre l'évolution du comportement du modèle.

Pourquoi conserver la sortie brute du modèle ?

La sortie brute vous permet de distinguer un problème lié au modèle d'un problème d'analyse. Lorsqu'une réponse est rejetée ou réparée, stockez le texte original à côté du résultat. Le débogage commence alors à partir de preuves et non de suppositions, et vous pouvez rejouer l'analyse avec un parseur corrigé sans rappeler le modèle.

Publié à l'origine sur sakshamjain.codes/blog/llm-output-handling-bugs. Besoin de cette solution ? Découvrez mes services sur NexoRush ou contactez-moi.