TRABAJO 3: SISTEMAS DE PREDICCIÓN, CLASIFICACIÓN Y RECOMENDACIÓN

REDES NEURONALES Y ALGORITMOS BIOINSPIRADOS




Presentado por:

Marcos David Carrillo Builes
Tomás Escobar Rivera
Jose Fernando López Ramírez
Esteban Vásquez Pérez



Profesor: Juan David Ospina Arango

Monitor: Andrés Mauricio Zapata Rincón


University Logo

Universidad Nacional de Colombia
Facultad de Minas
Ingeniería de Sistemas e Informática

07 de July de 2025

Tabla de Contenidos

Resumen Ejecutivo

El sector del transporte turístico enfrenta desafíos complejos que requieren soluciones tecnológicas avanzadas para optimizar operaciones, garantizar seguridad y personalizar experiencias. Este proyecto desarrolló un sistema integrado de inteligencia artificial que aborda tres problemas críticos: la predicción de demanda de transporte, la detección de conducción distractiva y la recomendación personalizada de destinos turísticos.

Problema y Objetivos: Se identificaron tres necesidades fundamentales en empresas de transporte turístico: (1) anticipar la demanda de pasajeros para optimizar recursos y planificación operativa, (2) detectar comportamientos distractivos en conductores para mejorar la seguridad vial, y (3) ofrecer recomendaciones personalizadas de destinos para mejorar la experiencia del usuario. El objetivo principal fue desarrollar modelos de aprendizaje profundo funcionales e integrarlos en una herramienta web unificada.

Solución y Tecnologías: Se implementaron tres módulos independientes utilizando diferentes arquitecturas de redes neuronales: (1) un modelo LSTM con mecanismo de atención para predicción de series temporales de demanda, (2) una red neuronal convolucional (CNN) diseñada desde cero para clasificación de imágenes de conductores, y (3) un sistema de filtrado colaborativo con embeddings para recomendación de destinos. Las tecnologías empleadas incluyeron Python, TensorFlow/Keras, Gradio para la interfaz web, y recursos de GPU gratuitos de Kaggle para entrenamiento.

Resultados Principales: El modelo de predicción de demanda alcanzó un error absoluto medio de aproximadamente 113 pasajeros (1% del valor medio), demostrando excelente capacidad predictiva. El clasificador de conducción obtuvo un accuracy de 64.7% con F1-scores superiores a 0.77 en las clases críticas como texting_phone y talking_phone. El sistema de recomendación logró un MAE de 1.226 estrellas en la predicción de calificaciones, siendo efectivo para personalización básica. Los tres módulos fueron exitosamente integrados en una aplicación web funcional desplegada en Hugging Face Spaces.

Conclusión: Este trabajo demuestra la viabilidad y efectividad de aplicar técnicas de aprendizaje profundo en el sector del transporte turístico. Los modelos desarrollados ofrecen un punto de partida robusto para sistemas de transporte inteligente, con potencial de implementación real tras ajustes con datos operativos específicos. La integración exitosa de múltiples modelos en una herramienta web accesible evidencia el valor práctico de soluciones de IA aplicadas a problemas empresariales reales.

1 Introducción

1.1 Contexto y Motivación

El sector del transporte y el turismo enfrenta retos complejos que requieren soluciones avanzadas. Por un lado, las empresas de transporte deben anticipar la demanda de viajes y garantizar la seguridad vial, mientras que, por otro, en la industria turística es crucial ofrecer experiencias personalizadas a los usuarios mediante sistemas de recomendación inteligentes. En ambos ámbitos, las redes neuronales profundas se han posicionado como herramientas poderosas para abordar estos problemas complejos, gracias a su capacidad de aprender patrones intrincados a partir de grandes volúmenes de datos heterogéneos (por ejemplo, imágenes, series de tiempo y preferencias de usuarios) [Xiao et al., 2025].

Un problema crítico en transporte es la conducción distraída, la cual se reconoce como una de las principales causas de accidentes de tráfico a nivel mundial [Sorum & Sorum, 2025]. Solo en 2022, se reportaron más de 3.300 muertes en Estados Unidos asociadas a choques con conductores distraídos [National Conference of State Legislatures, 2025], evidenciando la urgencia de mejorar la seguridad vial. Tecnologías de visión por computador basadas en deep learning pueden ayudar a monitorear en tiempo real el comportamiento del conductor para detectar distracciones y prevenir accidentes. Simultáneamente, en el ámbito del turismo, los viajeros se enfrentan a una sobreabundancia de opciones. Un sistema de recomendación de destinos turísticos personalizado puede mejorar enormemente la experiencia al sugerir destinos acordes a las preferencias individuales de cada usuario. Las técnicas de deep learning han demostrado mejorar la precisión de estas recomendaciones al procesar información compleja de usuarios y destinos, superando las limitaciones de métodos tradicionales [Xiao et al., 2025].

Además, la planificación operativa del transporte (por ejemplo, predecir cuántos pasajeros usarán cierta ruta en el futuro cercano) es otro desafío que puede abordarse con modelos de aprendizaje profundo. Prever la demanda de transporte con antelación permite optimizar recursos y rutas, contribuyendo a un servicio más eficiente.

La motivación central de nuestro trabajo es integrar soluciones basadas en redes neuronales profundas para mejorar tres aspectos clave en una empresa de transporte turístico: la predicción de demanda, la detección de conducción distraída y la personalización de recomendaciones de viaje. La disponibilidad de potentes recursos de cómputo en la nube –como las GPU ofrecidas en entornos Kaggle– ha democratizado el desarrollo de estos modelos, permitiéndonos entrenar redes profundas desde cero sin necesidad de infraestructura local costosa.

1.2 Planteamiento del Problema

El presente proyecto se enfoca en resolver los siguientes problemas interrelacionados mediante el uso de técnicas de deep learning:

  • ¿Cómo predecir la demanda de transporte en rutas específicas en los próximos 30 días para garantizar una planificación óptima de vehículos y personal?
  • ¿Cómo clasificar imágenes de conductores para identificar comportamientos distractores que pongan en riesgo la seguridad de los pasajeros?
  • ¿Cómo sugerir destinos turísticos personalizados a los clientes, basándose en su historial de viajes y preferencias?

Estos desafíos, de naturaleza compleja y multidimensional, requieren modelos de aprendizaje capaces de capturar relaciones no lineales en datos temporales, visuales y contextuales, tarea en la que las redes neuronales profundas han demostrado un desempeño sobresaliente.

1.3 Objetivos

A partir del diagnóstico anterior, se definen los siguientes objetivos específicos:

  • Predicción de Demanda: Construir un modelo predictivo para anticipar la cantidad de pasajeros por ruta, empleando datos históricos y técnicas de modelado de series temporales.
  • Clasificación de Conductores: Implementar una red neuronal convolucional (CNN) diseñada manualmente para detectar automáticamente conductas distractoras en imágenes de conductores.
  • Recomendación de Destinos: Desarrollar un sistema de recomendación personalizado que sugiere destinos de viaje usando el historial de viajes y preferencias de cada usuario.

