Rutube Saiu de Piloto Whisper para Plataforma Própria de Legendas e Reconhecimento de Fala

Rutube descreveu como iniciou legendas automáticas para vídeos gerados por usuários: primeiro através de um piloto rápido no Whisper, depois através de sua própria plataforma ASR. O time chegou a isso após perceber que reconhecer fala em uma demo e processar estável um fluxo inteiro de conteúdo são duas tarefas muito diferentes.

Por Que Whisper Não Foi Suficiente

No início, Whisper se mostrou uma opção conveniente para testar a hipótese. Permitiu construir rapidamente o primeiro serviço, colocar legendas em produção e compreender que os usuários realmente precisavam desse recurso. Mas após o lançamento, limitações surgiram que são difíceis de notar na fase de piloto: a plataforma recebe milhões de novos vídeos, alguns durando até 24 horas, o áudio pode ser ruidoso e o idioma é desconhecido antecipadamente. Somam-se a isso requisitos de qualidade de texto e restrições rígidas de velocidade de processamento, porque as legendas precisam aparecer não em algum momento depois, mas no ritmo operacional do serviço.

Entre "reconhecer fala" e "fornecer legendas para todo o conteúdo" existe uma enorme quantidade de trabalho.

Esse hiato foi precisamente a principal conclusão do time.

Para vídeo gerado por usuários, não é suficiente simplesmente passar a trilha de áudio através de um modelo pronto e salvar o resultado. Você precisa de toda a infraestrutura ao redor do reconhecimento: tratamento de arquivos longos, robustez a áudio de má qualidade, controle de qualidade de texto, gerenciamento de filas e desempenho previsível sob carga pesada. Caso contrário, até mesmo um bom modelo ASR se torna um gargalo que não consegue lidar com tráfego em escala industrial.

O Que O Sistema Se Tornou

No final, a tarefa deixou de ser "mais um serviço baseado em ASR" e se tornou uma plataforma completa de legendagem. Rutube escreve que para alcançar isso, tiveram de fazer a transição para uma arquitetura de microsserviços e seu próprio sistema de reconhecimento de fala. Essa abordagem era necessária não pela moda de pilhas tecnológicas, mas pela separação de responsabilidades: uma parte do sistema cuida da ingestão e preparação de vídeo, outra do reconhecimento em si, e uma terceira da montagem e entrega de resultados. Em escala, isso é crítico porque permite escalar componentes individuais independentemente e evita que todo o pipeline quebre devido à sobrecarga em um único lugar.

Para tal plataforma, vários requisitos são importantes simultaneamente:

• Aceitar um fluxo de milhões de novos vídeos sem intervenção manual
• Processar vídeos de até 24 horas sem colapso do pipeline
• Trabalhar com idiomas desconhecidos e áudio ruidoso gerado por usuários
• Manter qualidade de texto suficiente para publicação
• Permanecer dentro dos limites de velocidade e custo de processamento

A transição para ASR próprio faz sentido neste contexto. Quando um produto funciona em UGC em massa, um modelo externo universal ajuda você a começar, mas não é adequado para ajuste fino aos dados reais, restrições de infraestrutura e métricas de destino. Seu próprio sistema oferece mais controle sobre velocidade, qualidade, recursos e como o reconhecimento se comporta em casos extremos que se tornam a norma para uma plataforma de vídeo, não a exceção.

Como Alcançaram a Velocidade

O número mais impressionante na história de Rutube é uma taxa de transferência de cerca de 1200 vídeos por hora por instância de ASR. Este é um parâmetro importante porque em produção, a qualidade do reconhecimento não pode ser vista separadamente da taxa de transferência. Se o sistema produz bom texto mas enfileira milhares de vídeos, o usuário recebe pouco benefício. Se o pipeline funciona rápido mas é instável em vídeos longos ou áudio ruim, o produto quebra na operação real. Então a arquitetura aqui é tão importante quanto o modelo em si.

Por trás desse número não está um único algoritmo bem-sucedido, mas uma série de soluções de engenharia: como fatiar e alimentar áudio, como distribuir tarefas, como evitar perder tempo em estágios ineficientes e como manter recursos sob controle. O aspecto econômico também é importante. Quanto maior a taxa de transferência por instância de ASR, mais fácil é escalar o serviço sem crescimento explosivo de custos de infraestrutura. Para plataformas com um fluxo constante de UGC, isso não é mais uma questão de conveniência, mas economia básica do produto.

O Que Isso Significa

A história de Rutube ilustra bem a fronteira entre um protótipo de IA rápido e um produto maduro. Um modelo pronto como Whisper ajuda você a lançar rapidamente, mas um serviço em escala de massa requer sua própria arquitetura, controle de qualidade e otimização para cargas no mundo real. Para todos que constroem recursos de IA sobre conteúdo gerado por usuários, este é um sinal claro: o gargalo geralmente não está em um modelo, mas em todo o pipeline ao seu redor.