AssemblyAI detalla las pruebas de carga de agentes de voz antes del lanzamiento

AssemblyAI ha publicado una guía técnica sobre cómo probar la carga de un agente de voz antes del lanzamiento, argumentando que el rendimiento de la demostración en una sola llamada en una sala silenciosa no refleja las condiciones de producción. En la publicación, publicada el 2026-10-20, la empresa afirma que los equipos deberían reproducir sus llamadas reales más difíciles a través de toda la cadena en el pico de concurrencia proyectado y medir la precisión de la entidad, la latencia P95 , las conexiones rechazadas y el coste por tarea completada.

Lo que dice la guía para probar

El artículo dice que las pruebas de carga deben cubrir toda la pila de voz — voz a texto, el LLM, texto a voz, llamadas de herramientas y telefonía — y deberían separar la concurrencia, el rendimiento y la duración de la sesión, porque cada uno falla de forma diferente. AssemblyAI afirma que una campaña de llamadas que abre cientos de llamadas en una ventana corta puede alcanzar un límite diferente a una carga de concurrencia de larga duración, y que la mayoría de los equipos solo prueban el primer caso. La guía también recomienda cuatro perfiles: estado estacionario, rampa lineal, pico y absorción.

Los ejemplos de AssemblyAI se centran en entradas similares a la producción en lugar de audio limpio. La publicación dice que los equipos deberían construir un corpus a partir de sus peores llamadas, incluyendo compresión telefónica a 8 kHz, contenido con mucha carga de entidades como números de cuenta y códigos de confirmación, acentos reales, ruido de fondo, interrupciones y falsos comienzos. También advierte que las etiquetas de transcripción humana pueden contener omisiones o limpieza que distorsionan métricas de error de palabra, y sostiene que la precisión de las entidades debe ponderarse por encima de la precisión de las palabras al puntuar flujos de trabajo de voz.

Capacidad, facturación y modos de fallo

El artículo dice que la prueba debería demostrar que las sesiones cierran limpiamente y que la aceleración se mantiene dentro de los límites del proveedor. En las APIs de streaming y Voice Agent de AssemblyAI, las sesiones se facturan en función del tiempo conectado, y la guía dice que la capacidad está gobernada por cada cuenta. En streaming, la publicación dice que el límite es para nuevas sesiones por minuto y puede escalar automáticamente en cuentas de pago; para la API de Voice Agent, dice que el límite es para sesiones concurrentes.

AssemblyAI también dice que las pruebas de carga deben tener en cuenta el comportamiento de facturación. La publicación dice que el tiempo inactivo es facturable, que una sesión de streaming que no está explícitamente cerrada puede cerrarse automáticamente tras tres horas y facturarse por todo el periodo, y cerrar un socket de Voice Agent sin enviar session.end deja una ventana de reanudación de 30 segundos que también es facturable. La empresa dice que el coste por tarea completada es una métrica mejor que el coste por hora, porque un agente más barato pero menos eficaz puede seguir siendo más caro en la práctica.

Métricas de referencia y cifras de referencia

La guía recomienda informar de percentiles en lugar de promedios y da umbrales objetivo para varias métricas, incluyendo P95 por debajo de 500 ms para el retraso de finalización, P95 por debajo de 1.5 segundos para la latencia de turno de extremo a extremo, P95 por debajo de 500 ms para viajes de ida y vuelta por llamada de herramienta, cero rechazos en el pico planificado y por debajo de 0.5% sesiones eliminadas. También dice que los equipos deben separar las mediciones de fase de rampa y de fase de sostenimiento, porque la latencia puede empeorar durante la rampa.

Para ilustrar comparaciones de precisión, AssemblyAI cita su benchmark de agentes de voz en inglés de 12,460 escenarios guionizados. En ese benchmark, la empresa afirma que Universal-3.6 Pro Realtime registró 5.19% tasa de error de palabra y de 14.4% de entidad, en comparación con Deepgram Flux EN en 13.50% y 30.1%, ElevenLabs Scribe v2 en 7.78% y 18.5%, y Deepgram Nova-3 en 8.64% y 26.1%. La publicación también cita un subconjunto de números de teléfono en 2.4% frente a 11.5% para Deepgram Flux EN. Además, hace referencia al benchmark independiente de STT abierto de Pipecat, que según él encontró una tasa de error semántico de palabras agrupada 0.80% y un retraso mediano 307 ms en la transcripción final, mientras señala la opinión de Pipecat de que pequeñas brechas entre los servicios principales pueden no ser significativas.

Guiado del arnés y manejo de límite

AssemblyAI incluye código de muestra tanto para su API de streaming como para la API de Voice Agent, con énfasis en el ritmo del audio en tiempo real, esperar la confirmación de la sesión antes de enviar el audio y contar la concurrencia máxima solo después de que el servidor confirme que una sesión está activa. La publicación dice que las sesiones pueden ser rechazadas en el momento de conexión y que las sesiones rechazadas deben contarse en lugar de repetirse en una prueba de carga. También advierte que los fragmentos de audio deben mantenerse dentro del tamaño permitido por la API y que el flujo debe terminarse explícitamente para que la prueba no filtre sesiones facturables.

En cuanto a la planificación, la empresa dice que los equipos deberían fijar el modelo de voz en lugar de depender de los modelos de respaldo por defecto más recientes, comparar los modelos de respaldo en el mismo corpus y establecer umbrales de retroceso antes del lanzamiento. El artículo concluye con un plan de despliegue de una semana y una lista de verificación para la preparación para producción que cubre carga y concurrencia, monitorización, benchmarking en los propios datos del equipo y preguntas contractuales como límites de tarifa, unidades de facturación, regiones de procesamiento de datos y objetivos de respuesta de soporte.