evalscope : un seul point d'entrée pour évaluer LLM, VLM et services d'inférence

Le problème concret : mesurer un modèle sans écrire de harnais

Évaluer un modèle servi par API demande d'ordinaire trois choses distinctes : un jeu de données au format attendu, une boucle d'appel qui gère les erreurs et les limites de débit, et un calcul de métrique comparable d'une exécution à l'autre. evalscope existe pour supprimer cette plomberie. Le README présente le projet comme un cadre d'évaluation « one-stop » construit par la communauté ModelScope, avec une promesse de démarrage en une commande. Le public visé n'est donc pas le chercheur qui publie un nouveau benchmark, mais l'ingénieur qui doit trancher entre deux modèles ou vérifier qu'un déploiement se comporte comme annoncé. Les sujets déclarés couvrent l'évaluation, la performance, le RAG, les modèles de vision et de langage.

La portée est plus large que la seule qualité de réponse. Le README liste aussi les tests de charge d'inférence, avec des métriques comme TTFT et TPOT, et un mode arène pour des comparaisons par paires entre plusieurs modèles. Ces deux usages n'ont pas la même exigence : une évaluation de capacité demande des jeux de données figés et une métrique stable, un test de charge demande un générateur de requêtes et une horloge fiable. Le projet traite les deux dans la même interface, ce qui est pratique mais mélange deux natures de résultats dans un même rapport.

Le flux d'exécution : jeu de données, adaptateur, backend, rapport

Le README ne détaille pas l'architecture interne, mais il expose assez d'éléments pour reconstituer la chaîne. Une commande d'évaluation prend un modèle, un type d'évaluation, un ou plusieurs jeux de données, puis délègue le calcul à un backend. Les backends nommés sont OpenCompass, VLMEvalKit et RAGEval. Autrement dit, evalscope ne réimplémente pas chaque benchmark : il joue le rôle de façade et d'adaptateur au-dessus de moteurs existants, et normalise leurs sorties dans un rapport unique.

Cette couche d'adaptation est visible dans les notes de version. La v1.10.0 et les versions suivantes mentionnent une refonte de l'architecture d'adaptateurs, avec un `AudioLanguageAdapter` et un `FunctionCallAdapter` unifié, ainsi qu'une API publique `run_agent_loop`. Le mode agent fonctionne différemment du reste : il pilote le benchmark à l'intérieur d'une boucle multi-tours contrôlée, avec des stratégies, des outils et un bac à sable Docker enfichables, et enregistre une trace par échantillon. C'est la partie la plus intéressante du projet, parce que la trace est ce qui permet de comprendre pourquoi un modèle a échoué, là où un score agrégé ne dit rien. Le revers est que cette boucle ajoute un bac à sable et des outils à la surface d'installation, ce que le README ne quantifie pas.

Démarrer : une commande, puis des clés de configuration

L'installation tient en une ligne, `pip install evalscope`, avec Python 3.10 ou plus récent d'après le badge du dépôt. Le README donne ensuite un exemple complet d'évaluation via une API compatible OpenAI :

evalscope eval --model your-model-name --api-url $OPENAI_API_BASE_URL --api-key $OPENAI_API_KEY --eval-type openai_api --datasets gsm8k --limit 5

Les options visibles dans cet exemple sont `--model`, `--api-url`, `--api-key`, `--eval-type`, `--datasets` et `--limit`. Le `--limit 5` est important : il permet de valider la chaîne de bout en bout sur cinq échantillons avant de lancer un jeu complet. Les notes de version ajoutent d'autres clés au fil des versions, notamment `--data-source` pour le module de performance, avec une génération de requêtes parallélisée, et `--duration` comme budget en temps réel pour tous les modes de benchmark. Le projet accepte aussi des configurations au format Pydantic unifié, mentionnées pour le module RAG refondu en v1.10.0.

Rien dans le matériel fourni ne décrit les valeurs par défaut de ces options, ni la manière dont les identifiants sont stockés. Si vous passez `--api-key` en ligne de commande, il finit dans l'historique du shell : c'est un point à vérifier dans la documentation avant un usage en intégration continue.

Le rythme des versions impose un coût de suivi réel

Les versions récentes s'enchaînent vite : v1.11.1 le 31 août 2026, v1.11.0 le 24 août, v1.10.0 le 4 août. Les notes de version montrent des ajouts de benchmarks par lots, une dizaine à la fois en août 2026, et des refontes d'API comme le passage à MTEB 2.x et RAGAS 0.4.x pour le module RAG. Ce rythme a deux conséquences. La première est positive : les benchmarks récents arrivent sans attendre. La seconde est moins agréable : une refonte d'adaptateur ou une montée de version d'une dépendance externe peut changer la sortie d'un rapport sans que le nom du jeu de données ait bougé.

