L'évolution de l'évaluation NLP : du score BLEU aux métriques LLM-as-a-Judge

Imaginez que vous demandiez à un ami de traduire une phrase et qu'il utilise des mots parfaitement synonymes, mais pas exactement ceux de votre dictionnaire. Un outil de correction classique lui donnerait zéro, alors qu'un humain dirait : « C'est parfait ». C'est exactement le problème que le traitement du langage naturel (NLP) a traîné pendant vingt ans. On a essayé de mesurer l'intelligence des machines avec des règles de comptage rigides, alors que le langage est, par nature, fluide et nuancé.

Pendant deux décennies, le BLEU (Bilingual Evaluation Understudy) a été le roi incontesté. Apparu en 2002, ce score a été conçu pour la traduction automatique. Son principe est simple : on compare les mots du texte généré par l'IA avec ceux d'un texte de référence écrit par un humain. Si les mots et les séquences de mots (les n-grammes) correspondent, le score monte. C'est rapide, c'est mathématique, et c'est détermiste. Mais voilà, le évaluation NLP s'est heurtée à un mur avec l'arrivée des grands modèles de langage (LLM).

Le problème du « biais de vocabulaire » et l'échec des métriques lexicales

Le problème majeur de BLEU, et même de son cousin ROUGE (Recall-Oriented Understudy for Gisting Evaluation, souvent utilisé pour les résumés), c'est qu'ils ne comprennent absolument rien au sens. Ils ne font que comparer des chaînes de caractères. Si une IA répond « Le félin dort » alors que la référence est « Le chat sommeille », BLEU peut donner un score très bas alors que le sens est identique.

Cette rigidité crée ce que les chercheurs appellent un « biais de vocabulaire ». On a ainsi vu des modèles être optimisés pour mémoriser des motifs de mots précis plutôt que pour comprendre la tâche. Une étude de Koehn en 2004 avait déjà montré qu'on pouvait gonfler un score BLEU de 15 à 20 points simplement en choisissant les bons mots de vocabulaire, sans pour autant améliorer la qualité réelle de la réponse. En bref, on punissait la créativité et la paraphrase, précisément les capacités que nous voulons aujourd'hui chez un LLM.

L'arrivée des métriques sémantiques et neuronales

Pour sortir de cette impasse, la communauté a développé des approches basées sur des vecteurs et des embeddings. L'idée n'est plus de regarder si les mots sont identiques, mais s'ils sont « proches » dans un espace mathématique.

Le BERTScore est un excellent exemple. Il utilise la puissance de BERT pour comparer les représentations contextuelles des mots. Si vous utilisez un synonyme, BERTScore le reconnaît car il sait que ces deux mots occupent une place similaire dans le langage. Dans la même veine, BLEURT a été entraîné spécifiquement pour prédire les jugements humains, offrant une corrélation bien plus forte avec ce que nous, humains, considérons comme une "bonne" réponse.

LLM-as-a-Judge : Quand l'IA évalue l'IA

Le changement le plus radical est l'émergence du concept de LLM-as-a-Judge. Au lieu d'utiliser une formule mathématique, on demande à un modèle très performant (comme GPT-4o ou LLaMA 3.1) de noter la réponse d'un autre modèle en suivant une grille de critères précis : exactitude, clarté, ton et respect des consignes.

C'est une approche beaucoup plus flexible. On peut utiliser trois méthodes différentes selon nos besoins :

• L'évaluation pointwise : Le juge attribue une note numérique (ex: 8/10).
• L'évaluation pairwise : On présente deux réponses au juge, et il doit dire laquelle est la meilleure. C'est souvent la méthode la plus fiable car elle élimine la subjectivité des notes.
• L'évaluation Pass/Fail : Le juge répond simplement par Oui ou Non à une question de conformité.

Ce qui est fascinant, c'est que la qualité du juge dépend moins du modèle choisi que de la conception du prompt d'évaluation. Une étude de 2026 a prouvé que des critères de notation bien définis et des réponses de référence de haute qualité impactent plus la précision que le passage d'un modèle à un autre. Pour mesurer si ce juge est fiable, on utilise généralement le coefficient de corrélation de Spearman pour voir si ses notes suivent la même courbe que celles des humains.

Comment choisir sa stratégie d'évaluation aujourd'hui ?

S'il est tentant de tout confier à un LLM-juge, ce n'est pas toujours la solution idéale. Le coût des API et la latence peuvent devenir prohibitifs pour des milliers de tests. L'approche recommandée par des experts (comme chez Galileo AI ou Weights & Biases) est une stratégie en couches.

D'abord, utilisez BLEU ou ROUGE pour des « tests de fumée ». Si le score s'effondre, c'est qu'il y a un bug majeur de régression. Ensuite, passez au BERTScore pour vérifier que le sens global est préservé. Enfin, utilisez le LLM-as-a-Judge pour les décisions critiques : est-ce que la réponse est factuellement correcte ? Est-elle sécurisée ? Est-elle utile pour l'utilisateur final ?

Pour ceux qui déploient des systèmes de RAG (Retrieval-Augmented Generation), les métriques génériques ne suffisent plus. Il faut mesurer la pertinence du document récupéré, la fidélité de la réponse par rapport à la source (grounding) et la précision de la récupération. C'est ici que l'évaluation devient une science de la précision plutôt qu'une simple comparaison de textes.

Vers une spécialisation des métriques par tâche

Nous sortons enfin de l'ère du « score unique ». On réalise que pour évaluer du code, un score BLEU est inutile ; on a besoin de tests d'exécution pour savoir si le code tourne. Pour un chatbot de support client, on privilégiera la résolution du problème plutôt que la ressemblance avec un script.

L'avenir se tourne vers des benchmarks holistiques comme MMLU (Massive Multitask Language Understanding) ou HELM, qui testent les modèles sur des dizaines de dimensions différentes. L'idée est de ne plus demander « Est-ce que c'est juste ? » mais « Dans quels domaines ce modèle est-il fiable et où échoue-t-il ? ».