Adicionalmente, se propone integrar los tres módulos anteriores en una herramienta web funcional y amigable, que permita visualizar predicciones, cargar imágenes y recibir recomendaciones en tiempo real.

1.4 Alcances y Limitaciones

Este proyecto contempla la implementación de modelos funcionales para cada uno de los tres módulos mencionados, entrenados con datos públicos recopilados en contextos reales de India (turismo) y Bangladesh (conducción). Sin embargo, existen las siguientes limitaciones:

  • Generalización limitada: Los modelos fueron entrenados con datasets específicos (por ejemplo, imágenes capturadas en Dhaka), lo cual restringe su capacidad de generalizar a otras regiones o condiciones.
  • Recursos computacionales: Si bien se usaron GPUs gratuitas de Kaggle, la exploración completa del espacio de hiperparámetros fue acotada por tiempo y capacidad.
  • Interpretabilidad: Aunque se optó por diseñar una CNN desde cero para mayor comprensión, las decisiones del modelo no siempre son fácilmente explicables a usuarios finales.
  • Cobertura geográfica y de usuarios: El sistema de recomendación está limitado a los destinos del dataset de India, y la predicción de demanda se basa en datos históricos simulados o restringidos.

A pesar de lo anterior, los modelos desarrollados representan un punto de partida robusto y funcional para construir sistemas de transporte inteligente aplicables en la práctica.

2 Metodología

2.1 Enfoque General

Para abordar los retos definidos, adoptamos un enfoque estructurado basado en los principios del Design Thinking, una metodología centrada en comprender profundamente el problema, idear soluciones efectivas y evaluar su impacto desde la perspectiva de los usuarios. Aunque originalmente se asocia al diseño de productos, su estructura nos permitió organizar de forma eficiente el trabajo colaborativo en este proyecto:

  • Empatizar: Analizamos los desafíos de la empresa de transporte, reconociendo la importancia de anticipar la demanda, detectar comportamientos riesgosos al volante y personalizar la experiencia turística.
  • Definir: Delimitamos tres problemas clave: predicción de demanda, clasificación de conducción distractiva y recomendación de destinos.
  • Idear: Diseñamos una solución compuesta por tres modelos independientes que se integrarían en una sola herramienta web.
  • Prototipar: Implementamos y entrenamos modelos funcionales con datos reales, aprovechando recursos computacionales gratuitos como las GPUs de Kaggle.
  • Evaluar: Analizamos métricas de desempeño para cada módulo y reflexionamos sobre su aplicabilidad práctica en entornos reales.

Este enfoque nos permitió mantener una visión clara del proyecto, fomentar la colaboración continua entre integrantes y construir soluciones con impacto potencial para la industria del transporte y el turismo.

2.2 Fases del Proyecto

El desarrollo del sistema inteligente se estructuró en varias fases iterativas, que nos permitieron avanzar progresivamente desde la planificación hasta la implementación técnica:

  1. Inicialización del entorno y recursos:
    • Creamos dos repositorios en GitHub: uno para el desarrollo de la app web y otro para los notebooks en Kaggle.
    • Configuramos el pipeline de despliegue continuo para la app en Hugging Face Spaces con Gradio.
    • Establecimos una plantilla base en RPubs para redactar el informe técnico de manera colaborativa.
    • Definimos el stack de herramientas: Python, Gradio, TensorFlow/Keras, Kaggle Notebooks y almacenamiento externo en Google Drive para modelos de gran tamaño.
  2. Construcción del modelo de clasificación de imágenes:
    • Iniciamos el desarrollo del módulo de visión artificial por ser el más factible en términos de datos disponibles y claridad del objetivo.
    • En lugar de emplear arquitecturas preexistentes como AlexNet, optamos por construir manualmente una CNN bottom-up, lo cual nos permitió comprender mejor el impacto de cada capa y adaptar el modelo a nuestros recursos computacionales.
  3. Paralelización de módulos restantes:
    • Una vez consolidado el modelo de clasificación, distribuimos el trabajo para abordar los otros módulos:
      • José y Marcos comenzaron a explorar el dataset de turismo para construir un sistema de recomendación basado en filtrado colaborativo con embeddings.
      • Tomás se encargó de explorar los datos para modelar la demanda de transporte mediante series temporales.
      • Esteban lideró la organización de los repositorios, el despliegue técnico y la redacción del informe, garantizando una documentación clara y continua.
  4. Colaboración y revisión continua:
    • Establecimos reuniones semanales cada domingo, en las que discutíamos avances, compartíamos aprendizajes y coordinábamos las siguientes tareas.
    • Utilizamos funciones colaborativas de GitHub como issues, branches y pull requests para mantener un control claro del desarrollo.

2.3 Herramientas y Tecnologías

Durante el proyecto, empleamos un conjunto variado de herramientas que nos permitió construir, probar y desplegar nuestras soluciones de manera eficiente:

Las herramientas utilizadas en el proyecto fueron:

  • Kaggle: Entrenamiento de modelos en notebooks con GPU gratuita.
  • RPubs: Redacción y publicación del informe técnico.
  • Hugging Face Spaces: Hosting de la app web con despliegue automatizado.
  • Gradio: Creación de la interfaz gráfica para uso de modelos desde el navegador.
  • GitHub: Control de versiones, desarrollo colaborativo y documentación.
  • Google Drive: Almacenamiento de modelos pesados de forma externa.

El uso articulado de estas tecnologías nos permitió mantener un flujo de trabajo ordenado, reproducible y alineado con las necesidades técnicas y comunicativas del proyecto.

3. Módulo 1 - Predicción de Demanda de Transporte

3.1 Descripción del Dataset

En este proyecto generamos un dataset sintético que simula la demanda de transporte turístico en India, específicamente en rutas que parten desde Delhi Hub hacia cinco destinos turísticos populares: Taj Mahal, Goa Beaches, Jaipur City, Kerala Backwaters y Leh Ladakh.

El objetivo principal de este dataset es modelar y predecir la demanda diaria de pasajeros en función de múltiples factores temporales, operativos y externos.

Variables Incluidas

Tabla 1: Descripción de las variables del dataset de demanda de transporte
Variable Descripcion Tipo
ride_id Identificador único del viaje Numérica
travel_date Fecha del viaje Fecha
travel_time Hora de salida del viaje Hora
departure_city Ciudad de origen (siempre ‘Delhi Hub’) Categórica
destination Ciudad de destino (5 opciones) Categórica
vehicle_type Tipo de vehículo (luxury_bus, standard_bus, minibus, van) Categórica
max_capacity Capacidad máxima del vehículo Numérica
actual_passengers Número real de pasajeros en ese viaje Numérica
load_factor Factor de ocupación (pasajeros / capacidad) Numérica
payment_method Método de pago (cash, mobile_payment, credit_card, travel_card) Categórica
weather_condition Condiciones meteorológicas (sunny, rainy, cloudy, foggy, stormy) Categórica
ticket_price Precio del boleto según el destino Numérica
duration_hours Duración estimada del viaje en horas Numérica
special_event Indicador de evento especial (1 si hay evento, 0 si no) Binaria
month Mes del año (1 a 12) Numérica
day_of_week Día de la semana (0 = lunes, …, 6 = domingo) Numérica
is_weekend Indicador de fin de semana (TRUE/FALSE) Binaria
canceled Indicador de cancelación del viaje (1 si fue cancelado, 0 si no) Binaria

