/ Proyectos / Negocio / Asistente de selección de itinerarios de viaje
Asistente de selección de itinerarios de viaje: espacio factible + recomendación o segmentación
Cómo diseñar un asistente que elige traslado, vuelo y hospedaje para cada viaje de negocios, separando las restricciones que no son negociables de las preferencias que sí varían por persona.
El objetivo era diseñar un asistente que eligiera, para cada viaje de negocios, la combinación de traslado corto, vuelo y hospedaje que mejor se ajustara a las preferencias de cada usuario, sin violar restricciones del propio viaje. El catálogo de vuelos ronda las 400 opciones y el de hospedaje supera las 170,000, así que "elegir a mano" o con reglas simples no escala.
El reto de diseño, más que de modelo, fue decidir cómo estructurar el problema antes de elegir cualquier algoritmo. Mezclar en un solo paso las restricciones que el viaje exige por fuerza (hora de llegada, distancia al lugar de reunión) con las preferencias que varían por persona (precio, comodidad, rapidez) hubiera hecho el sistema difícil de depurar. Este artículo documenta esa decisión de arquitectura, no solo el modelo final.
Mapa del casoContenido
- Diagrama de la solución. Los bloques del pipeline, de la solicitud de viaje al itinerario elegido
- Construcción de la solución. Por qué separar restricciones duras de preferencias fue la decisión central
- Condiciones del proyecto. Restricciones reales y opciones descartadas antes de construir
- Pasos. Qué se dejó al agente y qué criterio se aplicó en cada uno
- Proceso de iteración. Qué tan lejos llega este prototipo y qué falta
- Descargables. Notebook, diagrama y repositorio del proyecto
- Lecciones importantes. La lección concreta que deja este caso
Estructura de alto nivelDiagrama de la solución
Pasa el cursor sobre cada bloque para ver qué hace ese paso.
La capa de selección es intercambiable: puede ser recomendación individual o segmentación por perfil, sin tocar el paso de filtrado. Esa independencia es la parte de diseño más importante del proyecto.
Cómo se construyóConstrucción de la solución
Condiciones del proyecto
| Restricción | Dato |
|---|---|
| Escala del catálogo | ~400 opciones de vuelo y más de 170,000 opciones de hospedaje por ciudad y fecha |
| Historial disponible | Insuficiente todavía para un modelo de recomendación entrenado con collaborative filtering |
| Restricciones del viaje | Hora límite de llegada, distancia máxima al lugar de reunión, tipo de estancia; no son negociables |
| Objetivo del producto | Un itinerario único y explicable por usuario, no una lista de opciones para que la persona decida |
| Opción | Por qué se descartó |
|---|---|
| Un solo modelo que mezcle restricciones duras y preferencias suaves | Difícil de depurar: si el itinerario elegido es malo, no queda claro si falló el filtro o la personalización |
| Collaborative filtering puro desde el inicio | Requiere miles de ejemplos de decisiones pasadas, volumen que el producto todavía no tiene |
| Reglas de negocio fijas para elegir entre opciones factibles | No se adapta a que distintos usuarios prioricen precio, comodidad o rapidez de forma distinta |
| Separar la generación del espacio factible (reglas duras) de una capa de selección intercambiable (recomendación individual o segmentación por perfil) | Permite depurar cada parte por separado y evolucionar la capa de selección sin tocar el filtrado, a medida que crece el historial disponible |
Pasos
Separar restricciones duras de preferencias suaves
Agente: propuso un solo modelo de scoring que incluyera tanto las restricciones del viaje como las preferencias del usuario en la misma función.
Criterio aplicado: dividir el pipeline en dos pasos independientes, generación del espacio factible primero, selección personalizada después, para que cada uno se pudiera depurar y evolucionar por separado.
Elegir la arquitectura de personalización según los datos disponibles, no por preferencia técnica
Agente: sugería collaborative filtering desde el inicio, por ser la técnica más precisa en sistemas de recomendación maduros.
Criterio aplicado: empezar con content-based filtering (score ponderado por preferencias individuales) y segmentación (K-Means), porque el historial disponible todavía no alcanza el volumen que collaborative filtering necesita para funcionar bien.
Definir el número de perfiles con evidencia, no arbitrariamente
Agente: proponía fijar un número redondo de perfiles (por ejemplo, 3 o 5) por simplicidad de negocio.
Criterio aplicado: usar el score de silueta para elegir el número de perfiles que mejor separa a los usuarios según sus preferencias, y solo después revisar si ese número es operativamente manejable.
Diseñar pensando en la siguiente iteración, no solo en el prototipo actual
Agente: entregaba el score heurístico como si fuera la solución final.
Criterio aplicado: documentar explícitamente que ese score ponderado es un punto de partida, y que la capa de selección puede evolucionar a un modelo entrenado de recomendación en cuanto exista suficiente historial de decisiones reales, sin rediseñar el paso de filtrado.
Proceso de iteración
Ajuste documentado, no forzado
Este es un prototipo temprano, no un sistema en producción. El score ponderado que decide entre opciones factibles es una heurística razonable, no un modelo entrenado con datos reales de decisiones de usuarios, porque ese historial todavía no existe en el volumen necesario. La comparación entre recomendación individual y segmentación por perfil, hecha sobre el mismo espacio factible, mostró que ambas coinciden la mayoría de las veces, y difieren justamente en los usuarios cuyas preferencias son atípicas dentro de su grupo, el caso donde más importa la diferencia entre personalizar por individuo o por segmento.
CierreLecciones importantes
La decisión de arquitectura más importante de este proyecto no fue qué algoritmo de recomendación usar, fue decidir qué partes del problema nunca deberían resolverse juntas. Separar restricciones duras de preferencias suaves permite depurar, explicar y evolucionar cada parte del sistema por separado, algo que un solo modelo monolítico no ofrece.
La segunda lección es de honestidad con la madurez del producto. No hacía falta collaborative filtering desde el día uno; empezar con una heurística ponderada y segmentación, documentando claramente que es un punto de partida, es una decisión de ingeniería tan válida como cualquier modelo entrenado, siempre que se diseñe pensando en cómo va a evolucionar.
Si quieres ver un enfoque publicado con una idea similar, combinar recomendación basada en contenido y filtrado colaborativo para sistemas de recomendación de viajes, este paper es una buena referencia del nivel de la contribución: Travel Recommendation System Using Content and Collaborative Filtering: A Hybrid Approach.
Termina ya tu proyecto
¿Tienes un proyecto similar y no sabes por dónde empezar? Yo te ayudo a diseñarlo.
El 92% de los profesionales de datos desbloquea sus proyectos al ver ejemplos completos resueltos.
Sin registro. Acceso inmediato