Les 10 principaux indicateurs d’évaluation du LLM à comprendre avant la publication

Déployer un LLM sans stratégie d’évaluation adéquate est un pari risqué que la plupart des équipes ignorent. Aujourd’hui, 67 % des organisations dans le monde utilisent des LLM en production, mais la majorité s’appuie encore sur des indicateurs d’évaluation conçus pour la traduction automatique de 2018 ou néglige complètement l’évaluation structurée. Le résultat est prévisible : des dysfonctionnements qui font la une des journaux, des chatbots qui donnent des conseils illégaux et des mises à jour de modèles qui provoquent des dysfonctionnements silencieux, imperceptibles jusqu’à ce que les utilisateurs commencent à les quitter.

Cet article présente les indicateurs d’évaluation LLM qui comptent vraiment. Nous aborderons ce que chaque indicateur mesure, quand l’utiliser, le score à viser et les détails souvent négligés par les équipes. Si vous envisagez de recruter une équipe d’assurance qualité dédiée ou de faire appel à d’autres services de test pour évaluer vos outils basés sur LLM, ces informations vous seront indispensables.

Les 10 principaux indicateurs d’évaluation du LLM qui comptent vraiment

Avant d’entrer dans le vif du sujet, voici un point important à savoir : les indicateurs pertinents pour l’évaluation des LLM dépendent du contexte dans lequel des trois éléments suivants vous vous trouvez :

• Évaluation du modèle de base
  Choisir ou optimiser un LLM et évaluer les capacités brutes.
• Évaluation du pipeline RAG
  Combiner un LLM avec un système de recherche et évaluer la chaîne complète, et pas seulement le modèle.
• Évaluation de l’agent
  Un LLM effectue des actions, utilise des outils et prend des décisions en plusieurs étapes, ce qui nécessite des indicateurs d’évaluation spécifiques pour les agents LLM que la plupart des benchmarks LLM standard ne couvrent pas.

Gardez le contexte à l’esprit lors de votre lecture. Les indicateurs ci-dessous s’appliquent aux trois, et le tableau récapitulatif indique lesquels sont pertinents et dans quel contexte.

Fidélité

La fidélité se mesure à la cohérence entre les résultats du modèle et les documents sources qui lui ont été fournis. Si votre étudiant en droit répond à une question en se basant sur des documents extraits, une réponse fidèle ne doit contenir que des affirmations directement étayées par ces documents. Toute affirmation allant au-delà de la source est une hallucination.

Cette métrique d’évaluation est essentielle pour la mise en œuvre des bonnes pratiques RAG et la construction d’un pipeline. Elle est incontournable si votre produit répond à des questions basées sur des documents internes, des bases de connaissances ou des données externes. L’objectif est d’obtenir un score supérieur à 0,8 sur une échelle normalisée de 0 à 1, tel que mesuré par des frameworks comme Ragas ou DeepEval. Un score inférieur à 0,7 indique probablement un problème de détection d’hallucinations LLM à grande échelle.

Il est important de noter que la fidélité indique seulement si le modèle est resté dans la source. Elle ne vous dit pas si la source elle-même était la bonne à récupérer. Il s’agit d’un problème distinct, traité par la précision et le rappel du contexte.

Pertinence de la réponse

Le critère de pertinence des réponses est essentiel pour les chatbots de support client, les outils de questions-réponses internes, les assistants de documentation et toute interface où les utilisateurs posent des questions directes et attendent des réponses directes. Il mesure si la réponse répond réellement à la question de l’utilisateur. Un modèle peut être parfaitement fidèle à son texte source et pourtant fournir une réponse hors sujet ou qui répond à une question différente de celle posée. Lors de l’évaluation, visez un score supérieur ou égal à 1, car un score inférieur à 0,75 indique généralement que le modèle paraphrase le contexte plutôt que de répondre à l’utilisateur.

Il est essentiel de tenir compte du fait que la pertinence des réponses est sensible à la conception des consignes. Par conséquent, des consignes mal structurées peuvent entraîner une chute brutale des scores de pertinence, même si le modèle lui-même est performant. Il est donc primordial de vérifier les consignes avant d’incriminer le modèle.

Précision et rappel du contexte

Ce sont les deux faces d’une même pièce dans les métriques d’évaluation LLM, et elles se situent au niveau de la couche de récupération de votre pipeline RAG, et non au niveau de la couche de génération.