Patrones Realistas Incluidos en el Dataset

  • Estacionalidad: Cada destino presenta temporadas altas y bajas que afectan significativamente la demanda. Por ejemplo, Goa Beaches tiene alta demanda en invierno (noviembre a marzo) y muy baja en temporada de lluvias (junio a septiembre).

  • Efecto de fin de semana: Hay un incremento de la demanda los sábados y domingos.

  • Efecto horario: Se observa mayor ocupación en las salidas de la mañana (7-10 am) y en la tarde (4-7 pm).

  • Condiciones climáticas: El mal clima (lluvia, tormentas o niebla) reduce la demanda debido a las condiciones desfavorables para el turismo.

  • Eventos especiales: En días con eventos turísticos o culturales, la demanda se incrementa aproximadamente un 50%.

  • Cancelaciones: Un 5% de los viajes son cancelados, lo cual impacta directamente en el número de pasajeros de esos viajes (se fijan en 0).

Objetivo del Dataset

Este dataset fue diseñado para resolver un problema de predicción de demanda futura. El modelo puede aprender a anticipar cuántos pasajeros habrá en un viaje futuro, teniendo en cuenta factores temporales (mes, día, hora), condiciones meteorológicas, eventos especiales, tipo de vehículo, capacidad y patrones de comportamiento de los usuarios.

Esta predicción es útil para:

  • Optimización de operaciones: Seleccionar el tamaño adecuado de los vehículos.
  • Gestión de recursos: Planificar mejor conductores, horarios y frecuencia.
  • Mejora en la rentabilidad: Ajustar precios o promociones según la demanda esperada.

3.2 EDA

1. Demanda Diaria Total de Transporte (Gráfico 1)

Figura 1. Demanda total diaria

Figura 1. Demanda total diaria

  • Hay variabilidad diaria considerable, pero la serie parece mantener un comportamiento relativamente estable en el largo plazo.
  • Hay picos y valles notables, lo que sugiere que podría haber patrones estacionales o eventos puntuales que afectan la demanda (feriados, clima, etc.).
  • Esto sugiere que se requiere un modelo que pueda manejar fluctuaciones a corto plazo (como una LSTM con input diario o semanal).

2. Descomposición Estacional de la Demanda Mensual (Gráfico 2)

Figura 2. Descomposición estacional de la Demanda Mensual

Figura 2. Descomposición estacional de la Demanda Mensual

  • Tendencia: Aumenta hasta 2022 y luego se estabiliza o decrece ligeramente.
  • Estacionalidad: Se observa un patrón repetitivo claro (picos anuales), indicando que hay efectos mensuales estacionales importantes.
  • Residuos: Parecen ser ruido blanco o variaciones aleatorias no explicadas por el modelo.

La estacionalidad mensual sugiere que se debe incorporar componentes estacionales (ej. SARIMA, LSTM con embeddings de mes).

3. Función de Autocorrelación (ACF) y Autocorrelación Parcial (PACF) (Gráfico 3)

Figura 3. Función ACF y PACF

Figura 3. Función ACF y PACF

  • La ACF tiene un primer valor muy alto (esperado) y luego valores bajos pero positivos durante varios lags → indica que hay alguna autocorrelación, pero no muy fuerte.
  • La PACF decae rápido → sugiere que la serie podría ser ARIMA de bajo orden o que no tiene una fuerte dependencia temporal inmediata (lo que puede favorecer enfoques tipo LSTM con ventanas más amplias).

4. Comparación con Diferenciación (Gráfico 4)

Figura 4. Comparación con diferenciación

Figura 4. Comparación con diferenciación

  • Al aplicar diferenciación de primer orden y estacional (lag=7 días), la serie parece estabilizarse alrededor de 0.
  • Esto sugiere que la serie no es estacionaria originalmente, pero puede transformarse en estacionaria mediante diferenciación.

Esto es importante si se van a usar modelos tradicionales como SARIMA o ARIMA: necesitan estacionarizar la serie antes.

5. Demanda Mensual por Destino (Gráfico 5)

Figura 5. Demanda Mensual por Destino

Figura 5. Demanda Mensual por Destino

  • Las rutas tienen comportamientos distintos, por ejemplo:

    • Leh Ladakh muestra una estacionalidad muy marcada (actividad sólo en meses específicos).
    • Taj Mahal y Goa Beaches muestran una demanda más constante.

  • Esto refuerza la necesidad de modelos por ruta específica, posiblemente entrenando un modelo individual por ruta o incluyendo la variable “ruta” como input categórico en un modelo multivariado (ej. LSTM multirruta).

6. Demanda Promedio por Día de la Semana (Gráfico 6)

Figura 6. Demanda promedio por día de la semana

Figura 6. Demanda promedio por día de la semana

  • Sábados y domingos tienen mayor demanda → hay un patrón semanal claro.
  • Esto debe incluirse como una variable categórica en el modelo (día de la semana como input).

7. Distribución de Pasajeros por Mes (Gráfico 7)

Figura 7. Distribución de Pasajeros por Mes

Figura 7. Distribución de Pasajeros por Mes

  • Aunque los promedios parecen similares, los rangos (mínimo y máximo) varían, especialmente entre junio y septiembre.
  • Puede haber más variabilidad en meses de vacaciones o eventos especiales, lo cual justifica agregar “mes” como variable en el modelo o aplicar normalización por mes.

Basado en el análisis exploratorio y en los requerimientos específicos del problema, la arquitectura seleccionada fue un modelo híbrido basado en LSTM con un mecanismo de atención. Esta elección se justifica porque las redes LSTM son especialmente adecuadas para trabajar con datos secuenciales como las series temporales, permitiendo capturar dependencias de largo plazo dentro de la demanda histórica. Además, la incorporación de una capa de atención permite al modelo enfocar su capacidad predictiva en los patrones más relevantes dentro de la secuencia, como las variaciones estacionales, los cambios por horarios o las fluctuaciones debidas a eventos especiales. Por otra parte, esta arquitectura es capaz de integrar tanto información temporal como variables categóricas o contextuales, lo que la hace especialmente robusta para abordar la complejidad del problema planteado.

3.3 Preprocesamiento y Preparación de Datos

El preprocesamiento del dataset incluyó un proceso de ingeniería de características donde, a partir de la fecha del viaje (travel_date), se extrajeron el año, el mes y el día de la semana. De manera similar, de la hora de salida (travel_time) se derivó la variable hour. También se generó la variable high_season, que indica si un viaje ocurre durante la temporada alta, definida según cada destino. Por ejemplo, para Taj Mahal corresponde de noviembre a febrero, para Goa Beaches de noviembre a marzo y para Leh Ladakh de abril a junio, entre otros.

