ProCat Solutions
Abigel.ai ya está disponible: asistente telefónico de IA y profesor de idiomas de IA
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.
Ayer, 14 de septiembre de 2026, cerramos nuestro proyecto con identificador DIMOP_PLUSZ-1.1.2/A-24-2025-00236, y el resultado del desarrollo está disponible en producción en https://abigel.ai. Esta entrada trata de dos cosas: qué hemos construido y qué aprendimos en el más de un año que pasamos construyendo un sistema que procesa una llamada telefónica en tiempo real.
Cofinanciado por la Unión Europea.
Qué es Abigel.ai
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 teléfono 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 compone 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 imparte clases de conversación en 26 idiomas, de A1 a B2. El alumno habla y el sistema responde, corrige y da retroalimentación en tiempo real. La cadena de procesamiento de voz construida para el asistente telefónico sirve aquí a otro fin, pero es la misma tecnología.
Ambos productos son SaaS multi-tenant: precio basado en el uso, datos separados por tenant, operación dentro de la UE y conforme al RGPD, registro de llamadas y exportación CSV. El proyecto se ejecutó con el contenido comprometido en la solicitud de subvención.
La latencia es la única métrica que de verdad importa
La lección técnica más importante del proyecto cabe en una frase: en una conversación telefónica, todo lo que dura más de unos cientos de milisegundos se oye. Una persona espera la respuesta de su interlocutor en aproximadamente medio segundo; si eso sube a segundo y medio, quien llama interrumpe, duda o cuelga.
El reconocimiento de voz, el modelo de lenguaje y la síntesis de voz, ejecutados uno tras otro, suman fácilmente varios segundos. Lo que hicimos contra eso:
- Streaming en cada paso. El reconocimiento de voz entrega resultados parciales antes de que termine 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 no funciona por pasos, sino como una tubería.
- Detección del final del habla. Decidir si quien llama ha terminado de hablar resultó más difícil de lo que pensábamos. Un umbral de silencio demasiado corto interrumpe a la persona; uno demasiado largo ralentiza. Ajustamos el umbral también según el contenido del habla, no solo según la duración del silencio.
- Gestión de las interrupciones. Si quien llama empieza a hablar mientras el asistente está diciendo algo, cortamos la reproducción de inmediato y consideramos como contexto la parte pronunciada hasta ese momento. 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 propios componentes corren en el mismo centro de datos. Cada salto de red son diez o veinte milisegundos, y se van sumando.
Medimos la latencia por llamada y por paso, y la seguimos como percentiles. Esta fue la métrica sobre la que tomamos la mayoría de las decisiones de arquitectura.
Telefonía: los viejos problemas no han desaparecido
Todas las experiencias sobre el mundo de SIP y PSTN de las que escribimos anteriormente volvieron a aparecer, con algunas nuevas añadidas:
- el audio de la red telefónica, a 8 kHz y codificado en G.711, contiene bastante menos información que aquello con lo que se entrenaron los modelos de reconocimiento de voz; la precisión del reconocimiento es peor con audio telefónico, y hay que compensarlo con preguntas de confirmación en el editor de flujos,
- la transmisión del audio entre el lado SIP y la cadena de procesamiento se hace sin búfer, en tramas pequeñas; 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, por lo que la capa bridge es configurable por operador,
- durante la llamada la red puede fluctuar; el jitter y la pérdida de paquetes degradan la calidad del reconocimiento, así que escribimos también los datos RTCP en el registro de llamadas.
Las pruebas no podían basarse en 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 esto habríamos tenido que telefonear a mano después de cada modificación.
El modelo de lenguaje en una llamada telefónica
El gran modelo de lenguaje es el motor de la conversación, pero la llamada telefónica es un entorno peculiar. Esperamos respuestas cortas y orales, no párrafos; debe seguir los pasos indicados en el editor de flujos, no improvisar; y si el reconocimiento ha fallado, debe preguntar, no adivinar. El modelo recibe la descripción del flujo como una instrucción estructurada; el texto libre está solo en la formulación.
La reserva de citas y operaciones similares van al backend como llamadas a herramientas (tool call), y este devuelve el resultado al modelo. También aquí la clave es el procesamiento idempotente: una llamada reintentada no puede reservar dos citas.
Y ahora qué
El proyecto ha terminado, el producto está vivo, y los próximos meses irán de operación y ajuste fino. Seguiremos compartiendo experiencias en el blog; las pruebas de carga de sistemas de voz y las alertas basadas en la calidad de las llamadas serán el siguiente tema.
Agradecemos el apoyo del Gobierno de Hungría y de la Unión Europea, y damos las gracias a todos los que durante el proyecto probaron, dieron su opinión y tuvieron paciencia con las primeras llamadas, todavía entrecortadas.
