VLMEvalKit : évaluer des modèles vision-langage sans recoller les jeux de données à la main

Le problème n'est pas le modèle, c'est la plomberie des données

Comparer deux modèles vision-langage demande normalement de télécharger chaque benchmark depuis son dépôt d'origine, d'écrire un chargeur par jeu de données, de normaliser les prompts, puis de recoller les scores dans un tableur. Ce travail ne produit aucune connaissance sur les modèles, et il est refait à chaque nouvel arrivant. VLMEvalKit prend ce travail à sa charge : le paquet s'appelle vlmeval, et le README annonce une évaluation en une commande sur des benchmarks variés, sans la charge de préparation des données répartie sur plusieurs dépôts. Le public visé est précis. D'un côté les équipes qui entraînent ou adaptent un LMM et doivent situer leur modèle par rapport à l'existant. De l'autre les mainteneurs de classements, qui ont besoin d'un chemin reproductible entre un identifiant de modèle et un score publié. Un lecteur qui cherche à évaluer un pipeline de détection d'objets ou de segmentation n'y trouvera rien : tout passe par la génération de texte en réponse à une entrée visuelle.

Génération d'abord, extraction ensuite

Le choix architectural central est énoncé sans détour dans le README : l'évaluation est générative pour tous les modèles. Le modèle produit une réponse libre, et le score est calculé après coup, par correspondance exacte ou par extraction de la réponse à l'aide d'un LLM. Ce second étage est la partie que les utilisateurs sous-estiment. Une réponse correcte formulée différemment de la référence peut être comptée fausse si l'extracteur ne la reconnaît pas, et la qualité de l'extracteur devient donc une variable du résultat. Les notes de version sont explicites sur ce point : dans la PR 1175, les fonctions can_infer_option et can_infer_text ont été affinées, ce qui, selon ces mêmes notes, oriente plus souvent l'évaluation vers les extracteurs de choix par LLM et conduit empiriquement à une légère amélioration des performances sur les benchmarks à choix multiples. Autrement dit, le score d'un modèle sur un QCM dépend en partie du routeur d'extraction. C'est un compromis assumé : il permet de couvrir des modèles aux formats de sortie très différents sans écrire un parseur par modèle, au prix d'une couche supplémentaire entre la réponse brute et la métrique.

Deux variables d'environnement qui changent la donne

Les modèles à mode raisonnement posent un problème concret : leurs réponses contiennent une trace de réflexion qui ne fait pas partie de la réponse finale. VLMEvalKit expose SPLIT_THINK=True. Par défaut, la fonction découpe le contenu situé entre les balises <think>...</think> et le range dans la clé thinking de la sortie. Le README recommande fortement cette option pour les modèles concernés, afin de préserver la justesse de l'évaluation, et indique qu'une fonction split_think personnalisée peut être écrite par modèle, l'implémentation d'InternVL servant d'exemple. La seconde variable concerne les sorties longues. Les cellules d'un fichier .xlsx sont plafonnées à 32 767 caractères, ce qui tronque silencieusement les réponses des modèles verbeux. En activant PRED_FORMAT=tsv, les prédictions sont écrites en TSV, et le README recommande ce format dès que les réponses dépassent 16k ou 32k tokens. Le mot important est silencieusement : une troncature ne provoque pas d'erreur, elle produit un score faux. Ces deux variables se placent avant toute campagne sérieuse, pas après.

Configurer un modèle dans config.py

L'intégration d'un modèle passe par vlmeval/config.py, où les configurations personnalisées sont déclarées. Pour accélérer l'inférence, le README indique depuis le 24 mai 2025 la prise en charge de l'inférence distribuée multi-nœuds via LMDeploy, qui couvre les séries InternVL, QwenVL et LLaMa4, ou via VLLM, qui couvre les séries QwenVL et LLaMa4. L'activation se fait en ajoutant le drapeau use_lmdeploy ou use_vllm à la configuration du modèle dans ce même fichier. C'est une option de débit, pas de correction : elle ne change pas la métrique, seulement le temps de campagne. Un point pratique mérite d'être signalé, car il n'apparaît pas dans le README principal : la disponibilité réelle d'un modèle dépend de ce que contient vlmeval/config.py à la version que vous installez. Le README annonce plus de 220 modèles pris en charge, mais cette liste évolue par ajouts successifs, et un modèle récent peut n'être présent que sur la branche main. Vérifiez le fichier avant de bâtir un plan de campagne autour d'un identifiant précis. Pour les benchmarks vidéo, une variable VLMEVALKIT_USE_MODELSCOPE permet de passer par ModelScope pour le téléchargement.