Se eliminaron variables que no aportaban información relevante o que podían generar fuga de datos, como ride_id, travel_date, travel_time, load_factor, canceled e is_weekend. Las variables finales se dividieron en categóricas (como destino, tipo de vehículo, método de pago o clima) y numéricas (como capacidad, precio, duración, variables temporales y special_event).

El pipeline de preprocesamiento incluyó imputación de datos faltantes (mediana para variables numéricas y moda para categóricas), junto con escalado de las numéricas mediante StandardScaler y codificación one-hot para las categóricas.

La división de datos se realizó respetando la secuencia temporal, utilizando el 80% de las fechas más antiguas para entrenamiento y el 20% más recientes para prueba. Posteriormente, se estructuró la serie temporal de demanda (actual_passengers) en secuencias, donde cada muestra utiliza los 90 días anteriores como entrada para predecir la demanda de los 30 días siguientes. Este esquema permite capturar la dependencia temporal de la serie y es adecuado para modelos LSTM.

3.4 Construcción y Entrenamiento del Modelo

Arquitectura del Modelo

El modelo desarrollado es una red neuronal secuencial con memoria a largo plazo (LSTM) complementada con un mecanismo de atención, diseñada para predecir la demanda de transporte durante los próximos 30 días, utilizando como entrada un historial de 90 días.

La arquitectura se compone de los siguientes elementos:

  1. Entrada Una secuencia temporal con la forma (90 días, 1 feature), que corresponde a la demanda histórica de pasajeros previamente escalada.

  2. Capa LSTM

    • Una capa LSTM con 128 unidades y return_sequences=True, lo que permite devolver una salida por cada paso temporal de la secuencia.
    • Posteriormente se aplica una capa de regularización Dropout con una tasa de 0.2 para evitar sobreajuste.

  3. Mecanismo de Atención Este componente permite que el modelo aprenda a asignar diferentes pesos a cada paso temporal de la secuencia, enfocándose más en aquellos días del pasado que son más relevantes para la predicción futura. El mecanismo funciona de la siguiente manera:

    • Se calcula un vector de atención mediante una capa densa con activación tanh.
    • Este vector se normaliza mediante softmax para convertirlo en pesos.
    • Los pesos se aplican sobre la salida de la LSTM mediante una operación de multiplicación ponderada.
    • Finalmente, se genera una representación agregada de la secuencia como suma ponderada de los estados ocultos.

  4. Capas Densas

    • Una capa Dense con 64 neuronas y activación relu para capturar relaciones no lineales.
    • Se agrega una segunda capa Dropout con tasa de 0.1 como medida de regularización.

  5. Capa de Salida

    • Una capa Dense con 30 neuronas, que corresponde a la predicción de la demanda para los 30 días siguientes.

  6. Compilación

    • Función de pérdida: mean_squared_error (mse).
    • Métrica de evaluación: mean_absolute_error (mae).
    • Optimizador: Adam con tasa de aprendizaje de 0.001.

Callbacks Utilizados

Se incorporan dos mecanismos para mejorar el entrenamiento y evitar el sobreajuste:

  • EarlyStopping Detiene el entrenamiento si la métrica de validación no mejora durante 15 épocas consecutivas y restaura los mejores pesos obtenidos hasta ese momento.

  • ModelCheckpoint Guarda automáticamente el mejor modelo basado en la pérdida de validación, en un archivo llamado best_model.h5.

Entrenamiento del Modelo

El modelo se entrena con los siguientes parámetros:

  • Número máximo de épocas: 100.
  • Tamaño del batch: 32.
  • Datos de validación: Se utiliza el 20% más reciente de la serie temporal.
  • Verbose: Nivel 1 (muestra el progreso del entrenamiento en consola).

El entrenamiento finaliza de forma anticipada si la métrica de validación deja de mejorar, gracias al uso de EarlyStopping.

3.5 Resultados del Modelo

Desempeño del Modelo

Después del proceso de entrenamiento utilizando la arquitectura híbrida LSTM con atención, se obtuvieron los siguientes resultados:

  • Pérdida (loss) en entrenamiento: 0.0211
  • Error Absoluto Medio (MAE) en entrenamiento: 0.1167
  • MAE en datos de prueba: 0.1132 (escala normalizada)

Métricas calculadas sobre los datos reales (desescalados):

  • MAE en test: aproximadamente 113 pasajeros
  • RMSE en test: aproximadamente 771.79 pasajeros

Estadísticas de la demanda real en el conjunto de prueba:

  • Media de la demanda real: 10,724.46 pasajeros
  • Desviación estándar: 925.96 pasajeros

3.6 Análisis de las Métricas

  • El MAE (Error Absoluto Medio) de aproximadamente 113 pasajeros indica que, en promedio, el modelo se equivoca por esa cantidad al predecir la demanda diaria. Comparado con una media de más de 10,000 pasajeros diarios, este error representa un porcentaje muy bajo (aproximadamente 1% del valor medio), lo cual es excelente para este tipo de predicciones.

  • El RMSE (Raíz del Error Cuadrático Medio) es más alto, 771.79 pasajeros, lo que indica que aunque la mayoría de las predicciones son precisas, existen algunos días con errores significativamente mayores (los cuales afectan más al RMSE que al MAE, por ser sensible a valores extremos).

  • La baja pérdida (loss = 0.0211) y el bajo MAE en entrenamiento y validación sugieren que el modelo ha logrado un buen ajuste, sin sobreajuste evidente.

  • Comparado con la desviación estándar de la demanda real (925.96), el RMSE es algo menor pero está en la misma magnitud, lo cual es esperable. Esto implica que el error típico es menor que la variación natural de la demanda.

3.7 Gráficas de los resultados

Figura 8. Comparación entre la demanda real y la demanda predicha para la ruta Goa Beaches.

Figura 8. Comparación entre la demanda real y la demanda predicha para la ruta Goa Beaches.

Descripción: En la Figura 8 se observa la comparación entre la demanda real y la demanda predicha específicamente para la ruta hacia Goa Beaches. El modelo logra capturar correctamente los picos de alta demanda y las caídas, manteniéndose generalmente cerca de los valores reales. Sin embargo, pueden observarse pequeñas desviaciones en algunos períodos, lo cual es esperable debido a factores impredecibles o ruido en los datos.En todas las otras imágenes podemos obtener la misma conclusión.

Figura 9. Comparación entre la demanda real y la demanda predicha para la ruta Jaipur City.

Figura 9. Comparación entre la demanda real y la demanda predicha para la ruta Jaipur City.

Descripción: La Figura 9 muestra la comparación para la ruta Jaipur City, donde el modelo refleja adecuadamente los patrones estacionales y los picos en la demanda. Las diferencias tienden a ser pequeñas y es capaz de seguir las tendencias generales.

Figura 10. Comparación entre la demanda real y la demanda predicha para la ruta Kerala Backwaters.

Figura 10. Comparación entre la demanda real y la demanda predicha para la ruta Kerala Backwaters.

