Singapore Airlines sustituye su chatbot con guiones por un LLM y duplica el CSAT

Es un dolor conocido para cualquiera que haya montado un servicio de atención al cliente: el chatbot basado en guiones. Hay que describir cada intención, dibujar de antemano cada rama, y entonces una persona escribe algo como «me cancelaron el vuelo y tengo traslado y hotel, ¿qué hago?». El bot responde con un menú de cinco opciones. Singapore Airlines pasó por ello y reescribió su bot Kris sobre un LLM. La compañía comparte cifras y detalles de arquitectura de los que se pueden extraer algunas lecciones.

Qué cambió en Kris

En el antiguo esquema con dialog-flow, la cobertura de temas dependía de cuántos diálogos se habían descrito a mano. Si no existía la intención necesaria, la conversación casi siempre pasaba a un operador, aunque la pregunta podría haberse resuelto mediante autoservicio. Escalar un sistema así es difícil: cada tema nuevo implica una rama nueva.

Tras migrar a la API de OpenAI, el bot interpreta por sí mismo la intención del cliente en forma libre, responde basándose en una base de conocimiento, mantiene una conversación sobre varios temas a la vez y traspasa el chat a un empleado humano junto con el contexto. Ahora Kris responde preguntas generales, gestiona peticiones especiales, informa de incidencias en vuelos en tiempo real y realiza parte de las transacciones. En los planes figuran la modificación de reservas, las operaciones con equipaje y escenarios agénticos más complejos.

Resultado según la aerolínea: el CSAT se multiplicó por 2. Aparte, se dio a los operadores una herramienta de resumen de llamadas sobre la misma API para que dediquen menos tiempo al trabajo posterior a la conversación. El tiempo medio de gestión de una consulta se redujo aproximadamente un 10 %.

Flight Recommender: el modelo llama a herramientas en lugar de inventar precios

El segundo producto es Flight Recommender. El cliente describe su viaje en lenguaje natural, en lugar de manipular una y otra vez los filtros de fechas y destinos. El uso creció casi el triple en un año.

No está planteado como «el modelo sabe de vuelos por sí mismo». Entre el modelo y el usuario hay una capa de orquestación conectada a los datos de tarifas y disponibilidad de asientos. El modelo interpreta la petición, llama a las herramientas necesarias y cuenta el resultado en lenguaje humano. Los precios y la disponibilidad provienen de los sistemas de la aerolínea, no de la memoria del modelo.

Alrededor de esto se han montado mecanismos de protección: validación de entrada y salida, tratamiento de solicitudes maliciosas e inapropiadas, reducción de alucinaciones, gestión de datos personales y acceso únicamente al contexto necesario para cada petición. El siguiente paso es convertir la búsqueda en un diálogo en el que se pueda afinar una idea sin empezar de cero.

IA en todo el ciclo de desarrollo, no solo en el código

La parte más aplicable del caso para los equipos es la de desarrollo. Los modelos se emplean en las etapas de aclaración de requisitos, análisis de reuniones con stakeholders, redacción de especificaciones, búsqueda de casos límite, generación de casos de prueba, revisión de arquitectura y división de tareas grandes en fragmentos verificables.

Un ejemplo del texto: para una funcionalidad comercial, el equipo pidió primero al modelo que cuestionara los supuestos y encontrara requisitos ambiguos. Solo después la IA ayudó a construir variantes de diseño, planes de implementación, pruebas y código. En las actividades seleccionadas, la mejora de productividad llegó hasta el 20 %. El papel de las personas pasó de producir artefactos a plantear tareas, revisar y validar.

Aparte, existe una plataforma interna llamada Jarvis, con control de acceso. Los empleados trabajan en ella con PDF, Word, Excel y presentaciones, y crean sus propios workflows y pequeñas bases de conocimiento. La usa cada mes más del 60 % de la plantilla.

Qué tener en cuenta al leer

Es un caso publicado en el sitio de OpenAI, es decir, un material con fines comerciales. No se revela la metodología de medición del CSAT, y no está claro con qué se comparó exactamente ni en qué período. Las cifras de tiempo de gestión (en torno al 10 %) y de desarrollo (hasta el 20 %) son mucho más modestas que el «doble» del titular. Conviene tomarlas como una referencia realista, no como una promesa.

Conclusiones prácticas para equipos que construyen soporte o búsqueda:

• Los bots con guiones chocan con la cobertura manual de temas. Un LLM con base de conocimiento elimina esa limitación, pero exige una base de calidad y un traspaso cuidadoso al operador con contexto.
• Los hechos (precios, disponibilidad, estados de vuelos) deben provenir de herramientas, y el modelo debe limitarse a entender la petición y formular la respuesta.
• Incorpore desde el principio guardrails, control de datos personales y revisión humana, no después del primer incidente.
• Tiene sentido adoptar la verificación de requisitos y la generación de edge cases antes que la autogeneración de código: es justo ahí donde el equipo de Singapore Airlines describe el beneficio más evidente.