Rutube abandonne son pilote Whisper pour sa propre plateforme de sous-titres et de reconnaissance vocale

Rutube a décrit comment il a lancé les sous-titres automatiques pour les vidéos des utilisateurs : d'abord via un pilote rapide sur Whisper, puis via sa propre plateforme ASR. L'équipe y est venue en constatant que reconnaître la parole dans une démo et traiter de façon stable tout le flux de contenus sont deux tâches très différentes.

Pourquoi Whisper ne suffisait pas

Au départ, Whisper était une option pratique pour valider l'hypothèse. Il a permis d'assembler vite un premier service, de mettre les sous-titres en production et de vérifier que les utilisateurs avaient réellement besoin de la fonction. Mais après le lancement, des limites difficiles à voir au stade du pilote sont apparues : la plateforme reçoit des millions de nouvelles vidéos, dont certaines durent jusqu'à 24 heures, le son peut être bruité et la langue n'est pas connue à l'avance. À cela s'ajoutent des exigences de qualité du texte et des contraintes strictes de vitesse de traitement, car les sous-titres doivent apparaître non pas plus tard, mais au rythme de fonctionnement du service.

Entre « reconnaître la parole » et « produire des sous-titres pour

tout le contenu », il y a une énorme couche de travail.

Cet écart a été la principale conclusion de l'équipe. Pour les vidéos d'utilisateurs, il ne suffit pas de passer la piste audio dans un modèle prêt à l'emploi et d'enregistrer le résultat. Il faut tout l'appareillage autour de la reconnaissance : gestion des fichiers longs, robustesse face au mauvais son, contrôle de la qualité du texte, gestion des files d'attente et performances prévisibles sous forte charge. Sinon, même un bon modèle ASR devient un goulet d'étranglement qui ne tient pas la charge industrielle.

Ce que le système est devenu

Au final, la tâche a cessé d'être « un service de plus basé sur un ASR » pour devenir une véritable plateforme de sous-titres. Rutube indique qu'il a dû, pour cela, passer à une architecture en microservices et à son propre système de reconnaissance vocale. Cette approche ne répond pas à un effet de mode, mais à une séparation des responsabilités : une partie du système reçoit et prépare la vidéo, une autre assure la reconnaissance elle-même, une troisième assemble et livre le résultat. Sur de gros volumes, c'est essentiel, car cela permet de faire évoluer chaque composant indépendamment et d'éviter que tout le pipeline s'effondre à cause d'une surcharge en un point.

Une telle plateforme doit satisfaire plusieurs exigences à la fois :

• Absorber un flux de millions de nouvelles vidéos sans intervention manuelle
• Traiter des vidéos allant jusqu'à 24 heures sans casser le pipeline
• Gérer une langue inconnue et un son d'utilisateur bruité
• Maintenir une qualité de texte suffisante pour la publication
• Respecter les contraintes de vitesse et de coût de traitement

Dans ce contexte, le passage à un ASR maison paraît logique. Quand un produit repose sur du UGC de masse, un modèle externe universel aide à démarrer, mais se prête mal à un réglage fin sur des données réelles, des contraintes d'infrastructure et des métriques cibles. Un système maison donne plus de contrôle sur la vitesse, la qualité, les ressources et le comportement de la reconnaissance dans les cas difficiles, qui deviennent la norme, et non l'exception, pour une plateforme vidéo.

Comment la vitesse a été obtenue

Le chiffre le plus marquant de l'histoire de Rutube est un débit d'environ 1200 vidéos par heure pour un ASR. C'est un repère important, car en production, la qualité de la reconnaissance ne peut être considérée indépendamment du débit. Si le système produit un bon texte mais accumule une file de milliers de vidéos, l'utilisateur en tire peu de bénéfice. Si le pipeline est rapide mais instable sur les vidéos longues ou le mauvais son, le produit recommence à casser en exploitation réelle. L'architecture compte donc autant que le modèle lui-même.

Derrière ce chiffre, il n'y a pas un algorithme brillant, mais une série de choix d'ingénierie : comment découper et fournir l'audio, comment répartir les tâches, comment ne pas perdre de temps dans les étapes inefficaces et comment garder les ressources sous contrôle. L'aspect économique compte aussi. Plus le débit par instance d'ASR est élevé, plus il est simple de faire évoluer le service sans explosion des coûts d'infrastructure. Pour les plateformes à flux constant de UGC, ce n'est plus une question de confort, mais l'économie de base du produit.

Ce que cela signifie

L'histoire de Rutube illustre bien la frontière entre un prototype d'IA rapide et un produit mature. Un modèle prêt à l'emploi comme Whisper aide à démarrer vite, mais un service de masse exige une architecture propre, un contrôle qualité et une optimisation pour des charges réelles. Pour tous ceux qui construisent des fonctions d'IA sur du contenu d'utilisateurs, c'est un signal direct : le goulet d'étranglement se trouve rarement dans un seul modèle, mais dans tout le pipeline qui l'entoure.