Descripción: En la Figura 10, para la ruta Kerala Backwaters, se observa que el modelo sigue bien la tendencia, especialmente en los períodos de alta temporada. Las discrepancias son más visibles en algunos puntos específicos de baja demanda.

Figura 11. Comparación entre la demanda real y la demanda predicha para la ruta Leh Ladakh.

Figura 11. Comparación entre la demanda real y la demanda predicha para la ruta Leh Ladakh.

Descripción: La Figura 11 presenta la comparación para la ruta Leh Ladakh, donde la demanda es muy estacional y concentrada en pocos meses. Esto hace que el modelo tenga un desafío mayor, pero logra captar correctamente los picos durante la temporada accesible.

Figura 12. Comparación entre la demanda real y la demanda predicha para la ruta Taj Mahal.

Figura 12. Comparación entre la demanda real y la demanda predicha para la ruta Taj Mahal.

Descripción: La Figura 12 muestra los resultados para Taj Mahal, uno de los destinos con mayor volumen de pasajeros. El modelo captura con bastante precisión los comportamientos regulares, aunque presenta ligeras desviaciones en algunos períodos de alta demanda.

3.8 Conclusiones

  • El modelo desarrollado, basado en una red LSTM con mecanismo de atención, logra capturar adecuadamente los patrones temporales y estacionales presentes en la demanda de transporte.

  • El error absoluto medio representa aproximadamente 1% del valor medio de la demanda, lo cual indica que el modelo tiene una excelente capacidad predictiva para un problema de esta naturaleza.

  • La inclusión de variables como condiciones meteorológicas, tipo de vehículo, destino, horarios y estacionalidades contribuyó significativamente a la mejora en la precisión del modelo.

  • Aunque el RMSE es más alto debido a algunos errores puntuales, en general las predicciones son bastante consistentes.

  • Este modelo es adecuado para ser utilizado en la planificación operativa, como asignación de vehículos, gestión de rutas o estimación de ingresos en base a la demanda proyectada.

4 Módulo 2: Clasificación de Conducción Distractiva

Para el diseño de nuestra arquitectura base, nos inspiramos en el trabajo de Ghaffar (2023), quien desarrolla un sistema de clasificación de imágenes para conductores distraídos usando redes convolucionales. A partir de este estudio, adaptamos una arquitectura más pequeña y eficiente, ajustada a nuestro conjunto de datos de 7.267 imágenes, con el fin de mantener una buena capacidad de generalización sin sobreentrenamiento.

El modelo propuesto por Ghaffar (2023) incluía siete capas convolucionales y múltiples capas densas para una clasificación de 10 clases con más de 22.000 imágenes. En nuestro caso, adaptamos esta arquitectura reduciendo significativamente la cantidad de capas y parámetros, ajustando la red a un conjunto más pequeño (7.267 imágenes) y a un dominio específico de cinco clases, logrando así un modelo más eficiente y menos propenso al sobreajuste.

4.1 Descripción del Dataset

El conjunto de datos utilizado proviene de escenas reales captadas dentro de vehículos en movimiento en Dhaka, Bangladesh. Incluye imágenes etiquetadas manualmente con cinco categorías de comportamiento del conductor:

  • safe_driving: conducción atenta y segura
  • turning: movimiento de giro o cambio de dirección
  • texting_phone: uso activo del teléfono para escribir
  • talking_phone: uso del teléfono en llamada
  • other_activities: cualquier otra actividad distractora, como comer, dormir o interactuar con otros pasajeros

El total de imágenes asciende a 7.267, con una distribución de clases razonablemente balanceada. Esta distribución se visualiza en la Figura 13.

Figura 13. Distribución de imágenes por clase en el dataset

Figura 13. Distribución de imágenes por clase en el dataset

4.2 Preprocesamiento de Imágenes

Las imágenes se redimensionaron a 224x224 píxeles y fueron procesadas utilizando ImageDataGenerator, con aumentos que incluyeron rotaciones, traslaciones, zoom, modificaciones de brillo y espejado horizontal. Esto nos permitió incrementar la diversidad del conjunto de entrenamiento y mejorar la generalización del modelo.

Adicionalmente, empleamos class_weights calculados con sklearn.utils.class_weight.compute_class_weight() para penalizar la pérdida en función de la frecuencia de cada clase.

También realizamos una exploración visual de las imágenes y ejemplos aleatorios, como se muestra en la Figura 14.

Figura 14. Ejemplos aleatorios de imágenes del dataset

Figura 14. Ejemplos aleatorios de imágenes del dataset

4.3 Arquitectura del Modelo

Inspirados en arquitecturas más complejas como AlexNet, diseñamos una red convolucional más ligera y eficiente con tres bloques convolucionales, regularización L2, BatchNormalization y Dropout entre capas. El modelo fue entrenado con:

  • Activación final: softmax
  • Función de pérdida: sparse_categorical_crossentropy
  • Callbacks: EarlyStopping y ModelCheckpoint
  • División: 80% entrenamiento / 20% validación

Este enfoque bottom-up nos permitió controlar el tamaño y complejidad del modelo en relación con el tamaño del dataset disponible.

4.4 Evaluación y Resultados

La Figura 15 muestra el comportamiento del modelo durante el entrenamiento. Se observa una convergencia estable, aunque con señales de sobreajuste moderado a partir de la época 25.

Figura 15. Evolución de precisión y pérdida durante el entrenamiento

Figura 15. Evolución de precisión y pérdida durante el entrenamiento

La matriz de confusión (Figura 16) muestra un rendimiento destacado en clases clave como talking_phone, texting_phone y safe_driving.

Figura 16. Matriz de confusión del modelo en el conjunto de validación

Figura 16. Matriz de confusión del modelo en el conjunto de validación

A continuación se resumen las métricas de evaluación por clase:

Tabla 2: Métricas por clase para el modelo de clasificación de conducción distractiva
Clase Precisión Recall F1_Score
other_activities 0.36 0.33 0.34
safe_driving 0.56 0.74 0.63
talking_phone 0.81 0.73 0.77
texting_phone 0.72 0.82 0.77
turning 0.75 0.47 0.58

El modelo alcanzó un accuracy global de 64.7%, con un F1-score macro de 0.627. Esto refleja un rendimiento adecuado, especialmente en las clases asociadas a conductas distractoras críticas como texting_phone y talking_phone.

4.6 Proceso Iterativo de Optimización del Modelo

