Reconhecimento de fala (ASR)

01 · CONTEXTO E REQUISITOS

O que um reconhecedor de fala precisa entregar

No artigo do Google sobre reconhecimento de fala (ASR) em celulares, o paradigma dominante é transmitir o áudio do dispositivo ao servidor, enquanto os resultados decodificados voltam em fluxo ao usuário.

Para esse tipo de modelo ser útil, ele precisa decodificar a fala em streaming, em tempo real. Também precisa ser robusto à cauda longa de usos e conseguir usar contexto específico do usuário.

Latência, aqui, é o atraso entre a pessoa falar e o texto aparecer na tela. O modelo precisa ser ao menos tão preciso quanto um sistema convencional, sem aumentar essa latência.

02 · COMO MEDIR

WER, latência e o que o WER não enxerga

A pesquisa em reconhecimento de fala costuma comparar sistemas pela taxa de erro de palavras (WER). O artigo do Whisper lembra que o WER se baseia em distância de edição entre cadeias de caracteres e penaliza todas as diferenças entre a saída do modelo e a transcrição de referência, inclusive diferenças inócuas de estilo.

Por isso, sistemas cujas transcrições humanos julgariam corretas ainda podem ter WER grande por diferenças mínimas de formatação. O Whisper responde padronizando o texto de forma extensa antes de calcular o WER.

Para velocidade, o artigo do Google usa o fator de tempo real: tempo de processamento dividido pela duração do áudio, no percentil noventa (RT90). Valores menores indicam processamento mais rápido e menor latência percebida. As métricas de erro e de velocidade aparecem juntas na tabela de quantização do artigo.

03 · STREAMING NO SERVIDOR

Do áudio ao texto, em fluxo

1. O dispositivo transmite o áudio ao servidor; este é o paradigma dominante descrito para reconhecimento de fala em celulares.

2. O serviço de reconhecimento roda um modelo de streaming, que não precisa esperar a fala inteira para começar a processar.

3. Os resultados decodificados voltam em fluxo ao usuário; o atraso entre falar e ver o texto é a latência.

4. O nó de métricas representa onde se acompanham erro de palavras e velocidade; o artigo do Google reporta WER e RT90.

Trocar esse desenho por um que roda inteiramente no dispositivo tem, segundo o artigo, implicações importantes de confiabilidade, latência e privacidade.

04 · NO DISPOSITIVO COM RNN-T

Um modelo de ponta a ponta que cabe no celular

Tentativas anteriores de ASR de vocabulário amplo no dispositivo costumavam encolher os componentes tradicionais: modelos acústico, de pronúncia e de linguagem. A alternativa do artigo é um modelo de ponta a ponta, que prevê sequências de caracteres diretamente e simplifica treino e inferência.

O CTC faz uma forte suposição de independência: os rótulos são condicionalmente independentes entre si dado o áudio. O RNN-T remove essa suposição ao condicionar no histórico completo dos rótulos anteriores não vazios. Em ambos, um rótulo de alinhamento não pode depender de quadros acústicos futuros, e isso permite construir sistemas de streaming que não esperam a fala inteira.

1. O encoder do artigo é formado por camadas de células LSTM unidirecionais.

2. Uma camada de redução de tempo no encoder acelera treino e inferência.

3. A rede de predição depende apenas dos históricos de rótulos, não do áudio.

4. A rede conjunta, feed-forward, recebe a saída do encoder e a da rede de predição.

5. Como a computação da rede de predição independe da acústica, usa-se cache de estados para evitar cálculo redundante em históricos idênticos.

6. O viés contextual injeta conhecimento prévio, como contatos do usuário, durante a inferência; o artigo usa shallow fusion.

Para rodar mais rápido que o tempo real no celular, o artigo usa threads separadas para o encoder e a rede de predição, em pipeline assíncrono, e quantiza os parâmetros de ponto flutuante de trinta e dois bits para ponto fixo de oito bits. A quantização simétrica reduz o RT90 em sessenta e quatro por cento frente ao modelo em ponto flutuante, o que é duas vezes mais rápido que o tempo real.

No conjunto, o sistema decodifica a fala duas vezes mais rápido que o tempo real num Google Pixel e melhora o WER em mais de vinte por cento relativos frente a um modelo CTC embarcado convencional em busca por voz e ditado.

05 · ÁUDIO LONGO E LOTE

Quando não há streaming: janelas de áudio

O artigo do Whisper reporta um conjunto de treino de 680 mil horas de áudio rotulado. O modelo é treinado em trechos de áudio de trinta segundos e não consome áudios mais longos de uma só vez.

Para áudio de minutos ou horas, o Whisper transcreve segmentos de trinta segundos em sequência e desloca a janela conforme os timestamps previstos pelo modelo. Os autores observaram que busca em feixe e escalonamento de temperatura, baseado na repetitividade e na log-probabilidade das predições, são cruciais para transcrever áudio longo de forma confiável.

Num desenho em lote, uma fila de mensagens separa o envio do arquivo do trabalho de transcrição. A escolha de fila, armazenamento e trabalhador é do desenho aqui proposto, não do artigo.

1. Neste desenho, o cliente se liga ao armazenamento de áudio, onde ficam os arquivos enviados.

2. Neste desenho, o armazenamento se liga à fila de transcrições, que enfileira um pedido por arquivo.

3. O nó transcritor aplica a estratégia de janelas do Whisper: segmentos de trinta segundos em sequência, com a janela deslocada pelos timestamps previstos pelo modelo.

4. Neste desenho, o transcritor grava o texto final no repositório de transcrições prontas.