Ton modèle passe les evals et échoue quand même en production

Ton LLM a affiché de bons scores sur tous les benchmarks avant le déploiement. Six semaines plus tard, un client fait une capture d'écran d'une réponse qui boucle, s'effiloche, ou répète la même tournure quatre fois de suite. Tes evals n'ont rien vu. Ton monitoring non plus. La dégénérescence de texte — la dégradation progressive ou soudaine de la cohérence des outputs — est l'un des modes d'échec les plus courants en production sur les modèles de langage déployés, et la plupart des équipes n'ont aucune instrumentation pour la détecter. C'est ce manque qu'il vaut la peine de combler avant que les utilisateurs ne ferment leur compte.

Ce qui a changé dans notre compréhension de ce mode d'échec

La dégénérescence de texte recouvre toute une famille de pathologies d'output : boucles de répétition, dérive sémantique, fins incohérentes, et texte de remplissage creux qui semble fluide mais ne veut rien dire. Le billet Hugging Face sur la dégénérescence de texte comme mode d'échec en production pose le problème central avec précision — les benchmarks standards mesurent la justesse sur des prompts courts et bien formés, pas la stabilité face à la distribution réelle des inputs soumis par tes utilisateurs. Un modèle peut obtenir d'excellents scores sur MMLU ou HumanEval tout en produisant des outputs dégradés dans les conditions qui comptent : contextes longs, instructions ambiguës, formulations adversariales, ou sampling à haute température sans pénalité sur la répétition.

Les mécanismes à l'origine de la dégénérescence sont bien documentés au niveau de la recherche. Le greedy decoding et le beam search convergent tous deux vers des séquences de tokens à haute probabilité qui se renforcent mutuellement — un phénomène parfois appelé exposure bias. Le nucleus sampling (top-p) et le scaling de température réduisent ce risque, mais introduisent leur propre instabilité en queue de distribution. Les paramètres de repetition penalty existent dans la plupart des frameworks d'inférence, mais leurs valeurs par défaut ont été calibrées pour un usage général, pas pour ton domaine spécifique, ta longueur de contexte ou ta structure de prompt.

Ce qui est plus récent, c'est la réalité opérationnelle : l'infrastructure d'inférence a mûri plus vite que les outils d'observabilité sur la qualité des outputs. Les équipes instrumentent rigoureusement la latence, le coût en tokens et les taux d'erreur. Presque aucune n'instrumente la cohérence sémantique, la densité de répétition ou les distributions de longueur d'output d'une façon qui permettrait de détecter la dégénérescence avant qu'une escalade utilisateur ne le fasse.

Pourquoi ça concerne ton stack en particulier

Si tu fais tourner des LLMs dans un workflow où les outputs alimentent une logique en aval — un résumé qui route un ticket, un brouillon soumis à validation humaine, une extraction structurée qui alimente une base de données — la dégénérescence ne fait pas qu'agacer les utilisateurs. Elle casse les pipelines en silence. Un résumé en boucle renvoie quand même un 200. Une extraction répétitive passe quand même la validation JSON. Ton error budget a l'air propre pendant que la qualité de tes données se dégrade.

Le profil de risque n'est pas uniforme. Il évolue avec quatre variables : la longueur de contexte (des inputs plus longs augmentent la probabilité de dérive), la température de décodage (des valeurs plus élevées augmentent le risque en queue de distribution), la spécificité du domaine (les modèles sont plus sujets à la dégénérescence sur des prompts hors distribution), et les objectifs de longueur d'output (des outputs plus longs amplifient toute instabilité dans la distribution de sampling). Si ton cas d'usage en production se situe dans le coin à haut risque sur les quatre axes — documents longs, tâches créatives ou ouvertes, vocabulaire spécialisé, output long — ton exposition est significative et probablement non surveillée.