A lo largo del desarrollo del módulo de clasificación, realizamos múltiples pruebas con variantes del modelo para alcanzar el rendimiento observado. Este fue el resultado de un proceso iterativo extenso, basado en las siguientes estrategias:

  • Reducción progresiva de la arquitectura: Partimos de un modelo de referencia más grande compartido en una guía técnica (Ghaffar, 2023), diseñada para más de 22.000 imágenes. Ante la diferencia en la cantidad de datos disponibles (7.267 imágenes), optamos por rediseñar la arquitectura, reduciendo su profundidad y cantidad de parámetros para evitar sobreajuste.
  • Comparación de técnicas de regularización: Probamos diversos valores de Dropout (entre 0.3 y 0.5) en diferentes bloques, así como el uso de regularización L2, observando su efecto sobre las métricas de validación.
  • Uso de BatchNormalization y tuning de learning rate: Experimentamos con y sin normalización por lotes, y modificamos la tasa de aprendizaje para evitar que el modelo convergiera demasiado rápido en mínimos locales.
  • Ajuste de resolución de imágenes: Aunque inicialmente trabajamos con 128x128, descubrimos que el modelo ganaba capacidad discriminativa al aumentar la resolución a 224x224, especialmente en clases como texting_phone y talking_phone.
  • Estrategias de entrenamiento y callbacks: Implementamos EarlyStopping para prevenir sobreentrenamiento y restaurar automáticamente los mejores pesos mediante ModelCheckpoint.
  • Múltiples ejecuciones con análisis de métricas: Tras varias corridas y afinaciones, elegimos el modelo con mejor rendimiento promedio en precisión y F1-score, evaluado sobre un conjunto de validación del 20%.

Además, se implementaron y evaluaron distintas arquitecturas con el fin de ajustar la capacidad del modelo al tamaño del conjunto de datos. Inicialmente se probó una arquitectura con tres bloques convolucionales, siguiendo el diseño propuesto por Ghaffar (2023). Sin embargo, esta configuración presentaba señales de sobreajuste e inestabilidad en la validación, lo cual motivó una reducción a solo dos bloques Conv2D combinados con una sección densa más expresiva.

Durante las iteraciones posteriores también se evaluaron: - La sustitución de Flatten() por GlobalAveragePooling2D() para reducir la cantidad de parámetros y estabilizar el entrenamiento. - Diversas combinaciones de capas densas (128, 256, 64 unidades) y funciones de activación (ReLU, LeakyReLU). - Aumentos progresivos en el nivel de Dropout (0.3 a 0.5). - La regularización L2 en distintas capas del modelo. - El impacto de ajustar class_weight para mejorar el rendimiento en clases minoritarias como other_activities.

Cabe destacar que se descartaron arquitecturas basadas en modelos preentrenados (transfer learning con ResNet50 o VGG16), así como ensambles, debido a restricciones de cómputo, y en favor de mantener un modelo entrenable desde cero con una arquitectura interpretable y ajustada a nuestras necesidades. Esta elección permite una integración directa con la herramienta web sin dependencias complejas o tiempos de carga elevados.

Este proceso iterativo nos permitió alcanzar una arquitectura final con solo dos bloques convolucionales, pero con una parte densa lo suficientemente expresiva como para lograr una precisión y F1-score superiores al 62%.

4.5 Análisis de Distracciones Comunes y Medidas Preventivas

Las clases talking_phone y texting_phone fueron las más fácilmente detectables, lo que sugiere que el modelo logró capturar patrones visuales asociados (posición del rostro, manos, presencia del celular). En contraste, other_activities mostró mayor confusión, debido a su heterogeneidad.

Este análisis permite proponer medidas como:

  • Instalación de sistemas de monitoreo con alertas automáticas para eventos de distracción detectados.
  • Capacitación a conductores con retroalimentación basada en los comportamientos detectados.
  • Revisión de políticas internas para restringir el uso de dispositivos móviles en ruta.

En conclusión, el modelo cumple con los objetivos de clasificación propuestos, ofreciendo resultados sólidos en las categorías más relevantes para la seguridad vial.

5. Módulo 3 - Recomendación de Destinos de Viaje

5.1 Introducción

En este módulo desarrollamos un sistema de recomendación de destinos basado en filtrado colaborativo. El objetivo es predecir la calificación (ExperienceRating) que un usuario daría a un destino turístico, utilizando únicamente su historial de visitas y características embebidas.

Esta tarea se formuló como un problema de regresión, donde el modelo predice una calificación entre 1 y 5. Se utilizaron embeddings para representar tanto a usuarios como destinos y se entrenó un modelo de factorización matricial con Keras.

5.2 Análisis Exploratorio de Datos

Antes de construir el modelo, se llevó a cabo un análisis exploratorio para entender la distribución de los datos y evaluar qué variables debían ser incluidas o descartadas.

Distribución de Calificaciones

Figura 17. Distribución de la variable ExperienceRating

Figura 17. Distribución de la variable ExperienceRating

La variable ExperienceRating presenta una distribución relativamente uniforme, sin sesgo marcado hacia los extremos. Esto sugiere que el modelo no deberá compensar clases desbalanceadas.

Destinos más populares

Figura 18. Tipos de destino más comunes en el dataset

Figura 18. Tipos de destino más comunes en el dataset

La frecuencia de destinos está relativamente balanceada entre las distintas categorías, destacándose ligeramente los destinos de naturaleza e historia.

Distribución por género

Figura 19. Distribución por género en los registros

Figura 19. Distribución por género en los registros

Se observa una distribución balanceada entre hombres y mujeres, lo cual es positivo en términos de representatividad del modelo.

Calificación por tipo de destino

Figura 20. Distribución de ratings por tipo de destino

Figura 20. Distribución de ratings por tipo de destino

Las medianas de calificación son similares entre los distintos tipos de destino, sin variaciones fuertes que justifiquen un modelo específico por categoría.

Correlaciones con ExperienceRating

Figura 21. Correlación de variables con ExperienceRating

Figura 21. Correlación de variables con ExperienceRating

No se evidencian correlaciones lineales fuertes con la variable objetivo, lo que valida el uso de una red neuronal para modelar relaciones no lineales complejas.

Preferencias más comunes

Figura 22. Preferencias más comunes de los usuarios

Figura 22. Preferencias más comunes de los usuarios

Las preferencias de los usuarios son consistentes con las categorías más visitadas, especialmente el interés por lo histórico y la naturaleza.

Distribución de visitas por mes

Figura 23. Cantidad de visitas registradas por mes

Figura 23. Cantidad de visitas registradas por mes

Los datos están concentrados en el primer trimestre del año. Esto debe tenerse en cuenta para evitar sesgos temporales en los resultados.

5.3 Arquitectura del Modelo

El modelo empleado es una red neuronal basada en factorización matricial simple con Keras. Esta arquitectura consiste en:

  • Embedding para UserID y DestinationID
  • Producto punto entre vectores de usuario y destino
  • Salida única como predicción continua (regresión)

Se utilizó la función de pérdida MSE y el optimizador Adam. El modelo fue entrenado con EarlyStopping y ModelCheckpoint.

5.4 Evaluación y Resultados

Curva de pérdida durante el entrenamiento

Figura 24. Evolución de la pérdida MSE en train y validación

Figura 24. Evolución de la pérdida MSE en train y validación

Se observa una clara convergencia del modelo. La validación se estabiliza alrededor de la época 15, lo cual sugiere una buena capacidad de generalización.

Predicción vs Real

Figura 25. Comparación entre rating real y predicho

Figura 25. Comparación entre rating real y predicho

El modelo tiende a subestimar ligeramente los valores altos de rating, pero logra capturar la tendencia general de los datos.

Métricas Finales

