Teste de agente de voz AI: prove que a chamada funcionou

O teste do agente de voz de IA não deve ser aprovado porque a transcrição parece plausível. Um teste defensável prova cinco coisas distintas: a chamada foi conectada, o agente respondeu dentro de um limite específico do fluxo de trabalho, a interrupção realmente interrompeu o áudio do assistente, cada ferramenta de efeito colateral atingiu um resultado conhecido e o resultado solicitado pelo chamador existe fora da conversa. Essa distinção é importante porque os artefatos usuais respondem a questões mais restritas. Uma gravação prova que o áudio existia. Uma transcrição prova que o reconhecimento de fala produziu texto. Uma rubrica LLM estima se aquele texto atendeu a um critério. Um status de telefonia do terminal comprova que a chamada foi encerrada. Nenhum destes factos por si só prova que uma consulta foi marcada, um cancelamento foi aplicado ou uma transferência chegou ao seu destino. O padrão prático é manter o simulador e o avaliador de transcrição e, em seguida, adicionar um pequeno recibo de chamada determinístico ao lado deles. Uma transcrição fluente tem apenas uma camada A simulação de voz é útil. Atual de Vapi documentação de teste de voz descreve uma chamada telefônica real entre o agente alvo e um agente de teste, seguida de gravação, transcrição e avaliação LLM em relação a uma rubrica. Isso exercita muito mais o caminho do que um teste de prompt somente de texto. Ainda deixa lacunas observáveis. Uma transcrição pode omitir o limite exato entre o término do chamador e o início da reprodução de áudio. Ele pode ser lido com clareza depois que o chamador falou com o assistente. Ele pode conter a confirmação confiável de uma ferramenta mesmo quando o tempo limite do sistema remoto expirou. A conclusão da telefonia tem um significado igualmente restrito. Documentos Twilio queued , ringing , in progress , completed , busy , failed , no answer , e canceled estados de chamada. Isso é Referência de recurso de chamada também alerta que completed significa que uma conexão foi estabelecida e o áudio foi transferido. Uma pessoa, um IVR ou correio de voz pode ter atendido. "Concluído" é, portanto, uma prova de transporte e não um veredicto comercial. Em vez disso, use cinco portas: Portão Evidência mínima Uma falha que expõe Acessibilidade ID de chamada correlacionado mais conectado ou in progress status Na fila, sem resposta, destino inválido Tempo de giro O áudio do usuário parou em t1 ; áudio do assistente iniciado em t2 Resposta lenta escondida por uma transcrição coerente Interrupção Interrupção do usuário em t3 ; áudio do assistente interrompido por t4 O agente continua falando pelo chamador Efeito de ferramenta ID de operação estável mais recibo de destino Tempo limite seguido por uma nova tentativa cega insegura Resultado Verificação independente do resultado prometido Fim da chamada normal sem reserva, transferência ou cancelamento Não combine isso em uma pontuação inicialmente. Uma média ponderada pode permitir que uma transcrição excelente esconda um resultado ausente. Mantenha a camada com falha visível. Grave limites de áudio, não apenas a latência do modelo O intervalo útil da primeira resposta começa quando o áudio do chamador é considerado concluído e termina quando o áudio do assistente realmente começa a ser reproduzido: Isso não é o mesmo que o tempo do modelo até o primeiro token. Endpointing de fala, transcrição, inferência de modelo, síntese, buffer e transporte de telefonia estão incluídos na experiência do chamador. Medir apenas um estágio interno pode fazer com que uma chamada lenta pareça saudável. A interrupção precisa de outra observação emparelhada: Vapi documentação de eventos do servidor expõe atualizações de status separadas, atualizações de fala, user interrupted , chamada de ferramenta e eventos de fim de chamada. Ele observa que a interrupção pode ser associada à evidência de interrupção da fala. Outros provedores usam nomes diferentes, mas o contrato é portátil: retém um ID de chamada, ID de turno quando disponível, carimbos de data e hora monotônicos, tipo de evento e um pequeno conjunto de campos sem conteúdo. Não existe um bom valor universal para nenhum dos intervalos. O fixture executável usado para este artigo define maxFirstResponseMs para 1200 e maxInterruptStopMs a 300, portanto a regra de decisão é inspecionável. Esses são exemplos de valores políticos, não de padrões da indústria. Calibre com caminhos de rede reais, idiomas, estilos de fala, necessidades de acessibilidade e o custo de uma falsa falha. Um teste de liberação também deve preservar a incerteza. Se a parada de fala do usuário estiver faltando, não calcule a latência a partir de um carimbo de data/hora da transcrição. Se o evento de interrupção existir, mas o assistente stop não, retorne barge in failed ou insufficient evidence de acordo com o contrato de cobrança. Nunca crie um intervalo saudável a partir de eventos incompletos. Repetir uma precedência de falha antes de testar chamadas ao vivo O artefato complementar contém oito fluxos de chamadas sem conteúdo. Cada evento possui um timestamp relativo e apenas os campos necessários para classificação: Execute o com: O fixture executado produziu a paridade esperada exata em oito veredictos: A precedência é importante. Verifique a acessibilidade antes de cronometrar porque uma chamada não atendida não pode ter uma primeira resposta significativa. Verifique o tempo e a interrupção antes dos efeitos da ferramenta, pois um chamador pode já ter experimentado uma interação interrompida. Reconcilie o efeito da ferramenta antes de avaliar a conclusão do terminal, pois tentar novamente um efeito colateral incerto pode duplicar o trabalho. Exija o resultado por último porque é a afirmação mais forte. Esta ordem é uma regra operacional, não uma classificação de gravidade. Um cancelamento malsucedido pode ter mais impacto do que um áudio lento. Encaminhe a gravidade do fluxo de trabalho e as consequências do usuário depois que a camada de evidências for conhecida. Mantenha o recibo da ferramenta separado do recibo do resultado Um agente de voz frequentemente invoca uma ferramenta de agendamento, pagamento, emissão de bilhetes ou transferência. O resultado da ferramenta do modelo não é necessariamente o estado durável do destino. Dê a cada tentativa de efeito colateral um ID de operação estável. Retenha a ação solicitada, a classe de destino, o número da tentativa, a classe de resposta e uma verificação de efeito sem conteúdo. Se o transporte expirar após o envio, reconcilie esse ID de operação antes de tentar novamente. Uma segunda solicitação com uma nova identidade pode criar um agendamento duplicado ou cancelamento. Em seguida, verifique o resultado prometido pelo chamador de forma independente. Um efeito de ferramenta pode ser real enquanto o resultado do usuário ainda estiver errado: existe um agendamento na conta errada, uma transferência conectada a uma URA em vez de uma operadora ou um cancelamento alterado em um item enquanto o pacote solicitado permanece ativo. O aparelho false complete caso é deliberadamente inconveniente. Possui uma chamada conectada, uma primeira resposta de 600 ms, um recebimento verificado do efeito da ferramenta e um status de chamada concluída. Ainda falha porque outcome.verified está ausente. Esse é o caso exato em que uma porta somente de transcrição provavelmente falhará. Um avaliador LLM continua útil para qualidades que são difíceis de codificar deterministicamente: se o agente reconheceu a frustração, explicou uma política claramente ou seguiu um estilo de interação. Mantenha seu veredicto com a camada de avaliação de transcrição. Não deixe que ele substitua a acessibilidade, os carimbos de data/hora, os recebimentos de destino ou o estado externo. Envie o menor recibo com segurança de privacidade O classificador não precisa de áudio do chamador ou texto transcrito. Um recibo mínimo pode conter IDs de chamadas e turnos pseudônimos, carimbos de data/hora relativos, tipos de eventos, estado do terminal, versão da política com hash, ID da operação e efeitos booleanos e resultados de resultados. Mantenha as gravações apenas quando o consentimento, a política de retenção e o valor de depuração as justificarem. Antes do lançamento, execute o dispositivo fixo para provar o próprio classificador. Em seguida, execute um pequeno conjunto de chamadas reais entre operadoras, regiões, idiomas e comportamentos importantes do chamador. Revise as distribuições de limites em vez de ajustar se a uma chamada de laboratório limpa. Por fim, reproduza as falhas de produção como novos casos de regressão sem copiar o conteúdo confidencial da conversa no conjunto de testes. A limitação é direta: esse artefato valida uma regra de decisão, não a qualidade do reconhecimento de fala ou o tempo de atividade de qualquer provedor. Ele não pode escolher limites para seus chamadores. No entanto, evita que uma conversa polida seja confundida com um trabalho verificado. A Sidewisp está atualmente em prévia privada. A sua experiência pública é um site de acesso antecipado e uma demonstração interativa; A coleta e recuperação de integridade do agente de produção não são enviadas no repositório do site atual. A direção do produto é uma camada de integridade em torno dos tempos de execução existentes, não uma plataforma de voz, provedor de telefonia ou fixador autônomo. Se este recibo de cinco portas corresponder às falhas que você precisa detectar, você pode junte se à visualização privada do Sidewisp e descreva o tempo de execução do agente de voz que você opera.