ProCat Solutions
Abigel.ai ya funciona, y medio segundo se convirtió en nuestra cifra clave
Cerramos el proyecto DIMOP Plusz: en abigel.ai ya están el asistente telefónico y el profesor de idiomas de IA. Lecciones sobre latencia, streaming y telefonía.
· Nuestro producto 
Ayer, 14 de septiembre de 2026, cerramos nuestro proyecto DIMOP_PLUSZ-1.1.2/A-24-2025-00236, y su resultado ya está en producción en https://abigel.ai. Durante más de un año construimos un sistema que procesa una llamada telefónica en tiempo real. Esta entrada cuenta qué hemos construido y qué aprendimos por el camino.
Cofinanciado por la Unión Europea.
Dos productos, una base
Abigel.ai reúne dos productos sobre una infraestructura común.
Asistente virtual. Un asistente telefónico de IA que atiende las llamadas en el número de la empresa las 24 horas del día. Conversa con quien llama, reserva citas, toma mensajes, responde a preguntas sencillas y genera una transcripción y un resumen de cada llamada. El cliente diseña el desarrollo de la llamada en un editor de flujos no-code, sin programar. El asistente habla más de 25 idiomas y detecta el de quien llama.
Profesor. Un profesor de idiomas de IA conversacional que da clases de conversación en 26 idiomas, de A1 a B2. El alumno habla y el sistema responde, corrige y da su valoración en tiempo real. La cadena de procesamiento de voz creada para el asistente telefónico cumple aquí otra función, pero la tecnología es la misma.
Ambos son SaaS multi-tenant: precio basado en el uso, datos separados por tenant, operación dentro de la UE conforme al RGPD, registro de llamadas y exportación CSV. El proyecto se ejecutó con el contenido comprometido en la solicitud de subvención.
Medio segundo
La lección técnica más importante del proyecto cabe en una frase: en una conversación telefónica se oye todo lo que dura más de unos cientos de milisegundos. Una persona espera la respuesta de su interlocutor en aproximadamente medio segundo. Si se va a segundo y medio, quien llama interrumpe, duda o cuelga.
Reconocimiento de voz, modelo de lenguaje y síntesis de voz, ejecutados uno tras otro, suman fácilmente varios segundos. Esto es lo que hicimos:
- Streaming en cada paso. El reconocimiento de voz entrega resultados parciales antes de que acabe la frase. La respuesta del modelo de lenguaje llega token a token. La síntesis de voz ya pronuncia la primera frase mientras se genera el resto. La cadena funciona como una tubería, con las etapas solapadas.
- Detección del final del habla. Saber si quien llama ha terminado de hablar resultó más difícil de lo previsto. Un umbral de silencio demasiado corto corta a la persona; uno demasiado largo ralentiza. Lo ajustamos según el contenido del habla, además de la duración del silencio.
- Interrupciones. Si quien llama empieza a hablar mientras el asistente habla, la reproducción se corta en el acto y solo cuenta como contexto lo que llegó a pronunciarse. Sin esto, la conversación resulta antinatural.
- Proximidad geográfica. Usamos los proveedores de modelos de voz y de lenguaje en endpoints dentro de la UE, y nuestros componentes corren en el mismo centro de datos. Cada salto de red son diez o veinte milisegundos, y se acumulan.
Medimos la latencia por llamada y por paso, y la seguimos en percentiles. Sobre esa métrica tomamos la mayoría de las decisiones de arquitectura.
Los viejos problemas de la telefonía
Todo lo que habíamos escrito antes sobre SIP y la red PSTN volvió a aparecer, con algunas novedades:
- el audio de la red telefónica, a 8 kHz y codificado en G.711, contiene bastante menos información que los datos con los que se entrenaron los modelos de reconocimiento de voz. Por teléfono la precisión es peor, y hay que compensarlo con preguntas de confirmación en el editor de flujos,
- el audio pasa entre el lado SIP y la cadena de procesamiento en tramas pequeñas y sin búfer; cada búfer es latencia,
- los SIP trunks de los operadores se comportan de forma distinta en la transferencia de llamadas y en la gestión de DTMF, así que la capa bridge es configurable por operador,
- la red puede fluctuar durante la llamada, y el jitter y la pérdida de paquetes empeoran el reconocimiento, por eso escribimos también los datos RTCP en el registro de llamadas.
Las pruebas no podían depender de llamadas manuales. Lanzamos llamadas automatizadas que recorren los flujos con voz pregrabada o sintetizada y comparan la transcripción con la esperada. Es lento, pero sin ello habría que haber telefoneado a mano tras cada cambio.
Prohibido improvisar
El gran modelo de lenguaje es el motor de la conversación, pero una llamada telefónica es un entorno peculiar. Hacen falta respuestas cortas y orales, no párrafos. El modelo debe seguir los pasos fijados en el editor de flujos y, si el reconocimiento ha fallado, preguntar en vez de adivinar. Recibe la descripción del flujo como instrucción estructurada; el texto libre solo interviene en la formulación.
La reserva de citas y operaciones similares van al backend como llamadas a herramientas (tool call), y el backend devuelve el resultado al modelo. También aquí la clave es el procesamiento idempotente: una llamada reintentada no puede reservar dos citas.
Operación y ajuste fino
El proyecto ha terminado, el producto está en marcha y los próximos meses serán de operación y ajuste fino. Seguiremos contando lo aprendido en el blog. El siguiente tema: pruebas de carga de sistemas de voz y alertas basadas en la calidad de las llamadas.
Agradecemos el apoyo del Gobierno de Hungría y de la Unión Europea, y damos las gracias a todos los que probaron, opinaron y tuvieron paciencia con las primeras llamadas, todavía entrecortadas.
