Por Que a Transcrição de IA Sempre Erra o Seu Sotaque — E O Que Realmente Resolve Isso

Existe um tipo específico de frustração silenciosa que aparece nas transcrições de reunião. Seu colega americano recebe um parágrafo limpo e bem pontuado. Você — com o sotaque brasileiro, alemão, taiwanês, nigeriano ou escocês — recebe um parágrafo que parece ter sido montado por alguém que ouviu a reunião através de uma parede. Seu nome aparece grafado de três formas diferentes. O número "treze" virou "trinta". Uma frase inteira simplesmente sumiu.

É tentador ler isso como uma falha pessoal de pronúncia. Não é. É uma propriedade mensurável e documentada de quase todo sistema de reconhecimento automático de fala (ASR) em uso hoje — e, se você é brasileiro falando inglês, você está exatamente do lado errado dessa estatística, porque a pesquisa mede justamente falantes não nativos como você.

A diferença, em números

A qualidade do reconhecimento de fala costuma ser medida em taxa de erro de palavras (WER, na sigla em inglês): o percentual de palavras que o sistema insere, apaga ou troca em relação a uma transcrição humana de referência. Uma WER de 5% significa uma palavra errada a cada vinte — chato, mas legível. Uma WER de 30% significa que aproximadamente uma palavra em cada três está errada, o ponto em que uma transcrição deixa de ser um registro e vira um quebra-cabeça.

Uma avaliação de 2025 sobre ASR em inglês não nativo (arXiv:2503.06924) colocou números concretos nessa divisão. Em fala lida com cuidado, falantes nativos ficaram em 8,0% de WER, enquanto falantes não nativos — o grupo em que a maioria dos brasileiros se encaixa ao falar inglês — chegaram a 24,8%, praticamente o triplo de erros no mesmo material. Saindo de frases lidas para uma conversa real, com hesitações, recomeços e falas sobrepostas, os dois grupos pioram: cerca de 30,7% e 33,8%, respectivamente. Benchmarks de mercado contam a mesma história pelo outro lado: fala nativa limpa com um bom microfone fica na faixa de 2-8%, enquanto fala com sotaque forte numa sala real cai rotineiramente na faixa de 30-50%.

O viés existe mesmo dentro do inglês nativo. Uma avaliação revisada por pares do Whisper, da OpenAI, publicada na JASA Express Letters (2024), encontrou reconhecimento sistematicamente melhor do inglês americano do que do britânico ou australiano, e descobriu que a precisão aumentava conforme a exposição de vida do falante ao inglês. O Whisper é a família de modelos por trás de boa parte das ferramentas de transcrição que você usa, inclusive as que rodam no aparelho — então isso não é uma história sobre um fornecedor ruim isolado.

As consequências vão além do incômodo. Um estudo de 2026 na npj Digital Medicine analisou especificamente erros relacionados a sotaque na transcrição de fala clínica e encontrou taxas de erro significativamente mais altas para falantes não nativos — num contexto em que uma palavra trocada pode virar uma dosagem errada.

Por que os modelos entendem sua voz pior

Quatro mecanismos explicam a maior parte dessa diferença, e entendê-los mostra quais você realmente consegue contornar.

1. Desequilíbrio nos dados de treino. Modelos grandes de ASR aprendem com qualquer áudio que a internet oferece em massa: podcasts americanos, YouTube, telejornais dos EUA. A distribuição de sotaques nesse volume não corresponde à distribuição de sotaques das pessoas nas suas reuniões. O modelo não é enviesado porque alguém escolheu ser injusto; é enviesado porque ouviu um sotaque cem vezes mais que os outros.

