Rutube pasa de un piloto con Whisper a su propia plataforma de subtítulos y reconocimiento de voz

Rutube ha descrito cómo lanzó los subtítulos automáticos para vídeo de usuarios: primero con un piloto rápido sobre Whisper y después con su propia plataforma ASR. El equipo llegó ahí al comprobar que reconocer voz en una demo y procesar de forma estable todo el flujo de contenido son dos tareas muy distintas.

Por qué Whisper no fue suficiente

Al principio, Whisper resultó una opción cómoda para validar la hipótesis. Permitió montar rápido un primer servicio, llevar los subtítulos a producción y comprobar que los usuarios realmente necesitaban la función. Pero tras el lanzamiento aparecieron limitaciones difíciles de ver en la fase de piloto: la plataforma recibe millones de vídeos nuevos, algunos de hasta 24 horas, el audio puede tener ruido y el idioma no se conoce de antemano. A eso se suman los requisitos de calidad del texto y unos límites estrictos de velocidad de procesamiento, porque los subtítulos deben aparecer no en algún momento futuro, sino al ritmo de trabajo del servicio.

Entre «reconocer voz» y «hacer subtítulos para todo el contenido» hay

una enorme capa de trabajo.

Esa brecha fue la principal conclusión del equipo. En el vídeo de usuarios no basta con pasar la pista de audio por un modelo ya hecho y guardar el resultado. Hace falta todo el andamiaje alrededor del reconocimiento: gestión de archivos largos, resistencia al mal audio, control de calidad del texto, gestión de colas y un rendimiento predecible bajo mucha carga. De lo contrario, incluso un buen modelo ASR se convierte en un cuello de botella que no soporta la carga industrial.

En qué se convirtió el sistema

Al final, la tarea dejó de ser «un servicio más basado en ASR» y pasó a ser una plataforma de subtítulos completa. Rutube cuenta que para ello tuvo que adoptar una arquitectura de microservicios y un sistema propio de reconocimiento de voz. Este enfoque no responde a una moda tecnológica, sino a la separación de responsabilidades: una parte del sistema recibe y prepara el vídeo, otra se encarga del reconocimiento y una tercera ensambla y entrega el resultado. Con grandes volúmenes esto es crítico, porque permite escalar cada componente de forma independiente y evita que todo el flujo se venga abajo por una sobrecarga en un punto.

Una plataforma así debe cumplir varios requisitos a la vez:

• Recibir un flujo de millones de vídeos nuevos sin intervención manual
• Procesar vídeos de hasta 24 horas sin romper el pipeline
• Trabajar con idioma desconocido y audio de usuarios con ruido
• Mantener una calidad de texto suficiente para publicarlo
• Cumplir los límites de velocidad y coste de procesamiento

En este contexto, pasar a un ASR propio parece lógico. Cuando un producto funciona con UGC masivo, un modelo externo universal ayuda a arrancar, pero se presta mal al ajuste fino para datos reales, limitaciones de infraestructura y métricas objetivo. Un sistema propio da más control sobre la velocidad, la calidad, los recursos y el comportamiento del reconocimiento en casos difíciles, que en una plataforma de vídeo son la norma y no la excepción.

Cómo se logró la velocidad

La cifra más llamativa de la historia de Rutube es un rendimiento de unos 1200 vídeos por hora por cada ASR. Es una referencia importante, porque en producción la calidad del reconocimiento no se puede considerar al margen del rendimiento. Si el sistema produce buen texto pero acumula una cola de miles de vídeos, al usuario le sirve de poco. Y si el pipeline es rápido pero inestable con vídeos largos o mal audio, el producto vuelve a fallar en la operación real. Por eso la arquitectura es tan importante como el propio modelo.

Detrás de esta cifra no hay un único algoritmo afortunado, sino una serie de decisiones de ingeniería: cómo cortar y alimentar el audio, cómo repartir las tareas, cómo no perder tiempo en etapas ineficientes y cómo mantener los recursos bajo control. También importa el aspecto económico. Cuanto mayor es el throughput por instancia de ASR, más fácil es escalar el servicio sin que se disparen los costes de infraestructura. Para plataformas con un flujo constante de UGC, esto ya no es cuestión de comodidad, sino la economía básica del producto.

Qué significa

La historia de Rutube muestra bien la frontera entre un prototipo rápido de IA y un producto maduro. Un modelo ya hecho como Whisper ayuda a arrancar deprisa, pero un servicio masivo exige arquitectura propia, control de calidad y optimización para cargas reales. Para quien construya funciones de IA sobre contenido de usuarios, es una señal directa: el cuello de botella no suele estar en un solo modelo, sino en todo el pipeline que lo rodea.