Gemini 3.6 Flash compte les changements d'état mais ne détecte pas les clignements

Un article publié sur arXiv le 6 août affirme que les modèles de langage vidéo échouent à la simple tenue de registre d'événements et que les benchmarks standard masquent l'ampleur de l'échec. « The Low Frequency Trap: Video Language Models Fail at Simple Event Bookkeeping » teste Gemini 3.6 Flash avec un profilage paramétrique fondé sur les traces, une méthode qui audite les événements rapportés par un modèle au lieu de ne noter que la réponse finale.

La représentation des événements détermine si un modèle voit quoi que ce soit

Les chercheurs ont conçu trois tâches vidéo contrôlées : les contacts d'une balle rebondissante avec les parois, les clignements visuels et les transitions d'état catégorielles. Sur 2 190 vidéos, ils ont fait varier le nombre et la fréquence des événements tout en maintenant le rendu fixe, et chaque clip était accompagné d'une trace d'événements exécutable, afin que les prédictions puissent être vérifiées par rapport à la vérité terrain au niveau de l'horodatage.

L'échec se manifeste par étapes. Au seuil de fiabilité de 80 %, Gemini 3.6 Flash compte correctement les transitions d'état persistantes jusqu'à 12 événements à 0,5 et 1,0 Hz. Les événements de clignement transitoires n'atteignent jamais de région de comptage positif fiable. Selon les auteurs, la représentation des événements détermine si un modèle accède initialement aux preuves, et la limitation se cumule à mesure que le nombre et la fréquence augmentent.

Le modèle testé est une offre de production, pas une curiosité de laboratoire. Google a ajouté Gemini 3.6 Flash à sa gamme en juillet, en tant qu'option moins chère et plus efficace dans un lot de trois modèles comprenant également un Lite plus rapide et une variante cyber validée. La documentation de l'API Gemini de Google indique que ces modèles peuvent traiter des vidéos et en extraire des informations. Compter les clignements est exactement le genre de tâche simple que ce cadrage suggère.

Des images supplémentaires gonflent le score sans récupérer les événements

Le chiffre le plus frappant de l'article est l'écart entre la précision et la fidélité. L'augmentation de la fréquence d'échantillonnage fait passer la précision de Bounce Ball de 19,6 % à 29,3 %, mais la séquence d'événements rapportée ne concorde avec la vérité terrain que dans 3,7 % des cas. Des images supplémentaires, concluent les auteurs, peuvent gonfler les scores finaux sans produire de récupération fidèle des événements.

Le régime à comptage et fréquence élevés semble pire : seuls 0,2 % des comptes finaux sont corrects, et le modèle ne récupère que 18,1 % des événements réels. Des tests antérieurs d'ancrage temporel ont trouvé le même obstacle, la précision restant stable qu'il s'agisse d'augmenter les paramètres, la résolution d'entrée ou le nombre d'images par seconde. Un échantillonnage clairsemé signifie que l'événement peut ne pas exister du tout dans l'entrée du modèle.

Régime	Résultat
Transitions persistantes à 80 % de fiabilité	Compte jusqu'à 12 événements entre 0,5 et 1,0 Hz
Clignements transitoires	Aucune région de comptage positif fiable
Précision de Bounce Ball après plus d'images	19,6 % à 29,3 %
Séquence rapportée concordant avec la vérité terrain	3,7 %
Comptes finaux corrects, régime à comptage élevé	0,2 %
Événements réels récupérés, régime à comptage élevé	18,1 %

Les benchmarks basés sur la réponse finale laissent les modèles masquer l'échec

Les benchmarks programmatiques existants ne notent que la réponse finale, si bien qu'un modèle qui aboutit à un chiffre plausible semble compétent, quelle que soit la partie du clip qu'il a réellement manquée. La contribution de l'article est une alternative fondée sur les traces : chaque vidéo est fournie avec une trace exécutable, permettant une évaluation au niveau de l'horodatage et une estimation de la surface de capacités.

La distinction est pratique, pas académique. Les résultats des benchmarks vidéo dépendent du prétraitement des médias et de la sélection des images, de sorte que ces choix de pipeline décident d'une partie du score avant même que le modèle ne voie quoi que ce soit. Les auteurs ont également essayé différentes stratégies de prompt et ont constaté des gains tout aussi limités, ce qui pointe vers la manière dont le modèle représente les événements transitoires plutôt que vers la formulation de la question.

La vidéo du monde réel montre le même plafond de comptage faible

Les résultats contrôlés se retrouvent dans les images naturelles : les évaluations vidéo du monde réel montrent la même concentration de succès à de faibles nombres d'événements, exactement le régime où un modèle semble utilisable. Toute application qui nécessite de compter des événements brefs et discrets se trouve du mauvais côté de ce plafond.

Il y a ici une ironie architecturale. Les projets vidéo continus tels que VLX-Flow, présentés dans un article de blog Hugging Face par Om AI Lab, notent que la plupart des modèles vidéo ne commencent à regarder qu'après qu'un utilisateur a posé une question, ce que les appareils réels ne peuvent pas attendre. Si la représentation des événements est le goulot d'étranglement, le visionnage continu à lui seul ne réparera pas la tenue de registre. L'argument final de l'article est méthodologique : le profilage fondé sur les traces déplace l'évaluation vidéo de la précision globale vers un diagnostic de là où le raisonnement temporel échoue. Pour quiconque déploie un modèle vidéo, la différence entre un score qui paraît bon et une trace qui correspond est l'histoire.