El AI podría ayudarte a llegar a una persona real más rápido

Una nueva investigación muestra que los sistemas de AI de estilo ChatGPT de código abierto pueden potencialmente enrutar a los llamantes al persona adecuada en un centro de llamadas utilizando lenguaje natural, sin seguir opciones de menú frustrantes que son diferentes cada semana, aparentemente obstaculizando deliberadamente.

Intentar llegar a una persona real en un centro de llamadas puede ser una experiencia frustrante, debido a la necesidad de navegar múltiples opciones de menú a un ritmo lento, a menudo sin certeza sobre cuál de las opciones es adecuada para su caso. Si ninguna de ellas es adecuada, los usuarios experimentados tienden a adoptar trucos y soluciones alternativas para acceder a un asesor humano y salir del “infierno de opciones”. Muchos de nosotros reconoceremos esto como una experiencia más o menos “combativa” y hostil para el usuario.

No es de extrañar que los centros de llamadas estén en la vanguardia para la mejora o reemplazo por sistemas de AI; y, a pesar de que se recomienda un enfoque cauteloso desde algunos cuartos, la automatización de AI en los centros de llamadas sigue siendo una fruta baja para titulares de tecnología y para la perspectiva de innovación basada en AI que puede ofrecer un ROI temprano y poco común.

Tienda cerrada

Pero hay algunas áreas donde los principios de código abierto y datos libremente disponibles rara vez se aplican o están disponibles, y esta es una de ellas. Tiene sentido: cualquier empresa interesada en automatizar sus sistemas de respuesta al cliente tendrá un interés limitado o nulo en compartir los datos que alimentan sus conocimientos, metodologías o propiedad intelectual corporativa.

Por un lado, compartir estos recursos les costaría una ventaja sobre los competidores; más importante aún, dado que los sistemas de AI en el bucle son propensos a divulgar información privilegiada, es legalmente arriesgado.

Esto ha llevado a que varios jugadores bien invertidos desarrollen sistemas de respuesta de centro de llamadas con ayuda de AI de forma independiente (presumiblemente con algo de redundancia de esfuerzo inevitable); y a una proliferación de startups y jugadores establecidos de B2B que buscan atender la creciente demanda de capacidades de respuesta al cliente impulsadas por AI.

Un asistente de voz de PolyAI abre una llamada de servicio al cliente para la empresa ficticia ‘Augusta Lawn Care’, basándose en grandes cantidades de conversaciones de entrenamiento para automatizar respuestas a través de la infraestructura de centro de llamadas existente. Fuente

Además, la carrera para eliminar la frustración de navegar un laberinto de centro de llamadas ha demostrado ser un estímulo para los esfuerzos de investigación – aunque la mayoría de estas publicaciones tienden a ocurrir lejos de Arxiv y otras redes de publicación de investigación abierta, en consonancia con la naturaleza generalmente clandestina del desarrollo de Respuesta de Voz Interactiva (IVR).

En lugar de eso, la investigación, los datos y la inteligencia empresarial relacionados con la automatización de AI de los sistemas de respuesta al cliente están todos celosamente custodiados, con muy pocas opciones de código abierto disponibles – incluso si el uso de sistemas y datos de FOSS ofreciera una opción legalmente sólida, lo cual es dudoso.

Llamada local

Con esto en mente, es refrescante ver un nuevo documento de Colombia que intenta sacar a IVR de su bóveda corporativa, al menos un poco. El nuevo trabajo, una entrada concisa titulada Más allá de los tonos de IVR: enrutamiento de intención del cliente utilizando LLM, proviene de un investigador de la Universidad Distrital Francisco José de Caldas en Bogotá, y afirma ser el primer proyecto no cerrado en utilizar Modelos de Lenguaje Grande (LLM) para generar un esquema de trabajo para un sistema de Enrutamiento de Intención del Cliente (CIR).

En lugar de intentar acceder a datos de llamadas del mundo real o árboles de menú propietarios, el nuevo proyecto genera todos los componentes desde cero utilizando tres modelos de AI: uno para inventar un menú de centro de llamadas realista; otro para simular cientos de quejas de llamantes; y un tercero para actuar como el chatbot, intentando enrutar esas quejas al destino correcto.

