Vous avez livré une fonctionnalité basée sur LLM il y a six mois. Il a été testé bien avant le lancement. Les utilisateurs semblaient satisfaits au début. Mais dernièrement, les tickets d’assistance concernant la qualité de l’IA se multiplient. Le fournisseur de modèles a publié le mois dernier une mise à jour que vous n'avez pas vraiment évaluée. Votre ensemble de données d'évaluation n'a pas été actualisé depuis le lancement. Et l'équipe qui a créé cette fonctionnalité est passée à d'autres projets, ne s'enregistrant que lorsque quelque chose se brise suffisamment pour exiger une attention particulière.
Il s'agit de la trajectoire par défaut pour les fonctionnalités LLM sans évaluation continue. Le modèle change, les données changent, les attentes des utilisateurs changent et personne ne remarque une dégradation de la qualité jusqu'à ce que cela devienne un réel problème.
Les rétrospectives d'évaluation LLM sont la pratique qui empêche cette lente dégradation. Il ne s’agit pas d’une phase de test ponctuelle avant le lancement, mais d’une habitude récurrente de mesurer la qualité, de comprendre les échecs et de s’améliorer systématiquement.
Pourquoi l'évaluation LLM est fondamentalement différente
Si vous venez du développement de logiciels traditionnel, votre instinct en matière de tests vous induira en erreur avec LLMs. Voici pourquoi :
Les sorties sont non déterministes. La même entrée peut produire des sorties différentes à chaque fois. Cela signifie que vous ne pouvez pas tester avec de simples assertions « la sortie attendue est égale à la sortie réelle ». Vous devez évaluer la qualité de sortie sur un spectre, et non avec une réussite/échec binaire.
L'exactitude est subjective. Pour de nombreuses tâches LLM, il n'y a pas de bonne réponse unique. Un bon résumé, une réponse utile du service client, un e-mail bien rédigé : tout cela implique des jugements sur lesquels des personnes raisonnables ne sont pas d'accord. Votre cadre d’évaluation doit gérer explicitement cette subjectivité.
La qualité se dégrade silencieusement. Les logiciels traditionnels tombent en panne bruyamment : erreurs, plantages, tests échoués. La qualité du LLM se dégrade progressivement : sorties légèrement moins précises, tonalité subtilement différente, réponses légèrement moins pertinentes. Au moment où quelqu'un le remarque, la qualité peut avoir diminué depuis des semaines.
Le modèle change sous vous. Si vous utilisez un modèle basé sur une API (ce que sont la plupart des équipes), le fournisseur de modèles peut mettre à jour le modèle à tout moment. Ces mises à jour améliorent généralement les choses dans leur ensemble, mais elles peuvent modifier le comportement de votre cas d'utilisation spécifique d'une manière inattendue.
Ces différences signifient que vous avez besoin d'une pratique d'évaluation continue, et non d'une approche de test puis d'expédition.
Que mesurer
Vous n'avez pas besoin de tout mesurer. Vous devez mesurer les éléments importants pour votre cas d'utilisation spécifique et les mesurer de manière suffisamment cohérente pour détecter les tendances. Voici un cadre pratique.
Précision et fidélité
Le modèle produit-il des informations correctes ? Cette dimension est particulièrement importante pour les tâches factuelles : réponse aux questions, synthèse, extraction de données, analyse.
Comment évaluer : Prenez un échantillon des sorties de production récentes. Demandez à un évaluateur humain de vérifier chacun d'entre eux à la recherche d'erreurs factuelles, d'hallucinations (informations non étayées par le contexte fourni) et d'omissions (informations importantes disponibles mais non incluses).
Que suivre : Le taux d'erreurs factuelles par échantillon et si ce taux a une tendance à la hausse ou à la baisse. Suivez également la gravité des erreurs : un nom mal orthographié est moins préoccupant qu’un chiffre financier incorrect.
Instructions suivantes
Le modèle fait-il ce que vous lui avez demandé ? Cela couvre la conformité du format, le respect des contraintes et l’achèvement des tâches.
Comment évaluer : Définir des critères clairs pour ce à quoi ressemble une exécution « correcte » de la tâche. Le résultat correspond-il au format demandé ? Est-ce que ça respecte les contraintes de longueur ? Reste-t-il dans le périmètre défini ? Ceux-ci sont plus objectivement mesurables que les jugements de qualité.
Que suivre : Le pourcentage de sorties qui suivent toutes les instructions. Catégorisez les violations : s'agit-il de problèmes de format, de violations de contraintes ou de dérives de portée ? Chacun pointe vers un correctif différent.
Qualité perçue par l'utilisateur
Les utilisateurs trouvent-ils les résultats utiles, bien rédigés et utiles ? C’est la dimension la plus difficile à mesurer mais sans doute la plus importante.
Comment évaluer : Deux approches fonctionnent bien. Tout d'abord, les signaux intégrés au produit : pouce vers le haut/vers le bas, évaluations explicites, questions de suivi (si l'utilisateur demande un suivi, la première réponse n'a peut-être pas été complète). Deuxièmement, une évaluation humaine périodique : prenez un échantillon et évaluez-le selon une rubrique qui définit ce que « bon » signifie pour votre fonctionnalité.
Que suivre : Tendances globales de la satisfaction et dimensions de qualité spécifiques sur lesquelles les utilisateurs expriment leur insatisfaction.
Sécurité et alignement
Le modèle produit-il des résultats nuisibles, biaisés ou inappropriés ? Cette dimension est un enjeu de table : les échecs ici ont un impact démesuré.
Comment évaluer : Exécutez régulièrement votre suite de tests de sécurité (pas seulement au lancement). Incluez les tests contradictoires : entrées conçues pour provoquer des sorties nuisibles. Examinez toutes les sorties signalées par votre couche de modération de contenu.
Que suivre : Le taux de violations de sécurité, y compris les quasi-accidents détectés par les filtres. Suivez les résultats des tests contradictoires lors des mises à jour de modèles : un modèle qui était sûr avant une mise à jour pourrait ne pas l'être après.
La rétrospective d’évaluation
Cadence
Le mensuel fonctionne bien pour la plupart des équipes. Plus fréquemment si vous travaillez dans un domaine à enjeux élevés (santé, finance, droit) ou si vous parcourez rapidement les invites. Moins fréquemment si votre fonctionnalité est stable et à faible risque, mais jamais moins d'une fois par trimestre.
Préparation
La qualité de la rétrospective dépend des données que vous y apportez. Un membre de l'équipe (en alternant ce rôle) doit préparer :
Tableau de bord métrique. Vos indicateurs de qualité clés pour la période en cours, par rapport à la période précédente. Gardez cela concentré : 4 à 6 métriques maximum, directement liées aux dimensions ci-dessus.
Résultats des exemples d'évaluation. Exécutez votre suite d'évaluation et apportez les résultats. Si vous effectuez une évaluation humaine, faites-la avant la réunion, pas pendant celle-ci.
Exemples d'échecs. Les 5 à 10 pires résultats de la période. Incluez le contexte complet : entrée, invite, sortie et pourquoi c'est mauvais. C’est dans ces exemples concrets que se déroulent les discussions les plus productives.
Changelog. Toute modification susceptible d'avoir affecté la qualité : mises à jour d'invites, modifications de version du modèle, mises à jour de données, modifications de fonctionnalités, changements dans les modèles d'utilisation.
Structure de la réunion (60 minutes)
Examen des métriques (10 minutes). Sommes-nous en amélioration, en déclin ou à plat sur chaque dimension ? Des mesures qui ont franchi un seuil qui nous intéresse ? Des changements inattendus que nous ne pouvons pas expliquer ?
Analyse approfondie des échecs (25 minutes). Parcourez les exemples d'échecs. Pour chacun d’entre eux, l’équipe doit discuter :
- Qu'est-ce qui n'a pas fonctionné spécifiquement ?
- S'agit-il d'un nouveau mode de défaillance ou d'un mode que nous avons déjà vu ?
- Quelle est la cause première : invite, modèle, données ou autre ?
- Comment pourrions-nous détecter cela automatiquement à l’avenir ?
Le but n’est pas de réparer tous les échecs de la réunion. Il s’agit de comprendre les modèles et d’établir des priorités.
Revue du processus d'évaluation (10 minutes). Notre évaluation mesure-t-elle réellement les bonnes choses ? Y a-t-il des modes de défaillance que nous ne détectons pas ? Devons-nous mettre à jour nos cas de test ? Nos critères d’évaluation sont-ils toujours alignés sur ce qui intéresse les utilisateurs ?
Cette méta-revue est importante. Les processus d’évaluation peuvent devenir obsolètes, comme toute autre chose. Si vos cas de test datent tous d'il y a six mois et que les besoins de vos utilisateurs ont changé, votre évaluation vous donne un faux sentiment de sécurité.
Éléments d'action (15 minutes). Choisissez 2-3 améliorations spécifiques. Ceux-ci se répartissent généralement en catégories :
- Modifications rapides pour répondre à des modèles de défaillance spécifiques
- Améliorations de l'évaluation (nouveaux cas de test, rubriques mises à jour, meilleure automatisation)
- Mises à jour de garde-corps (nouveaux filtres de sécurité, contrôles post-traitement supplémentaires)
- Tâches d'enquête (couvrir un changement de qualité inexpliqué, profiler un mode de défaillance spécifique)
Construire votre pile d'évaluation
Vous n'avez pas besoin d'outils coûteux pour démarrer. Voici une progression pratique.
Phase 1 : Évaluation manuelle (commencez ici)
Chaque semaine, échantillonnez 20 à 30 résultats de production. Demandez à deux membres de l’équipe d’évaluer chacun indépendamment sur votre rubrique de qualité. Comparez leurs notes : s’ils sont fréquemment en désaccord, votre rubrique doit être plus spécifique. Suivez ces notes dans une feuille de calcul.
C'est peu glamour mais efficace. Vous en apprendrez davantage sur le comportement de votre modèle en lisant 30 sorties réelles qu'en lisant n'importe quelle métrique automatisée.
Phase 2 : Évaluation semi-automatique
Créez un ensemble de données d'évaluation : 100 à 200 exemples avec des entrées, des caractéristiques de sortie attendues (pas nécessairement des sorties exactes) et des annotations de qualité. Exécutez-le automatiquement chaque fois que vous modifiez les invites ou les modèles. Utilisez les résultats pour détecter les régressions avant qu’elles n’atteignent la production.
Ajoutez l'évaluation LLM en tant que juge pour les dimensions où elle fonctionne bien : conformité du format, suivi des instructions, vérification factuelle de base. Utilisez l’évaluation humaine pour les dimensions là où ce n’est pas le cas : nuance, utilité, pertinence du ton.
Phase 3 : Surveillance continue
Mettre en place des contrôles de qualité automatisés sur le trafic de production. Ceux-ci n'ont pas besoin de tout détecter : ils doivent en capturer suffisamment pour vous alerter lorsque la qualité change de manière significative. Une approche simple : échantillonnez aléatoirement un petit pourcentage de requêtes de production, exécutez des contrôles automatisés et alertez si le taux d'échec dépasse un seuil.
Cela complète plutôt que remplace votre évaluation humaine. La surveillance automatisée détecte rapidement les changements soudains. L'évaluation humaine détecte une dérive de qualité subtile que les métriques automatisées oublient.
Erreurs d'évaluation courantes
Évaluer uniquement sur des exemples simples. Si votre ensemble de données d'évaluation n'inclut pas de cas difficiles, vous mesurez les performances dans le meilleur des cas, et non les performances du monde réel. Incluez les entrées contradictoires, les requêtes ambiguës, le contenu spécifique au domaine et les types d'entrées désordonnées envoyées par vos utilisateurs réels.
Utiliser des métriques automatisées comme seule mesure. Les métriques automatisées (BLEU, ROUGE, BERTScore) sont utiles pour suivre les tendances mais sont mal corrélées aux jugements de qualité humains pour de nombreuses tâches. Si vos mesures automatisées indiquent que la qualité est bonne mais que les utilisateurs se plaignent, faites confiance aux utilisateurs.
Comparaison de modèles sur différents ensembles d'évaluation. Si vous envisagez de changer de modèle, utilisez exactement le même ensemble d'évaluation pour les deux. Si vous testez le modèle A sur un ensemble d’exemples et le modèle B sur un ensemble différent, la comparaison n’a aucun sens.
Ne suit pas l'accord entre les évaluateurs. Si vos évaluateurs humains sont en désaccord sur 40 % des notes, vos données d'évaluation sont bruitées. Soit améliorez votre rubrique, proposez plus de formation, soit acceptez que la tâche est intrinsèquement subjective et concevez vos mesures en conséquence.
Évaluer trop rarement. Une évaluation mensuelle avec des changements de modèle hebdomadaires signifie que vous consultez toujours des données obsolètes. Faites correspondre votre cadence d’évaluation à votre cadence de changement.
Intégrer l’évaluation à la culture
La partie la plus difficile de l’évaluation LLM n’est pas la méthodologie, mais le maintien de la pratique. L'évaluation semble être une surcharge, surtout lorsque les choses se passent bien. La tentation de sauter « juste ce mois-ci » est réelle.
Ce qui aide : rendre visibles les résultats de l’évaluation. Partagez-les dans les canaux d’équipe. Célébrez les améliorations de la qualité. Traitez les régressions de qualité comme des incidents qui méritent une enquête. Lorsque l’évaluation révèle un problème avant que les utilisateurs ne le remarquent, rendez-le également visible : cela justifie l’investissement continu.
Au fil du temps, les équipes dotées d’une solide pratique d’évaluation développent de meilleures intuitions sur leurs modèles. Ils anticipent les modes de défaillance. Ils apportent des changements rapides avec plus de confiance. Ils détectent les problèmes plus rapidement lorsqu’ils surviennent. La rétrospective est le mécanisme qui construit cette connaissance institutionnelle.
Essayez NextRetro gratuitement — Structurez votre rétrospective d'évaluation avec des phases d'examen des métriques, d'analyse des échecs et de planification des améliorations.
Dernière mise à jour : février 2026
Temps de lecture : 8 minutes
