OpenCompass : évaluer un LLM sans réécrire la plomberie

Le problème n'est pas le benchmark, c'est le harnais autour

Comparer deux modèles sur un jeu de données académique prend une après-midi. Comparer huit modèles, dont trois accessibles uniquement par API et cinq exécutés localement, sur une centaine de jeux de données, demande une infrastructure. Il faut normaliser les invites, gérer les formats de sortie, découper le calcul en tâches reprenables, puis agréger des métriques qui ne sont pas définies de la même façon d'un benchmark à l'autre. C'est cette couche-là qu'OpenCompass prend en charge. Le dépôt décrit un catalogue de modèles qui couvre Llama3, Mistral, InternLM2, GPT-4, Qwen, GLM et Claude, et un catalogue de jeux de données qui dépasse la centaine. La cible est donc l'équipe qui évalue régulièrement, pas le développeur qui veut lancer une mesure unique. Un chercheur en évaluation, une équipe d'ingénierie modèle, ou un service qui doit produire un tableau comparatif reproductible avant une décision d'adoption.

Une évaluation est un fichier Python, pas un fichier de configuration

Le choix structurant d'OpenCompass est de représenter une campagne d'évaluation comme un script Python qui assemble des objets. Le README renvoie à des exemples nommés, par exemple examples/eval_mmbench_vlmevalkit.py ou examples/eval_intern_s1_pro.py, ce qui indique la forme attendue : on écrit un fichier, on y déclare les modèles et les jeux de données, puis on l'exécute. Les configurations de jeux de données vivent dans opencompass/configs/datasets, avec des fichiers comme opencompass/configs/datasets/MultiIF/MultiIF_gen.py pour l'évaluation du suivi d'instructions multi-tours. Ce n'est pas du YAML : vous héritez de la puissance de Python, donc des imports, des boucles et des fonctions, mais aussi de la nécessité de lire du code pour comprendre ce qu'un benchmark mesure réellement. Les modèles sont implémentés dans opencompass/models, avec des fichiers dédiés par famille d'API, par exemple opencompass/models/openai_response.py pour l'API Responses d'OpenAI, opencompass/models/litellm_api.py pour la passerelle LiteLLM, opencompass/models/gemini_sdk_api.py et opencompass/models/claude_sdk_api.py. Les tâches d'inférence et d'évaluation sont également des modules distincts, comme opencompass/tasks/openicl_infer_concurrent.py et opencompass/tasks/openicl_eval_watch.py. Cette séparation entre inférence et évaluation est le point intéressant du design : elle permet de lancer l'inférence d'abord, puis de surveiller l'arrivée des résultats et de déclencher l'évaluation ensuite, plutôt que de tout enchaîner en un bloc monolithique.

Ce que la version 0.4.0 a cassé, et pourquoi cela vous concerne

Le README signale un changement cassant en version 0.4.0 : les fichiers de configuration auparavant répartis dans ./configs/datasets, ./configs/models et ./configs/summarizers ont été consolidés dans le paquet opencompass. Toute référence de configuration pointant vers les anciens chemins doit être mise à jour. Ce détail a des conséquences pratiques au-delà de la migration ponctuelle. Il signifie que les configurations de benchmarks sont versionnées avec le code d'OpenCompass, et non avec votre projet. Quand un mainteneur corrige une invite ou une métrique, votre campagne change de comportement sans que vous ayez touché à votre dépôt. Pour un travail de comparaison publié, cela impose de figer la version du paquet au moment de la campagne, sinon les chiffres ne sont plus comparables d'un mois sur l'autre. C'est un compromis assumé : centraliser les configurations évite la dérive entre équipes, mais retire au utilisateur le contrôle direct sur la définition du benchmark.

Mise en route : installer, écrire un script, lancer

L'installation est documentée à l'adresse indiquée dans le README, sous get_started/installation.html, et le paquet est distribué sur PyPI sous le nom opencompass, même si le badge PyPI est commenté dans le README. Une fois installé, la démarche consiste à écrire un script d'évaluation sur le modèle des fichiers du dossier examples, puis à l'exécuter avec l'outil de ligne de commande du projet. Les clés de configuration que vous manipulerez dans ce script concernent le modèle (son implémentation dans opencompass/models et ses paramètres d'accès) et le jeu de données (son fichier dans opencompass/configs/datasets). Pour les modèles servis par API, il faut fournir les identifiants attendus par l'implémentation correspondante, par exemple pour openai_response.py ou claude_sdk_api.py. Deux outils annexes méritent d'être connus avant de lancer une grosse campagne : tools/analyze_repeat.py, qui détecte les contenus répétitifs et les sorties en boucle dans les résultats existants, et le mécanisme CascadeEvaluator, qui enchaîne plusieurs évaluateurs pour construire un pipeline d'évaluation personnalisé. Le second est utile quand une métrique automatique ne suffit pas et qu'un juge LLM doit intervenir après un premier filtre.

