Por qué se necesita un planificador «comprensivo»
Cada pasajero elige su ruta a su manera. Para uno, lo principal es llegar más rápido; para otro, hacer menos transbordos; un tercero evita conscientemente los autobuses o quiere reducir los tramos a pie. Las aplicaciones de navegación estándar suelen ofrecer solo unas pocas opciones impersonales, ordenadas por tiempo o precio. Las preferencias individuales quedan fuera de juego.
Para cambiar esta situación, se propone el framework ChatPlanner, descrito en el preprint de arXiv:2606.15315. Los autores — Tingting Yang, Chenhao Xue y Jun Chen — han desarrollado un enfoque en el que el usuario explica sus deseos con palabras corrientes y el sistema los traduce en requisitos para la ruta. Esto amplía notablemente los límites de la ruta clásica: el diálogo con el pasajero se convierte en una señal de entrada tan importante como el horario y el mapa del transporte.
La solución se basa en grandes modelos de lenguaje y ya ha sido enviada a la revista Transportation Research Part C. Según el texto del trabajo, no se trata de un chatbot más: el modelo influye directamente en la lógica de optimización de la búsqueda de rutas.
Arquitectura de la solución
En el centro de ChatPlanner hay una interfaz conversacional que procesa solicitudes en lenguaje natural. El usuario puede escribir algo como «quiero ir más rápido, pero sin metro» o «no soporto las largas esperas». La tarea del framework no es solo reconocer las palabras, sino también extraer de ellas parámetros de ruta: prioridades de tiempo, número de transbordos, medios de transporte y otras características.
Para ello se utiliza una combinación de dos mecanismos:
- LLM ajustada finamente — se encarga de la salida estructurada y está entrenada para reconocer patrones típicos de preferencias. «Comprende» cómo se suelen formular los deseos y los reduce a un formato unificado.
- Retrieval-Augmented Generation (RAG) — añade contexto relevante a la solicitud. Esto ayuda a resolver expresiones ambiguas o coloquiales, así como a calibrar con mayor precisión las valoraciones continuas — por ejemplo, el grado de aversión a los transbordos.
El resultado del procesamiento es un conjunto de puntuaciones de preferencias (preference scores) según diferentes criterios. Estas puntuaciones se integran luego en la función objetivo del algoritmo de ruta del transporte público. En otras palabras, la LLM no se limita a parafrasear una ruta ya hecha, sino que participa activamente en su construcción, adaptando la optimización al pasajero concreto.
Entrenamiento: personas y contextos
Para que el modelo tuviera de qué aprender, los autores crearon conjuntos de datos que incluyen ocho personas y cinco contextos. Las personas son tipos generalizados de pasajeros con diferentes prioridades y hábitos: por ejemplo, un estudiante al que le importa el precio, una persona mayor con movilidad reducida o un viajero de negocios que valora cada minuto. Los contextos describen situaciones típicas: viaje al aeropuerto, hora punta, paseo turístico, etc.
Este etiquetado no solo es importante para el entrenamiento. También se utiliza para establecer estándares de referencia de evaluación — «rúbricas» — con las que se comparan las respuestas del sistema. Gracias a ello, se puede juzgar objetivamente con qué precisión el framework extrajo las preferencias y los parámetros de la ruta a partir del diálogo.
Experimentos y resultados
Para confirmar la viabilidad del enfoque, los investigadores realizaron cuatro experimentos. Cada uno verificaba un aspecto distinto:
- Viabilidad de las soluciones — si el sistema ofrece siempre rutas reales y ejecutables.
- Extracción de información — con qué precisión se reconocen los parámetros de ruta y las preferencias.
- Calidad y completitud del conjunto de soluciones — cuántas alternativas adecuadas genera el framework y qué tan buenas son.
- Latencia y viabilidad computacional — si el sistema responde en un tiempo aceptable.
Los resultados mostraron que ChatPlanner genera de forma estable soluciones viables. El ajuste fino proporcionó la estructura de salida requerida y permitió al sistema aprender patrones generales de preferencias. El RAG, por su parte, aportó el contexto de la solicitud concreta: gracias a él se lograron manejar formulaciones imprecisas y coloquiales y calibrar correctamente las puntuaciones. La mayor precisión se alcanza con el uso conjunto de ambos enfoques: la extracción de información no solo es más precisa, sino también coherente con la rúbrica.
En los estudios de caso, el framework encontraba soluciones que respondían a diferentes deseos de los pasajeros y afectaban a los aspectos más variados del viaje. Además, estas rutas eran pasadas por alto por los planificadores existentes. ChatPlanner también ofrecía más alternativas, lo que da al usuario una elección significativa.
Rendimiento
Los autores prestaron especial atención a la aplicabilidad práctica. Las mediciones de latencia confirman que el framework es computacionalmente viable: a pesar de la participación de modelos de lenguaje pesados y de los mecanismos adicionales de RAG, el sistema puede funcionar en tiempo real. Este es un argumento importante a favor de que el enfoque no se quedará en el laboratorio, sino que puede servir de base para servicios reales de planificación de viajes.
Conclusiones
La investigación de ChatPlanner es un paso hacia un nuevo paradigma en el que la comprensión del lenguaje natural y la optimización del transporte ya no existen por separado. En lugar de exigir al pasajero que especifique claramente los parámetros, el sistema los extrae por sí mismo de la conversación. El diálogo se convierte en una parte plena del proceso de optimización, y la búsqueda de rutas, en un servicio personalizado.
Por ahora es un desarrollo científico, pero sus resultados parecen convincentes: la combinación de fine-tuning y RAG permite alcanzar una alta precisión, y el rendimiento sigue siendo aceptable. Es probable que pronto aparezcan interfaces similares en las aplicaciones de transporte urbano, y elegir ruta se vuelva tan natural como hablar con un conserje.
