Outils d’évaluation pour les applications de LLM : ensembles de données, notation et seuils de régression

L’envoi d’une fonctionnalité basée sur un LLM est la partie facile ; prouver qu’elle continue à fournir de bonnes réponses est là où la plupart des équipes butent. Un outil d’évaluation comble cette lacune : il exécute un ensemble fixe de tâches sur un modèle, évalue chaque réponse et transforme les jugements du type « ça semble correct » en chiffres que l’on peut comparer entre différentes versions. À la fin de ce guide, vous saurez en quoi consiste un tel outil, pourquoi les sorties d’un LLM en ont plus besoin que du code ordinaire, et comment il s’intègre dans le processus de publication en servant de mécanisme de détection des régressions.

Le terme peut sembler exotique, mais l’idée est familière. Si vous avez déjà écrit des tests unitaires, validé un pipeline de données ou mis en place des contrôles de qualité des données avant la mise à jour d’un tableau de bord, vous comprenez déjà l’essentiel.

La question à laquelle toute fonctionnalité d’IA doit finir par faire face

Imaginez un assistant interne qui répond aux questions professionnelles. Un stakeholder demande quels clients ont généré le plus de revenus au deuxième trimestre, et la réponse semble crédible. Un autre demande pourquoi les revenus en Allemagne ont chuté, et cette réponse paraît également convaincante.

Deux réponses convaincantes prouvent très peu de choses. Ce que vous devez vraiment savoir, c’est si l’assistant est fiable face aux milliers de questions différentes que les gens taperont chaque jour, y compris celles complexes auxquelles personne n’a pensé pendant la démonstration. Vérifier manuellement ne peut pas être étendu à cette échelle, et il n’y a aucun signe indiquant qu’un changement s’est produit discrètement.

C’est le mur auquel se heurtent de nombreux projets d’IA : développer l’application prend des semaines, tandis que démontrer son fonctionnement fiable peut prendre beaucoup plus de temps. Un outil de type « harness » permet de rendre cette démonstration systématique.

Quel est réellement le rôle d’un harness

Un outil d’évaluation est un cadre qui fournit à un modèle un ensemble prédéfini de questions ou de tâches, collecte les résultats obtenus, les évalue selon des règles définies, et présente les résultats. On peut le considérer comme un système de contrôle qualité automatisé pour le comportement du modèle, ou comme un examinateur qui propose le même examen à tous les candidats et le corrige de la même manière.

Le flux est linéaire : les entrées de test sont envoyées à l’outil, celui-ci appelle le modèle, les réponses sont évaluées, puis ces évaluations se transforment en scores et en rapports :

Test Questions
      │
      ▼
   Harness
      │
      ▼
 AI Model
      │
      ▼
Generated Answers
      │
      ▼
 Evaluation
      │
      ▼
   Scores &
    Reports

Comme chaque étape est automatisée, il est possible de relancer l’ensemble du processus d’évaluation chaque fois que quelque chose change : la question posée, la version du modèle, les paramètres de récupération des données, ou la valeur de température.

Pourquoi un examen standardisé rend les comparaisons équitables

Considérez comment une équipe sensée recrute un analyste de données. Avec trois candidats, on ne discuterait pas avec chacun au hasard avant de se fier à son intuition. On leur poserait la même épreuve SQL, le même cas d’usage et le même problème analytique, puis on comparerait les résultats.

Le choix du modèle fonctionne de la même manière. Les candidats deviennent GPT, Claude et Gemini ; les questions d’entretien deviennent des questions métier, des problèmes de codage, des tâches de résumé et des tâches de génération SQL. Une comparaison n’a de sens que lorsque chaque modèle passe le même examen dans des conditions identiques. Sinon, on mesure la différence entre les questions, et non entre les modèles.

Pourquoi les LLM ont plus besoin de cela que le code traditionnel

La plupart des logiciels conventionnels sont déterministes. Une expression comme celle-ci :

2 + 2

a exactement un seul résultat acceptable :

4

Tout autre cas constitue une erreur, et une assertion d’égalité suffit comme test.

Les modèles de langage ne fonctionnent pas de cette manière. Demandez à deux modèles d’expliquer ce qu’est un entrepôt de données. L’un pourrait le décrire comme un stockage centralisé de données historiques intégrées ; l’autre pourrait le qualifier de système permettant de rassembler des données provenant de multiples sources pour analyse. Les deux descriptions sont correctes, pourtant les textes produits n’ont presque rien en commun. Même le même modèle peut formuler les choses différemment d’une exécution à l’autre.

Ainsi, la tâche passe de vérifier une sortie exacte à évaluer la qualité : l’ réponse est-elle correcte, pertinente et complète, même si sa formulation est nouvelle ? Ce changement représente la différence fondamentale entre le testage de logiciels et l’évaluation des IA, et c’est pourquoi un outil dédié existe plutôt qu’une simple bibliothèque d’assertions.