El resultado es una prueba de concepto completamente sintética pero convincente, que presenta a una empresa de telecomunicaciones ficticia, junto con 920 consultas de usuario distintas, lo que permite al experimento sortear los riesgos legales mientras se investiga cómo bien puede interpretar el AI el lenguaje vago y desordenado, y aún así conectar al llamante con la persona correcta.

Las pruebas indican que el esquema del sistema puede emparejar quejas de llamantes de forma libre con el destino de centro de llamadas correcto con una precisión de hasta 89,13%, especialmente cuando se le dan opciones de menú “aplazadas” en lugar de descripciones verbosas (más sobre esto después).

El estudio también encontró que cuando los llamantes utilizaban un lenguaje más casual o variado, el AI se equivocaba más; pero que algunos de esos errores ocurrían no porque el AI malentendiera, sino porque el menú de teléfono en sí era confuso.

Ejemplos de interacciones de cliente, compartidos como parte del nuevo proyecto. Fuente

Los datos para el proyecto han sido hechos públicamente disponibles.

Método

El primer modelo en el enfoque tripartito crea un menú de teléfono detallado para una empresa de telecomunicaciones ficticia; el segundo genera mensajes de llamantes únicos – algunos simples, otros reexpresados o más casuales – para simular cómo la gente habla cuando llama para pedir ayuda. En cuanto a esto, se generaron 920 ejemplos para el proyecto.

El tercer modelo se le dio la tarea de conectar a cada llamante con el departamento correcto, basándose solo en el mensaje y una versión del menú. Este esquema permitió que el experimento fuera completamente repetible, mientras sorteaba la necesidad de datos de llamadas reales o exponer información del cliente:

Los tres sistemas elegidos para el enfoque tripartito. Fuente

Los tres modelos utilizados, respectivamente, fueron gpt-3.5-turbo; gpt-4o-mini; y gpt-4.1-mini.

Para simular un entorno de servicio al cliente convincente, fue necesario sintetizar un menú de teléfono complejo desde cero. Debido a la escasez de conjuntos de datos relevantes, el modelo gpt-3.5-turbo se utilizó para generar una estructura de menú completa y de varios niveles para un proveedor de telecomunicaciones ficticio.

Cada rama se configuró para representar áreas de servicio como facturación, soporte técnico de cuenta, gestión de cuenta y servicios nuevos, con opciones realistas y subopciones y una profundidad variable en todo el árbol. A partir de este menú artificial, se crearon dos versiones para pruebas posteriores: una como una jerarquía de texto plano, para imitar cómo un ser humano podría leer todo el menú; y otra como una lista de puntos finales, cada uno con su propia secuencia de pulsaciones de botones.

Esto permitió que el sistema se probara tanto en una versión detallada como en una versión “despojada” del desafío de enrutamiento:

Se proporcionaron dos versiones del menú de teléfono al AI: una jerarquía de texto detallada y una lista simplificada de opciones de menú directas, para comparar cómo bien cada formato apoyaba la ruta de los llamantes al lugar correcto.

Para crear los mensajes de llamantes necesarios para las pruebas, se utilizó un segundo modelo de lenguaje para producir un conjunto de quejas o solicitudes originales, con diez ejemplos únicos realizados para cada punto final del menú.

Cada uno de estos se expandió luego en varias versiones reexpresadas, para imitar la gama de formas en que los llamantes reales podrían expresar sus problemas, y se introdujeron cambios en la longitud, el tono y incluso errores menores o ‘palabras de relleno’.

Los 920 mensajes de llamantes generados al principio se diseñaron tanto para probar la precisión del sistema como para simular la imprevisibilidad del lenguaje del mundo real.

La tercera etapa probó cuán precisamente el modelo final podría asignar cada mensaje de llamante al destino de menú correcto, basándose en las dos formas diferentes de presentar el sistema de IVR (ver imagen anterior).

En la primera versión, el AI se le dio una descripción completa y detallada del árbol de teléfono, con cada rama y subopción expuesta en forma de texto. En la segunda, solo vio una lista de destinos finales, cada uno vinculado a una secuencia de pulsaciones de botones.

