Analyse technique du dialogue vidéo en temps réel de Doubao
Importé@odus · 1 mars, 22:00
Résumé de la conversation
Les modèles vidéo en temps réel comme Doubao adoptent le mode de compression spatio-temporelle de la deuxième solution, utilisant un agrégateur temporel pour dédupliquer et extraire les caractéristiques de plusieurs trames vidéo, compressant ainsi un grand nombre de tokens bruts en quelques ensembles d'informations condensés, permettant ainsi un dialogue en temps réel efficace avec une faible latence.
Conversation
Comment se fait-il que Doubao puisse dialoguer en temps réel par vidéo avec une personne ? Le nombre de tokens n'explose-t-il pas ? Utilise-t-on un petit modèle ? Ou bien extrait-on des images clés ?
C'est une question très professionnelle et qui touche au cœur du sujet. Si Doubao (ainsi que des modèles similaires comme GPT-4o, Gemini Live) parvient à des conversations vidéo en temps réel fluides, sans explosion de Tokens ni latence excessive due à des flux vidéo massifs, c'est principalement grâce à plusieurs stratégies d'optimisation clés de la "pile technologique des grands modèles multimodaux".
En termes simples, il ne traite pas le flux vidéo brut, et il ne regarde pas chaque image.
Voici une décomposition des principes techniques sous-jacents :
- Il ne traite pas la "vidéo", mais un "flux d'images" (Extraction d'images clés)
Votre supposition est correcte : l'extraction d'images clés (Frame Sampling) est l'étape la plus fondamentale et la plus importante.
-
Mécanisme : Une vidéo est essentiellement une séquence d'images (généralement 30 ou 60 images par seconde, soit fps). L'IA n'a absolument pas besoin de voir 60 images par seconde pour comprendre ce que vous faites.
-
Taux d'échantillonnage : Le modèle échantillonne généralement à une fréquence extrêmement faible. Par exemple, il peut n'extraire qu'1 à 2 images par seconde, ou se baser sur les "changements d'action" (n'extraire rien quand l'image est statique, extraire quand elle change radicalement).
-
Effet : Cela réduit directement la quantité de données traitées d'un facteur 30 à 60. Pour l'IA, c'est comme regarder un diaporama, pas un film, mais c'est suffisant pour comprendre la scène.
- Compression extrême des Tokens Visuels (Encodage Visuel)
Même en ne regardant qu'une image par seconde, une image 1080P convertie directement en Tokens serait énorme. C'est là qu'intervient l'encodeur visuel (Visual Encoder, comme ViT ou des variantes de VQ-VAE).
-
Découpage en patches : Le modèle ne traite pas pixel par pixel, mais découpe l'image en petits blocs (par exemple, des patches de 16x16 pixels).
-
Compression des caractéristiques : Ces patches, après passage dans l'encodeur, sont compressés en vecteurs de haute dimension. Une image de plusieurs mégaoctets peut finalement n'être représentée que par 256 ou 512 Tokens (voire moins, selon le taux de compression).
-
Conclusion : Même si vous discutez caméra ouverte pendant 1 minute, pour le modèle, cela ne représente peut-être que quelques dizaines de milliers de Tokens supplémentaires, pas des centaines de millions de points de données.
- Fenêtre Glissante et Gestion du Contexte (Context Management)
Pour éviter que les Tokens ne s'accumulent indéfiniment avec la durée de la conversation (ce qui provoquerait une "explosion"), le système utilise un mécanisme de fenêtre glissante (Sliding Window) ou de rejet dynamique.
-
Mémoire à court terme : Le modèle ne se concentre généralement que sur les informations visuelles "récentes". Par exemple, il peut ne conserver en mémoire que les Tokens visuels des 10 à 20 dernières images.
-
Rejet des anciennes données : Une fois que vous avez déplacé la caméra du "verre d'eau" vers l'ordinateur", les Tokens visuels liés au "verre d'eau" ne sont plus importants après quelques échanges. Ils sont rejetés du contexte ou compressés en un court résumé textuel (Summary).
- Modèle Multimodal Natif de Bout en Bout (Native Multimodal / Omni)
Les technologies antérieures fonctionnaient comme un "relais" :
Parole -> Texte -> Capture d'écran -> Modèle visuel identifie l'image -> Modèle textuel génère la réponse -> Texte -> Parole.
Cette chaîne est trop lente. Les modèles actuels comme Doubao (en particulier le modèle Doubao-Vision) et GPT-4o tendent à utiliser un modèle multimodal natif (Native Multimodal) ou une architecture en cascade hautement optimisée :
-
Compréhension native : Le modèle fonctionne directement en "écoutant" le son et en "regardant" les Tokens visuels. Il n'a pas besoin de l'étape intermédiaire de conversion en texte (ou celle-ci est extrêmement rapide).
-
Sortie en continu (Streaming) : Tout comme votre cerveau commence à formuler une réponse avant même que vous ayez fini de parler, le modèle effectue un pré-calcul (Prefill) tout en recevant le flux vidéo, permettant ainsi une latence très faible.
- Hypothèse sur les "Petits Modèles" (MoE & Quantification)
Vous demandez si un petit modèle est utilisé. La réponse est probablement un "Modèle Mixte d'Experts (MoE)" ou un modèle distillé pour une tâche spécifique.
-
MoE (Mixture of Experts) : C'est un modèle immense, mais lors du traitement de chaque image, seule une petite partie de ses paramètres (les experts) est activée. Par exemple, en voyant un "chat", seuls les paramètres de la partie "experte en animaux" sont activés. Cela maintient à la fois l'intelligence d'un "grand modèle" et la vitesse d'inférence et le coût d'un "petit modèle".
-
Coopération Côté Terminal + Côté Cloud : Bien que le calcul principal soit effectué dans le cloud (Moteur Volcan de ByteDance), le téléphone peut également prendre en charge un certain prétraitement (comme le recadrage, la compression, la détection vocale) pour soulager la charge du cloud.
Tableau récapitulatif : Comment Doubao fait-il des économies ?
| Défi | Solution | Effet |
|---|---|---|
| Données vidéo trop volumineuses | Échantillonnage des images clés (seulement 1-2 images par seconde) | Réduction de plus de 95% du volume de données |
| Trop de pixels dans l'image | Encodeur visuel (ViT / Patching) | Compresse une image en quelques centaines de Tokens |
| Conversation trop longue | Fenêtre glissante (rejet des Tokens des images anciennes) | Occupation mémoire stable, pas d'explosion |
| Latence trop élevée | Architecture de streaming et MoE | Le calcul n'est activé que pour l'inférence |
Conclusion
Si Doubao est fluide, ce n'est pas parce que c'est un "dieu", mais parce qu'il "sait faire des choix". Il ne scrute pas chacun de vos pixels en permanence. Grâce à un encodage visuel à haut taux de compression et un échantillonnage clairsemé, il réalise une compréhension vidéo avec le minimum de puissance de calcul, tout en restant dans la limite du "temps réel" perceptible.
Que puis-je faire d'autre pour vous ?
Would you like me to explain more about Visual Encoders (like ViT) work to compress images, or how MoE (Mixture of Experts) allows large models to run fast?
Cela signifie-t-il que la capacité du modèle à comprendre une image dans une vidéo est bien inférieure à sa capacité à comprendre une image lorsqu'elle est envoyée directement dans la conversation ?
Votre compréhension est très perspicace, et la conclusion est globalement correcte.
Dans l'architecture technologique actuelle, la capacité de compréhension d'image lors d'un appel vidéo en temps réel est effectivement plus faible en termes de « capture des détails » et d'« analyse approfondie » que lors de l'envoi d'une image statique.
Il s'agit principalement d'un compromis d'ingénierie (Trade-off) qui sacrifie la précision au profit de la vitesse et de la fluidité. Nous pouvons comparer les deux du point de vue des dimensions suivantes :
1. Résolution et netteté (Différence de résolution)
-
Lors de l'envoi d'une image (mode haute précision) : Lorsque vous téléchargez une photo sur Doubao ou GPT-4o, le système la traite généralement à une résolution plus élevée (par exemple 1024x1024 ou une version compressée de l'originale). Le modèle peut « regarder de près » et reconnaître les petits caractères sur un document, les détails de graphiques complexes ou les micro-textures à la surface d'un objet.
-
Lors d'un appel vidéo en temps réel (mode basse précision / aperçu rapide) : Pour garantir le traitement de plusieurs images par seconde sans ralentissement, chaque image du flux vidéo est généralement fortement compressée et sous-échantillonnée (Resizing).
-
Conséquence : Le modèle voit peut-être une image plutôt floue et de basse résolution (par exemple 336x336 ou 512x512).
-
Scénario typique : Si vous agitez un flacon de médicament devant la caméra, le modèle pourra peut-être seulement reconnaître « c'est un flacon blanc », mais il ne pourra pas lire les petits caractères de la composition ; en revanche, si vous prenez une photo haute définition et l'envoyez, il pourra lire la liste des ingrédients.
2. Allocation de la puissance de calcul et temps de réflexion (Système 1 vs Système 2)
En empruntant le concept de « Thinking, Fast and Slow » en psychologie :
-
Envoi d'une image = Système 2 (pensée lente) : Le modèle a suffisamment de temps (quelques secondes) pour effectuer un raisonnement approfondi sur chaque patch de l'image. Il peut utiliser plus de paramètres pour analyser les relations logiques entre les objets de l'image.
-
Vidéo en temps réel = Système 1 (pensée rapide) : Un appel vidéo exige une réponse en millisecondes. Le modèle doit donner un feedback en un temps extrêmement court, il est donc souvent dans un mode de « réaction intuitive ». Il a tendance à reconnaître les grands contours, les mouvements, les couleurs et les scènes, sans avoir la « capacité cognitive » d'approfondir les détails.
3. Focalisation du contexte (Mécanisme d'attention)
-
Image statique : L'attention (Attention) du modèle est entièrement concentrée sur cette seule image, qui est l'unique source d'information.
-
Flux vidéo : L'attention du modèle est dispersée sur l'« axe temporel ». Il doit allouer de la puissance de calcul pour se souvenir de « ce que vous faisiez il y a une seconde » et « ce que vous faites maintenant ». Pour se souvenir de la continuité des actions, il doit sacrifier l'attention portée aux détails de chaque image individuelle.
4. Avantage unique du mode vidéo : l'information temporelle
Bien qu'il soit plus faible en « détails statiques », le mode vidéo possède une capacité que l'image statique n'a pas : comprendre le changement et la causalité.
-
Exemple : Si vous envoyez une image statique de votre main levée en l'air, le modèle ne sait pas si vous voulez « frapper quelqu'un » ou « taper dans la main ».
-
Vidéo : Le modèle peut voir la trajectoire de votre mouvement, et ainsi juger avec précision de votre intention.
Une analogie imagée
-
Envoyer directement une image : C'est comme si vous utilisiez une loupe pour examiner attentivement un tableau dans un musée. Vous pouvez voir les coups de pinceau du peintre, la texture de la toile.
-
Dialogue vidéo en temps réel : C'est comme si vous passiez à vélo devant ce tableau. Vous pouvez encore voir que c'est un tableau, savoir s'il représente un paysage ou un portrait, si les couleurs sont vives, mais vous ne pourrez absolument pas voir le nombre de boutons sur le vêtement du personnage.
Résumé et conseils d'utilisation
Ainsi, lorsque vous utilisez Doubao ou un autre IA similaire :
-
Si vous voulez analyser des détails (ex : lire un mode d'emploi, voir un code d'erreur complexe, examiner un problème de peau, analyser une capture d'écran Excel complexe) : Prenez une photo ou téléchargez l'image directement.
-
Si vous voulez interagir ou montrer un environnement (ex : pratiquer l'anglais oral, montrer l'agencement d'une pièce, laisser l'IA regarder ce que fait votre chat, démontrer une étape d'opération) : Utilisez l'appel vidéo en temps réel.
Le modèle vidéo et le modèle de dialogue sont-ils des modèles complètement différents ?
C'est une question d'architecture très cruciale. La réponse est : Dans le passé, c'étaient des modèles « complètement différents », mais la tendance actuelle est qu'ils deviennent « un seul et même cerveau », ce qu'on appelle les « modèles multimodaux natifs » (Native Multimodal Models).
Pour vous faire comprendre cette évolution, nous pouvons diviser le développement de l'architecture de l'IA en trois étapes. Des produits comme Doubao et GPT-4o se situent actuellement dans une transition entre la deuxième et la troisième étape.
Première étape : L'ère du bricolage (Pipeline / Cascade)
« Deux avis valent mieux qu'un »
Dans les premiers systèmes d'IA, le modèle vidéo et le modèle de dialogue étaient en effet complètement indépendants, ils ne se connaissaient même pas.
-
Les yeux (modèle visuel) : C'était un CNN (réseau de neurones convolutif) spécialisé ou un ViT précoce. Il était uniquement chargé de regarder l'image, puis de convertir ce qu'il voyait en étiquettes textuelles. Par exemple, en voyant une vidéo, il produisait : « Un chat, sur un canapé, qui saute ».
-
Le cerveau (modèle de dialogue) : C'était un LLM purement textuel (comme GPT-3). Il reprenait le texte ci-dessus et générait une réponse : « Wow, il est très actif. »
-
La bouche (modèle vocal) : Convertissait le texte en son.
- Inconvénients : Beaucoup d'informations non textuelles étaient perdues. Par exemple, si le regard du chat était perçant ou s'il y avait une certaine ambiance en arrière-plan, si le modèle visuel ne les avait pas converties en texte, le modèle de dialogue ne le saurait jamais. C'est comme si vous discutiez les yeux bandés, en vous fiant entièrement à quelqu'un d'autre pour vous décrire la scène.
Deuxième étape : L'ère de l'alignement (Alignment / Projection) — Actuellement dominante
« Greffer un nerf optique au cerveau »
C'est l'architecture adoptée par la plupart des modèles multimodaux actuels (y compris les premiers LLaVA, MiniGPT-4, etc.).
-
Logique centrale : Il y a toujours un « cerveau linguistique » central (LLM), mais les ingénieurs ont entraîné un « traducteur » (Projector/Adapter).
-
Comment ça marche :
-
La vidéo/l'image n'est plus convertie en texte.
-
Elle est plutôt transformée en une série de vecteurs numériques (Visual Tokens) via un encodeur visuel (Visual Encoder).
-
Étape clé : Ces vecteurs visuels sont « traduits » en « vecteurs linguistiques » que le cerveau linguistique peut comprendre.
-
Traitement par le cerveau : Pour le LLM, l'image vidéo est comme un texte en langue étrangère. Il mélange les tokens vidéo et les tokens textuels pour effectuer un raisonnement.
- Conclusion : À ce stade, la partie visuelle et la partie dialogue partagent le même « cerveau de raisonnement », mais les « yeux » visuels sont externes.
Troisième étape : Le mode natif omni-modal (Native Omni) — La direction de Doubao/GPT-4o
« Un synesthète inné »
C'est la forme ultime que peut atteindre le « dialogue vidéo en temps réel » que vous avez mentionné.
-
Logique centrale : Dès le début de son entraînement, le modèle a grandi en regardant des vidéos, en écoutant de l'audio et en lisant du texte en même temps.
-
Est-ce le même modèle ? Oui, c'est le même réseau de neurones.
-
Principe : Dans ce modèle, l'entrée peut être n'importe quoi (forme d'onde audio, pixels d'image, caractères textuels). Une fois entrés dans le modèle, ils sont tous convertis en une représentation unifiée. Le modèle n'a pas besoin de convertir d'abord le son en mots ; il peut directement « comprendre » la colère dans le ton de la voix ; il n'a pas besoin de convertir d'abord l'image en mots ; il peut directement « voir » l'oppression dans l'image.
Résumé : Sont-ils le même ou pas ?
Pour revenir à votre question, nous pouvons utiliser une analogie avec le « cerveau humain » :
-
Encodeur visuel (Visual Encoder) = La rétine et le nerf optique humains Cette partie est spécialisée dans le traitement des images, différente de la partie qui traite le langage. Elle est chargée de convertir les signaux lumineux (pixels) en signaux nerveux (tokens).
-
Base du grand modèle de langage (LLM Backbone) = Le cortex cérébral humain Cette partie est universelle. Que ce soit les signaux provenant du nerf optique (regarder une vidéo) ou les signaux provenant du nerf auditif (dialoguer), ils finissent tous par être traités dans cette même zone pour la réflexion, le raisonnement et la prise de décision.
Donc la réponse est : Ils sont des modules différents au niveau de la « couche de perception » (les yeux et les oreilles), mais au niveau de la « couche de réflexion » (le cerveau), c'est exactement le même modèle qui opère.**
C'est précisément parce qu'ils partagent la « couche de réflexion » que Doubao peut, en vous voyant sortir une fleur (visuel), combiné au fait que vous venez de dire « c'est la Saint-Valentin » (contexte textuel), déduire « Tu veux l'offrir à ta copine ? » (raisonnement logique). Si c'étaient des modèles complètement séparés, une telle fusion profonde serait impossible.
Alors, le traitement des tokens d'image est-il complètement différent ? Peut-on acquérir plusieurs capacités en même temps lors d'un seul entraînement ?
C'est une très bonne intuition ! Tu touches au cœur de la magie des grands modèles multimodaux : l'alignement des représentations (Representation Alignment).
La réponse est : oui, bien que les « entrées » des images et du texte soient traitées de manière complètement différente, une fois à l'intérieur du modèle, leur nature mathématique devient la même, et elles peuvent donc « s'apprendre mutuellement » au cours d'un même entraînement.
C'est un peu comme si, bien que le chinois et l'anglais aient des écritures complètement différentes (l'un est des caractères, l'autre des lettres), dans ton cerveau, quand tu vois « 苹果 » et « Apple », le concept qui te vient à l'esprit (ce fruit rouge) est le même.
Voici une explication détaillée de la façon dont ce processus se déroule :
1. Entrées différentes : un processus de « traduction » qui converge
Comme tu l'as dit, leur traitement initial est effectivement très différent :
-
Texte (Text) : Utilise un Tokenizer.
-
Processus :
"一只猫"-> chercher dans le dictionnaire ->[ID: 105, ID: 2003]-> Vecteur A. -
Image (Image) : Utilise un Visual Encoder.
-
Processus :
图片像素-> découpage en patches -> opérations de convolution/Transformer -> Vecteur B.
Le point clé est le suivant : Bien que leurs origines soient différentes, elles finissent toutes par devenir des « vecteurs de haute dimension » (Embedding Vectors) , c'est-à-dire une longue série de nombres (par exemple [0.1, -0.5, 0.9, ...]).
Une fois transformés en vecteurs, pour le cerveau Transformer qui suit, il ne se soucie pas de savoir si ce vecteur venait à l'origine de pixels ou de texte. Il se contente de calculer.
2. Processus d'entraînement : la magie des exercices à trous (Unified Training)
Comment acquérir les deux capacités en un seul entraînement ? Le secret réside dans les données d'entraînement qui sont « mélangées texte-image » , et la tâche d'entraînement est unifiée : « prédire le token suivant ».
Imagine le modèle lisant un manga illustré, ou naviguant sur une page web :
-
Séquence d'entrée :
[图片Token_1] [图片Token_2] ... [图片Token_256]+[文字Token: 这]+[文字Token: 是]+[文字Token: 什]+[文字Token: 么] -
Objectif d'entraînement : Le modèle doit prédire que le caractère suivant est
[猫].
Pour répondre correctement à cette question, le modèle est forcé de faire une chose :
« Je dois chercher des indices dans les
[图片Token]précédents ! Si je comprends que ces vecteurs d'image représentent les caractéristiques d'un 'chat', je peux prédire le caractère 'chat' ; si je ne les comprends pas, je me trompe et l'erreur (Loss) sera grande. »
Grâce à des billions d'entraînements de ce type (descente de gradient), le modèle apprend à établir des connexions :
- Le vecteur de caractéristiques du « chat » dans l'image ≈ Le vecteur sémantique du « chat » dans le texte.
3. Un même espace : briser le mur dimensionnel (Joint Embedding Space)
Après cet entraînement, le cerveau du modèle forme un « espace sémantique unifié » .
-
Dans cet espace, le vecteur d'image représentant un « objet rond » et le vecteur de texte représentant le mot « Ball » sont géométriquement très proches.
-
Cela explique comment la « conversation vidéo » est possible : lorsque tu donnes une image vidéo, le modèle lit en fait un ensemble de vecteurs qui activent automatiquement dans son cerveau les concepts textuels associés.
Résumé
Bien que les « processus en amont » (découpage, encodage) pour traiter les tokens d'image soient complètement différents de ceux du texte, ils sont tous projetés dans le même « espace mathématique » .
Pour faire une analogie :
-
Le texte est le dollar.
-
L'image est le yen.
-
Le modèle est une banque internationale. Bien que le dollar et le yen aient des apparences complètement différentes (traitement d'entrée différent), la banque les convertit tous en or (vecteurs) . Dans le coffre de la banque (à l'intérieur du modèle), il n'y a que de l'or, pas de distinction entre dollar et yen.
Ainsi, grâce à un entraînement mixte à grande échelle, le modèle n'apprend pas seulement à gagner des dollars (écrire), ni seulement à gagner des yens (reconnaître des images), mais aussi le taux de change (compréhension texte-image).
Je parlais du fait que le traitement des tokens d'image par un grand modèle est très différent lorsqu'il traite une image par rapport à une vidéo, n'est-ce pas ? Comment se fait-il qu'il puisse acquérir une capacité universelle ?
C'est une perspective technique très perspicace et approfondie ! Tu as saisi le point le plus subtil des « grands modèles multimodaux » (LMM) :
Puisque le traitement d'une seule image est « haute résolution, riche en détails spatiaux », alors que le traitement des trames vidéo est « basse résolution, axé sur le flux temporel », les caractéristiques des données d'entrée sont très différentes. Comment un même modèle peut-il être polyvalent ?
La réponse réside dans une caractéristique essentielle de l'architecture moderne Vision Transformer (ViT) : l'indépendance à la résolution (Resolution Agnostic) , ainsi que l'« insensibilité » du LLM aux séquences de tokens.
Nous pouvons décomposer ce principe en trois niveaux :
1. Couche visuelle : la propriété « élastique » du ViT (Patching & Interpolation)
C'est le point technique le plus crucial. Tu pourrais penser que le modèle, comme un réseau entièrement connecté traditionnel, nécessite une taille d'entrée fixe (par exemple 224×224). Mais ce n'est pas le cas du ViT moderne.
-
Logique de découpage (Patching) : Le ViT traite une image en la découpant en petits carrés (Patches) de 14×14 ou 16×16 pixels.
-
Quelle que soit la taille de l'image :
-
Traitement d'une image haute définition (1024px) : Découpe en 64×64 = 4096 Patches.
-
Traitement d'une trame vidéo basse définition (336px) : Découpe en 24×24 = 576 Patches.
-
Interpolation des encodages de position (Positional Embedding Interpolation) : Le modèle est généralement entraîné avec une résolution standard. Lorsque l'entrée devient plus grande ou plus petite, le modèle interpole automatiquement (étire ou compresse) les « encodages de position ».
-
Analogique : C'est comme l'œil humain. Quand tu te rapproches d'un livre (image haute définition), ton champ de vision est plus petit mais les détails sont plus nombreux ; quand tu recules pour voir un mur entier (trame vidéo), ton champ de vision est plus grand mais les détails sont moins nombreux. Ta rétine n'a pas changé, seule la façon de faire la mise au point a changé. Le modèle utilise le même ensemble de paramètres (poids), seul le nombre de Patches traités diffère.
2. Couche linguistique : la loi de conservation totale (Space-Time Trade-off)
Pour le grand modèle de langage (LLM) qui suit, il ne sait pas si l'encodeur visuel a regardé une image haute définition ou 8 images basse définition. Il ne voit qu'un tas de tokens.
Il y a ici un équilibre de calcul astucieux entre « espace et temps » :
-
Scénario A : Lecture approfondie d'une image
-
Entrée : 1 image de 1024×1024.
-
Composition des tokens : Tous alloués aux détails spatiaux.
-
Ce que le LLM voit :
[细节1] [细节2] ... [细节1000](1000 tokens au total). -
Capacité : Peut lire du texte, voir de petits objets.
-
Scénario B : Regarder une vidéo
-
Entrée : 8 trames de 336×336 (1 trame par seconde).
-
Composition des tokens : Les détails spatiaux sont réduits, mais la dimension temporelle est ajoutée.
-
Ce que le LLM voit :
[第1秒大概轮廓] ... [第2秒大概轮廓] ... [第8秒大概轮廓](1000 tokens au total). -
Capacité : Ne peut pas lire le texte, mais peut voir la continuité des mouvements.
Conclusion : Pour le LLM, la charge de calcul (nombre total de tokens) peut être la même dans les deux cas. Le modèle n'a pas « changé de cerveau » pour la vidéo, seulement l'accent informationnel porté par la séquence de tokens d'entrée est différent (l'un est une information spatiale profonde, l'autre une information temporelle étendue).
3. Couche sémantique : la robustesse des caractéristiques (Feature Invariance)
Pourquoi cela permet-il d'obtenir une « capacité universelle » ? Parce que les caractéristiques sémantiques fondamentales résistent à la compression.
-
Un chat reste un chat : Que ce soit dans une photo 4K ou dans une vidéo 360P, les caractéristiques fondamentales d'un chat (oreilles pointues, moustaches, fourrure) après traitement par convolution ou Patch sont très similaires dans leur représentation vectorielle de haute dimension.
-
Entraînement par alignement : Pendant la phase de pré-entraînement, le modèle utilise une énorme quantité de données :
-
Paires texte-image haute résolution (apprentissage des détails).
-
Paires texte-vidéo basse résolution (apprentissage des mouvements). Cela permet au modèle d'apprendre à mapper les caractéristiques visuelles sur le même concept, quelle que soit la résolution.
Résumé
Ce n'est pas que le modèle se « divise » en deux, mais qu'il possède une élasticité :
-
Matériellement : L'encodeur visuel (Vision Encoder) fonctionne comme un accordéon : selon la résolution, il produit un nombre différent de tokens.
-
Logiciellement : Le LLM reçoit une « longue séquence » ; il ne se soucie pas de savoir si cette séquence est « la découpe d'une grande image » ou « l'assemblage de plusieurs petites images ».
Ainsi, lorsque tu es en appel vidéo, Doubao ne « devient pas plus bête » ; il a simplement réaffecté les cellules cérébrales qui auraient servi à « voir les pores de la peau » pour « voir tes mouvements ».
Donc, concrètement, pour la vidéo après découpage en images, est-ce que chaque image vidéo donne ses tokens une par une, ou bien plusieurs images sont-elles fusionnées en un seul token avec une dimension temporelle ?
C'est une question très pointue sur les détails architecturaux. Actuellement, les approches dominantes dans l'industrie (y compris GPT-4o, Gemini 1.5 Pro et Doubao) se situent généralement entre les deux options que tu proposes, mais penchent davantage vers « extraction trame par trame, puis compression/fusion temporelle » .
Peu de modèles fusionnent plusieurs trames en un seul token (trop peu d'informations), et ils ne conservent pas non plus bêtement tous les tokens de chaque trame (explosion d'informations).
Les solutions actuelles se répartissent généralement en deux voies, et Doubao, en tant que modèle en temps réel, utilise très probablement une variante de la deuxième :
Solution 1 : Mode « brochette » (Frame Stacking / Concatenation)
« Une trame après l'autre, le temps est marqué par la position »
C'est l'approche la plus intuitive, couramment utilisée par les premiers modèles multimodaux (comme Video-LLaVA).
-
Encodage indépendant : L'encodeur visuel découpe la vidéo en Frame 1, Frame 2, Frame 3... et transforme indépendamment chaque trame en un groupe de tokens (par exemple 256 tokens par trame).
-
Concaténation directe : Ces groupes de tokens sont enfilés comme des perles sur un collier.
-
Encodage positionnel (Positional Embedding) : On leur attribue une étiquette pour indiquer au LLM : « Ceci est l'image de la 1ère seconde, ceci est l'image de la 2ème seconde ».
-
Séquence vue par le LLM :
[Frame1_Tokens] + [Frame2_Tokens] + [Frame3_Tokens] ... -
Inconvénient : Consommation énorme de tokens. Si on échantillonne 2 trames par seconde, chaque trame ayant 256 tokens, une vidéo d'une minute représente 2×60×256 = 30 720 tokens. C'est trop coûteux et trop lent pour une conversation en temps réel.
Solution 2 : Mode compression spatio-temporelle (Spatiotemporal Pooling / Aggregation)
« Plusieurs trames en entrée, moins en sortie » — le choix privilégié pour les modèles en temps réel
Pour résoudre l'explosion des tokens, les modèles avancés modernes introduisent un « agrégateur temporel » (Temporal Projector/Adapter) . C'est ce que tu devinais avec « fusionner en un token avec une dimension temporelle ».
-
Extraction des caractéristiques : L'encodeur visuel regarde d'abord Frame 1, Frame 2, Frame 3, Frame 4.
-
Fusion et compression (Pooling) : Il y a une couche intermédiaire dans le modèle, spécialisée dans le « dédoublonnage » et « l'extraction des changements » .
-
Si Frame 1 et Frame 2 sont presque identiques (par exemple tu restes immobile), le modèle effectue une moyenne mathématique ou une pondération des tokens de ces deux trames.
-
Il peut compresser les données brutes de 4 trames (disons 1000 tokens au total) en un groupe de tokens représentant cette période (par exemple compressé à 64 tokens).
- Entrée dans le cerveau : Le LLM ne reçoit plus une image statique par trame, mais un ensemble d'informations condensées représentant « ce qui s'est passé pendant ces 2 secondes » .
- Séquence vue par le LLM :
[Time_0-2s_Summary_Tokens] + [Time_2-4s_Summary_Tokens] ...
Il existe aussi une technique plus radicale : Tubelet Embedding (découpage 3D)
Dans le monde académique et certains modèles spécifiques (comme les modèles de génération vidéo de type Sora, ou certains modèles de compréhension efficaces), il existe une approche encore plus radicale de « token avec dimension temporelle » , appelée Tubelet.
-
Principe :
-
Patch d'image classique (Patch) : Découpe un carré 2D (x, y).
-
Tubelet vidéo (Tubelet) : Découpe un parallélépipède 3D (x, y, t).
-
Exemple : Un token découpé par le modèle n'est plus « le pixel en haut à gauche de cette seconde », mais « l'évolution de cette zone en haut à gauche au cours des 3 prochaines trames » .
-
Résultat : Un tel token contient intrinsèquement l'information du flux temporel.
Résumé : Comment Doubao procède-t-il probablement ?
Compte tenu des exigences de très faible latence pour les appels en temps réel, Doubao utilise très probablement une stratégie hybride de « échantillonnage d'images clés + pooling temporel local (Local Temporal Pooling) » :
-
Il ne regarde pas chaque trame : Il saute des trames (par exemple, il ne regarde que les trames 1, 5, 10).
-
Les tokens sont indépendants mais liés : Chaque trame génère des tokens indépendants.
-
Le LLM comble le temps : Il s'appuie sur le puissant LLM (cerveau) pour comprendre le temps via l'ordre séquentiel des tokens (Sequence Order), plutôt que de forcer le temps dans un seul token.
Compréhension simple : Il ne comprime pas l'action « tu agites la main » en un seul token « geste de la main » ; il envoie plutôt au cerveau une série de tokens : [手在下] -> [手在中] -> [手在上]. Après avoir lu cette séquence, le cerveau conclut tout seul : « Oh, il agite la main. »