2. Mapeamento de fonemas a partir da sua língua materna. Todo falante mapeia sons desconhecidos para o som mais próximo do seu próprio repertório. Falantes de alemão ensurdecem consoantes finais, então bad soa mais como bat. Falantes de mandarim e cantonês costumam reduzir grupos consonantais finais, então tests e test colapsam num só. E falantes de português brasileiro têm uma marca própria: a vogal epentética depois de consoante final — hope vira algo como "hopi", Facebook vira "Facebooki". Some a isso o /h/ aspirado no lugar do R inicial (right soa como "hait") e a dificuldade clássica com o "th" (que vira /t/, /d/ ou /f/), e você tem um conjunto de desvios fonéticos que o modelo, treinado majoritariamente em fala americana, simplesmente não espera. Cada um desses desvios é perfeitamente inteligível para um ouvinte humano depois de dois segundos de adaptação. O modelo não tem essa etapa de adaptação.

3. Interferência de prosódia e tom. Falantes de línguas tonais carregam contornos de entonação para o inglês que o modelo interpreta como limites de frase ou ênfase. Avaliações repetidamente encontram algumas das piores taxas de erro justamente para falantes cuja língua materna é tonal. É também por isso que a pontuação da sua transcrição pode sair estranhamente errada mesmo quando as palavras estão certas.

4. O imposto das hesitações. Falantes não nativos, com toda razão, produzem mais correções no meio da frase — recomeços, "eh", autocorreções — enquanto compõem a fala numa segunda língua. Modelos treinados majoritariamente em fala polida lidam mal com essas correções, muitas vezes apagando a frase corrigida junto com o reparo. É por isso que os erros se concentram nas suas frases mais longas e mais importantes, e não nas curtas.

O que realmente quebra numa transcrição de reunião

A WER agregada esconde onde o estrago acontece. Em transcrições reais de reunião os erros não se distribuem de forma uniforme — eles se concentram exatamente nos trechos que você mais gostaria de manter:

• Nomes próprios. Nomes de pessoas, clientes, produtos e cidades são tokens raros, sem contexto para o modelo se apoiar. Uma única reunião pode grafar o nome de um colega de quatro formas diferentes.
• Números e unidades. Treze/trinta, quinze/cinquenta e cinquenta/cinquenta e cinco se diferenciam por um padrão de ênfase que o sotaque desloca. Numa discussão de orçamento ou dosagem, essa é a classe de erro mais perigosa de todas.
• Jargão interno. Siglas internas e nomes de projeto nunca estiveram nos dados de treino, então o modelo substitui pela palavra em inglês mais parecida que conhece.
• Code-switching. Solte uma frase em português no meio de uma reunião em inglês e a maioria dos sistemas, presos a um único idioma por arquivo, vai transcrever aquilo como um inglês sem sentido nenhum. Times de tecnologia brasileiros alternam idioma o tempo todo dentro da mesma frase — "vamos fazer o deploy na sprint que vem" é a norma, não a exceção — e um ASR de um idioma só lida muito mal com isso.
• Limites de fala. Quando dois falantes com sotaque se sobrepõem, a diarização costuma juntar as duas vozes, e uma frase acaba atribuída à pessoa errada — o que é pior do que simplesmente perdê-la.

Os ajustes que realmente mudam o número

Você não pode retreinar o modelo, mas a pesquisa é clara: parte da diferença é acústica e parte é configuração — e as duas estão sob seu controle. Em ordem aproximada de impacto:

1. Diminua a distância do microfone. Isso domina tudo o resto. Um celular deitado no meio de uma mesa com seis pessoas está captando reverberação tanto quanto fala; o mesmo celular a 30-50 cm do falante, com a tela virada pra cima e apoiado em algo macio em vez de uma mesa dura e ressonante, pode reduzir drasticamente a taxa de erro. Viés de sotaque e má acústica se somam — corrigir a segunda abre margem pra absorver o primeiro.
2. Defina o idioma explicitamente. A detecção automática é um chute feito nos primeiros segundos de áudio, e uma frase de abertura com sotaque forte é exatamente o caso em que ela erra. Se a sua ferramenta permite fixar o idioma, fixe. Se a reunião é genuinamente bilíngue, fixe o idioma que carrega o conteúdo mais importante.
3. Alimente o sistema com uma lista de vocabulário. Qualquer ferramenta que aceite termos personalizados, um glossário ou um prompt com os nomes dos participantes vai usá-los. Nomes e jargão são os erros de maior impacto para eliminar e os mais fáceis, porque são uma lista finita que você já conhece antes da reunião começar.
4. Fale números duas vezes, uma delas decomposta. "Treze — um, três." Parece exagero por exatamente uma reunião, e depois vira o hábito que te salvou de um número errado num resumo.
5. Guarde o áudio, não só a transcrição. A propriedade mais útil de qualquer sistema de transcrição é poder voltar ao áudio original no exato momento em que o texto parece errado. Uma ferramenta que descarta a gravação depois de processar tirou de você o único mecanismo de correção que existia.
6. Deixe uma LLM revisar depois. O trabalho publicado na npj Digital Medicine descobriu que uma passada de modelo de linguagem sobre uma transcrição com sotaque recupera uma parcela relevante dos erros causados pelo sotaque, porque o contexto resolve o que a acústica sozinha não conseguiu. É exatamente o que uma boa etapa de resumo já está fazendo silenciosamente por você.