Là où l'outil devient le mauvais choix

La couche d'extraction par LLM est aussi la principale faiblesse. Elle suppose que vous pouvez faire tourner un juge, ce qui implique un accès à un modèle suffisamment capable et un budget d'inférence qui s'ajoute à celui des modèles évalués. Si votre contrainte est un environnement hors ligne sans juge local, le mécanisme central perd une partie de sa valeur. Deuxième cas défavorable : les tâches dont la métrique est intrinsèquement structurée, comme la détection avec boîtes englobantes ou la segmentation par masques. L'évaluation générative n'est pas le bon cadre pour ces sorties, et le projet ne prétend pas le contraire. Troisième cas : la comparaison historique. Si vous avez déjà des scores obtenus avec un autre pipeline, les reproduire à l'identique n'est pas garanti, puisque les extracteurs can_infer_option et can_infer_text ont été modifiés dans la PR 1175 et que ce changement déplace les scores sur les QCM. Un écart de quelques points entre deux campagnes peut venir de l'outil et non du modèle. C'est une raison suffisante pour figer une version du paquet et la noter à côté des résultats.

Face à lm-evaluation-harness et aux scripts maison

L'alternative la plus proche côté esprit est lm-evaluation-harness, qui vise lui aussi l'évaluation en une commande sur de nombreux modèles et jeux de données. La différence de conception est nette : lm-evaluation-harness s'appuie largement sur la log-vraisemblance des continuations candidates, ce qui donne des scores déterministes et peu coûteux pour les tâches à choix multiple, mais suppose un accès aux probabilités du modèle. VLMEvalKit fait le choix inverse, la génération, ce qui lui permet d'évaluer des modèles accessibles uniquement par API, comme le suggèrent les sujets du dépôt (chatgpt, gemini, claude, openai-api), là où un accès aux logits n'existe pas. Le prix est l'étage d'extraction et son coût. La seconde alternative est le script maison : quelques centaines de lignes suffisent pour un benchmark unique, et elles resteront plus simples à déboguer qu'un cadre générique. VLMEvalKit devient intéressant au deuxième ou troisième benchmark, quand la duplication des chargeurs commence à coûter plus cher que l'apprentissage d'une interface.

Maintenance, versions et licence

Le rythme de publication est irrégulier. Le dépôt montre v0.2rc1 en juin 2024, v0.2 en mars 2025, puis v0.3rc1 en juin 2025, et le README documente des changements de code jusqu'en septembre 2025. Entre deux versions, des fonctionnalités sont annoncées comme disponibles sur main, y compris des corrections qui modifient les scores. La conséquence pratique est qu'une installation depuis PyPI et une installation depuis main ne donnent pas forcément les mêmes chiffres. Pour un usage de recherche, c'est acceptable si la version est consignée. Pour un usage de conformité ou de suivi de régression, une version figée est préférable. Le projet est distribué sous Apache-2.0, une licence permissive 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. Cela ne dit rien du statut des benchmarks eux-mêmes : chaque jeu de données intégré conserve sa propre licence et ses propres conditions d'usage, et c'est ce point qu'il faut vérifier avant de publier des résultats, pas la licence du paquet.

Conclusion éditoriale

Adoptez VLMEvalKit si vous devez comparer plusieurs modèles vision-langage sur des benchmarks hétérogènes sans réécrire un pipeline de données par benchmark, et si vous acceptez l'évaluation générative comme cadre. Écartez-le si vos métriques reposent sur des sorties structurées au token près, ou si vous ne pouvez pas exécuter vous-même un juge LLM. Avant de vous engager, vérifiez trois choses dans le dépôt : le contenu réel de vlmeval/config.py pour vos modèles, le comportement de SPLIT_THINK=True sur vos modèles à raisonnement, et le format de sortie retenu (PRED_FORMAT=tsv si vos réponses dépassent 16k tokens).

Sources officielles

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