Voz sintetizada leu um romance em 1h58, e o que quebrou foi o código ao redor do modelo

Uma voz sintetizada leu um romance inteiro: 16 capítulos, 15 444 palavras, 1h58 de áudio. Segundo o autor da série de artigos no Habr, a voz se manteve estável durante as duas horas. Quase todas as falhas estavam não no modelo em si, mas no código ao redor dele. O conjunto de verificação de 14 frases, usado para comparar versões do modelo, não mostrou nenhuma delas.

O texto usado no experimento foi o romance «Merdiven» («A Escada»), de Shamil Aliadin. Este é o terceiro artigo da série: o primeiro trazia uma tabela com os resultados da leitura do livro, e no segundo o autor prometeu analisar separadamente o que quebrou na longa distância. Ele não revela nomes de modelos, fontes de dados, scripts internos nem parâmetros de treinamento e de decodificação. O texto se concentra nas métricas, na metodologia de verificação e nos erros em que ele tropeçou.

Onde as falhas realmente aconteciam

O autor lista cinco áreas problemáticas. Todas pertencem ao código ao redor do modelo, ou seja, ao que acontece antes e depois da geração do áudio:

• divisão do texto em frases;
• junção de frases curtas;
• corte de respirações;
• extração do texto do arquivo do livro;
• marcação de tempo.

Para engenheiros que já trabalharam com TTS, a lista é familiar. O modelo recebe um trecho de texto limpo e devolve um trecho de áudio limpo. Se o texto é cortado fora do sentido, se uma fala curta («— Não.») é colada ao vizinho errado ou se uma respiração é cortada no meio de uma sílaba, o ouvinte percebe o defeito, mesmo que as métricas do modelo não tenham mudado. Um erro na extração do texto do arquivo do livro acontece antes mesmo da síntese: o modelo vai narrar fielmente o que receber.

Por que as 14 frases não perceberam nada

A segunda conclusão do autor talvez seja mais interessante que a primeira. O conjunto de 14 frases de verificação servia para comparar versões do modelo e, pelo que se vê, cumpria bem essa tarefa. Mas ele não enxergava os problemas da longa distância. É compreensível: uma frase isolada não tem junções entre sentenças, não exige o corte de um capítulo e não testa como a marcação de tempo se acumula ao longo de duas horas de áudio.

Há ainda um caso mais incômodo. Em um dos episódios, o conjunto não conseguiu distinguir um ajuste bom de um prejudicial. Para uma equipe que toma decisões com base nesses testes, é um sinal de alerta: uma métrica que não diferencia melhora de piora vira ruído.

Os números ajudam a dimensionar o problema. 15 444 palavras em 118 minutos dão cerca de 131 palavras por minuto, e cada capítulo tem em média cerca de 965 palavras e 7 minutos de áudio. Nessa distância, há muito mais junções entre fragmentos do que em qualquer conjunto curto, e cada junção é um ponto potencial de falha.

O que verificar no seu pipeline

O material leva a conclusões práticas, que não dependem de nenhum modelo específico.

• Mantenha, ao lado do conjunto curto, pelo menos uma execução longa: um capítulo ou um livro inteiro. O conjunto curto serve para comparar versões do modelo, mas não para validar o pipeline inteiro.
• Teste o código ao redor separadamente do modelo: segmentação, junção, corte de pausas, extração de texto e marcação de tempo. Cada etapa precisa de suas próprias verificações.
• Comece a análise de defeitos pelo texto que vai para a síntese. Se o erro está ali, culpar o modelo não faz sentido.
• Verifique o próprio teste: se ele não distingue um ajuste útil de um prejudicial, ainda é cedo para tomar decisões com base nos resultados.

O autor promete detalhar a metodologia de verificação no artigo em si, e ela deve ser o principal valor do material. Por ora, o anúncio deixa uma conclusão simples: quando a voz soa estável por duas horas seguidas, a qualidade do pipeline depende de quão bem costuradas estão as emendas.