Como testar uma ferramenta de transcrição com a sua própria voz em dez minutos

Benchmarks publicados são médias sobre falantes que não são você. Fabricantes quase sempre medem a precisão anunciada em fala nativa lida e limpa, a condição mais fácil que existe. Faça o seu próprio teste em vez disso — leva o tempo de um cafezinho e é o único número que importa de verdade:

1. Escreva um roteiro de 150 palavras com cinco nomes de colegas, cinco siglas internas e seis números, incluindo um par treze/trinta.
2. Grave três vezes com a mesma ferramenta: uma a 30 cm num ambiente silencioso, uma a dois metros no mesmo ambiente, uma com o ruído normal de escritório.
3. Conte só substituições e apagamentos nos nomes, siglas e números. Ignore palavras de preenchimento — ninguém liga pra um "é" perdido.
4. Repita com a segunda ferramenta da sua lista, usando as mesmas condições de áudio.
5. Depois, confira o caminho de correção: dá pra tocar o áudio no ponto de uma palavra errada, e dá pra corrigir o texto e manter a correção?

O teste das três distâncias costuma surpreender mais do que a comparação entre ferramentas. Se o resultado a 30 cm está ótimo e o de dois metros é inutilizável, o problema nunca foi o seu sotaque — foi a mesa.

O problema da reunião multilíngue

O caso mais difícil não é nem um sotaque — é uma reunião que troca de idioma no meio da frase, o estado normal das coisas em São Paulo, Zurique, Singapura e em metade dos times de engenharia da internet. Quase todo pipeline de ASR decide um único idioma por arquivo. Uma vez tomada essa decisão, a frase em português dentro da sua reunião em inglês é transcrita como um inglês sem nexo nenhum — e nenhuma disciplina de microfone recupera isso. Vale lembrar também que o inverso acontece: uma reunião inteira em português, gravada por uma ferramenta configurada em inglês por padrão, sai igualmente arruinada, mesmo sem nenhum code-switching envolvido.

Existem só duas estratégias práticas. Ou você divide a gravação — para e começa um novo arquivo quando o idioma muda, o que é desajeitado mas funciona perfeitamente — ou aceita uma transcrição que é um apoio de memória em vez de um registro fiel, e confia num resumo gerado sobre ela pra carregar o sentido. Escolher a segunda opção é perfeitamente razoável, desde que seja uma escolha deliberada e não uma descoberta uma semana depois, ao reler o arquivo.

Por que vale a pena resolver isso, em vez de tolerar

A pesquisa sobre memória é inequívoca quanto à alternativa. Sem um registro externo, a maior parte dos detalhes de uma conversa desaparece em um dia. Se você opera na sua segunda língua, está carregando uma carga cognitiva extra durante a reunião e uma transcrição pior depois. As duas falhas se somam, e quem paga essa conta é justamente quem já tinha o trabalho mais difícil na sala.

Esse é o verdadeiro argumento para levar a sério a distância do microfone, a configuração explícita de idioma e um glossário de nomes. Não é frescura de audiófilo — é a diferença entre um registro em que você confia e um que você silenciosamente para de abrir. O modelo não vai te encontrar no meio do caminho. A configuração vai.

Perguntas frequentes