• La précision contextuelle indique dans quelle mesure les informations extraites étaient réellement utiles pour répondre à la question. Une précision élevée signifie que le système n’intègre pas de données parasites.
• Le rappel contextuel indique dans quelle mesure les informations nécessaires pour répondre à la question étaient présentes dans les extraits récupérés. Si le niveau de rappel est élevé, cela signifie que le système de récupération ne manque pas d’informations essentielles.

Il est important de prendre en compte ces indicateurs d’évaluation LLM lors du débogage d’un système RAG présentant de faibles scores de fidélité ou de pertinence. Souvent, le modèle est correct et le problème se situe en amont, au niveau du moteur de recherche.

De nombreuses équipes se contentent d’évaluer la qualité des données générées par LLM et négligent le fait que 60 à 70 % des échecs d’évaluation RAG proviennent de la récupération des données, et non de leur génération. Si vous ignorez ces deux indicateurs pour l’évaluation de LLM, vous travaillez à l’aveugle sur la moitié de votre infrastructure.

Taux d’hallucinations

Il s’agit d’une des principales métriques d’évaluation des modèles de langage (LLM) qui mesure le pourcentage de résultats contenant des affirmations factuellement incorrectes. Contrairement à la fidélité, qui compare le résultat à un contexte de référence, le taux d’erreurs mesure l’exactitude factuelle par rapport à la vérité de terrain, ce qui le rend plus difficile à automatiser mais plus pertinent pour les cas d’utilisation à forts enjeux.

Il s’agit d’un critère d’évaluation crucial pour le développement de solutions d’IA dans les domaines juridique, médical, financier ou de la conformité, où une erreur factuelle peut avoir de réelles conséquences. De plus, il est essentiel pour tout produit où les utilisateurs sont susceptibles d’agir sur la base des résultats du modèle sans les vérifier.

Pour la plupart des indicateurs d’évaluation des LLM en production, visez un taux d’hallucinations inférieur à 5 %. Dans les secteurs à forts enjeux, ce seuil devrait être plus proche de 1 %.

Il convient de noter que la détection des hallucinations par les LLM est coûteuse à mesurer à grande échelle, car elle nécessite souvent une vérification humaine ou l’intervention d’un second LLM. Il est donc essentiel de prévoir un budget à cet effet avant d’en faire un indicateur clé.

BLEU and ROUGE

Certaines métriques de performance des modèles linéaires à longue portée (LLM) basées sur une référence comparent la sortie d’un modèle à une réponse correcte connue. Ce sont :

• BLEU (Étudiant en évaluation bilingue)
  Il mesure le chevauchement des n-grammes entre le texte généré et le texte de référence, en privilégiant la précision. Il a été initialement conçu pour la traduction automatique.
• ROUGE (Sous-étudiant axé sur la mémorisation pour l’évaluation globale)
  Elle se concentre sur la mémorisation et est couramment utilisée pour évaluer la qualité du résumé.

Il est nécessaire d’utiliser ces indicateurs lors de la conception de chaînes de traduction, de tâches de résumé structuré et d’outils de génération de documents, lorsque le résultat attendu est défini. Le score à viser dépend fortement du domaine. Un score BLEU supérieur à 0,4 est généralement acceptable pour la traduction. Par ailleurs, un score ROUGE-L supérieur à 0,5 constitue un seuil raisonnable pour le résumé.

Toutefois, il ne faut jamais utiliser BLEU ou ROUGE comme indicateurs uniques pour l’évaluation des modèles de raisonnement logique dans les applications ouvertes. Une étude publiée en 2024 a confirmé que ces deux indicateurs prédisent mal les performances réelles des modèles de raisonnement logique pour les tâches conversationnelles ou de raisonnement. Ils pénalisent les paraphrases valides et ne tiennent pas compte de l’équivalence sémantique. Ils peuvent être utiles, mais ne doivent pas constituer votre principal critère d’évaluation.

Perplexité

Cette métrique d’évaluation LLM est indépendante de Perplexity AI. Elle mesure la fiabilité avec laquelle le modèle prédit le jeton suivant dans une séquence. Plus la perplexité est faible, plus le modèle est sûr de ses résultats. Elle constitue un indicateur de la fluidité et de la cohérence au niveau de la modélisation du langage.

Il est nécessaire d’évaluer la perplexité du modèle lors de l’évaluation initiale et de l’ajustement fin. Cela permet de comparer différentes versions du modèle ou de mesurer l’impact d’une session d’entraînement sur la fluidité de la sortie.

