Publicado em: · Versão para IA (markdown)
Você escolhe um mecanismo de reconhecimento de fala (STT) para chamadas não pela “precisão em geral” anunciada, mas pelo desempenho dele especificamente nas suas conversas: no seu idioma, em áudio telefônico de 8 kHz, dentro do seu orçamento por minuto e conforme seus requisitos sobre para onde os dados vão. Não existe um mecanismo universalmente “melhor” — existe o que se encaixa na tarefa. A seguir, os seis critérios para decidir e por que testá-los no seu próprio arquivo, em vez de confiar em benchmarks de terceiros.
Passo 1. Comece pelo idioma e pelos sotaques
O primeiro critério eliminatório é o idioma. Um mecanismo excelente em inglês pode ter desempenho bem mais fraco em português, e vice-versa. Se suas chamadas ocorrem em vários idiomas ou com sotaques regionais fortes, procure um mecanismo multilíngue, não um conjunto de modelos monolíngues. Para telefonia em português, mecanismos locais costumam ser fortes; para dezenas de idiomas, modelos multilíngues em nuvem se destacam.
É importante não confundir o idioma da interface com o idioma do reconhecimento: são coisas diferentes. Determine em quais idiomas suas chamadas realmente ocorrem e em que proporções. Se 95% das conversas são num só idioma, otimize para ele; se o fluxo é misto, é essencial que o mecanismo consiga alternar entre idiomas dentro da mesma conversa sem “cair” no idioma padrão.
Passo 2. Verifique a precisão em áudio telefônico de 8 kHz
Essa é a principal armadilha. A maioria dos números bonitos de precisão vem de áudio de estúdio limpo, de 16 kHz ou mais, enquanto a telefonia é áudio de banda estreita de 8 kHz, com codecs, ruído de linha, eco e sobreposição de fala. Um mecanismo que brilha em podcasts pode ter um resultado bem pior em chamadas reais. Por isso, a precisão precisa ser testada em gravações o mais parecidas possível com as suas — com a mesma telefonia, as mesmas condições, o mesmo jargão.
Um método prático: pegue uma dezena de chamadas típicas cujo conteúdo você conhece com certeza, rode-as em vários mecanismos e compare as transcrições manualmente. Preste atenção não à porcentagem geral, mas ao que é crítico para você: se nomes, números, valores, nomes de produtos e termos específicos são reconhecidos corretamente. Um erro num valor de contrato pesa mais do que um “hum” perdido. Não confie em benchmarks alheios — sua acústica é única.
Passo 3. Calcule o custo por minuto
Os mecanismos variam de preço em múltiplos, e em volume isso é decisivo. O cálculo não deve ser sobre um preço abstrato, mas sobre o custo do minuto do seu cenário específico: considere a duração das chamadas, o número de canais (gravação estéreo com atendente/cliente separados dobra o custo em mecanismos que cobram por canal) e o volume mensal de fluxo.
O custo de operação dos mecanismos varia bastante — de frações de centavo a alguns centavos por minuto. Na plataforma, as operações são debitadas do saldo pelo custo de operação do mecanismo, sem markup, então seu preço por minuto é exatamente o preço do mecanismo; é fácil comparar os planos na página de preços. Um mecanismo multilíngue caro se justifica quando é preciso máxima precisão e há muitos idiomas envolvidos; para volumes grandes e homogêneos, geralmente um mecanismo local barato, específico para um idioma, sai na frente.
Passo 4. Resolva a questão da diarização e dos canais
Para analisar chamadas, o texto sozinho não basta — é preciso saber quem disse o quê: onde estão as falas do atendente e onde estão as do cliente. Há dois caminhos. Se a gravação é estéreo e os papéis já estão separados por canal (atendente num canal, cliente no outro), a separação fica precisa quase automaticamente — essa é a melhor opção, e vale planejá-la já na configuração da telefonia. Se a gravação é mono, os papéis são separados por diarização — que divide a faixa única entre os falantes.
Considere que a diarização é uma operação separada, com uma linha própria de custo, e sua qualidade em áudio telefônico é menor do que em áudio limpo. Por isso, quando possível, grave as chamadas em estéreo com canais separados: é mais preciso e mais barato do que depender de diarização sobre uma faixa mono. Como funciona a camada de reconhecimento e marcação de papéis está detalhado na página de análise automática de chamadas.
Passo 5. Escolha o modo: tempo real ou processamento em lote
Nem toda tarefa precisa de reconhecimento instantâneo. Se você está analisando um arquivo ou processando chamadas posteriormente para métricas e controle de qualidade, o tempo real não é necessário — e o processamento em lote com atraso costuma ser bem mais barato. Em alguns mecanismos, o modo com atraso custa uma fração do modo síncrono com a mesma qualidade, e em volume isso representa uma economia relevante.
O tempo real (reconhecimento em streaming) é necessário onde o texto é exigido durante a própria conversa: apoio ao atendente, transcrição ao vivo, agente de voz com IA. Para todo o resto — pós-processamento, análises, marcação retroativa do arquivo — escolha o modo em lote. Além disso, cortar silêncios antes do reconhecimento (arquivo mais curto, custo menor) e usar o cache de transcrições repetidas (o mesmo áudio com os mesmos parâmetros não é reconhecido duas vezes) ajudam a reduzir ainda mais a conta.
Passo 6. Defina os requisitos de dados (nuvem ou self-hosted)
O último critério não é técnico, mas de confiança e conformidade regulatória. Se, pela política da empresa ou por exigência legal, o áudio das chamadas não pode sair do seu perímetro, um mecanismo em nuvem não serve, independentemente da precisão ou do preço. Nesse caso, escolha reconhecimento self-hosted: o modelo roda na sua infraestrutura, e os dados não saem para fora.
Para esse cenário, mecanismos como Whisper ou Vosk, rodando na sua própria infraestrutura, se encaixam bem: podem ser colocados em produção localmente e reconhecer sem pagamento por minuto a um provedor externo e sem enviar áudio para a nuvem. Na plataforma, esse modo é implementado por meio de um worker local: você baixa e executa na sua própria infraestrutura, pareia por código, e a transcrição com diarização rodam dentro do seu perímetro — o áudio não sai dele. Mais detalhes sobre modelos de isolamento de dados e opções on-premise na página de segurança.
Como reunir os critérios
Não existe um mecanismo “melhor” isolado, mas há um caminho simples para chegar a uma decisão. Primeiro, elimine pelas restrições rígidas: idioma (o mecanismo precisa entender bem seus idiomas) e dados (se precisar de self-hosted, a nuvem já sai de cogitação). Depois, nos candidatos restantes, teste a precisão em áudio telefônico do seu próprio arquivo e calcule o custo por minuto do seu fluxo real. Por fim, considere canais/diarização e o modo de processamento — eles geram economias fáceis de deixar passar.
Na prática, não vale a pena se prender a um único mecanismo para sempre. Cenários diferentes podem exigir mecanismos diferentes: um caro e preciso para idiomas importantes ou chamadas complexas, um barato em lote para o fluxo em massa, um self-hosted para dados sensíveis. A plataforma permite conectar mecanismos do sistema, trazer sua própria chave para um provedor externo ou rodar um worker local, então a escolha não é definitiva: pode mudar conforme você cresce e for testando nos seus próprios dados.
Próximos passos
Escolher o mecanismo é a base, mas não o objetivo final: o texto reconhecido vale pelo que se extrai dele. O próximo passo é transformar as transcrições em métricas, temas e controle de qualidade em todas as chamadas de uma vez. Se você está comparando a própria abordagem — plataforma de análise contra “apenas transcrição” —, veja em que a análise de chamadas se diferencia da transcrição.