Tabla 3: Métricas finales del modelo de recomendación
Métrica Valor
MAE 1.226
RMSE 1.493
Correlación 0.083

5.5 Conclusiones

  • Se logró construir un sistema de recomendación con un error promedio de 1.2 estrellas, lo cual es aceptable para fines exploratorios.
  • El modelo es simple, eficiente y puede integrarse fácilmente en una plataforma de turismo inteligente.
  • El filtrado colaborativo con embeddings demuestra ser efectivo incluso en conjuntos de datos con poca correlación lineal.

6. Herramienta Web Integrada

Para demostrar la aplicabilidad práctica de los modelos desarrollados, se implementó una aplicación web interactiva que integra los tres módulos de inteligencia artificial en una interfaz unificada y accesible. La herramienta fue desarrollada utilizando Gradio, un framework de Python que permite crear interfaces web para modelos de machine learning de manera sencilla y efectiva.

6.1 Arquitectura de la Aplicación

La aplicación web está estructurada como una interfaz con pestañas (TabbedInterface) que organiza cada módulo de manera independiente, permitiendo a los usuarios navegar fácilmente entre las diferentes funcionalidades:

6.2 Módulo de Clasificación de Conducción Distractiva

Funcionalidades Implementadas

El módulo de clasificación permite a los usuarios cargar imágenes de conductores y obtener una predicción automática del comportamiento detectado. La interfaz incluye:

  • Carga de imágenes: Los usuarios pueden subir imágenes en formatos comunes (JPG, PNG, etc.)
  • Clasificación automática: El modelo CNN entrenado procesa la imagen y predice una de cinco categorías:
    • Conducción segura
    • Hablando por teléfono
    • Escribiendo en el teléfono
    • Girando
    • Otras actividades

Procesamiento de Imágenes

La imagen se redimensiona automáticamente a 224x224 píxeles (resolución requerida por el modelo), se normaliza y se procesa para obtener la predicción.

Ejemplos de Clasificación

La aplicación web permite a los usuarios interactuar directamente con el modelo de clasificación de conducción a través de una interfaz intuitiva. A continuación se muestran ejemplos de uso real:

Figura 26. Interfaz de clasificación de conducción distractiva con instrucciones de uso.

Figura 26. Interfaz de clasificación de conducción distractiva con instrucciones de uso.

La Figura 26 muestra la interfaz principal del módulo de clasificación. En el recuadro (1) se observa la zona de carga de imágenes donde los usuarios pueden seleccionar archivos desde su computadora, tomar una foto directamente con la cámara, o pegar una imagen desde el portapapeles. El recuadro (2) muestra el área donde se despliega el resultado de la clasificación una vez procesada la imagen.

Figura 27. Ejemplo de clasificación correcta: conductor escribiendo en el teléfono.

Figura 27. Ejemplo de clasificación correcta: conductor escribiendo en el teléfono.

En la Figura 27 se presenta un caso exitoso donde el modelo clasifica correctamente a un conductor que está “Escribiendo en el teléfono” mientras conduce. El sistema detecta apropiadamente la postura característica y la presencia del dispositivo móvil, demostrando la capacidad del modelo para identificar este comportamiento de alto riesgo.

Figura 28. Ejemplo de clasificación errónea.

Figura 28. Ejemplo de clasificación errónea.

La Figura 28 ilustra una limitación del modelo, donde clasifica incorrectamente una imagen de conducción segura como “Otras actividades”.

6.3 Módulo de Predicción de Demanda de Transporte

Funcionalidades Implementadas

El módulo de demanda ofrece una visualización de las predicciones del modelo LSTM para diferentes rutas turísticas:

  • Selección de rutas: Dropdown con cinco destinos disponibles:
    • Goa Beaches
    • Jaipur City
    • Kerala Backwaters
    • Leh Ladakh
    • Taj Mahal
  • Visualización automática: Al seleccionar una ruta, se muestra automáticamente la gráfica correspondiente que compara la demanda real vs. predicha.

Gráficas de Predicción vs. Demanda Real

El módulo de predicción de demanda ofrece una interfaz simple pero efectiva que permite visualizar los resultados del modelo LSTM para diferentes rutas turísticas:

Figura 29. Interfaz del módulo de predicción de demanda con ejemplo de la ruta Taj Mahal.

Figura 29. Interfaz del módulo de predicción de demanda con ejemplo de la ruta Taj Mahal.

La Figura 29 muestra la funcionalidad del módulo de predicción de demanda. Los usuarios pueden seleccionar cualquiera de las cinco rutas disponibles desde un menú desplegable, y automáticamente se muestra la gráfica correspondiente que compara la demanda real vs. la predicha por el modelo LSTM. En este ejemplo se observa la ruta hacia Taj Mahal, donde el modelo captura adecuadamente los patrones estacionales y las fluctuaciones en la demanda de pasajeros. La interfaz es intuitiva y permite a los operadores de transporte evaluar rápidamente el rendimiento predictivo del modelo para la planificación operativa.

6.4 Módulo de Recomendación de Destinos

Funcionalidades Implementadas

El sistema de recomendación ofrece la funcionalidad más sofisticada de la aplicación:

  • Entrada de usuario: Campo de texto para ingresar el ID del usuario
  • Perfilado automático: Si el usuario existe en el sistema, se extrae su perfil completo
  • Recomendaciones personalizadas: Top 5 destinos recomendados con calificaciones predichas

Ejemplos de Recomendaciones

El sistema de recomendación demuestra su capacidad de personalización a través de una interfaz que extrae automáticamente el perfil del usuario y genera sugerencias adaptadas:

Figura 30. Interfaz del sistema de recomendación con ejemplo de usuario personalizado.

Figura 30. Interfaz del sistema de recomendación con ejemplo de usuario personalizado.

La Figura 30 ilustra el funcionamiento del módulo de recomendación. En este ejemplo, el sistema analiza el perfil del Usuario 525, identificando que se trata de una persona de género femenino que viaja con 1 niño y 1 adulto, con preferencia por destinos aventureros y que usualmente viaja en enero. Basándose en esta información contextual, el sistema genera recomendaciones personalizadas:

  • Recomendación 1: Kerala Backwaters con calificación 2.2
  • Recomendación 2: Taj Mahal con calificación 2.2
  • Recomendación 3: Goa Beaches con calificación 2.2
  • Recomendación 4: Leh Ladakh con calificación 2.1
  • Recomendación 5: Jaipur City con calificación 2.1

Es importante mencionar que los usuarios disponibles para análisis son aquellos que están registrados en el archivo df_ready_for_training.csv, de donde se extraen los IDs válidos para el sistema. Esta personalización demuestra la efectividad del filtrado colaborativo con embeddings para capturar las preferencias latentes de los usuarios y generar sugerencias relevantes para mejorar la experiencia turística.

6.5 Despliegue y Accesibilidad

Plataforma de Despliegue

