Comment Netflix orchestre ses pipelines d’IA multimodale pour la recherche vidéo

Une seule saison d’une série Netflix peut générer plus de 2 000 heures de rushes. Pour les amateurs de chiffres, cela représente environ 216 millions de frames individuelles. Quand un monteur doit retrouver l’instant précis où un personnage prononce une réplique spécifique dans un décor bien particulier, il se retrouve face à l’un des problèmes de recherche les plus complexes de l’ingénierie logicielle.

Au début, on pourrait penser que la solution réside simplement dans la création d’un modèle d’IA ultra-puissant. Mais la réalité, comme j’ai souvent pu le constater sur des architectures de production, est bien différente : c’est avant tout une question de plomberie et d’infrastructure.

Auparavant, les équipes éditoriales de Netflix perdaient des journées entières à chercher des moments précis perdus dans des milliers d’heures de rushes. Un réalisateur pouvait avoir besoin de tous les plans d’un personnage dans un décor donné, tandis qu’une équipe marketing cherchait les cinq séquences d’action les plus marquantes d’une franchise. Pour trouver ces moments, il fallait passer des heures à faire défiler manuellement les images. C’était le moyen le plus sûr de casser toute dynamique de création.

La solution mise en place ressemble à une simple barre de recherche pour l’utilisateur. Pourtant, derrière cette interface se cache un pipeline à trois niveaux qui orchestre un ensemble de modèles d’IA, fusionne leurs résultats sur une chronologie partagée et traite des requêtes hybrides (textuelles et vectorielles) en moins d’une seconde. Lorsque plusieurs modèles s’exécutent sur les mêmes images, le volume initial de 216 millions de frames explose pour devenir des milliards de points de données superposés. Stocker, aligner et croiser une telle masse d’informations tout en garantissant des temps de réponse inférieurs à la seconde dépasse largement les capacités d’une base de données traditionnelle.

Ce qu’il faut retenir de cette architecture

• Une approche par spécialisation : Netflix utilise un ensemble de modèles spécialisés (reconnaissance de visages, classification de scènes, transcription) plutôt qu’un unique modèle généraliste.
• Un pipeline découplé en 3 étapes : L’ingestion, la fusion temporelle hors ligne et l’indexation temps réel sont strictement séparées pour éviter les goulets d’étranglement.
• La fusion par compartimentation temporelle (temporal bucketing) : Toutes les données des modèles sont ramenées à des intervalles fixes d’une seconde pour aligner les différentes analyses.
• Une recherche hybride performante : Le moteur combine la recherche textuelle exacte (via Elasticsearch) et la recherche vectorielle pour capter à la fois les mots exacts et les concepts sémantiques.

Pourquoi multiplier les modèles d’IA ?

Pourquoi s’encombrer de plusieurs modèles d’IA sur un même contenu au lieu d’utiliser un modèle unique et massif ? L’expérience montre que les modèles spécialisés surpassent systématiquement les généralistes sur leurs tâches respectives. Un modèle entraîné spécifiquement pour la reconnaissance faciale identifiera les personnages avec bien plus de précision qu’un modèle de vision par ordinateur généraliste. De même, un modèle calibré pour la classification de scènes cartographiera les environnements plus fidèlement, et un outil de transcription retranscrira les dialogues de manière plus fiable.

Netflix fait donc tourner un ensemble d’experts. Un modèle reconnaît les personnages, un autre classifie les décors, un troisième s’occupe des dialogues et un quatrième détecte les objets. Le problème, c’est que chacun de ces experts produit des données de nature radicalement différente :

• Le modèle de reconnaissance de personnages renvoie un simple label textuel (par exemple, “Joey”).
• Le modèle de classification de scènes génère un plongement vectoriel (embedding) à 512 dimensions, représentant mathématiquement le sens de la scène.
• Le modèle de dialogue produit du texte transcrit et horodaté.

Gérer ces formats disparates n’est que la moitié du problème. L’autre difficulté réside dans le fait que chaque modèle découpe la vidéo selon ses propres intervalles de temps, qui se chevauchent sans jamais s’aligner parfaitement. Le modèle de personnages peut détecter “Joey” de la seconde 2 à la seconde 8, tandis que le modèle de scène détecte une “cuisine” de la seconde 4 à la seconde 9. Il n’y a pas de chronologie commune.

La question cruciale pour l’équipe d’ingénierie était donc la suivante : comment unifier ces données hétérogènes, produites à des résolutions temporelles différentes, dans un seul index interrogeable ?

Pour être tout à fait complet, Netflix explore également une approche différente avec un modèle de fondation unifié baptisé MediaFM, capable de traiter simultanément l’audio, la vidéo et le texte. L’avenir nous dira si la balance penchera vers ces modèles unifiés ou vers les ensembles de spécialistes. En attendant, le système de production actuel s’appuie sur une architecture à trois étapes bien distinctes.

L’architecture du pipeline en trois étapes