Les quatre composants d’un outil dédié

La plupart des frameworks, qu’ils soient développés en interne ou achetés prêts à l’emploi, sont assemblés à partir des mêmes quatre composants.

Ensemble de données de test

Cet ensemble de données correspond au sujet d’examen : une collection de requêtes, de questions ou de tâches qui représentent ce que le système doit être capable de gérer. Voici un petit exemple varié :

Write a SQL query to find duplicate customers.

Summarize this article in one paragraph.

Classify this customer support ticket.

Un framework ne peut jamais être supérieur à ses cas de test. Un ensemble de données utile couvre les requêtes courantes, les cas difficiles connus ainsi que les modes de défaillance déjà observés en production. De nombreuses équipes le mettent sous contrôle de version et y ajoutent un cas chaque fois qu’un utilisateur signale une mauvaise réponse, de la même manière qu’une correction de bug donne lieu à un test de régression. Pour comprendre pourquoi les réponses attendues nécessitent elles-mêmes une gestion de version, consultez la gestion de version des ensembles de données dans les suites d’évaluation des LLM.

Modèle testé

C’est le système qui est examiné : GPT, Claude, Gemini, Llama, Mistral, ou votre application complète développée à partir de l’un d’eux. Un avantage majeur de cette conception est que l’ensemble de données est écrit une seule fois et réutilisé pour chaque modèle que vous souhaitez tester.

Dans la pratique, « le modèle » est souvent plus que simplement le modèle brut. Il peut s’agir du modèle de prompt, de l’étape de récupération des informations et du traitement ultérieur réunis, ce qui correspond exactement à l’expérience utilisateur ; c’est donc généralement ce que vous devez tester.

Logique d’évaluation

Lorsqu’une réponse revient, il faut la noter. Parfois, cela est trivial. La réponse attendue est :

Paris

Le modèle renvoie :

Paris

et le verdict est :

Pass

Ce type de correspondance exacte ou normalisée fonctionne bien pour des réponses factuelles courtes, des étiquettes de classification et des sorties structurées. La plupart des applications réelles nécessitent des critères plus complexes, tels que :

• Exactitude
• Relevance
• Complétude
• Taux d’hallucinations
• Ton
• Sécurité
• Fidélité au matériel source

Beaucoup de ces critères ne peuvent pas être vérifiés par comparaison de chaînes de caractères, c’est pourquoi les outils modernes utilisent de plus en plus un deuxième modèle en tant qu’évaluateur, une approche connue sous le nom de LLM-as-a-judge. Cette méthode est puissante, mais elle introduit sa propre source d’erreur ; par conséquent, l’évaluateur doit être calibré à l’aide de labels fournis par des humains. ce document explique en détail comment créer une évaluation avec un évaluateur fiable.

Rapportage

Finalement, les scores individuels sont regroupés en indicateurs et dans des tableaux de bord. Un résumé simplifié pourrait ressembler à ceci :

Model      Accuracy
GPT         92%
Claude      90%
Gemini      87%

Les chiffres présentés ici sont à titre illustratif et ne constituent pas de référence. Ce qui importe, ce sont les décisions auxquelles un tel rapport permet de parvenir :

• Quel modèle déployer
• Si une nouvelle version est supérieure à l’actuelle
• Si un changement dans le prompt améliore réellement les résultats
• Si une nouvelle version est sûre à mettre en production

Régressions : l’échec que le système est conçu pour détecter

La raison principale d’investir dans un tel système est de stopper les régressions. Supposons que votre assistant obtienne actuellement un score de :

Accuracy = 92%

Quelqu’un modifie le prompt pour rendre les réponses plus amicales. Quelques vérifications manuelles montrent que tout est en ordre, donc la modification est intégrée. Trois jours plus tard, le nombre de tickets d’assistance augmente fortement, et lorsqu’on enquête enfin, la précision est tombée à :

84%

En l’absence d’un système de gestion, ce sont les clients qui remarquent en premier les problèmes. Avec un tel système, la même modification des prompts est testée sur l’ensemble des données avant le déploiement, et toute baisse de performance apparaît comme une vérification échouée. Cela correspond directement à un ensemble de tests de régression dans le développement traditionnel. Considérez les prompts, les versions des modèles et les paramètres de récupération comme des modifications de code qui doivent réussir ces tests.

Un point important à garder à l’esprit : comme les sorties des LLM varient d’une exécution à l’autre, de petites différences de scores peuvent être dues au bruit aléatoire. Exécuter chaque cas plus d’une fois ou définir une tolérance avant de considérer qu’il s’agit d’une régression permet d’éviter que le système ne réagisse de manière excessive.

