Métriques pour systèmes LLM

Pourquoi une seule métrique ne suffit jamais

Un système à base de LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire qui répond vite, avec des phrases bien construites et un ton assuré, donne une impression de fiabilité qui n'a souvent aucun rapport avec sa fiabilité réelle. C'est le piège central de l'évaluation de ces systèmes : la qualité perçue et la qualité mesurable divergent, et cette divergence ne se voit pas à l'œil nu pendant une démo.

Évaluer un système LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire correctement suppose de renoncer à l'idée d'un score unique. Trois axes doivent être mesurés séparément, parce qu'ils peuvent varier indépendamment les uns des autres : l'exactitude (le contenu produit est-il vrai ?), le groundedness (le contenu s'appuie-t-il réellement sur les sources fournies ?) et l'expérience utilisateur (le système aide-t-il concrètement à accomplir une tâche ?). Un système peut exceller sur l'un et échouer silencieusement sur un autre.

Un score d'exactitude élevé ne garantit rien sur le groundedness. Un modèle peut produire une réponse vraie par coïncidence, sans s'être appuyé sur les documents qu'on lui a fournis — ce qui la rend non reproductible et non auditable.

Trois axes indissociables

La figure ci-dessous illustre deux profils de systèmes fictifs. Le premier présente un score équilibré sur les trois axes. Le second affiche une exactitude et une UX élevées, mais un groundedness faible : concrètement, il répond juste assez souvent pour rassurer en démonstration, mais ses réponses ne découlent pas de manière vérifiable des documents sources qu'on lui a soumis. C'est le profil le plus dangereux à déployer, parce qu'il échoue précisément dans les cas où l'on ne peut pas vérifier a posteriori — les questions rares, les cas limites, les documents contradictoires.

Mesurer l'exactitude

L'exactitude répond à une question simple : la réponse produite est-elle factuellement correcte ? La simplicité de la question masque la difficulté de la mesure.

Exact match et mesures lexicales. Sur des tâches à réponse courte et déterministe (extraction d'une date, d'un nombre, d'un nom propre), on compare la sortie du modèle à une réponse de référence, parfois via des métriques de chevauchement lexical (ROUGE, BLEU) héritées de la traduction automatique. Ces mesures sont rapides à calculer mais fragiles : une reformulation correcte est pénalisée si elle ne partage pas les mots de la référence.

Correspondance sémantique. Pour dépasser cette fragilité, on utilise des embeddingsembeddingIAReprésentation numérique dense d'un texte, d'une image ou d'un objet dans un espace vectoriel, utilisée pour la similarité et la recherche sémantique.Voir dans le glossaire pour comparer le sens plutôt que la forme, ou un second modèle chargé de juger si deux réponses sont équivalentes sur le fond. Cela règle le problème de la reformulation, mais introduit une nouvelle source d'erreur : le juge lui-même peut se tromper.

Benchmarks de référence. Pour une évaluation comparative entre versions d'un même système ou entre fournisseurs, on s'appuie sur des jeux de questions-réponses annotés à l'avance, couvrant idéalement le périmètre réel d'usage — pas un benchmark académique générique sans rapport avec le domaine métier visé. Un benchmark de culture générale ne dit rien de la fiabilité d'un assistant juridique interne.

Un score élevé sur un benchmark public largement diffusé peut simplement signifier que ce benchmark (ou des variantes très proches) faisait partie des données d'entraînementdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire du modèle. Ce chiffre ne prédit alors rien sur la performance dans votre domaine spécifique.

Mesurer le groundedness

Le groundedness — l'ancrage factuel — mesure si une affirmation produite par le modèle découle effectivement des documents ou données qui lui ont été fournis, typiquement dans une architecture de type RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire (retrieval-augmented generation). C'est l'axe le plus souvent négligé, parce qu'il est invisible dans une réponse isolée : une phrase peut être vraie sans être ancrée, et fausse tout en semblant citer une source réelle.

Décomposition en affirmations atomiques. La méthode la plus fiable consiste à découper la réponse en affirmations unitaires (« le contrat a été signé le 12 mars », « la clause 4.2 prévoit une pénalité de 5 % »), puis à vérifier pour chacune si elle est explicitement soutenue par un passage identifiable du corpus source. Une affirmation non soutenue est comptée comme une hallucinationhallucinationIAProduction par un modèle d'un énoncé faux formulé avec la même assurance qu'un fait établi. Le phénomène est structurel : le modèle optimise la vraisemblance, pas la vérité.Voir dans le glossaire, même si elle se révèle vraie par ailleurs — le problème n'est pas qu'elle soit fausse, c'est qu'elle n'est pas vérifiable à partir de ce qui a été fourni au système.

Vérification des citations. Quand le système produit des références (numéros d'article, extraits, liens), on vérifie que la citation existe réellement dans le corpus et que le passage cité soutient effectivement l'affirmation associée — et pas seulement qu'il en partage le vocabulaire. Une citation qui pointe vers un document réel mais sans rapport avec l'affirmation est un faux positif classique.

Taux de rétractation utile. Un système bien conçu doit pouvoir dire « je ne sais pas » ou « cette information n'est pas dans les documents fournis » quand c'est le cas. Un taux de rétractation proche de zéro sur un corpus incomplet est un signal d'alerte : le modèle comble probablement les trous avec des inférences non ancrées plutôt que de les signaler.

Un assistant interne interrogé sur une clause absente du contrat téléversé répond avec assurance en citant un article inexistant. Le score d'exactitude apparent sur les questions courantes reste élevé — le problème ne se révèle que lors d'un audit ciblé sur les cas où l'information manque réellement dans le corpus.

Mesurer l'expérience utilisateur

L'exactitude et le groundedness mesurent la qualité du contenu. Ils ne disent rien sur ce qui se passe réellement lorsqu'une personne utilise le système pour accomplir une tâche.

Taux de complétion de tâche. Sur un parcours défini (résoudre un ticket support, rédiger un premier jet de contrat), on mesure la proportion d'interactions qui atteignent l'objectif sans intervention humaine corrective, et le nombre moyen d'échanges nécessaires. Une réponse individuellement correcte mais qui exige quatre reformulations pour obtenir l'information utile dégrade l'expérience, même si chaque réponse prise isolément « passerait » un test d'exactitude.

Taux d'abandon et de correction manuelle. Combien d'utilisateurs abandonnent la conversation avant d'obtenir une réponse satisfaisante ? Combien corrigent eux-mêmes la sortie du modèle avant de l'utiliser (dans un outil d'aide à la rédaction, par exemple) ? Ce taux de correction est un indicateur direct de confiance résiduelle : un utilisateur qui relit et corrige systématiquement n'accorde pas de crédit réel au système, même s'il continue à l'utiliser.

Latence perçue et cohérence de ton. Un temps de réponse trop long casse l'usage même si le contenu final est irréprochable. À l'inverse, un système qui répond instantanément mais avec un ton incohérent d'un tour à l'autre (formel puis familier, hésitant puis péremptoire) génère une méfiance diffuse difficile à quantifier mais mesurable via des enquêtes de satisfaction structurées.

Les enquêtes de satisfaction déclarative surestiment systématiquement la qualité perçue par rapport à la qualité réelle mesurée par audit. Les deux mesures sont complémentaires, jamais substituables l'une à l'autre.

LLM-as-judge : promesses et limites

Face au coût de l'évaluation humaine systématique, une pratique s'est généralisée : utiliser un second LLM comme juge pour noter les réponses du premier, selon une grille de critères explicite (exactitude, ton, complétude, présence de citations valides).

Cette approche permet de faire passer l'évaluation à l'échelle — des milliers de réponses évaluées en quelques heures plutôt qu'en semaines. Elle comporte cependant des biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire documentés et récurrents :

Ces biais ne rendent pas la méthode inutilisable — ils imposent des garde-fous : alterner l'ordre de présentation des réponses comparées, utiliser un modèle juge distinct de la famille du modèle évalué, et calibrer périodiquement le juge contre un échantillon annoté par des humains pour mesurer son propre taux d'erreur.

Un LLM-as-judgeLLM-as-judgeIAÉvaluation automatisée où un LLM note ou compare des sorties selon des critères définis, souvent en complément de métriques classiques.Voir dans le glossaire non calibré n'est pas un raccourci vers la vérité, c'est un second système dont il faut mesurer la fiabilité exactement comme celle du système évalué. Sans cette calibration périodique, on remplace un problème de confiance par un autre, invisible.

Construire un pipeline d'évaluation reproductible

Un pipeline d'évaluation utile pour piloter un déploiement combine plusieurs niveaux, du moins coûteux au plus coûteux :

1. Tests automatisés de régression — un jeu de cas fixes (une centaine à quelques milliers selon le périmètre) rejoué à chaque changement de promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire, de modèle ou de configuration de récupération documentaire, avec des seuils d'alerte définis à l'avance.
2. Évaluation LLM-as-judge en continu — sur un échantillon représentatif du trafic réel, avec rotation régulière des juges et calibration contre des annotations humaines.
3. Audit humain ciblé — sur les cas signalés comme incertains par le juge automatique, sur les cas où l'utilisateur a corrigé la réponse, et sur un échantillon aléatoire indépendant pour détecter les biais systématiques du pipeline lui-même.
4. Suivi des métriques d'usage réel — taux de complétion de tâche, taux d'abandon, taux de correction manuelle, mesurés en production et pas seulement en environnement de test.

La tentation courante consiste à s'arrêter au premier niveau, parce qu'il est le moins coûteux et donne l'impression d'une couverture suffisante. C'est une erreur : les tests de régression détectent les régressions sur des cas connus, ils ne détectent jamais les nouveaux modes de défaillance qui apparaissent avec un trafic réel et varié.

Pièges fréquents

• Confondre score de benchmark et fiabilité en production. Un benchmark mesure une distribution de questions qui ne recoupe que partiellement l'usage réel.
• Évaluer uniquement les cas faciles. Les cas qui font échouer un système sont, par construction, sous-représentés dans un échantillon aléatoire naïf — il faut les rechercher activement (questions ambiguës, informations absentes du corpus, requêtes contradictoires).
• Ignorer la dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire dans le temps. Un système évalué favorablement au lancement peut se dégrader si le corpus documentaire évolue, si le modèle sous-jacent est mis à jour silencieusement par le fournisseur, ou si les usages réels s'éloignent du périmètre testé initialement.
• Traiter l'UX comme secondaire. Un système exact et bien ancré mais pénible à utiliser sera contourné par les utilisateurs, qui reviendront à leurs méthodes précédentes — rendant tout l'effort d'évaluation de l'exactitude sans objet.

Checklist avant mise en production

• Les trois axes (exactitude, groundedness, UX) sont mesurés séparément, avec des seuils explicites pour chacun.
• Un jeu de cas de régression couvre les cas limites connus, pas seulement les cas faciles.
• Le taux de rétractation a été testé sur des questions dont la réponse est délibérément absente du corpus.
• Si un LLM-as-judge est utilisé, il a été calibré contre un échantillon annoté par des humains, avec un taux d'accord mesuré et documenté.
• Un audit humain ciblé est planifié en continu, pas seulement au lancement.
• Les métriques d'usage réel (complétion de tâche, correction manuelle, abandon) sont suivies en production, pas uniquement en environnement de test.
• Un plan de re-calibration est prévu en cas de mise à jour du modèle sous-jacent ou du corpus documentaire.

Cette discipline de mesure ne supprime pas le risque résiduel inhérent à ces systèmes. Elle permet de savoir où il se situe, à quelle fréquence il se manifeste, et donc de décider en connaissance de cause du périmètre d'usage acceptable — ce qui est précisément l'objectif d'une évaluation, plutôt que la recherche d'un score parfait qui n'existe pas.