Pour passer des données brutes des modèles à un index de recherche performant, Netflix a mis en place un processus découplé. Chaque étape gère une seule responsabilité. Cette séparation stricte est indispensable pour éviter les ralentissements majeurs à l’échelle de l’infrastructure de Netflix.

Étape 1 : La persistance transactionnelle

Les annotations brutes de tous les modèles sont immédiatement ingérées et stockées dans Apache Cassandra, une base de données distribuée choisie pour ses performances en écriture. Cette étape donne la priorité absolue à l’intégrité des données. Chaque sortie de modèle est enregistrée exactement telle qu’elle a été produite, sans aucune transformation.

Cette séparation est essentielle : si le système tentait de traiter ou de fusionner les données dès l’ingestion, la charge de calcul paralyserait l’acquisition en temps réel. Grâce à ce découplage, la couche d’ingestion absorbe le flux de données sans encombre, quel que soit le nombre de modèles en cours d’exécution.

Étape 2 : La fusion de données hors ligne

Une fois les données brutes sécurisées dans Cassandra, un événement déclenche un traitement asynchrone. Cette couche de fusion hors ligne constitue le véritable cœur du système. En effectuant les calculs lourds en dehors du chemin d’accès en temps réel, les croisements de données complexes ne ralentissent jamais l’ingestion.

La technique clé repose sur la compartimentation temporelle (ou temporal bucketing). Le pipeline normalise les sorties de tous les modèles en les découpant en intervalles fixes d’une seconde, selon un processus en trois temps :

1. Le découpage en compartiments : Les détections continues sont segmentées en tranches discrètes d’une seconde. Si “Joey” est détecté de la seconde 2 à la seconde 8, le pipeline crée sept compartiments distincts d’une seconde.
2. L’intersection des annotations : Lorsque plusieurs modèles génèrent des annotations pour une même seconde, le système les fusionne. Si “Joey” et “cuisine” apparaissent tous deux dans le compartiment de la quatrième seconde, ils sont fusionnés en un enregistrement unique indiquant : “Joey est dans une cuisine à cet instant précis”.
3. La persistance optimisée : Ces enregistrements enrichis sont réécrits dans Cassandra sous forme d’entités distinctes. On obtient ainsi un index seconde par seconde des intersections de données, liant chaque annotation fusionnée à la vidéo d’origine.

Pour rendre ce processus incrémental, le pipeline utilise des opérations d’insertion/mise à jour (upserts) basées sur une clé composite associant l’ID de la vidéo et le compartiment temporel. Si un compartiment existe déjà pour une seconde donnée (par exemple, alimenté par un précédent modèle), le système met à jour l’enregistrement existant au lieu de créer un doublon. Cela permet d’avoir une source de vérité unique et d’intégrer facilement de nouveaux modèles au fil du temps.

Le choix d’un compartiment d’une seconde n’est pas anodin. Des compartiments plus petits offriraient une plus grande précision mais augmenteraient considérablement le volume de données. À l’échelle de 2 000 heures de rushes, une résolution d’une seconde génère déjà 7,2 millions de compartiments. C’est le point d’équilibre idéal trouvé par les ingénieurs entre précision et exploitabilité.

Étape 3 : L’indexation pour la recherche en temps réel

Une fois les compartiments temporels fusionnés et stockés, un nouvel événement déclenche leur indexation dans Elasticsearch, le moteur de recherche du système. Chaque compartiment y est structuré comme un document imbriqué (nested document) :

• Le niveau parent contient le contexte général (ID de la vidéo, ID du film, intervalle de temps).
• Les documents enfants contiennent les annotations spécifiques (données de personnages, embeddings de scènes, transcriptions).

Cette structure hiérarchique permet de réaliser des requêtes croisées complexes. Quand un utilisateur recherche “Joey dans la cuisine”, Elasticsearch peut faire correspondre l’annotation du personnage et celle de la scène au sein d’un même document parent en une seule opération.

Sous le capot du moteur de recherche

Une fois la chronologie indexée, le système est prêt à répondre aux requêtes des utilisateurs. Lorsqu’une recherche est lancée, elle passe d’abord par une phase de prétraitement en trois étapes :

• La détection du type de requête oriente la demande vers le chemin d’accès le plus efficace.
• L’extraction de filtres isole les contraintes sémantiques (comme les noms de personnages ou les décors) pour réduire le volume de données à analyser avant les calculs lourds.
• La transformation vectorielle convertit la requête textuelle en un plongement vectoriel à haute dimension pour la correspondance sémantique.

Le système traduit ensuite ce plan en une requête Elasticsearch optimisée.

La recherche hybride

Une requête telle que “Joey dans la cuisine” nécessite deux types de recherche très différents. “Joey” est un nom propre qui demande une correspondance textuelle exacte. “Cuisine” est un concept sémantique qui profite d’une recherche par similarité vectorielle (où le système mesure la distance mathématique entre le vecteur de la requête et les vecteurs des scènes en index).