La aplicación fue desplegada en Hugging Face Spaces, una plataforma que permite hospedar aplicaciones de machine learning de forma gratuita y accesible. Esto garantiza:

  • Acceso universal: Disponible desde cualquier navegador web
  • Sin instalaciones: No requiere configuración local por parte del usuario
  • Escalabilidad: Manejo automático de múltiples usuarios concurrentes
  • Mantenimiento: Actualizaciones automáticas cuando se modifica el código

Características de la Interfaz

  • Diseño responsivo: Compatible con dispositivos móviles y de escritorio
  • Interfaz intuitiva: Controles simples y claros para cada funcionalidad
  • Retroalimentación inmediata: Resultados mostrados en tiempo real
  • Manejo de errores: Validación de entradas y mensajes informativos

7. Resultados Generales y Discusión

Lecciones Aprendidas y Limitaciones del Módulo 1

El desarrollo del modelo LSTM con atención permitió capturar patrones temporales como la estacionalidad, el efecto del clima y los eventos especiales en la demanda de transporte. Incorporar estas variables fue clave para mejorar las predicciones.

Sin embargo, se presentaron desafíos en rutas con alta variabilidad o baja demanda, donde el modelo mostró mayor error. Además, al trabajar con datos sintéticos y agregados por día, el modelo puede no generalizar perfectamente a escenarios reales o predicciones en tiempo real.

A pesar de estas limitaciones, el modelo demuestra ser una base sólida para entender el comportamiento de la demanda y abre la puerta a futuras mejoras.

Lecciones Aprendidas y Limitaciones del Módulo 2

Durante el desarrollo del modelo de clasificación de conducción distractiva, aprendimos que construir una arquitectura CNN desde cero nos permite tener un mayor control sobre la complejidad del modelo y adaptarlo eficientemente al tamaño del dataset disponible. A diferencia de las arquitecturas preentrenadas, nuestra versión manual balanceó precisión y eficiencia computacional, logrando buenos resultados en clases críticas como texting_phone y talking_phone.

También descubrimos la importancia del aumento de datos y la regularización, especialmente cuando se trabaja con volúmenes moderados de imágenes. Técnicas como Dropout, L2, y class_weights fueron claves para evitar el sobreajuste sin sacrificar rendimiento.

Sin embargo, enfrentamos limitaciones que vale la pena mencionar:

  • La clase other_activities fue difícil de modelar debido a su heterogeneidad. Una mejor estrategia podría ser subdividirla en comportamientos más específicos.
  • Aunque el modelo fue entrenado y evaluado en condiciones realistas, su despliegue en entornos reales requeriría ajustes adicionales como detección en tiempo real, control de calidad en imágenes y latencia mínima.

Estas lecciones sientan las bases para futuras mejoras del sistema y para su integración en contextos reales de monitoreo de seguridad vial.

Lecciones Aprendidas y Limitaciones del Módulo 3

Durante el desarrollo del sistema de recomendación basado en filtrado colaborativo, comprendimos que incluso modelos simples como la factorización matricial con embeddings pueden ofrecer un rendimiento competitivo cuando se entrenan adecuadamente y se alimentan con datos bien estructurados.

Una de las principales lecciones fue el valor de representar entidades (usuarios y destinos) mediante vectores entrenables, lo cual permite capturar relaciones latentes sin necesidad de utilizar información explícita o textual. Esta estrategia redujo la dimensionalidad del problema y facilitó la generalización.

Asimismo, aprendimos que, a pesar de la aparente debilidad de correlaciones lineales entre variables y la calificación (ExperienceRating), un modelo no lineal fue capaz de extraer patrones útiles para la predicción.

Sin embargo, enfrentamos algunas limitaciones importantes:

  • El modelo tiende a subestimar calificaciones altas y sobreestimar las bajas, probablemente debido a la regularización implícita en el aprendizaje de los embeddings.
  • El sistema no incorpora aún información contextual rica (como texto libre o comportamiento reciente), lo cual limita su capacidad para personalizar recomendaciones más allá del historial básico.
  • Las recomendaciones actuales se basan en preferencias históricas globales, sin tener en cuenta factores como la temporalidad, la disponibilidad de destinos o las restricciones del usuario.

Estas experiencias nos orientan hacia futuras mejoras como la incorporación de filtros dinámicos, variables contextuales y estrategias híbridas que combinen filtrado colaborativo con contenido explícito.

8. Conclusiones y Recomendaciones

Este proyecto logró desarrollar e integrar tres sistemas basados en inteligencia artificial enfocados en el ámbito del transporte y el turismo: un modelo de predicción de demanda, un modelo de clasificación de conducción distractiva y un sistema de recomendación turística.

En el módulo de predicción de demanda, el uso de redes neuronales LSTM con mecanismo de atención demostró ser efectivo para capturar patrones estacionales, horarios y contextuales. A pesar de trabajar con datos sintéticos, el modelo mostró un buen desempeño relativo, lo que valida su diseño y su potencial aplicabilidad en entornos reales.

El modelo de clasificación de conducción distractiva permitió comprender la importancia del diseño arquitectónico y de técnicas de regularización, especialmente cuando se trabaja con datos visuales y múltiples categorías de comportamiento.

Por su parte, el sistema de recomendación implementado mostró cómo el análisis de perfiles y preferencias puede ser una herramienta poderosa para mejorar la experiencia de los usuarios en el sector turístico.

Entre las principales recomendaciones se destacan:

En general, este proyecto evidencia que la aplicación de modelos de inteligencia artificial en transporte y turismo no solo es viable, sino también altamente efectiva cuando se realiza un diseño cuidadoso tanto de los datos como de los modelos.

9. Aspectos Éticos y Creatividad

Durante el desarrollo de este proyecto, consideramos diversos aspectos éticos asociados al uso de datos y modelos de inteligencia artificial en el sector del transporte y turismo.

En primer lugar, aunque el dataset de predicción de demanda fue generado de manera sintética, en un escenario real sería fundamental garantizar la privacidad de los datos personales de los usuarios, especialmente en los sistemas de recomendación y monitoreo de conductores. La anonimización y la protección de datos sensibles serían requisitos indispensables.

Otro aspecto crítico es el sesgo en los datos. Al trabajar con datos históricos o específicos de ciertas regiones, existe el riesgo de que los modelos reproduzcan patrones injustos o no generalicen correctamente a otros contextos. Esto se observa, por ejemplo, en rutas con baja frecuencia o en comportamientos atípicos en el módulo de clasificación de conducción.

En cuanto al módulo de recomendación, es importante garantizar la transparencia del sistema, evitando que las recomendaciones sean influenciadas únicamente por criterios comerciales y asegurando que respeten las preferencias reales de los usuarios.

Finalmente, desde la creatividad, este proyecto demuestra cómo es posible integrar tres modelos distintos (predicción, clasificación y recomendación) en un ecosistema unificado. La generación de un dataset sintético realista, el diseño manual de arquitecturas de redes neuronales, y el despliegue de una herramienta web accesible, reflejan un proceso creativo con foco tanto en la innovación técnica como en la solución de problemas prácticos.

10. Bibliografía

Referencias

11 Anexos

Datasets

Repositorios de Código

Aplicación Web Desplegada

Recursos Complementarios