Validation des sorties LLM en streaming : les leçons de NarrateAI
La validation des sorties LLM est souvent traitée comme une étape finale : le modèle génère, puis un contrôle relit la réponse avant de l'afficher. Le 25 septembre 2026, une équipe d'AWS a publié le retour d'expérience de NarrateAI, un assistant de pilotage utilisé par plus de 4 000 dirigeants internes pendant six mois. Leur choix est inverse : valider chaque paragraphe pendant qu'il est généré.
Le résultat est chiffré. Le délai avant le premier contenu affiché passe de 100,2 secondes à 13,2 secondes, soit 86,8 % de moins, et l'exactitude des chiffres reste à 99,3 % sur toute la période. Pour une équipe qui met un agent en production devant des utilisateurs exigeants, c'est l'un des retours les plus concrets publiés cette année.
Le contexte
NarrateAI répond à des questions de pilotage du type « quelles régions n'atteignent pas leurs objectifs, et pourquoi ? ». Les réponses sont lues en revue de direction. Un chiffre faux ou une réponse qui met deux minutes à arriver devant un comité de direction a un coût immédiat pour la personne qui présente.
Un LLM seul ne garantit ni l'exactitude des nombres, ni la disponibilité de l'API aux heures de pointe, ni un temps de réponse compatible avec une réunion. L'équipe a donc construit autour du modèle une chaîne de contrôle qualité en cinq couches, sur Amazon Bedrock, AgentCore et le framework open source Strands Agents.
Deux termes reviennent dans la suite. Le TTFC (time to first content) est le temps entre la question et le premier texte visible. Un évaluateur est un contrôle automatique qui juge un morceau de réponse : présence d'emoji, formulation vague, chiffre non conforme aux données sources.
Coût et disponibilité : router, puis répartir
Router selon le volume de données, pas selon le pire cas
La première couche décide du chemin de traitement selon la quantité de données récupérées pour la question. Si elle reste sous un seuil calibré sur les limites de taille d'entrée, la réponse part en un seul appel au modèle. Au-delà, les données sont découpées et traitées en lots parallèles.
En production, environ 90 % des questions passent par le chemin rapide. Le coût moyen tombe à environ 1,4 appel LLM par question, soit 72 % de moins qu'une stratégie qui ferait systématiquement plusieurs passes. Le chemin rapide répond en général en moins de 25 secondes, le chemin complet en 50 à 75 secondes.
La leçon dépasse AWS : beaucoup de pipelines RAG sont dimensionnés pour la requête la plus lourde. Mesurer la distribution réelle des requêtes, puis router, coûte moins cher que d'appliquer le traitement maximal à tout le monde.
Répartir la charge sur une grille de quotas
La deuxième couche traite la disponibilité. Au lieu d'ajouter de l'infrastructure, l'équipe répartit les appels sur une grille de plusieurs modèles et plusieurs comptes AWS, chaque couple modèle-compte ayant ses propres quotas Bedrock. Les modèles sont classés par compromis qualité-vitesse, la charge est répartie de façon aléatoire, et un couple indisponible est détecté vite, en 100 à 200 ms via un changement de rôle STS.
Sur les tests de charge, le système a tenu plus de 100 utilisateurs simultanés sans aucune requête en échec, et toutes les requêtes ont abouti pendant les six mois.
Côté plateforme, cette approche suppose une organisation multi-comptes déjà propre : rôles d'accès, suivi des coûts par compte, supervision des quotas. Sans cette base, la grille devient difficile à auditer. C'est un bon exemple d'une question d'IA qui se résout surtout avec de l'ingénierie de plateforme classique.
Validation des sorties LLM en streaming : le cœur de la méthode
La troisième couche est la plus intéressante. Le modèle génère sa réponse paragraphe par paragraphe, chaque paragraphe est placé dans une file, et un consommateur le valide en parallèle pendant que la génération continue. Cela fonctionne parce que les paragraphes d'une réponse de pilotage sont largement indépendants les uns des autres.
L'équipe raisonne avec un ratio simple : le rythme de génération divisé par le rythme de validation. Sur le chemin rapide, ce ratio vaut environ 0,095, la validation est donc invisible pour l'utilisateur. Sur le chemin lent, il monte à environ 21,5 et la file freine volontairement la génération. Le surcoût mesuré sur le premier paragraphe est de 1,4 seconde par rapport à un streaming sans contrôle.
Trois évaluateurs, chacun avec son correcteur
Chaque paragraphe passe par trois évaluateurs en parallèle : un contrôle des formulations vagues par expressions régulières, un filtre d'emoji, et une vérification des chiffres. Chaque évaluateur a un correcteur associé, qui corrige le paragraphe au lieu de le rejeter. Les deux contrôles déterministes prennent 79 ms en médiane, la vérification par LLM environ 2 secondes.
L'équipe fixe une contrainte d'extensibilité claire : on peut ajouter des évaluateurs tant que le ratio global reste sous 1. Au-delà, la validation redevient visible pour l'utilisateur.
Vérifier les chiffres en cascade
La dernière couche vérifie que chaque nombre cité existe bien dans les données sources, en trois étapes du moins cher au plus cher. D'abord une correspondance exacte par extraction et comparaison d'ensembles, environ 0,3 ms par paragraphe. Ensuite une comparaison de similarité de chaînes dans le contexte, environ 1,7 ms par métrique. Enfin, seulement si nécessaire, une vérification sémantique par un agent LLM, environ 1,8 seconde par métrique.
En production, 87 % des métriques passent dès la première étape, et seulement 30 % de celles qui la franchissent ont besoin de l'étape LLM. Le coût moyen de vérification tombe à environ 812 ms par métrique, 54 % de moins qu'une vérification entièrement confiée à un LLM. Sur 1 000 questions réelles, soit 10 439 paragraphes analysés, l'exactitude numérique se maintient à 99,3 %.
Reproduire cette validation des sorties LLM sans AWS
Rien dans cette architecture n'impose Bedrock. Le schéma tient en quelques briques que l'on trouve dans n'importe quelle stack : un modèle qui sait streamer, une file thread-safe, un pool de validateurs et une source de vérité pour les chiffres.
Commencez par découper la sortie en unités indépendantes. Pour un rapport, c'est le paragraphe. Pour un agent qui remplit un formulaire, c'est le champ. Pour un assistant de support, ce peut être chaque étape d'une procédure. Si les unités dépendent fortement les unes des autres, la validation en parallèle perd son intérêt.
Écrivez ensuite les contrôles déterministes avant tout LLM-juge : expressions régulières, listes de valeurs autorisées, comparaison avec les données sources. Ils sont rapides, explicables et testables en CI comme n'importe quel code. Le juge LLM ne vient qu'après, sur ce qui reste ambigu.
Enfin, instrumentez trois mesures dès le premier jour : le délai avant premier contenu, le taux de paragraphes corrigés par évaluateur, et la part des vérifications qui montent jusqu'à l'étape LLM. Ces trois courbes suffisent à savoir si la chaîne de validation tient la charge et où concentrer l'effort.
Ce que ça change pour les équipes IA
Ce retour d'expérience donne une méthode reproductible pour la validation des sorties LLM, bien au-delà de Bedrock.
Mettre les contrôles bon marché en premier. La cascade exact, puis similarité, puis LLM, est transposable à tout agent qui cite des chiffres, des références produit ou des identifiants. Le LLM-juge devient un dernier recours, pas le contrôle par défaut.
Mesurer la distribution avant d'optimiser. Le gain de 72 % vient d'un constat simple : 90 % des requêtes sont petites. Instrumentez la taille des contextes récupérés et la latence par chemin avant de choisir une architecture.
Traiter la latence de validation comme une file d'attente. Le ratio génération / validation est un indicateur à suivre dans votre observabilité, au même titre que la latence p95. Il dit si un nouvel évaluateur va dégrader l'expérience avant même le déploiement.
Corriger plutôt que rejeter. Un évaluateur qui bloque une réponse entière force une régénération complète. Un correcteur par évaluateur garde le flux et limite le coût.
Anticiper les quotas comme une ressource de capacité. Sur un fournisseur managé, la limite est souvent le quota avant la puissance de calcul. Un plan de capacité pour un agent en production doit inclure les quotas par modèle, par région et par compte.
Pour une équipe qui industrialise un assistant métier, la validation des sorties LLM en streaming est donc moins une brique d'IA qu'un problème de flux, de files et de budgets de latence, un terrain familier pour les équipes DevOps.
En bref
- NarrateAI valide chaque paragraphe pendant la génération : TTFC de 100,2 s à 13,2 s, pour 1,4 s de surcoût sur le premier paragraphe.
- 90 % des questions prennent le chemin rapide : environ 1,4 appel LLM par question, 72 % d'appels en moins.
- Une grille de quotas multi-modèles et multi-comptes a tenu plus de 100 utilisateurs simultanés sans échec.
- La vérification des chiffres en cascade maintient 99,3 % d'exactitude et coûte 54 % de moins qu'une vérification tout LLM.
- La validation des sorties LLM se pilote comme une file d'attente : gardez le ratio génération / validation sous 1.
Vous industrialisez vos agents IA ? SeedVision propose des audits IA en 3-5 jours et des forfaits de mise en production de 15 à 30 jours. Voir les packages ou réserver un appel de 30 min.
Photo de couverture : Photo by Stephen Dawson on Unsplash.