OpenVLHarness dote les modèles multimodaux de mémoire et d'outils : +9,7–12,6 points

Les auteurs d'OpenVLHarness proposent de laisser au modèle multimodal son raisonnement, et de lui fournir des outils externes ainsi qu'une mémoire où sont stockés les résultats de ces outils. Sur 22 benchmarks et huit modèles, ouverts et propriétaires, cette surcouche a relevé le score moyen de 9,7 à 12,6 points par rapport à des baselines identiques sans outils. Le résultat le plus marquant concerne le coût : GPT-6 Luna, avec un reasoning effort moyen, devance de 7,7 à 8,5 points le modèle de base, Codex et Visual Sketchpad, qui tournaient à l'effort maximal. Elle a consommé au plus 37% de leurs tokens.

Pourquoi le raisonnement seul ne suffit pas

Le point de départ du travail est une expérience contrôlée sur les mêmes 22 benchmarks. Augmenter simplement le budget d'inférence du modèle de base, c'est-à-dire lui accorder davantage de tokens de réflexion, ne produit qu'un gain modeste. La raison tient à la nature des tâches. Elles exigent une perception ancrée dans l'image, des connaissances externes et des mesures numériques. Chacun de ces éléments provient d'un outil différent, et le modèle ne peut pas les déduire de ses propres poids, aussi longtemps qu'il réfléchisse.

Un second problème se pose. La sortie d'un outil doit être convertie en un format que le modèle sait lire, puis rester disponible à l'étape de raisonnement suivante. C'est là que la plupart des schémas agentiques échouent : une image ou un tableau apparaît une seule fois, et trois étapes plus tard, il n'en reste qu'un résumé textuel.

Comment fonctionne la surcouche

OpenVLHarness repose sur deux couches et une interface.

• La capability layer réunit des interfaces d'outils au niveau de la tâche et un rendu des éléments de preuve. Elle offre un accès unifié à des backends hétérogènes et convertit leurs sorties en observations compréhensibles par le modèle.
• La mémoire multimodale persistante conserve images, données structurées et liens web sous forme d'artefacts adressables pendant toute la durée de la requête.
• Le coding interface exécute des programmes générés sur les données stockées, ce qui permet de calculer en combinant les résultats de plusieurs outils.

L'ensemble transforme la réponse en boucle itérative : obtenir un élément de preuve, l'examiner, le combiner avec d'autres. L'adressabilité des artefacts est ici le détail clé. Le modèle désigne une image ou un jeu de données précis dans la mémoire par son adresse, au lieu de les trimballer en entier dans son contexte.

Les chiffres

• Couverture : 22 benchmarks, huit backbones ouverts et propriétaires.
• Gain moyen par rapport au matched no-tool baseline : 9,7–12,6 points.
• Qwen3-VL-8B : +11,2.
• Kimi K3 : +9,7.
• GPT-6 Astra : +9,9.
• GPT-6 Luna à effort medium contre le modèle de base, Codex et Visual Sketchpad à effort maximal : avantage de 7,7 à 8,5 points.
• Consommation de tokens du modèle : au plus 37% de celle de ces concurrents.

L'écart entre modèles mérite l'attention. Le compact Qwen3-VL, avec 8 milliards de paramètres, gagne +11,2, soit plus que des modèles propriétaires phares comme GPT-6 Astra (+9,9). Pour les petits modèles, les outils et la mémoire compensent en partie le manque de capacités propres.

Que faire de ces résultats côté développeurs

La conclusion pratique pour ceux qui construisent des agents visuels : quand la qualité manque, mieux vaut d'abord revoir l'architecture autour du modèle plutôt que relever le reasoning effort. La comparaison avec Codex et Visual Sketchpad montre qu'un effort moyen associé à des outils bien organisés peut dépasser l'effort maximal sans outils, et ce pour un coût en tokens trois fois moindre.

Trois pratiques valent d'être adoptées dès maintenant. Convertir les sorties des outils dans un format que le modèle lit sans perte. Stocker images et données intermédiaires comme objets adressables, et non comme résumés textuels. Donner au modèle la possibilité de calculer un résultat par du code à partir des données stockées. Une réserve s'impose : les chiffres proviennent de la description des auteurs eux-mêmes, et le matériel ne contient aucune vérification indépendante. Il convient donc de les revérifier sur ses propres tâches avant tout déploiement.