--- title: "Como escolher um mecanismo de reconhecimento de fala para chamadas" description: "O mecanismo STT certo para telefonia é escolhido não pela precisão de marketing, mas pelo idioma, pela qualidade em áudio de 8 kHz, pelo custo por minuto e pelos requisitos de dados. Seis critérios e como testá-los no seu próprio arquivo." datePublished: "2026-07-12" canonical: "https://callscribe.me/pt/guides/choose-stt-engine" --- # Como escolher um mecanismo de reconhecimento de fala para chamadas 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](/pricing). 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](/product/call-analytics). ## 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](/security). ## 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](/compare/vs-transcription).