Rutube est Passé d'un Pilote Whisper à sa Propre Plateforme de Sous-titres et Reconnaissance Vocale

Rutube a décrit comment il a lancé les sous-titres automatiques pour les vidéos générées par les utilisateurs : d'abord via un pilote rapide sur Whisper, puis via sa propre plateforme ASR. L'équipe en est venue à cette conclusion après s'être aperçue que reconnaître la parole dans une démo et traiter de manière stable un flux entier de contenu sont deux tâches très différentes.

Pourquoi Whisper N'a Pas Suffi

Au départ, Whisper s'est avéré être une option pratique pour tester l'hypothèse. Cela a permis de construire rapidement le premier service, de mettre les sous-titres en production et de comprendre que les utilisateurs avaient réellement besoin de cette fonctionnalité. Mais après le lancement, des limitations sont apparues qui sont difficiles à repérer lors de la phase pilote : la plateforme reçoit des millions de nouvelles vidéos, dont certaines durent jusqu'à 24 heures, l'audio peut être bruyant et la langue est inconnue à l'avance. À cela s'ajoutent les exigences de qualité du texte et les contraintes strictes de vitesse de traitement, car les sous-titres doivent apparaître non pas à un moment quelconque après, mais au rythme opérationnel du service.

Entre « reconnaître la parole » et « fournir des sous-titres pour tout le contenu » se cache une énorme quantité de travail.

C'est précisément cet écart qui a été la principale conclusion de l'équipe.

Pour les vidéos générées par les utilisateurs, il ne suffit pas de simplement faire passer la piste audio à travers un modèle prêt et de sauvegarder le résultat. Vous avez besoin de toute l'infrastructure autour de la reconnaissance : le traitement des fichiers longs, la robustesse au mauvais audio, le contrôle de la qualité du texte, la gestion des files d'attente et les performances prévisibles sous charge lourde. Sinon, même un bon modèle ASR devient un goulot d'étranglement qui ne peut pas supporter le trafic à l'échelle industrielle.

Ce Que Le Système Est Devenu

Au final, la tâche a cessé d'être « un autre service basé sur ASR » et est devenue une plateforme complète de sous-titrage. Rutube écrit que pour y parvenir, ils ont dû passer à une architecture de microservices et leur propre système de reconnaissance vocale. Cette approche était nécessaire non pas pour suivre les tendances technologiques, mais pour la séparation des responsabilités : une partie du système s'occupe de l'ingestion et de la préparation des vidéos, une autre de la reconnaissance elle-même, et une troisième de l'assemblage et de la livraison des résultats.

À grande échelle, c'est critique car cela permet de mettre à l'échelle les composants individuels indépendamment et empêche tout le pipeline de s'effondrer à cause d'une surcharge à un endroit.

Pour une telle plateforme, plusieurs exigences sont importantes simultanément :

• Accepter un flux de millions de nouvelles vidéos sans intervention manuelle
• Traiter les vidéos jusqu'à 24 heures sans effondrement du pipeline
• Travailler avec des langues inconnues et l'audio bruyant généré par les utilisateurs
• Maintenir la qualité du texte suffisant pour la publication
• Rester dans les limites de vitesse et de coût de traitement

La transition vers un ASR interne a du sens dans ce contexte. Quand un produit fonctionne sur l'UGC de masse, un modèle externe universel vous aide à démarrer, mais ne convient pas bien à l'ajustement fin aux données réelles, aux contraintes d'infrastructure et aux métriques cibles. Votre propre système vous donne plus de contrôle sur la vitesse, la qualité, les ressources et la façon dont la reconnaissance se comporte sur les cas extrêmes qui deviennent la norme pour une plateforme vidéo, pas l'exception.

Comment Ils Ont Atteint la Vitesse

Le chiffre le plus frappant dans l'histoire de Rutube est un débit d'environ 1200 vidéos par heure par instance ASR. C'est un paramètre important car en production, la qualité de la reconnaissance ne peut pas être considérée séparément du débit. Si le système produit un bon texte mais accumule une file d'attente de milliers de vidéos, l'utilisateur en retire peu de bénéfice. Si le pipeline fonctionne rapidement mais est instable sur les vidéos longues ou le mauvais audio, le produit s'effondre en exploitation réelle. L'architecture est donc tout aussi importante que le modèle lui-même.

Derrière ce chiffre se cachent non pas un seul algorithme réussi, mais une série de solutions d'ingénierie : comment découper et servir l'audio, comment distribuer les tâches, comment ne pas gaspiller de temps sur les étapes inefficaces et comment maintenir les ressources sous contrôle. L'aspect économique est également important. Plus le débit par instance ASR est élevé, plus il est facile de mettre à l'échelle le service sans une croissance explosive des coûts d'infrastructure. Pour les plateformes avec un flux constant d'UGC, ce n'est plus une question de commodité mais d'économie basique 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 comme Whisper vous aide à lancer rapidement, mais un service à grande échelle nécessite sa propre architecture, le contrôle de la qualité et l'optimisation pour les charges du monde réel. Pour tous ceux qui construisent des fonctionnalités d'IA sur le contenu généré par les utilisateurs, c'est un signal clair : le goulot d'étranglement se trouve généralement non pas dans un seul modèle, mais dans tout le pipeline autour.