Qual é a origem do tempo de espera em chamadas com inteligência artificial?
Após a chamada passar pela linha telefônica e pela rota SIP/PBX, o áudio é processado e o sistema determina se o usuário terminou de falar. Em seguida, o modelo interpreta a fala e aciona as ferramentas da empresa. Finalmente, a resposta é convertida em áudio e enviada de volta para o telefone. Se a consulta ao CRM ou a criação de um chamado exigirem tempo de espera, isso também causará um atraso perceptível. Ao medir apenas o primeiro token do modelo, o sistema ignora todo o caminho real percorrido pela chamada.
Análise detalhada da latência em atendimento ao cliente por voz com inteligência artificial, desde a origem até o destino.| Fase | Medição de início e fim | Riscos comuns |
|---|
| Comunicação por telefone | A função de entrada e saída no sistema de voz | Rotas de telecomunicações, codificação/decodificação, latência e perda de pacotes na rede. |
| Identificação de contornos | O usuário deve parar de falar assim que o sistema confirmar o término. | Esperar por muito tempo ou interromper a comunicação muito cedo. |
| Resposta modelo | Enviar dados válidos para gerar conteúdo reproduzível. | Contexto excessivamente longo, seleção de modelos e inferência complexa. |
| Chamada para solicitar ferramentas | Enviar uma API para obter os resultados disponíveis. | Gerenciamento de sistemas corporativos: tratamento de falhas, reabertura e filas de espera. |
| Reprodução de áudio | O texto ou áudio começa a ser reproduzido no dispositivo telefônico. | Buffer sintético, espera inicial e cancelamento de reprodução. |
O VAD (Verbal Audio Detection) identifica se há fala, enquanto a detecção de ciclo verifica se a fala terminou.
O VAD (Voice Activity Detection) geralmente determina o início e o fim da fala com base no volume e no tempo de silêncio; o VAD semântico vai além e estima se a fala ainda está em andamento. Um tempo de espera mais longo pode reduzir o risco de interrupção, mas também aumenta o tempo de pausa; uma resposta muito rápida pode cortar frases como "hum... eu gostaria de mudar isso" em duas partes. Os parâmetros não podem ser usados de forma uniforme para todos os casos; nome, endereço completo, código e descrições abertas exigem diferentes níveis de tolerância a pausas.
"Barge-in" refere-se ao controle de interrupção, e não significa necessariamente o fim da rodada.
A função "Barge-in" permite que o interlocutor interrompa a reprodução da IA e finalize a chamada original, sendo útil para corrigir informações, pular conteúdos já apresentados e encurtar menus. É importante distinguir que "Barge-in" e a função do sistema que interpreta o silêncio do usuário são coisas distintas. Em geral, a interrupção deve ser permitida em conversas normais; no entanto, a gravação de mensagens, a necessidade de revelar informações ou a confirmação de campos importantes devem ser avaliadas individualmente, de acordo com os processos da empresa e as exigências legais. Desativar completamente a função "Barge-in" pode tornar a conversa menos eficiente, enquanto ativá-la globalmente pode impedir a reprodução de conteúdos importantes.
Não se limite a apresentar apenas a média de latência. É importante também analisar as médias p50, p95 e a taxa de variação das latências.
A média pode ser facilmente distorcida por amostras muito pequenas e lentas ou por amostras muito grandes e rápidas. O p50 representa a experiência típica de comunicação, enquanto o p95 representa os casos mais extremos, mas ainda comuns. Além disso, são registradas informações como o tempo desde que o usuário para de falar até a primeira resposta, o tempo de conclusão da ferramenta, erros de interrupção, tempos de espera e falhas na inserção de interrupções. Cada amostra também deve indicar a tarefa, a rede, o idioma e se a API da empresa foi chamada. Caso contrário, as informações de diferentes cenários se misturam, dificultando a identificação do problema.
É importante registrar tanto o atraso quanto a alternância (ou rotação) de forma coordenada.| Critérios de avaliação | Definição do evento | Finalidade de uso |
|---|
| Primeira resposta atrasada | Verificar se o ciclo de confirmação foi concluído até que o usuário receba uma resposta. | Distinguir entre etapas, modelos e tempos de espera. |
| Em espera | A API agora retorna os resultados disponíveis. | Identifique gargalos em sistemas corporativos ou em sistemas de terceiros. |
| Erro de corte | O usuário começou a responder antes de terminar de falar. | Ajustar estratégias para VAD, colunas e campos. |
| Erro aguardando | O usuário terminou de falar, mas o sistema permanece em silêncio. | Verificação de conclusão, tempo limite e status das ferramentas |
| Mensagem enviada com sucesso | Após o usuário fazer uma nova entrada, a resposta anterior é desativada e a nova entrada é mantida. | Verificar se a ação de cancelar a reprodução é consistente com o contexto. |
Para o teste de linha telefônica, é necessário incluir ruído, eco, sotaques e campos longos.
O microfone embutido no navegador, em um ambiente de escritório silencioso, não representa a qualidade do áudio em dispositivos móveis, carros, telefones sem fio, fones de ouvido Bluetooth ou telefones fixos. O teste deve abranger ruídos de fundo, eco, instabilidade do sinal, velocidade da fala, sotaques comuns, números, códigos alfanuméricos e endereços longos. Para campos importantes, o objetivo não é apenas a precisão literal, mas sim a capacidade do sistema de repetir, permitir que o usuário corrija e interromper a execução quando houver incerteza.
Quando você precisa de ajuda, não use respostas falsas para preencher o silêncio.
APIs de CRM, ERP ou de atribuição de tarefas podem levar vários segundos ou até mesmo entrar em um processo assíncrono. O sistema pode fornecer atualizações curtas para evitar a sensação de lentidão, mas não deve afirmar que a tarefa foi concluída antes da obtenção dos resultados. Quando o tempo de espera for excessivo, é recomendável criar um estado de "aguardando confirmação", encaminhar para tratamento manual ou enviar notificações subsequentes, utilizando um identificador único para evitar execuções repetidas. Otimizar a latência, se isso comprometer a precisão dos resultados, apenas acelera a comunicação de erros.
"3 segundos" é apenas um objetivo de design, e não um Serviço de Nível de Serviço (SLA) divulgado pela GoGoCha.
Os casos públicos da GoGoCha demonstram a eficácia do acesso telefônico e do fluxo de trabalho de despacho imediato, mas não há informações públicas sobre a distribuição de latência, o ambiente de telecomunicações, amostras de chamadas ou SLAs. Não se deve definir metas de design de produtos como níveis de serviço alcançados sem a mesma definição e medição. Projetos empresariais devem redefinir os parâmetros p50, p95 e amostras de falhas sob suas próprias condições de PBX/SIP, API e pico de demanda.