Le rôle de l’évaluation dans le cycle de vie de la livraison de l’IA

Les novices pensent souvent que l’ingénierie de l’IA consiste principalement à rédiger des prompts. Les systèmes en production nécessitent un cycle de vie complet, qui, au sein d’une équipe expérimentée, ressemble à peu près à ceci :

Build
   ↓
Test
   ↓
Evaluate
   ↓
Compare
   ↓
Deploy
   ↓
Monitor

L’outil gère les étapes de test, d’évaluation et de comparaison. En les sautant, les décisions de déploiement se basent sur des impressions plutôt que sur des preuves. Le suivi après la mise en production ajoute de nouveaux cas d’échec au jeu de données, ce qui maintient le cycle fermé.

Un scénario concret : un assistant pour les données de ventes sur Databricks

Pour rendre cela concret du point de vue de l’ingénierie des données, imaginez un assistant développé sur Databricks qui répond aux questions concernant les données de ventes. Les utilisateurs posent des questions telles que :

What were total sales in Q1?

Who are our top customers?

Which regions experienced growth last year?

Avant la mise en production d’une nouvelle version du modèle, l’équipe rassemble quelques centaines de questions représentatives. L’outil les exécute automatiquement et vérifie :

• La qualité du SQL généré
• La précision des réponses finales
• La cohérence entre les exécutions
• Le délai de réponse
• Les hallucinations

La nouvelle version n’est promue que si ses performances sont au moins équivalentes à celles de la version actuellement en production. En pratique, il s’agit d’un CI/CD pour une application d’intelligence artificielle : l’exécution d’évaluation constitue une étape du pipeline, et le score sert de critère de validation.

Un outil unique, de nombreux modèles

Peut-on utiliser le même outil pour évaluer GPT, Claude et Gemini en parallèle ? Oui, et comparer les modèles fait partie de ses principales fonctions. La clé réside à ce que la logique d’évaluation reste indépendante de tout fournisseur particulier, afin que les modèles puissent être intégrés via une interface commune :

Harness
   ├── GPT
   ├── Claude
   ├── Gemini
   └── Llama

Chaque modèle reçoit les mêmes questions et est évalué selon les mêmes règles, ce qui permet une comparaison équitable pour votre cas d’usage spécifique plutôt qu’un classement générique. Les résultats sont également adaptés à vos données : le modèle qui arrive en tête d’un benchmark public n’est pas nécessairement celui qui répond le mieux aux questions de votre équipe.

Outils que vous rencontrerez probablement

Il est rarement nécessaire de tout construire à partir de zéro. Parmi les options couramment utilisées, on trouve :

• OpenAI Evals
• DeepEval
• LangSmith
• MLflow Evaluation
• Promptfoo
• RAGAS, axé sur l’évaluation des pipelines RAG

Pourquoi les ingénieurs en données ont un avantage

Les ingénieurs en données supposent souvent que l’ingénierie de l’intelligence artificielle est une discipline complètement distincte. La superposition entre les deux est en réalité plus importante qu’il n’y paraît. Les années passées à s’assurer que des données de mauvaise qualité n’atteignent jamais un tableau de bord (en définissant des attentes, en effectuant des vérifications à chaque chargement, en bloquant toute mise en production en cas d’échec) correspondent exactement aux habitudes nécessaires pour évaluer l’intelligence artificielle. Ce qui est testé a changé, passant d’une table à les réponses d’un modèle ; la discipline d’ingénierie reste identique.

Points clés

• Choisir le modèle le plus performant importe moins que de pouvoir mesurer le comportement de son système ; c’est l’évaluation qui distingue une démonstration d’un produit réel.
• Un cadre de test se compose de quatre éléments : un ensemble de données de test, le modèle à tester, la logique d’évaluation et la génération de rapports. L’ensemble de données fixe les limites pour tout le reste.

La sortie d’un LLM ne peut pas être vérifiée uniquement par une égalité stricte ; donc l’évaluation combine généralement des vérifications déterministes avec des critères gradués, parfois en utilisant un modèle comme juge.

Exécutez le framework sur chaque modification de prompt, de modèle ou de configuration, et bloquez les mises en production dont la note est inférieure au seuil actuel.

Le fait de rester indépendant du fournisseur d’évaluation vous permet de comparer les modèles de manière équitable sur vos propres données.

En résumé en une phrase : un framework de ce type constitue le cadre d’essais unitaires, de contrôle qualité et de tests de régression pour les applications utilisant des LLM. Aucune équipe sérieuse ne déploie de logiciel sans tests, et une fonctionnalité basée sur un LLM mérite le même traitement avant d’être mise en production.

Lectures complémentaires