O sistema de voz da Retell funciona como uma cadeia ao vivo com três etapas principais. E cada uma depende da etapa anterior a ela.
ASR → LLM → TTS
ASR (reconhecimento automático de fala) ouve quem liga e transforma a fala em texto.
LLM (modelo de linguagem) lê esse texto, entende o que foi dito e decide o que responder.
TTS (conversão de texto em fala) pega essa resposta e a transforma em áudio falado que quem ligou ouve.
Então o fluxo é basicamente: quem liga fala → o ASR transcreve → o LLM gera uma resposta → o TTS a fala de volta.
Quando alguém está em uma chamada, tanto o ASR quanto o LLM são os sistemas críticos trabalhando em tempo real. E ambos podem falhar, ficar lentos ou se comportar de forma imprevisível. Precisamos poder confiar que ambos os sistemas funcionem, então construímos uma configuração que monitora, faz backup e troca constantemente em tempo real. E veja como os dois trabalham juntos e por que essas atualizações importam:
Primeiro, ficamos atentos à lentidão (não à falha)
Estamos constantemente fazendo uma pergunta simples: "O sistema está acompanhando a conversa?" A cada 0,1 segundo, comparamos:
- Quanto áudio enviamos
- Quanto áudio foi de fato processado
Se a diferença cresce além de 5 segundos, esse é o nosso sinal: este provedor está ficando para trás. Não morto. Não quebrado. Mas a caminho disso. E é aí que agimos.
Mantemos uma "rede de segurança" ao vivo do seu áudio
Enquanto o áudio está sendo processado, mantemos um backup contínuo de tudo o que ainda não foi totalmente tratado. Pense assim:
- Se o sistema confirma que processou algo → descartamos
- Se ainda não → seguramos
Então, a qualquer momento, temos uma cópia perfeita do áudio "intermediário", que é a parte com maior risco de se perder. Sem adivinhação. Sem lacunas.
Então trocamos por um backup
No momento em que detectamos a lentidão, não ficamos esperando. Nós:
- Acionamos um provedor de backup (há uma ordem de prioridade: primeiro o mais rápido, mais próximo e mais confiável)
- Enviamos todo aquele áudio "em suspenso" para que ele possa se atualizar
- Desligamos o provedor que está com dificuldades
Também damos ao novo provedor um curto período de tolerância (~20 segundos) para se estabilizar antes de começarmos a julgar seu desempenho.
O resultado?
A transcrição simplesmente… continua. Sem salto. Sem retrocesso. Sem lacunas estranhas. Do ponto de vista de quem ligou, nada aconteceu.
Por que isso importa
A maioria dos sistemas espera um provedor travar completamente antes de trocar.
Nós não. Captamos o momento em que ele começa a ter dificuldades e o substituímos antes que se torne um problema.
Conclusão
- Não esperamos a falha
- Detectamos as lentidões em tempo real
- Preservamos cada segundo de áudio
- Trocamos de provedor de forma fluida
Para que a conversa continue fluindo exatamente como deveria.
LLM: do roteamento em nível de provedor ao nível de implantação
Como funcionam os nossos fallbacks de LLM
Agora, no lado da resposta, a falha não é tão óbvia. É mais sutil. Para cada modelo de LLM (ou seja, GPT-4.1), temos um conjunto de "implantações" que servem esse modelo. Pense em uma implantação como um data center físico. Quando queremos obter a resposta de IA de um modelo, precisamos especificar uma implantação específica para enviar essa requisição. Às vezes, as requisições podem falhar, seja por um problema de conectividade de internet ou por um monte de tráfego sendo enviado por outras pessoas para a mesma implantação, que pode ficar sobrecarregada.
Por baixo dos panos, há algumas peças em movimento e pode ficar um pouco complexo, mas a ideia central é simples:
Roteamos para implantações que têm menor latência
Garante que as respostas sejam geradas mais rápido e reduz a lentidão para manter as conversas em sincronia em tempo real.
Medimos e monitoramos constantemente a taxa de erro de cada implantação
E cortamos o tráfego para as que têm altas taxas de erro.
Temos sede de velocidade ao enviar uma requisição para uma implantação
Se está lenta, não esperamos. Enviamos a requisição para outro lugar e seguimos até que uma responda.
Que vença o melhor modelo de IA
Se um modelo falha em várias implantações, não continuamos tentando. Trocamos por outro e seguimos.
Conclusão
Não estamos dependendo de um modelo ou de um provedor.
Estamos constantemente:
- roteando para a melhor opção
- evitando o que está falhando
- correndo por respostas mais rápidas
- e trocando quando necessário
Para que, mesmo quando os sistemas têm um dia ruim, as suas conversas não tenham.