La v1.11.0 annonce des « versions d'évaluation publiées » pour des résultats reproductibles, ainsi qu'une meilleure gestion des exécutions incomplètes et une sémantique de rapport unifiée. C'est un aveu indirect : avant cette version, la comparabilité entre deux exécutions n'était pas garantie par le cadre lui-même. Si vous archivez des scores pour suivre une régression, notez la version d'evalscope à côté du score, pas seulement le nom du modèle et du jeu de données. Le matériel fourni ne précise pas la politique de compatibilité entre versions mineures.

Ce que le cadre ne peut pas vous promettre

Le point le plus délicat est la comparabilité externe. Un score obtenu avec evalscope sur gsm8k ne sera pas nécessairement identique à celui du tableau d'un article, parce que le prompt, l'extraction de la réponse et le découpage des échantillons varient d'un harnais à l'autre. Le README ne revendique pas cette équivalence, et les versions d'évaluation publiées de la v1.11.0 suggèrent que le projet cherche à la construire plutôt qu'à la supposer acquise. Utiliser evalscope pour départager deux modèles que vous servez vous-même est raisonnable. L'utiliser pour contester un chiffre publié ne l'est pas sans vérifier la configuration exacte.

Deuxième limite : la dépendance aux backends. En s'appuyant sur OpenCompass, VLMEvalKit et RAGEval, evalscope hérite de leurs contraintes, de leurs versions et de leurs bogues. Un correctif dans un benchmark peut demander une montée de version du backend, laquelle peut à son tour casser un adaptateur. Le mode agent ajoute une dépendance à Docker pour le bac à sable, ce qui exclut de fait les environnements où les conteneurs ne sont pas disponibles. Enfin, le matériel fourni ne contient aucun chiffre de performance propre au cadre lui-même : impossible de dire combien de temps prend une exécution complète sur MMLU, ni combien de mémoire consomme le rapport.

Face à lm-evaluation-harness : façade contre implémentation

L'alternative la plus directe reste lm-evaluation-harness, le harnais de référence de la communauté EleutherAI. La différence n'est pas une question de qualité mais de position dans la pile. lm-evaluation-harness implémente lui-même ses tâches et sert de source pour beaucoup de tableaux publiés : le nom de la tâche y est lié à une définition stable, ce qui facilite la comparaison avec la littérature. evalscope se place au-dessus de moteurs tiers et met l'accent sur l'unification des sorties, les rapports visuels et les tests de charge.

Concrètement, si votre besoin est de reproduire une tâche telle qu'elle est définie dans un article, le harnais d'origine est le chemin le plus court. Si votre besoin est de comparer plusieurs modèles servis par API, de mesurer TTFT et TPOT sur un endpoint, ou de faire tourner un benchmark agentique avec une trace inspectable, evalscope couvre ces cas dans une seule interface, ce que lm-evaluation-harness ne vise pas. Le choix se fait donc sur la nature de la question posée, pas sur une supériorité générale de l'un ou de l'autre.

Licence et maintenance

Le dépôt est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec obligation de conserver les mentions de copyright et le texte de licence, et une clause de brevets. Cette licence ne dit rien des jeux de données eux-mêmes : chaque benchmark embarqué peut avoir ses propres conditions d'utilisation, et le matériel fourni ne les énumère pas. Avant de publier des scores issus d'un benchmark précis, vérifiez la licence de ce jeu de données séparément de celle du cadre. Ce n'est pas un avis juridique, seulement un rappel de ce que la licence du dépôt couvre et ne couvre pas.

Côté maintenance, le rythme de publication est soutenu et le dépôt n'est pas archivé. Le coût réel pour une équipe tient moins à l'installation qu'au suivi : monter de version pour obtenir un nouveau benchmark peut modifier la sémantique des rapports, comme l'indique la v1.11.0, et les montées de dépendances externes (MTEB 2.x, RAGAS 0.4.x) peuvent demander des ajustements de configuration. Prévoir une version figée par campagne d'évaluation est plus prudent que de suivre la branche principale, mais le matériel fourni ne documente pas de canal de correctifs pour les anciennes versions.

Conclusion éditoriale

evalscope convient aux équipes qui doivent comparer plusieurs modèles servis par API, mesurer TTFT et TPOT sur un endpoint, ou faire tourner un benchmark agentique dans un bac à sable Docker sans maintenir de code d'orchestration. Il faut l'éviter si votre objectif est de reproduire au chiffre près un score publié : la documentation ne garantit pas cette équivalence, et les versions d'évaluation publiées introduites en v1.11.0 sont précisément là pour combler cet écart. Avant d'adopter, installez le paquet, lancez la commande d'exemple du README avec --limit 5 sur votre propre endpoint, puis inspectez le rapport généré et la trace d'agent, qui est le seul artefact réellement propre à ce projet.

Sources officielles

1. License: Apache-2.0
2. modelscope/evalscope on GitHub
3. Project website
4. README
5. Releases