Là où OpenCompass vous coûtera plus qu'il ne vous rapporte

Le coût réel d'une campagne ne vient pas du logiciel mais de l'inférence. Évaluer un modèle local sur une centaine de jeux de données suppose un budget GPU et un temps de calcul que le dépôt ne réduit pas ; évaluer un modèle propriétaire suppose un budget d'API proportionnel au nombre d'échantillons. OpenCompass organise ce calcul, il ne le rend pas gratuit. Deuxième limite : le projet évolue vite. Les notes de version montrent des ajouts réguliers, intégration de VLMEvalKit en août 2026, API Responses et LiteLLM en juillet 2026, inférence multi-tours en juillet 2026, analyse des répétitions en mai 2026, inférence concurrente et surveillance des évaluations en mars 2026. Cette cadence signifie que la documentation en ligne peut décrire une version différente de celle que vous avez installée. Troisième cas où l'outil est mal adapté : si votre besoin est de vérifier qu'un modèle ne régresse pas sur cinquante cas internes à chaque commit, la machinerie de configuration et de tâches distribuées est disproportionnée. Un harnais de test écrit à la main sera plus lisible et plus rapide à faire tourner en intégration continue.

Face à lm-evaluation-harness, deux philosophies de configuration

L'alternative la plus directement comparable est le harnais d'évaluation du projet EleutherAI, généralement désigné sous le nom lm-evaluation-harness. La différence tient à la façon de décrire une évaluation. lm-evaluation-harness privilégie des tâches déclarées en YAML, avec un format relativement contraint, ce qui rend l'ajout d'un benchmark simple et la lecture d'une configuration prévisible. OpenCompass, lui, décrit les campagnes en Python et place les définitions de jeux de données dans le paquet lui-même, ce qui autorise des enchaînements plus libres, comme le CascadeEvaluator ou l'inférence concurrente avec surveillance, mais rend la personnalisation dépendante de la lecture du code source. Le second axe de différence est la couverture des modèles propriétaires : OpenCompass consacre des implémentations distinctes aux API Responses d'OpenAI, à Gemini, à Claude et à la passerelle LiteLLM, et le README cite l'intégration de VLMEvalKit pour les benchmarks multimodaux. Si votre évaluation porte uniquement sur des modèles ouverts exécutés en local, l'argument en faveur d'OpenCompass est plus faible et le harnais YAML suffit souvent.

Maintenance, licence et ce qu'il faut vérifier avant d'adopter

Le dépôt n'est pas archivé, la branche par défaut est main, et les versions récentes listées sont 0.5.2 en février 2026, 0.5.3 en juin 2026 et 0.5.4 en août 2026, avec un dernier push en septembre 2026. Le rythme est donc soutenu, ce qui implique une veille de mise à jour et des tests de non-régression sur vos propres scripts d'évaluation à chaque montée de version mineure. La licence est Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de copyright et du texte de licence, et une clause de brevets. Je ne donne pas d'avis juridique : si vous redistribuez OpenCompass ou l'intégrez dans un produit, faites relire les conditions par votre service compétent. Un point à ne pas négliger : les jeux de données eux-mêmes ont leurs propres licences, distinctes de celle du code, et le dépôt ne les détaille pas dans les éléments dont je dispose. Avant de publier un tableau de résultats, vérifiez les conditions de chaque benchmark utilisé, pas seulement celles d'OpenCompass.

Conclusion éditoriale

Adoptez OpenCompass si vous devez comparer plusieurs modèles, y compris via des API propriétaires, sur un corpus de jeux de données déjà décrit dans le dépôt, et si votre équipe lit du Python de configuration sans difficulté. Passez votre chemin si vous voulez une bibliothèque légère à intégrer dans une suite de tests existante, ou si vous ne pouvez pas immobiliser un GPU ou un budget d'API pour la campagne. Avant de vous engager, vérifiez deux choses concrètement : que le modèle visé figure bien dans opencompass/models, et que le jeu de données visé figure dans opencompass/configs/datasets, puisque les fichiers de configuration ont été déplacés dans le paquet à partir de la version 0.4.0.

Sources officielles

1. License: Apache-2.0
2. open-compass/opencompass on GitHub
3. Project website
4. README
5. Releases