Les IA vidéo en flux savent à peine redemander : le meilleur modèle n'obtient que 7,22% au test AskStream

Une équipe de l'Institut d'automatisation de l'Académie chinoise des sciences, de l'Académie d'IA de Pékin (BAAI) et de deux autres universités publie AskStream, un test pour les IA vidéo qui regardent un clip comme s'il s'agissait d'un direct. Il évalue une compétence que les modèles maîtrisent à peine : comprendre à temps qu'il manque de l'information, et la demander. Pour cela, les chercheurs ont conçu la métrique Ask-F1, qui ne valide une question que si elle est posée dans la bonne fenêtre temporelle et pour la bonne raison. Le meilleur modèle offline obtient 52,18%, le meilleur modèle en streaming 7,22%. L'écart est d'un facteur sept.

Pourquoi un modèle doit redemander

Le schéma habituel est simple : le modèle reçoit la vidéo entière, puis répond. Les modèles en streaming, eux, regardent le clip au fil de l'arrivée des images et répondent en temps réel. L'étape suivante, ce sont les modèles proactifs : ils choisissent eux-mêmes le moment de répondre, par exemple pour signaler une anomalie ou guider l'utilisateur pas à pas. Tous ces schémas supposent que le flux finira par contenir tout ce qu'il faut pour répondre.

En pratique, ce n'est pas le cas. L'objet utile peut être flou, la caméra peut filmer du mauvais côté, l'utilisateur peut poser une question ambiguë. Le modèle attend alors indéfiniment, ou invente une réponse. Les auteurs proposent une troisième action, en plus d'« attendre » et de « répondre » : demander.

Ils ont mesuré l'utilité de cette action. Lorsque l'objet clé de la vidéo est flou, la précision des réponses atteint 42,3%. Après une demande de vidéo nette, elle monte à 62,3%. Avec une vidéo parfaitement nette d'emblée, elle est de 63,1%. Les demandes de précision inadaptées n'aident presque pas. L'information correcte, elle, réduit l'incertitude du modèle et fait basculer la probabilité vers la bonne réponse.

Huit situations où il faut poser une question

L'incertitude a deux sources : la vidéo et l'utilisateur. Ensemble, elles donnent huit sous-tâches :

• KVEM — l'objet clé du plan est flou ; il faut demander une vidéo plus nette.
• VIM — les détails nécessaires ne sont pas visibles depuis l'angle actuel ; il faut en demander un autre.
• ICM — un objet est visible à l'écran, mais le modèle ignore ce qu'il représente pour l'utilisateur (par exemple, à qui appartient-il) ; il doit poser la question.
• PACM — l'utilisateur effectue une action qu'il désigne par un nom qui lui est propre, et dont le modèle ne connaît pas la définition.
• AUQ — la question est ambiguë ; il faut clarifier l'intention.
• Question à fausse prémisse — le modèle doit remarquer que la question contredit la vidéo, corriger l'utilisateur, puis répondre.
• UPM — la réponse dépend des goûts de l'utilisateur, par exemple son style, et il faut les lui demander.
• UPC — les préférences enregistrées sont périmées, et le modèle doit demander les préférences actuelles.

Dans certaines tâches, le problème est visible tout de suite : le modèle doit alors poser sa question, puis attendre les images utiles. Dans d'autres, le manque n'apparaît qu'au fil de la vidéo, et la question doit venir plus tard. Un tour est validé si la bonne question est posée dans la bonne fenêtre, puis suivie d'une réponse correcte.

Construction et évaluation

Le test comprend 438 vidéos et 1 401 questions réparties sur neuf domaines. Les clips durent de 16,72 secondes à 118 minutes. Les vidéos proviennent de YouTube et de jeux de données existants ; une partie a été synthétisée dans Blender. Le floutage des objets a été réalisé avec Grounded SAM 2, et PySceneDetect a servi au découpage. Les variantes de réponses ont été générées par GPT-5.6 Sol, puis chaque exemple a été vérifié par des humains : sans l'information manquante, on ne peut pas répondre de façon univoque ; avec elle, on le peut. Au total, le test compte 2 714 repères temporels précis à l'image près, soit 3,2 tours en moyenne par vidéo.

Pour les modèles offline, qui ne savent pas travailler sur un flux, les auteurs ont mis en place une mémoire hiérarchique. Les 10 dernières images (1 image par seconde) sont conservées telles quelles. Toutes les 10 images, elles sont compressées en une entrée de mémoire intermédiaire. Toutes les quatre entrées de ce type sont fusionnées en une entrée de long terme, avec au maximum huit blocs de long terme. Le modèle prend une décision une fois par seconde, avec une tolérance de ±1 seconde. En mode ouvert, les réponses sont évaluées par Gemini-3.8 Flash.

Ce que montrent les résultats

Parmi les modèles offline, Gemini-3.8 Flash se détache : par sous-tâche, 37,17% sur KVEM, 43,10% sur les questions à fausse prémisse et 81,36% sur UPC. Les résultats varient toutefois fortement selon le type d'incertitude.

Les modèles proactifs en streaming s'en sortent bien moins bien : sur la plupart des sous-tâches, ils obtiennent zéro, et beaucoup n'ont pas réussi à exécuter la tâche. Le meilleur d'entre eux, AURA, n'atteint que 7,22%.

Les erreurs sont le plus souvent de deux types : une question trop précoce, posée alors que les éléments de preuve n'existent pas encore, et une question qui ne porte pas sur le fond. Si l'on indique au modèle quand et quoi demander, l'Ask-F1 progresse de 43,83 points de pourcentage. Autrement dit, l'échec principal ne se situe pas dans les réponses, mais dans la capacité à repérer la lacune.

Ce que cela signifie pour les développeurs

Pour les assistants vidéo, qu'il s'agisse de conseils du quotidien ou d'accompagnement d'opérations à distance, cette capacité est quasiment indispensable. Un assistant qui répond avec assurance à partir d'une image floue est plus dangereux qu'un assistant qui demande à revoir la scène. Pour l'instant, les modèles en streaming n'y sont pas prêts, et le benchmark leur fournit un objectif mesurable. Les limites du test : son échelle modeste (1 401 questions) et sa forte dépendance à des modèles juges en mode ouvert.