Toutefois, n’oubliez pas que la perplexité ne vous renseigne en rien sur l’exactitude des faits, la pertinence ou l’achèvement de la tâche. Un modèle peut présenter une perplexité très faible et produire malgré tout des résultats absurdes. Par conséquent, il convient de l’utiliser comme un signal d’aide à la décision lors du développement du modèle, et non comme un critère de qualité déterminant pour la production.

Score de toxicité et de biais

Le score de toxicité mesure la fréquence à laquelle un modèle produit un contenu nuisible, offensant ou discriminatoire. Cet indicateur d’évaluation permet de signaler les résultats contenant des propos injurieux, des menaces ou du contenu explicite. Parallèlement, les scores de biais révèlent les schémas dans lesquels le modèle traite systématiquement certains groupes différemment, par exemple en donnant de meilleures réponses aux questions formulées autour d’un groupe démographique plutôt qu’à un autre.

Vous devez implémenter ces indicateurs d’évaluation LLM pour chaque déploiement destiné aux clients, sans exception. Au-delà de l’expérience utilisateur, la réglementation européenne sur l’IA, en vigueur depuis 2024, exige que les systèmes d’IA à haut risque démontrent avoir fait l’objet de tests de précision et de sécurité portant sur des caractéristiques protégées. Il s’agit désormais d’une obligation de conformité, et non plus d’un contrôle qualité facultatif.

Pour évaluer cela dans votre produit, vous pouvez utiliser l’API Perspective de Google (pour la toxicité) et des ensembles d’évaluation LLM personnalisés et adaptés à votre domaine. Cependant, gardez à l’esprit que les classificateurs de toxicité génériques passent souvent à côté de préjudices subtils et contextuels. Un générateur de documents juridiques pourrait produire un contenu qui passe les filtres de toxicité standard, mais qui expose néanmoins votre organisation à des poursuites. Les ensembles d’évaluation spécifiques au domaine sont essentiels dans ce cas ; assurez-vous donc d’en tenir compte dans un plan de tests d’IA personnalisé.

Taux d’achèvement des tâches

Le taux d’achèvement des tâches permet de déterminer si le LLM atteint effectivement l’objectif qui lui a été assigné. Il s’agit de la métrique d’évaluation la plus importante pour un agent LLM, et celle que la plupart des équipes mesurent en dernier, voire pas du tout. Pour un système d’agents, le taux d’achèvement des tâches répond à la question suivante : l’agent a-t-il terminé sa tâche ? Il ne s’agit pas de savoir s’il a produit une réponse, mais s’il a atteint l’objectif, utilisé les outils appropriés et abouti à un résultat valide.

Tout système où le LLM effectue des actions plutôt que de simplement générer du texte doit être évalué selon ce paramètre. Les systèmes de réservation, les agents de génération de code, l’automatisation des flux de travail et les pipelines d’analyse de données sont quelques exemples typiques où un taux d’achèvement élevé des tâches est indispensable. En fonction de la complexité de la tâche, visez un taux supérieur à 90 % pour les tâches simples en une seule étape. Pour les flux de travail automatisés en plusieurs étapes, un taux de 70 % est généralement considéré comme satisfaisant, et tout résultat inférieur à 50 % indique que l’agent nécessite des retouches avant sa mise en production.

Il est important de noter que le taux d’achèvement des tâches est quasiment impossible à mesurer sans un cadre d’évaluation LLM approprié. Par conséquent, il est indispensable de définir des critères de réussite pour chaque type de tâche avant de commencer les mesures. Si votre équipe n’a pas encore rédigé ces critères, il convient d’y remédier en priorité.

Compromis entre latence et qualité

Ce critère d’évaluation des modèles de langage (LLM) est quelque peu différent. Il ne s’agit pas d’un critère unique, mais d’une relation entre deux éléments : le temps de réponse du modèle et la qualité de sa réponse. En production, ces deux dimensions sont constamment en tension. Un modèle plus lent, mais plus performant, peut produire de meilleurs résultats, mais risque de frustrer les utilisateurs qui attendent des réponses en moins de deux secondes.

Chaque déploiement en production doit définir des seuils de latence acceptables, en plus des seuils de qualité. Savoir évaluer les performances d’un modèle LLM de manière isolée ne permet pas de déterminer si ce modèle est réellement prêt à être déployé.

Éléments à suivre :