El objetivo era ver si una versión simplificada del menú haría que fuera más fácil para el modelo decidir a dónde debía ir cada llamada. En ambos casos, el sistema recibió un mensaje a la vez y se le pidió que devolviera solo la ruta, sin palabras adicionales o explicaciones, para facilitar la puntuación automática.

Aislamiento

Para evitar contaminar los resultados de las pruebas, el experimento mantuvo cada modelo aislado de los demás: el menú de teléfono se redactó con el primer modelo, pero luego se finalizó manualmente, para que permaneciera desconocido para los otros sistemas.

Los mensajes de llamantes se generaron por separado por gpt-4o-mini, utilizando solo los nombres de los puntos finales, y sin acceso a la estructura del menú. Finalmente, gpt-4.1-mini, que manejó el enrutamiento, solo vio el texto del menú y los mensajes entrantes, y no participó en la creación de ninguno de los dos.

Métricas

Para medir cómo bien se desempeñó el sistema de enrutamiento, se utilizaron dos métricas estándar: precisión se definió como el porcentaje de casos en los que el modelo devolvió la ruta exactamente correcta (como 1‑2‑3). Para aislar la ubicación de los errores, también se generaron matrices de confusión*, que muestran con qué frecuencia cada ruta se confundió con otras. Las evaluaciones se ejecutaron en Python utilizando las bibliotecas pandas y scikit-learn.

Resultados

En las pruebas, la precisión del modelo dependió en gran medida de cómo se presentó el menú de teléfono: cuando se le dio la lista plana de rutas de menú, el sistema alcanzó una precisión del 89,13% en el conjunto de datos más simple, en comparación con el 81,30% cuando se utilizó la versión descriptiva completa del menú:

Precisión de enrutamiento para el tercer modelo (LLM3), en diferentes formatos de prompt y tipos de conjunto de datos, lo que indica que las rutas de menú planas superaron consistentemente a las descripciones jerárquicas, y que la precisión disminuyó ligeramente cuando las entradas se ampliaron con lenguaje parafraseado o informal.

Este patrón se mantuvo para el conjunto de datos más grande y variado, donde la versión plana volvió a tener un mejor desempeño, con una puntuación del 86,52% en comparación con el 77,07% para el formato descriptivo.

Estos resultados, según el documento, sugieren que los prompts más simples y basados en listas ayudaron al modelo a emparejar las consultas de forma más confiable que las descripciones jerárquicas largas.

La precisión también disminuyó ligeramente cuando se introdujeron versiones parafraseadas e informales de los mensajes de llamantes, lo que indica que una mayor variedad mejoró la sensación de realidad, pero también hizo que la clasificación fuera más difícil.

El documento concluye:

‘Nuestros resultados muestran que los LLM enrutan intenciones con mayor precisión cuando se les dan rutas de IVR planas (hasta 89,13) que descripciones de menú verbosas (tan bajas como 77,07%), lo que sugiere que los prompts concisos y estructurados reducen el ruido y se alinean mejor con la tarea de enrutamiento.

‘Esto apoya el principio de que la claridad y la brevedad mejoran el rendimiento de los LLM en entornos de clasificación.

‘Es importante destacar que transformar los menús en rutas planas es un proceso simple y automatizable para uso en el mundo real.’

Conclusión

Es refrescante ver al menos algún trabajo abierto que ocurre en una de las corrientes de investigación más aisladas y excluyentes de la literatura. Lo que queda por ver es si se necesitarán arquitecturas de “enmarcado” que contextualicen los LLM en el futuro, o si el modelo solo necesitará acceder a la inteligencia empresarial (disponible localmente), lo que haría innecesario que la empresa comparta datos con proveedores de terceros.

En última instancia, los principios de diseño más amplios que están en juego aquí parecen probablemente ser adoptados de forma natural por futuros sistemas de AI, incluso en dominios más allá del servicio al cliente, sin requerir un alineamiento deliberado con ese caso de uso.

* Por favor, consulte el documento de origen para estos.

Publicado por primera vez el miércoles 29 de octubre de 2025