Ce que la plupart des vendors d'observabilité ratent, c'est que la dégénérescence est une propriété statistique d'une distribution, pas un flag binaire sur une réponse isolée. Un seul output dégradé peut ressembler à du bruit. Cinquante outputs dégradés sur mille, regroupés autour d'un pattern de prompt ou d'une fenêtre temporelle précise, c'est un signal — mais seulement si tu collectes et analyses des métriques de qualité au niveau de l'output, pas uniquement des métriques d'infrastructure.

Parler à Domani AI de comment construire ça →

Le mouvement du lundi matin : un audit en quatre questions de ton instrumentation actuelle

Avant de changer quoi que ce soit dans ton stack d'inférence, identifie ce que tu peux déjà voir. Quatre questions suffisent à révéler les lacunes :

• Est-ce que tu loggues les outputs complets du modèle ? Pas seulement les comptages de tokens — le texte réel. Si tu ne loggues que les métadonnées, tu ne peux pas détecter la dégénérescence rétrospectivement.
• As-tu une métrique de répétition ou de cohérence dans tes dashboards ? Un simple taux de répétition n-gram ou un score self-BLEU sur des outputs échantillonnés, c'est un point de départ. Si la réponse est non, c'est le premier instrument à ajouter.
• Quels sont tes paramètres actuels de repetition penalty et de top-p, et à quand remonte leur dernière révision face à ta distribution de prompts en production ? Les valeurs par défaut de la documentation des frameworks ne sont pas calibrées pour ton cas d'usage.
• As-tu un échantillon de revue humaine ? Un échantillonnage aléatoire de 50 à 100 outputs par semaine, relu par quelqu'un qui sait à quoi ressemble un bon output dans ton domaine, capturera ce que les métriques automatisées ratent.

Si tes réponses révèlent des lacunes — ce qui sera le cas pour la plupart des équipes — la séquence est la suivante : logger d'abord, mesurer ensuite, ajuster en dernier. Essayer de régler les paramètres de décodage sans mesure, c'est tourner un bouton que tu ne peux pas voir.

Pour les équipes qui font tourner plusieurs modèles en production ou plusieurs variantes de prompt, ajoute une cinquième question : est-ce que tu testes en A/B les métriques de qualité d'output, ou uniquement les métriques de tâche ? Un nouveau template de prompt qui améliore le taux de complétion de tâche peut simultanément dégrader la cohérence de l'output. Ces deux signaux évoluent souvent en sens opposés et doivent être suivis séparément.

Ce que ça coûte versus ce que ça fait économiser

Ajouter une instrumentation de qualité d'output n'est pas un investissement d'ingénierie majeur pour une équipe qui fait déjà du logging structuré. Une métrique de taux de répétition sur des outputs échantillonnés peut être implémentée en quelques heures. Un pipeline de cohérence sémantique plus complet — détection de dérive par embedding, monitoring des distributions de longueur, alertes d'anomalie — représente 2 à 4 semaines pour un ingénieur, selon ton infrastructure de données existante. C'est l'estimation honnête.

Le coût de ne pas le faire est plus difficile à quantifier, mais plus facile à reconnaître après coup. Les bugs de dégénérescence remontent via les tickets support, via des incidents de qualité de données en aval, et parfois via des captures d'écran publiques. Chacun de ces chemins est plus lent et plus coûteux à corriger que d'avoir détecté le signal dans un dashboard. Plus tes outputs d'IA alimentent des décisions automatisées plutôt qu'une revue humaine, plus le risque de queue d'un événement de dégénérescence s'aggravant silencieusement sur des milliers d'entrées avant que quiconque ne le remarque est élevé.

Le compromis est le suivant : l'instrumentation prend du temps d'ingénierie que tu n'as peut-être pas budgété. Mais l'alternative, c'est de piloter des LLMs en production avec uniquement des jauges de latence — ce qui signifie que ton premier avertissement d'une régression de qualité sera une plainte utilisateur plutôt qu'une alerte. Pour la plupart des CTOs à qui nous parlons, ce compromis se résout rapidement une fois que le mode d'échec est clairement nommé.