• Délai d’obtention du premier jeton (pour les interfaces de streaming)
• Latence de réponse totale (pour le traitement par lots ou hors flux continu)
• Score de qualité à chaque intervalle de latence

Les équipes optimisent souvent la qualité pendant le développement et découvrent les problèmes de latence lors des tests de performance. Si vous utilisez des tests de performance dans votre processus d’assurance qualité, assurez-vous que la latence LLM soit prise en compte dès le départ dans le plan de test, et non ajoutée a posteriori.

Évaluation LLM-as-a-Juge (G-Eval)

Dans ce cas, un modèle de langage secondaire est utilisé pour évaluer les résultats d’un modèle d’IA par rapport à un ensemble de critères de traitement du langage naturel. G-Eval, introduit par Liu et al. (2023), est l’une des implémentations les plus répandues de l’approche d’évaluation utilisant un modèle de langage comme juge. Au lieu de s’appuyer sur le chevauchement des n-grammes ou sur des vérifications basées sur des règles, un modèle juge analyse le résultat et l’évalue selon des dimensions telles que la cohérence, la pertinence et l’achèvement de la tâche.

Vous devez tenir compte de cette métrique d’évaluation LLM avec les tâches ouvertes où il n’y a pas de réponse unique correcte, la génération de formes longues, les tâches de raisonnement et tous les cas où vous avez besoin d’un signal de qualité évolutif de type humain sans payer pour des annotateurs humains à chaque évaluation.

L’avantage de l’évaluation par un système de notation automatisée (LLM) réside dans le contrôle des critères d’évaluation. Il est donc essentiel de les définir clairement avant de lancer les évaluations. Toutefois, il convient de ne pas oublier que les systèmes de notation automatisés peuvent présenter des biais. Ils ont tendance à privilégier les réponses plus longues, les textes plus assurés et les résultats qui reflètent leur propre distribution d’entraînement. Pour atténuer ce biais, il est possible d’utiliser un modèle différent de celui évalué, de faire appel à plusieurs systèmes de notation automatisés et de calculer la moyenne des scores, ou encore de calibrer le système de notation automatisée à l’aide d’annotations humaines sur un échantillon.

Comment choisir les indicateurs appropriés à votre cas d’utilisation

Toutes les métriques ne s’appliquent pas à tous les produits. Cependant, une règle demeure : il est toujours préférable de combiner au moins une métrique de référence avec une métrique indépendante et une métrique spécifique à la tâche. Une seule métrique est insuffisante, et en utiliser plus de cinq sans objectif précis est contre-productif.

Indicateurs clés du retour sur investissement d’une plateforme d’évaluation de LLM

Mettre en place un processus d’évaluation des LLM représente un investissement initial en temps et en argent, mais ne pas en mettre en place coûte encore plus cher. Voici comment présenter l’argumentaire en faveur du retour sur investissement :

• Coût d’un incident de falsification de chatbot : l’affaire d’hallucination du chatbot d’Air Canada a abouti à une décision de justice obligeant la compagnie aérienne à honorer un prix que le bot n’aurait jamais dû proposer. Les coûts juridiques et d’atteinte à la réputation liés à cet incident ont largement dépassé tout investissement dans une infrastructure d’évaluation LLM.
• Coût d’une mauvaise sélection de modèle : Seuls 5 % des programmes d’IA générale permettent une accélération rapide des revenus. L’une des causes d’échec les plus fréquentes est la sélection ou l’optimisation d’un modèle par les équipes sans processus d’évaluation structuré des modèles de langage (LLM) pour mesurer la qualité des résultats et vérifier leur adéquation à leur cas d’usage.
• Coût de l’absence de tests de régression : chaque mise à jour d’un modèle introduit un risque de régression. Sans suivi des indicateurs d’évaluation LLM dans le temps, vous ne disposez d’aucun système d’alerte précoce. Par conséquent, l’intégration des tests de régression à votre processus d’assurance qualité est indispensable.

Les équipes qui mettent en œuvre des pipelines d’évaluation LLM structurés constatent systématiquement des taux de détection de défauts plus faibles et des cycles d’itération plus rapides, car elles peuvent mettre à jour leurs modèles en toute sécurité, sans craindre de régressions silencieuses. Les services de test d’IA de QAwerk sont conçus précisément selon cette approche. Contactez-nous dès aujourd’hui et élaborons ensemble un plan adapté à vos objectifs commerciaux.