Cascata T-one e GigaAM: rascunho das legendas durante a reunião, versão final depois

O autor de um serviço de reuniões individuais verificou se é possível deixar o Deepgram, na nuvem, e migrar para um servidor próprio sem placa de vídeo, mantendo tanto as legendas ao vivo quanto um texto final de qualidade. Ele montou uma cascata de dois modelos. Durante a chamada, o T-one transforma a fala em um rascunho com atraso inferior a 2 segundos.

Depois da reunião, o GigaAM revisa o rascunho, corrige os erros e entrega a versão final, com pontuação. O esquema funcionou, e as medições levaram três dias. Mas dois resultados surpreenderam o autor mais do que os próprios modelos: o gabarito de qualidade errava em um a cada quatro pontos duvidosos, e a técnica popular de "o segundo modelo corrige os termos" quase não trouxe ganho nas chamadas dele.

De onde veio a ideia da cascata

Na primeira parte, o autor descobriu que o número de vCPU diz pouco sobre o desempenho. Um Xeon de 2013 sem AVX2 sustenta de 6–8 vezes menos trilhas ao vivo do que um processador moderno com número de núcleos parecido. A máquina B dele (6 vCPU Xeon E5-2680 v2, 11 GB de RAM) aguenta duas reuniões simultâneas: o T-one entrega a frase 1,08 s (p50) e 1,2 s (p95) após a pausa.

O T-one tem pontos fracos. Ele não coloca pontuação e, em taxa de acerto de palavras, fica atrás tanto da nuvem quanto do GigaAM. Já o GigaAM só trabalha com gravação pronta. A cascata cobre as duas lacunas. Quem deu o empurrão foi o @pahaz, que no mesmo dia publicou um artigo sobre uma cascata GigaAM + Parakeet para transcrição offline e sugeriu incluir o Parakeet na comparação.

Os requisitos continuam os mesmos: as trilhas dos participantes chegam separadas, então não é preciso diarização; a frase nas legendas deve aparecer em no máximo 2 s (p95); e o áudio não sai do servidor na Rússia. Entrou um requisito novo: um texto final com pontuação, no mínimo tão bom quanto o da nuvem, onde o mais importante são valores, prazos e nomes.

O gabarito que favorecia os modelos

Na primeira parte, o gabarito era o Deepgram, e o próprio autor considerava isso um ponto fraco. Agora ele ampliou a amostra e revisou o gabarito manualmente. Descobriu que, em um a cada quatro pontos duvidosos, o gabarito anterior errava e favorecia os modelos a partir dos quais tinha sido montado. Isso significa que o WER medido contra esse gabarito superestima a qualidade dos sistemas "de casa".

A segunda descoberta diz respeito à correção de termos. No teste do @pahaz, o segundo modelo, que corrige os termos, reduziu o WER em 5 p.p. Nas chamadas de trabalho do autor, isso não mudou nada na melhor das hipóteses e, na pior, acrescentou 7 p.p. O ganho da cascata depende muito do domínio e da qualidade da gravação.

O que exatamente foi medido

Dados de teste:

• 51 segundos de call center do pacote do T-one • sessão de coaching de 29 minutos • 4 gravações de chamadas de trabalho: 2 h 21 min, 14 970 palavras

Gabaritos: concordância entre os motores em uma amostra, o texto do Deepgram nova-3 na sessão, o texto consensual de três sistemas com correção manual dos termos e escuta por amostragem.

Na primeira parte, foram comparados T-one, GigaAM-v3, Vosk, Deepgram nova-2 e nova-3. Na segunda:

• T-one nos modos greedy e com o modelo de linguagem KenLM • GigaAM-v3 e2e • Parakeet TDT 0.6B v3 • Deepgram nova-3

Métricas: WER, WERx, erros em números, precisão de termos e de pontuação. Separadamente, o autor analisou o que sobrecarrega a CPU em tempo real, como dividir o trabalho entre os dois modelos e quanto isso custa.

Conclusão prática

Quem monta a própria transcrição deve começar pelo gabarito, não pelos modelos. Se o gabarito é construído a partir da saída dos mesmos sistemas que você está comparando, os números saem otimistas. É preciso revisão manual, ao menos dos pontos duvidosos, e escuta direta, principalmente onde aparecem valores, datas e nomes.

A segunda conclusão trata das cascatas. O ganho de 5 p.p. que outra pessoa obteve com um modelo corretor não se transfere automaticamente para as suas conversas, então teste nas suas gravações. A divisão de papéis entre dois modelos se justifica pela própria lógica da tarefa: um modelo rápido e mais grosseiro para as legendas ao vivo, outro lento e preciso para o documento pós-reunião. Para um serviço pequeno, isso quer dizer que duas chamadas simultâneas num velho Xeon de seis núcleos são perfeitamente viáveis, desde que a parte ao vivo fique com o modelo leve e o trabalho pesado seja adiado para depois da reunião.