Harnais d'évaluation : ce qu'ils sont et pourquoi ils sont cruciaux

Dans tout projet IA sérieux, il arrive un moment où la question n'est plus « quel modèle est le plus populaire ? » mais « quel modèle est le meilleur pour mon cas ? ». Et là, la réponse « GPT-4o est le meilleur » ne suffit plus. Vous avez besoin de mesurer, reproductiblement, sur vos propres tâches. C'est exactement le rôle d'un harnais d'évaluation (en anglais evaluation harness). Ce guide explique ce que c'est, les outils de référence, et pourquoi aucun projet IA mûr ne s'en passe.

Qu'est-ce qu'un « harnais » d'évaluation ?

Un harnais d'évaluation est un cadre logiciel qui soumet un modèle à une série de tâches standardisées, collecte ses réponses, les note selon des critères définis, et produit des métriques comparables. Le mot « harnais » (harness) vient de l'idée qu'on « attelle » le modèle à un banc d'essai, comme on teste un moteur sur un banc de puissance plutôt qu'en conduisant au feeling.

Un harnais fait typiquement quatre choses :

• Charger une tâche : un jeu de prompts + (souvent) des réponses attendues ou des critères de notation.
• Interroger le modèle : via API ou en local, avec des paramètres contrôlés (température, max tokens, system prompt).
• Noter : exactitude, similarité, conformité à un schéma, jugement d'un autre modèle (LLM-as-judge), ou évaluation humaine.
• Agréger : produire un score par tâche, par modèle, par configuration, reproductible.