Une recherche textuelle classique raterait les scènes associées à des termes proches mais différents. À l’inverse, une recherche purement vectorielle peinerait à identifier précisément les noms propres. La combinaison des deux (la recherche hybride) offre des résultats bien supérieurs.

Les ingénieurs ont également laissé aux utilisateurs le contrôle sur ce moteur hybride. Ils peuvent choisir entre :

• La recherche exacte des k plus proches voisins (k-NN), mathématiquement optimale mais gourmande en calculs, et des algorithmes de recherche approximative (ANN) qui privilégient la rapidité sur de très grands volumes de données.
• Différentes mesures de distance comme la similarité cosinus ou la distance euclidienne, les modèles n’organisant pas tous leurs espaces vectoriels de la même façon.
• Des seuils de confiance permettant de filtrer les résultats les moins pertinents pour ne présenter aux monteurs que les correspondances les plus fiables.

La recherche dans les dialogues

Pour retrouver des répliques précises, le système applique plusieurs techniques d’analyse de texte :

• La recherche par phrase avec un paramètre de proximité (“slop”), qui tolère un certain écart entre les mots saisis pour pallier les erreurs de mémoire des utilisateurs.
• La recherche semi-automatique (saisie intuitive) basée sur l’indexation de fragments de mots dès l’ingestion, affichant des résultats à l’image près dès les premières lettres tapées.
• La racinisation (stemming) multilingue, qui permet à une recherche sur le mot “courir” de faire remonter des scènes taguées avec “court” ou “couru”.
• La recherche floue (fuzzy matching) pour tolérer les fautes de frappe ou les erreurs de transcription, évitant ainsi de passer à côté d’un plan précieux à cause d’une simple coquille.

Le traitement des résultats

Les résultats bruts doivent être mis en forme avant d’être présentés. Le système regroupe les résultats à l’aide d’agrégations personnalisées (par exemple, pour isoler les 5 meilleurs clips d’un acteur par épisode), évitant qu’un seul contenu ne monopolise l’écran. Une couche de reconstruction temporelle convertit ensuite les limites arbitraires des compartiments d’une seconde en véritables scènes cohérentes pour les monteurs.

Enfin, l’utilisateur peut choisir entre deux modes d’affichage : le mode *Union*, qui affiche l’intégralité des séquences où apparaît au moins un des critères recherchés (privilégiant la quantité), et le mode *Intersection*, qui restreint les résultats aux seuls moments où tous les critères se superposent exactement (privilégiant la précision).

Les arbitrages techniques et leurs coûts

Chaque choix d’architecture implique des compromis, et les ingénieurs de Netflix ont clairement identifié ceux qu’ils étaient prêts à accepter :

• Le choix de la fusion hors ligne : Le traitement asynchrone impose un léger délai avant que les nouveaux contenus ne soient entièrement interrogeables. Netflix a préféré privilégier la capacité de traitement à la fraîcheur immédiate des données. Pour des archives de production qui grandissent de milliers d’heures, ce choix est tout à fait cohérent, même s’il s’avérerait problématique pour un système exigeant un index temps réel absolu.
• La recherche exacte vs. approximative : Laisser l’utilisateur choisir entre la précision du k-NN exact (coûteux) et la rapidité de l’ANN permet de déplacer l’arbitrage selon le besoin du moment.
• La complexité de l’approche multi-modèles : Faire tourner de nombreux modèles spécialisés et fusionner leurs données nécessite une infrastructure lourde. Un modèle unique simplifierait grandement l’architecture, mais au détriment de la précision sur les tâches pointues. C’est d’ailleurs pour cela que Netflix continue de travailler en parallèle sur son pipeline de modèles spécialisés et sur son modèle de fondation unifié MediaFM.

Les prochaines étapes

Ce système de recherche vidéo pose les bases de développements encore plus ambitieux. Les équipes de Netflix travaillent déjà sur trois axes d’évolution :

• La recherche en langage naturel : L’objectif est de dépasser les requêtes structurées pour aller vers une interface conversationnelle. Un monteur pourrait ainsi simplement écrire : “Trouve les meilleurs plans de suivi de Tom Holland en train de courir sur un toit”.
• Le classement adaptatif : Grâce à des boucles de rétroaction basées sur l’apprentissage automatique, le système analysera les clips effectivement sélectionnés par les monteurs pour affiner sa définition mathématique de la pertinence au fil du temps.
• La personnalisation selon le domaine : Une équipe de montage de bandes-annonces marketing n’a pas les mêmes critères de recherche qu’une équipe de montage d’épisodes ou de recherche documentaire. Le moteur adaptera dynamiquement la pondération des résultats selon le profil de l’utilisateur.

À terme, ce moteur de recherche est appelé à devenir un véritable collaborateur de création. Mais ce que cette architecture démontre déjà, c’est que lorsque plusieurs modèles d’IA génèrent des données hétérogènes sur un même contenu, la complexité réside principalement dans la couche de fusion. Les modèles sont certes indispensables, mais c’est bien la qualité du pipeline qui traite, aligne et indexe leurs données qui rend l’ensemble véritablement exploitable.