Los agentes de voz están transformando la forma en que las empresas interactúan con los clientes, gestionando reservas de citas, consultas de pedidos, gestión de cuentas y más a través de conversaciones habladas naturales. Pero a medida que estos agentes se vuelven más capaces, surge un desafío fundamental: ¿cómo se los prueba?
A diferencia de los chatbots basados en texto, donde se pueden escribir entradas y afirmar salidas, los agentes de voz operan en un paradigma fundamentalmente diferente. Transmiten audio de forma bidireccional, responden de forma no determinista, mantienen el contexto en conversaciones de varios turnos y utilizan herramientas en tiempo real. La única forma en que la mayoría de los equipos realizan pruebas hoy en día es que alguien hable físicamente con el sistema y escuche lo que regresa. Eso es lento, inconsistente y no escala.
Esta brecha en las pruebas crea dos problemas críticos para los equipos que crean aplicaciones de voz:
La iteración de las indicaciones del sistema y las configuraciones de herramientas es tremendamente lenta. Cada vez que modifica un mensaje o ajusta las definiciones de herramientas para mejorar la precisión, debe volver a probar manualmente docenas de escenarios de conversación para ver si las cosas mejoraron o empeoraron. Sin retroalimentación automatizada, la ingeniería rápida se convierte en conjeturas. No existe un marco de evaluación confiable para la calidad de los agentes de voz. No puede ejecutar un conjunto de regresión antes de implementar un cambio. No se puede medir si su agente maneja correctamente los casos extremos en cientos de escenarios. No se pueden detectar regresiones sutiles, como que el agente de repente se olvide de confirmar una reserva, hasta que un cliente real los golpea.
Si tienes 50 escenarios de conversación entre 3 usuarios, estás viendo 150 pruebas manuales, cada una de las cuales requiere varios minutos de interacción en tiempo real. Ejecútelo después de cada cambio rápido y gastará días en control de calidad.
En esta publicación, lo guiaremos a través de Nova Sonic Test Harness, un marco de código abierto que creamos para resolver ambos problemas. Sirve como una herramienta de iteración rápida para ajustar las indicaciones del sistema y las configuraciones de herramientas (ejecutar una conversación, ver resultados, ajustar, repetir) y como un marco de evaluación integral para validar la calidad del agente de voz a escala. Ejecuta conversaciones completas de varios turnos con Amazon Nova Sonic automáticamente, las evalúa utilizando técnicas de LLM como juez e incluso puede detectar casos en los que la salida de audio del modelo no coincide con su salida de texto (alucinaciones de audio). No se requiere micrófono.
Por qué las pruebas de habla a voz son diferentes
Si ya ha probado modelos de lenguaje grande (LLM) basados en texto, quizás se pregunte por qué no puede simplemente adaptar esas herramientas. Esto es lo que hace que las pruebas de agentes de voz sean fundamentalmente más difíciles:
Transmisión bidireccional. Los modelos de voz a voz no utilizan solicitud-respuesta. Mantienen una conexión persistente y full-duplex donde el audio y el texto fluyen en ambas direcciones simultáneamente. Las herramientas de prueba HTTP estándar no pueden interactuar con este protocolo.
Respuestas no deterministas. Haga la misma pregunta dos veces y obtendrá una redacción diferente, una sincronización de audio diferente e incluso un orden de llamadas de herramientas diferente. No se pueden escribir afirmaciones como "esperar la cadena exacta X".
Contexto multiturno. Un solo giro no te dice casi nada. El comportamiento interesante ocurre entre turnos: ¿recuerda el modelo lo que dijo antes la persona que llamó? ¿Hace un seguimiento adecuado? ¿Sabe cuándo termina la conversación?
Divergencia audio-texto. Los modelos de voz a voz producen texto y audio al mismo tiempo y pueden decir cosas diferentes. El texto puede leer "3:00 p. m." mientras que el audio dice "3:30 p. m.". No se puede captar esto leyendo únicamente las transcripciones.
Límites de sesión. Las conexiones se agotan después de unos 8 minutos. Si su conversación de prueba es más larga, debe encargarse de la reconexión y la reproducción del historial.
El arnés de prueba se encarga de todo esto. Veamos cómo funciona.
Cómo funciona el arnés de prueba
En un nivel alto, el arnés hace cuatro cosas: configura un escenario de prueba, ejecuta una conversación completa con Nova Sonic, evalúa el resultado y produce un informe. Todo el oleoducto funciona sin supervisión. Usted define el escenario en un archivo JSON y regresa a los resultados.
Figura 1: descripción general de la arquitectura. El arnés de prueba coordina un simulador de usuario, Nova Sonic, y un juez de LLM en todos los servicios de AWS.
Repasemos cada fase.
Definición de un escenario de prueba
Cada prueba comienza con un archivo de configuración JSON. Piense en ello como si describiera un escenario de conversación: ¿quién pretende ser Nova Sonic, quién es la persona que llama, qué herramientas están disponibles y cómo se ve el “éxito”?
Aquí hay un ejemplo real, probando un agente de reserva de citas:
La idea clave es que usted está definiendo objetivos y criterios de evaluación, no resultados esperados. Debido a que Nova Sonic responde de manera diferente cada vez, evaluamos con rúbricas en lugar de verificar cadenas exactas.
Un registro de modelo (models.yaml) asigna alias cortos como claude-haiku a ID de modelo completos de Amazon Bedrock, de modo que las configuraciones no se interrumpan cuando cambian las versiones del modelo.
Dirigiendo la conversación
Una vez que tenga un archivo de configuración, el arnés ejecuta la conversación automáticamente. Esto es lo que sucede en cada turno:
Figura 2: El proceso de prueba de cuatro fases desde la configuración hasta los resultados.
Figura 3: Flujo de datos dentro de un solo turno de conversación.
El simulador de usuario genera un mensaje. Un LLM (por ejemplo, Claude Haiku en Amazon Bedrock) lee la conversación hasta el momento y decide qué diría a continuación la persona que llama. Se mantiene en carácter. Si la persona es un "cliente impaciente", actúa impaciente. El mensaje va para Nova Sonic. Ya sea como texto (rápido, bueno para la mayoría de las pruebas) o como audio sintetizado usando Amazon Polly (para probar el proceso completo de reconocimiento de voz). Nova Sonic transmite su respuesta. Las llamadas de texto, audio y posiblemente a herramientas llegan de forma asincrónica. El arnés procesa todo esto en tiempo real utilizando flujos reactivos. El arnés detecta cuando se realiza el giro. Nova Sonic produce texto en dos etapas (especulativa y luego final). Cuando se hayan finalizado todos los bloques especulativos, se completará el turno. Esto es más confiable que esperar el silencio o usar tiempos de espera. Las llamadas a herramientas se manejan en el flujo. Si Nova Sonic solicita llamar a una herramienta (como verificar la disponibilidad de citas), el controlador registrado se ejecuta y devuelve el resultado sin interrumpir la conexión. Todo está registrado. Se guardan el texto final, el audio WAV, las llamadas a herramientas y los metadatos de sincronización.
Luego el bucle se repite.
¿Qué pasa con las conversaciones largas?
Las conexiones de Nova Sonic se agotan después de aproximadamente 8 minutos. SessionContinuationManager maneja esto de forma transparente: monitorea la antigüedad de la conexión, crea una nueva sesión antes del tiempo de espera (predeterminado: 6 minutos) y reproduce el historial de conversaciones en la nueva sesión. Su escenario de prueba no necesita saber sobre esto. Simplemente funciona.
Evaluación de la calidad
Una vez finalizada la conversación, el arnés pasa la transcripción completa a un juez de LLM independiente (por ejemplo, Claude Opus). El juez no sabe nada sobre la configuración de la prueba. Sólo ve la conversación y los criterios de evaluación. Esto evita sesgos.
Figura 4: El juez de LLM evalúa cada métrica de forma independiente con veredictos de rúbrica SÍ/NO.
El juez evalúa seis métricas integradas, organizadas en tres niveles:
Nivel de métrica Lo que verifica Logro de objetivos Crítico ¿La conversación logró lo que el usuario quería? Precisión de la respuesta Crítica ¿Fueron correctos los hechos, las cifras y las afirmaciones? Uso de herramientas importante ¿Se utilizaron las herramientas adecuadas con los parámetros correctos? Flujo de la conversación Importante ¿Pareció una conversación natural? Cumplimiento de las indicaciones del sistema Importante ¿El agente se mantuvo en su personaje? Aviso sobre formato de voz ¿La respuesta sonaría natural cuando se habla en voz alta?
El sistema de niveles determina la lógica de aprobación/reprobación: ambas métricas críticas deben aprobarse para un APROBADO general. Métricas importantes contribuyen a la puntuación de la tasa de aprobación. Las métricas de asesoramiento se informan pero no afectan el veredicto.
Cada métrica se evalúa a través de múltiples preguntas de rúbrica que reciben respuestas estrictas de SÍ/NO. Una métrica se aprueba sólo si se aprueban todas las preguntas de la rúbrica. Esto significa que cuando algo falla, usted sabe exactamente qué pregunta falló y puede leer el razonamiento del juez para comprender por qué.
También puede definir preguntas de rúbrica personalizadas para su dominio. Para un agente de atención médica, podría agregar: "¿Verificó el agente la información del seguro antes de reservar?" Para un agente bancario: "¿El agente confirmó el monto de la transferencia antes de ejecutarla?"
Ver resultados
Los resultados vienen en múltiples formatos dependiendo de su flujo de trabajo:
Panel interactivo. Con una aplicación Streamlit, puede explorar visualmente los resultados de los lotes, comparar ejecuciones, profundizar en las fallas y buscar entre transcripciones. JSON/CSV estructurado. Cada sesión produce un registro de interacción, resultados de evaluación y archivos de audio en un directorio organizado. Los resúmenes de lotes agregan tasas de aprobación en todas las sesiones. Integración continua y entrega de veredictos amigables (CI/CD). La salida binaria PASA/FALLA y la tasa de aprobación numérica están diseñadas para conectarse directamente a puertas de calidad automatizadas.
Captar alucinaciones sonoras
Los modelos de voz a voz producen salidas de texto y audio simultáneamente. La mayoría de las veces coinciden. Pero ocasionalmente, Nova Sonic puede escribir una cosa y decir otra. Imagine a un agente de voz que le dice a un cliente que su pedido llega "el próximo lunes" en audio mientras el flujo de texto dice "el próximo martes". Si solo revisa los registros de texto, nunca lo detectará.
Cargue el audio de cada turno a Amazon Simple Storage Service (Amazon S3). Transcríbalo usando Amazon Transcribe (lo que realmente se habló). Compare la transcripción con el resultado del texto utilizando un LLM. Clasifique cada diferencia: palabras de relleno, variantes de fraseo o errores fácticos.
Cada turno obtiene un veredicto:
COHERENTE. Sólo palabras de relleno (“um”, “uh”) o ninguna diferencia. DIFERENCIAS_MENORES. Variantes de fraseo con el mismo significado (“Puedo ayudarte” frente a “Déjame ayudarte”). ALUCINACIÓN. Discrepancia fáctica. Diferentes números, fechas, nombres o reclamos entre texto y audio.
Esto es más importante para los agentes de voz que comunican hechos específicos: horarios de citas, precios, números de teléfono, nombres de medicamentos, códigos de confirmación. Una alucinación en cualquiera de estos podría dañar directamente al usuario.
Pruebas a escala
Probar un escenario es útil para el desarrollo. Pero para tener confianza antes de la implementación, debe probar docenas de escenarios, con diferentes personas, casos extremos y rutas de conversación, y debe ejecutarlos repetidamente para tener en cuenta el no determinismo.
Figura 5: La ejecución por lotes ejecuta sesiones de prueba paralelas con informes de calidad agregados.
El ejecutor de lotes hace que esto sea práctico:
El arnés se entrega con paquetes de escenarios listos para usar: 12 escenarios de atención médica (reserva de citas, reclamos de seguros, referencias), ocho escenarios bancarios (transferencias, consultas de saldo, disputas) y cinco variantes de servicio al cliente (personas que llaman enojadas, tranquilas y confundidas con diferentes estados de pedido).
Después de una ejecución por lotes, el panel muestra las tasas de aprobación en todos los escenarios, desgloses por métrica, correlaciones de co-fallo (qué métricas tienden a fallar juntas) y una comparación lado a lado entre ejecuciones. Puede ver exactamente qué mejoró o retrocedió después de un cambio rápido.
Elegir el modo de entrada correcto
Las diferentes necesidades de pruebas requieren enfoques diferentes. El arnés admite cuatro modos de entrada:
Modo Cómo funciona Cuándo usarlo Texto (predeterminado) Mensajes generados por LLM enviados como eventos de texto Pruebas diarias, iteración de mensajes, validación de herramientas Amazon Polly TTS Texto de usuario sintetizado en audio usando Amazon Polly Prueba de la canalización de reconocimiento automático de voz (ASR), condiciones realistas de producción Mensajes predefinidos con script, no implica LLM Pruebas de regresión, reproducibilidad exacta entre ejecuciones Escenarios basados en conjuntos de datos cargados desde JSONL o evaluación comparativa de Hugging Face, conjuntos de pruebas a gran escala
El modo texto es más rápido y admite el mayor paralelismo. Utilice el modo Amazon Polly cuando necesite probar específicamente cómo Nova Sonic maneja la entrada de audio real (incluidas posibles interpretaciones erróneas de ASR). Utilice el modo de secuencia de comandos para pruebas de regresión en las que necesite entradas idénticas en todo momento.
Empezando
Para obtener instrucciones de instalación completas, requisitos previos y detalles de configuración, consulte el repositorio de GitHub. Ejecutará su primera conversación automatizada en menos de cinco minutos.
Servicios de AWS utilizados
Servicio ¿Qué hace en el arnés? ¿Requiere? Amazon Bedrock alberga Nova Sonic, LLM de simulador de usuario y LLM de jueces Sí Amazon Polly Convierte texto de usuario en voz para pruebas de entrada de audio Opcional Amazon S3 Almacena temporalmente archivos de audio para transcripción Opcional Amazon Transcribe Convierte audio en texto para detección de alucinaciones Opcional
Limpiar
Las invocaciones del modelo Amazon Bedrock son de pago por uso sin cargos por inactividad. Si utilizó los servicios opcionales, elimine los depósitos de Amazon S3 creados para la evaluación de audio (los objetos internos se limpian automáticamente, pero el depósito en sí persiste). Puede eliminar trabajos de Amazon Transcribe desde la Consola de administración de AWS si es necesario.
Conclusión
Antes de esta herramienta, probar un agente de voz de Nova Sonic significaba una de dos cosas: que un humano le hablara (lento, inconsistente, no escala) o no probarlo (arriesgado, especialmente cuando se iteran indicaciones o se implementa en nuevos escenarios).
Nova Sonic Test Harness le ofrece una tercera opción: pruebas automatizadas, repetibles y escalables que cubren el ciclo de vida completo de la conversación, desde el primer turno hasta la evaluación y la detección de alucinaciones. Maneja las partes difíciles (transmisión bidireccional, tiempos de espera de sesión, evaluación no determinista) para que usted pueda concentrarse en crear mejores experiencias de voz.
Conclusiones clave
No se necesita ningún hardware de audio. Pruebe Nova Sonic tan fácilmente como probar cualquier API. Evaluación impulsada por LLM. Maneja el no determinismo con una evaluación basada en rúbricas en lugar de afirmaciones frágiles. Detección de alucinaciones sonoras. Capta la divergencia de texto y audio. Escala horizontalmente. Ejecute cientos de escenarios en paralelo con un solo comando. Código abierto y extensible. Agregue sus propias herramientas, métricas, rúbricas y escenarios.
Clona el repositorio y ejecuta tu primera prueba hoy. A medida que su aplicación Nova Sonic crece, las pruebas crecen con ella.
Sobre los autores
Osman Ipek
Osman es un arquitecto de IA aplicada en el equipo AGI de Amazon que se centra en los modelos básicos de Nova. Guía a los equipos para acelerar el desarrollo a través de estrategias prácticas de implementación de IA, con experiencia que abarca IA de voz, sistemas agentes, evaluación de modelos y MLOps.
Lana Zhang
Lana es arquitecta senior especializada en soluciones para IA generativa en AWS dentro de la Organización Mundial de Especialistas. Se especializa en IA/ML, con especial atención en casos de uso como asistentes de voz de IA y comprensión multimodal. Trabaja en estrecha colaboración con clientes de diversas industrias, incluidos los medios y el entretenimiento, los juegos, los deportes, la publicidad, los servicios financieros y la atención médica, para ayudarlos a transformar sus soluciones comerciales a través de la IA.