La clé est la reproductibilité : deux exécutions du harnais sur le même modèle doivent donner le même score (à la stochasticité près, qu'on contrôle avec une graine et une température à 0).

Pourquoi c'est crucial pour réussir un projet

Voici le scénario classique d'un projet qui n'a pas de harnais : on choisit un modèle « parce qu'il est bien noté », on l'intègre, ça marche sur les trois exemples de démo, puis en production ça rate sur 30 % des cas réels. Personne ne sait pourquoi, et chaque changement de modèle est un saut dans le vide. Le harnais transforme cela en démarche scientifique :

• On compare objectivement : modèle A vs B vs C sur vos données, pas sur MMLU.
• On détecte les régressions : quand vous changez de version de modèle ou de prompt, le harnais dit immédiatement si vous avez gagné ou perdu.
• On quantifie le trade-off coût/qualité : un modèle 5× moins cher qui perd 2 points sur votre métrique vaut-il le changement ? Sans harnais, impossible à répondre ; avec, c'est un tableau.
• On documente la décision : « on a choisi X car il score 87 % sur notre jeu métier vs 84 % pour Y, à 30 % du coût ». C'est défendable.

Règle de pouce : si vous ne pouvez pas chiffrer la qualité d'un modèle sur votre tâche, vous ne pouvez pas l'améliorer. Le harnais est le thermomètre du projet.

Les benchmarks académiques (et leurs limites)

Les harnais open source embarquent des batteries de benchmarks standardisés. Les plus connus :

• MMLU / MMLU-Pro : connaissances générales multi-domaines. Utile comme sanity check, mais éloigné d'un usage métier.
• GSM8K / MATH : raisonnement mathématique. Indique la capacité de calcul étape par étape.
• HumanEval / MBPP : génération de code. Mesure la correction fonctionnelle des programmes produits.
• BFCL (Berkeley Function Calling Leaderboard) : qualité du function calling — crucial pour les agents (voir notre article sur Hermes 2.3).
• IFEval : conformité aux instructions (format, contraintes). Mesure la steerability.

Attention : ces benchmarks sont contaminés (les modèles les ont vus à l'entraînement) et éloignés du terrain. Un modèle qui score 90 % au MMLU peut rater votre tâche d'extraction de factures. Les benchmarks académiques sont un filtre de premier niveau, pas une décision finale.

Les harnais de référence

lm-evaluation-harness (EleutherAI)

Le standard de facto, open source, maintenu par EleutherAI. Il embarque des dizaines de benchmarks, supporte l'inférence locale (Hugging Face, vLLM) et via API (OpenAI, Anthropic…). C'est l'outil à connaître en premier. On lance une éval en une commande du type lm_eval --model hf --tasks mmlu,gsm8k --model_args pretrained=....

lighteval (Hugging Face)

Alternative moderne, bien intégrée à l'écosystème HF, avec un système de tâches déclaratif. Particulièrement propre pour des pipelines CI et des comparaisons reproductibles.

OpenCompass

Harnais complet, très utilisé en Asie, avec une large couverture de benchmarks multilingues et de tâches vision/langage. Bon choix si vous évaluez des modèles non anglophones.

Promptfoo / DeepEval / RAGAS

Orientés « application » plutôt que « modèle nu ». Promptfoo compare des prompts et des modèles sur vos cas ; DeepEval et RAGAS ciblent les systèmes RAG (pertinence, fidélité, hallucination). Ce sont les harnais à utiliser quand vous évaluez un produit fini, pas un LLM brut.

Construire son propre harnais métier

Le plus important : les benchmarks académiques ne remplacent jamais un harnais métier. Voici la démarche recommandée :

1. Constituer un golden set : 100 à 500 exemples représentatifs de votre tâche réelle, avec la réponse attendue (ou les critères de jugement). C'est l'actif le plus précieux du projet.
2. Définir la métrique : exactitude exacte ? similarité (BLEU/ROUGE) ? conformité à un schéma JSON ? jugement d'un LLM-as-judge ? Chaque tâche appelle une métrique différente.
3. Fixer les paramètres : température 0, même system prompt, même max_tokens pour tous les modèles. Sinon vous comparez des choux et des carottes.
4. Évaluer plusieurs modèles : inclure un frontier model (référence haute), un modèle open (Hermes, Llama…) et un modèle moins cher. Vous obtenez un axe qualité/prix.
5. Automatiser en CI : relancez le harnais à chaque changement de prompt ou de modèle. Une régression doit être visible avant la mise en production.

Le coût de cette démarche est minuscule comparé au coût d'un mauvais choix de modèle en production. Un golden set de 200 exemples, évalué sur 5 modèles, coûte quelques dollars d'API et quelques heures de mise en place — et vous évite des mois de dérive.

LLM-as-judge : l'arme à double tranchant

Pour les tâches sans réponse exacte (génération, résumé, ton), on utilise souvent un autre LLM comme juge (« LLM-as-judge »). C'est puissant mais piégeux :

• Biais de position : le juge préfère souvent la première réponse présentée. Randomisez l'ordre.
• Biais d'auto-préférence : un juge GPT-4 peut préférer les réponses de GPT-4. Utilisez un juge d'une famille différente du modèle évalué.
• Calibration : faites valider un sous-ensemble par un humain pour vérifier que le juge est aligné avec votre critère réel.

Harnais et choix de matériel

Si vous évaluez en local (modèles open), le harnais consomme du GPU. Pour des évals sérieuses sur des modèles 70B, une RTX 5090 32 Go ou un Mac mini M4 Pro 64 Go sont des bases correctes (voir les guides matériel et Mac mini IA). Pour des évals massives et ponctuelles, louer du GPU à l'heure sur Vast.ai ou RunPod est souvent plus malin que d'acheter.

Le mot de la fin

Un harnais d'évaluation n'est pas un luxe de chercheur, c'est l'outil de base de l'ingénieur IA. Il transforme le choix de modèle d'une opinion en une mesure, détecte les régressions avant qu'elles n'atteignent vos utilisateurs, et rend défendable chaque décision d'architecture. Commencez petit — un golden set de 100 exemples et un script qui interroge trois modèles — et faites grandir le harnais avec le projet. C'est, avec le choix du modèle lui-même, le meilleur investissement de temps d'un projet IA.