Exploración de datos: Accidentes de tráfico registrados en EE.UU. Valentina Álvarez Valderrama Gabriel David Castillo Rodríguez Daniel Esteban Yaruro Contreras 2211333 Facultad de ingeniería de sistemas e informática Bucaramanga, Colombia 2220055 Facultad de ingeniería de sistemas e informática Bucaramanga, Colombia 2220088 Facultad de ingeniería de sistemas e informática Bucaramanga, Colombia Abstract—El proyecto desarrolla técnicas de machine learning para predecir la severidad de accidentes de tráfico utilizando un dataset que incluyen información temporal, geoespacial, meteo rológica y de infraestructura vial. El modelo está orientado a funcionar como un Sistema de Alertas de Emergencia para detectar accidentes críticos de forma temprana. Index Terms—Procesamiento de datos, Servicios de Emergen cias, Severidad, Machine Learning I. Introducción Como resultado de los accidentes de tránsito en todo el mundo, cerca de 1.35 millones de personas pierden la vida anualmente. Alrededor de 20 a 50 millones de personas sufren lesiones no mortales debido a estos accidentes y muchas de estas quedan con discapacidades permanentes [1]. Estados Unidos se encuentra entre los países con la tasa más alta de muertes relacionadas con el tráfico por cada millón de habitantes. La tasa de muertes por tráfico por cada 100 millones de millas recorridas por vehículos anuales alcanzó su punto máximo en 2016 [2]. En el 2022, aproximadamente 42,400 personas murieron en accidentes automovilísticos en los EE.UU representando un estimado del 3.6% de los 1.19 millones de personas que se estima que son víctimas de estas fatalidades automovilísticas a nivel global [3]. Es un tema de discusión que ha tomado relevancia en el análisis de datos, con la finalidad de identificar los factores que inciden en la ocurrencia de estos accidentes y así mitigar los problemas principales en el ámbito de seguridad vial. De acuerdo al servicio de emergencias médicas (EMS) de Estados Unidos, los profesionales médicos atienden cerca de 1.5 millones choques de vehículos en las carreteras del país cada año. No importa cuándo o dónde ocurra el accidente, el 911 recibe la llamada y si hay lesiones involucradas, el Despacho Médico de Emergencia basado en el 911 inicia la atención y envía a los médicos del servicio de emergencia para que brinden la atención médica fundamental necesaria para ayudar a reducir las muertes y la discapacidad en carreteras. Durante los últimos 50 años, el Departamento de Transporte (DOT) ha apoyado el desarrollo de este sistema, el cual debe contar con buenos recursos que pueda brindar la atención apropiada en el momento oportuno [4]. Conforme a lo anterior, destaca la importancia en abordar la gravedad que representa un choque automovilísitco y a partir de ello priorizar la respuesta de los servicios de emergencia de forma eficiente. Sin embargo, uno de los desafíos actualmente es la falta de mecanismos automáticos y precisos para evaluar el nivel de severidad del accidente en tiempo real, esto puede resultar en demoras en la atención, que el accidente sea considerado menos grave de lo que realmente es o en asignaciones de recursos médicos que no corresponden a las necesidades reales del caso. Por ello, este proyecto busca solucionar dicha problemática desarrollando estrategias basadas en el análisis de datos que permitan identificar la severidad de una accidente vehicular, optimizando la toma de decisiones del sistema de emergen cias; de forma que, los casos más graves reciban atención prioritaria reduciendo significativamente las tasas de mortal idad derivadas de estos hechos. A. Conceptos fundamentales En primera instancia, para comprender el problema base del proyecto es imprescindible mencionar la definición de la variable principal del conjunto de datos seleccionado. a) Severidad de accidentes vehiculares: La severidad se presenta como la gravedad del accidente de tráfico, siendo representada por un número entre 1 y 4, donde 1 indica el menor impacto en el tráfico (es decir, un retraso corto como resultado del accidente) y 4 indica un impacto significativo en el tráfico (es decir, un retraso largo). Esta clasificación es crítica para los servicios de emrgencias pues determina la prioridad en el despacho de ambulancias y la preparación re querida en centros hospitalarios, todo liderado por un tiempo de respuesta óptimo. b) Variables auxiliares : Como respaldo en las predicciones a conseguir se toman en cuenta características ambientales, de infraestructura y geoespaciales. Ahora bien, la base técnica para el modelo predictivo a desarollar tiene en cuenta algoritmos de Machine Learning que sean capaces de identificar combinaciones específicas de factores que predicen la severidad de manera más precisa que el análisis estadístico convencional. Por ello, se agregan a continuación las herramientas especializadas que se selec cionaron para el desarrollo y ejecución del proyecto. c) Vaex: Esta librería utiliza una característica denominada evaluación perezosa permitiendo que no se cargue completa mente el conjunto de datos en memoria, de esta manera solo se va a procesar lo necesario. Debido a su especialización en visualizaciones interactivas es ideal en análisis exploratorios iniciales de datos geoespaciales y temporales. d) Modin: Acelera operaciones de la librería Pandas distribuyendo el procesamiento en múltiples nodos, aplicando a su vez lazy evaluation en el momento de retrasar la ejecución hasta que sea necesaria para continuar optimizando las operaciones. Es adaptable al preprocesamiento de datasets grandes incluyendo limpieza de registros nulos y transformación de columnas. e) H2O.ai: Esta plataforma se encarga de proporcionar implementaciones eficientes de algoritmos avanzados ya opti mizados. Debido a su integración de AutoML, se simplifica todo el proceso de creación de modelos, desde la selección de algoritmos hasta la evaluación de resultados y a su vez maneja el ajuste de hiperparámetros. Al incluir algoritmos robustos como Gradient Boosting Machine (GBM) y XGBoost es menos sensible a datos anómalos. De igual manera, presenta técnicas de ensemble que consiste en combinar múltiples modelos para mejorar el rendimiento y alcanzar predicciones más consistentes y confiables. f) Apache Spark y Hadoop: Para despliegue en producción, la combinación de estas plataformas proporciona un ecosis tema completo para la gestión de recursos y ejecución de operaciones. Apache Spark siendo un motor de procesamiento en paralelo, se presenta como un sistema distribuido diseñado para el big data reduciendo a gran medida los tiempos en la manipulación de los datos. Por otro lado, el clúster en Hadoop garantiza un sistema de archivos distribuido que replica los datos a través de diferentes nodos (un nodo maestro y dos nodos esclavos en este caso), de manera que si uno falla, los datos sigan disponibles. g) PySpark: Esta es la interfaz de Python que trabaja en conjunto con Apache Spark para la ejecución de opera ciones y entrenamiento de modelos a gran escala. De igual manera, ofrece un módulo de MLlib que incluye pipelines de preprocesamiento entre otra librerías de visualización como matplotlib y seaborn para conectar el sistema con flujos de datos reales. h) Métricas Seleccionadas: De igual manera, es funda mental la comprensión de las métricas de evaluación a emplear en este contexto. Debido a que los conjuntos de datos relacionados con accidentes típicamente suelen tener muchos accidentes leves y pocos accidentes considerados como fatal idades, este desbalance en clases puede hacer que las métricas tradicionales que suelen optimizar solo para exactitud global sean engañosas. A continuación se listan las métricas a utilizar: • Precisión: Proporción de predicciones positivas que fueron correctas. Lo cual es crítico para evitar falsas alarmas que vayan a desperdiciar recursos que dejen que otros accidentes realmente graves puedan quedar desa tendidos o que se genere un costo económico innecesario al sistema de salud. • Recall: Proporción de casos positivos reales que fueron correctamente identificados. En este proyecto es crucial para no perder casos graves y en casos de emergen cias médicas, es preferible sobrestimar la gravedad que subestimarla, pues un falso negativo puede costar una vida. • F1 Score: Más conocida como la media armónica entre la precisión y el recall, proporciona una medida bal anceada del desempeño del modelo general. Entendiendo la selección de las métricas señaladas se adquiere un mejor contexto de las implicaciones de acuerdo a la prob lemática a trabajar, puesto que, en servicios de emergencia es preferible tener mayor recall (no perder casos graves) aunque se sacrifique algo de precisión, ya que es mejor sobrestimar que subestimar la severidad. II. Objetivo general • Predecir la severidad de un accidente vehicular dado un llamado de emergencia, utilizando variables auxiliares para optimizar la capacidad de respuesta operativa ante estos incidentes. III. Objetivos específicos • Analizar el aporte de variables asociadas a condiciones climáticas, ambientales, indicadores de visibilidad de luz natural y presencia de señalización de tránsito en la predicción de la severidad. • Determinar los modelos predictivos que estimen en mejor medida la severidad del accidente. • Evaluar la precisión y desempeño del modelo predictivo a través de métricas apropiadas. • Proponer recomendaciones para la implementación op erativa del servicio de emergencias. IV. Justificación del proyecto A causa del volumen de la información requerida para la predicción de la severidad de accidentes vehiculares, se observa una gran cantidad de variables heterogéneas a tratar, cuya complejidad necesita de herramientas de analítica de datos robustas que se pueden adaptar a procesamientos a gran escala. Especialmente la implementación de modelos de aprendizaje automático, que permiten encontrar patrones que pueden no ser tan evidentes si se emplean los métodos de análisis tradicionales comunes de estadística que no suelen capturar interacciones complejas en numerosos datos combi nados demostrando un desempeño limitado . Por esta razón, se opta por el uso de herramientas como H2O.ai y Apache Spark para tratar relaciones no lineales y de alta dimensión entre las variables auxiliares del conjunto de datos, de forma que se pueda escalar las predicciones a diferentes condiciones sin necesidad de rediseñar los modelos desde cero, sino que pueden ser actualizados dando a lugar a una realimentación de los resultados que se vayan obteniendo. Tomando en consideración que la variable principal a predecir por los modelos será la severidad de los accidentes, se requieren soluciones que puedan almacenar y transformar toda la información disponible, para extraer patrones útiles capaces de apoyar decisiones críticas en los servicios médicos de emergencia. Por lo anterior, se vuelve relevante la apli cación de algoritmos y técnicas de ejecución que integren en conjunto los datos geoespaciales y temporales sin requerir parametrizaciones manuales o limitaciones en recursos com putacionales. V. Descripción y exploración del dataset A. Descripción general del dataset El conjunto de datos seleccionado contiene información de accidentes de tráfico abarcando 49 estados de los Estados Unidos. Los datos se han recopilado continuamente desde febrero de 2016 hasta el año 2023 utilizando varios provee dores de datos, incluidas múltiples API que proporcionan datos de eventos de tráfico en tiempo real. Estas API trans miten eventos de tráfico capturados por diversas entidades, como los departamentos de transporte de EE. UU. y estatales, las agencias de aplicación de la ley, las cámaras de tráfico y los sensores de tráfico dentro de las redes de carreteras. Actualmente, hay alrededor de 1.5 millones de registros de accidentes en este dataset con 46 columnas en donde 16 de estas son de tipo categóricas y en total ocupa 3.06GB. Para mayor comprensión, a continuación se agrupan las variables por categorías lógicas: a) Variables de Identificación y Ubicación: • ID: Identificador único del accidente. • Start_Lat, Start_Lng: Coordenadas GPS del punto inicial. • End_Lat, End_Lng: Coordenadas GPS del punto final. • Distance: Longitud del tramo afectado por el accidente. • Number, Street, Side, City, County, State, Zipcode, Country: Información de dirección. • Timezone: Zona horaria del accidente. b) Variables Temporales: • Start_Time, End_Time: Tiempos de inicio y fin del accidente. • Sunrise_Sunset: Período del día (día/noche). • Civil_Twilight, Nautical_Twilight, Astronomical_Twilight: Diferentes definiciones de crepúsculo. c) Variables Meteorológicas: • Weather_Timestamp: Momento de la observación me teorológica. • Temperature, Wind_Chill: Temperatura y sensación térmica. • Humidity, Pressure: Humedad y presión atmosférica. • Visibility: Visibilidad en millas. • Wind_Direction, Wind_Speed: Dirección y velocidad del viento. • Precipitation: Precipitación. • Weather_Condition: Condición climática general. • Airport_Code: Estación meteorológica más cercana. d) Variables de Infraestructura Vial (POI): • Amenity, Bump, Crossing, Give_Way: Elementos de la vía. • Junction, No_Exit, Railway, Roundabout: Intersec ciones y características. • Station, Stop, Traffic_Calming, Traffic_Signal, Turning_Loop: Señalización y control. e) Variable Objetivo: • Severity: Severidad del accidente (1 4), descripción de impacto en el tráfico por el accidente. B. Preprocesamiento de datos y proceso de curado Dado que el dataset original contiene un estimado de 1.5 millones de registros, se decidió trabajar con una muestra de 800,000 registros. Esta decisión se basó en consideraciones de eficiencia y prevención de posibles limitaciones en el entorno distribuido de Hadoop, donde los recursos computacionales en términos de memoria, almacenamiento y procesamiento pueden verse comprometidos en operaciones a gran escala si no se gestionan adecuadamente, adicionalmente, se quería evitar posibles problemas de rendimiento al momento de cargar un número masivo datos en componentes de hardware más restringidos. A partir de esta muestra representativa, se aplicaron las siguientes estrategias de preprocesamiento y curado utilizando PySpark: • Eliminación de columnas con altas proporciones de valores nulos: Se removieron variables como End_Lat, End_Lng, Precipitation(in), Wind_Chill(F) y Airport_Code, ya que presentaban un volumen consid erable de datos ausentes. • Relleno de valores nulos en columnas numéricas: En columnas como la velocidad del viento, visibilidad, humedad, temperatura y presión, se reemplazaron los valores vacíos por el valor medio central (mediana), lo que permitió conservar una representación balanceada de los datos sin sesgar la información. • Relleno de valores nulos en columnas categóricas: En columnas como ciudad, zona horaria, condición del clima, dirección del viento y condiciones de luz (por ejemplo, Sunrise_Sunset), los valores vacíos fueron reemplazados con la moda de cada uno, es decir, el valor que más se repite en cada caso. Esto ayuda a mantener la coherencia de las categorías. • Relleno de valores nulos en variables de tiempo: Todas las fechas se convirtieron a un formato estándar de tiempo, lo que facilitó su manejo. Luego, se calculó la mediana del tiempo (es decir, el valor central de las fechas disponibles) y se usó ese valor para rellenar los espacios vacíos. En los pocos casos donde toda la columna estaba vacía o no era posible calcular una mediana, se asignó una fecha fija por defecto. Se hizo una revisión final verificando que no quedaran datos vacíos en ninguna columna antes de continuar con los sigu ientes pasos del análisis. • Aplicación de feature engineering sobre la columna de descripción: Sobre la columna ‘Description’ se encuentra información específica para cada accidente registrado. En un primer mo mento se realiza una limpieza básica del texto eliminando los signos de puntuación y convirtiendo todas las palabras a minúsculas. Después se instancia un tokenizador que divide el texto en palabras individuales (tokens) separando por espa cios, para la cual se selecciona solo la columna de tokens y se convierte a un dataframe con un límite determinado de 10,000 registros con el objetivo de extraer nuevas características útiles para los modelos que se van a ejecutar posteriormente. Con las nuevas columnas generadas por el proceso de feature engi neering se comprueba si palabras relevantes como ‘accident’ aparecen en la lista de tokens y así mejorar las predicciones. A su vez, se realizan transformaciones de vectorización para representar la frecuencia de las palabras, cuyos resultados permiten la realización de un análisis de patrones a nivel de lenguaje natural. C. Exploración y análisis exploratorio: a) ¿Hay predominancia de algún nivel en la severidad de accidentes?: En primera instancia se desea conocer la dis tribución de la variable objetivo, en este caso la columna de severidad. Fig. 3: Relación entre condición climática y severidad de los accidentes En este mapa de calor cuyo enfoque es relacionar las condiciones climáticas con la severidad de los accidentes de tráfico. La condición “Fair” (Clima despejado o bueno) es la más frecuente en todas las categorías de severidad, espe cialmente en la severidad 2, con más de 244,000 accidentes registrados. Esto sugiere que, aunque el clima es favorable, la alta exposición vehicular también incrementa los accidentes. Otras condiciones como “Mostly Cloudy”, “Cloudy” y “Partly Cloudy” también muestran cantidades altas, principalmente en severidades 2 y 3. d) ¿La presencia de señales de tráfico reduce la severidad de accidentes?: Fig. 1: Conteo de registros por nivel de severidad del accidente Entre las observaciones claves se presenta un desbalance extremo de clases, en la cual predomina la severidad número 2 con aproximadamente más de 600.000 casos siendo mucho mayor al 50% de la muestra seleccionada. Por otro lado las severidades 1 y 4 son más raras a encontrar. Con la figura se interpreta que la mayoría de accidentes son moderados, es decir, causan retrasos en el tráfico pero no demasiado críticos. b) ¿En qué horas del día ocurren más accidentes?: Fig. 4: Impacto de las Señales de Tráfico en la Severidad de Accidentes Fig. 2: Distribución de accidentes por hora y nivel de severidad La mayor cantidad de accidentes ocurre entre las 6:00 y las 9:00 de la mañana y entre las 15:00 y las 18:00 horas. Estos picos coinciden con los horarios de mayor tráfico vehicular, sugiere una fuerte relación entre la densidad vehicular y la ocurrencia de accidentes. El máximo absoluto ocurre a las 7:00, seguido de cerca por las 16:00 y 17:00 horas. Las horas con menos accidentes son entre las 0:00 y 4:00, posiblemente por menor volumen de tráfico en esas franjas. c) ¿Cómo influye la condición climática en la severidad de los accidentes de tráfico?: La figura tiene como propósito mostrar cómo se distribuyen los accidentes de tráfico según su nivel de severidad (1 a 4) y si ocurrieron con o sin un semáforo cerca del lugar del accidente.La mayoría de los accidentes de cualquier severidad ocurre sin la presencia de un semáforo (False), especial mente en la categoría de severidad 2, con más de 500,000 casos. Cuando hay semáforos presentes (True), el número de accidentes es considerablemente menor, pero también se concentra en severidad 2. En todos los niveles de severidad, la ausencia de semáforos está asociada con una mayor cantidad de accidentes. Los accidentes más graves (severidad 4) también son más comunes en lugares sin semáforo. VI. Metodología El procesamiento de datos se realizó en un clúster univer sitario de computación distribuida compuesto por 1 nodo maestro y 2 nodos esclavos, empleando Apache Spark a través de su API PySpark. Se utilizó un entorno interactivo Jupyter Notebook para desarrollar el código PySpark, lo que facilitó la integración de comandos de Spark y la visualización de resultados intermedios. Este entorno aprovecha el paralelismo de Spark para manejar grandes volúmenes de datos de forma eficiente en memoria distribuida. En la etapa de modelado, se utilizó la plataforma H2O.ai mediante su interfaz web H2O Flow. H2O se desplegó en el entorno computacional para aprovechar también el procesamiento paralelo en la construcción de modelos de machine learning. A través de H2O Flow, fue posible configurar los algoritmos de apren dizaje automático de manera interactiva sin necesidad de escribir código adicional, manteniendo la experimentación reproducible dentro del flujo de trabajo. Las principales herramientas y librerías involucradas en todo el proceso fueron: PySpark (Spark SQL, DataFrame API), Python (para scripting en el notebook, incluyendo librerías de apoyo como Pandas para manipulación tabular local y Matplotlib/Seaborn para visualización de datos en el EDA) y H2O (implementa ciones de XGBoost distribuidas). Los módulos de PySpark utilizados incluyen la clase SparkSession para iniciar la sesión de Spark, el módulo pyspark.sql.functions (provee funciones como col, when, agregaciones, etc. para transformar datos) y métodos del DataFrame API (select, filter, groupBy, agg, withColumn, entre otros) para llevar a cabo las operaciones de limpieza y análisis de los datos. En el lado de H2O, se aprovecharon los módulos internos de H2O Flow para entre nar modelos, equivalentes a usar programáticamente clases como H2ODeepLearningEstimator y H2OXGBoostEstimator de la librería H2O, inicializando previamente el clúster de H2O (con h2o.init()) en el mismo entorno. Todo el proceso se ejecutó en un entorno Python 3.13, con Spark y H2O corriendo sobre Java en el backend del clúster para las tareas distribuidas. A. Preprocesamiento de Datos y Análisis Exploratorio Ingesta de datos: Los datos originales fueron cargados en el clúster Spark desde su fuente original (p. ej., archivos CSV del dataset) utilizando PySpark. Se creó una sesión Spark (SparkSession) y mediante métodos como spark.read.format(“csv”).option(…).load(…) se leyó el con junto de datos bruto en un DataFrame distribuido. A continuación, se llevó a cabo una inspección inicial de la estructura y calidad de los datos, utilizando funciones como df.printSchema() para verificar el esquema (tipos de cada columna) y df.show() para observar ejemplos de registros. Limpieza y transformación: Se aplicaron múltiples pasos de limpieza de datos para garantizar la calidad del dataset. Esto incluyó la eliminación de duplicados (df.dropDuplicates() en caso de registros repetidos) y el manejo de valores faltantes (df.na.drop() para descartar filas con valores nulos, o alternativamente df.na.fill() para imputar valores según el contexto apropiado). Adicionalmente, se lle varon a cabo transformaciones de tipo cuando fue necesario: por ejemplo, conversión de columnas a tipos numéricos o de fecha utilizando funciones como df.withColumn junto con pyspark.sql.functions (to_date, cast, etc.). También se crearon o modificaron columnas derivadas cuando la ingeniería de características lo requirió – por ejemplo, recodificación de categorías en valores numéricos o creación de bins/rangos para variables continuas, en caso de ser útil para el análisis posterior. Todas estas operaciones aprovecharon la API de DataFrame distribuida de Spark, asegurando que incluso con grandes volúmenes de datos las transformaciones fueran eficientes. Análisis exploratorio de datos (EDA): Con los datos ya limpios, se procedió a un análisis exploratorio para comprender las características principales del dataset y de tectar patrones relevantes. Se calcularon estadísticas descrip tivas globales usando métodos como df.describe().show() para obtener métricas como media, mediana, desviación estándar, valores mínimo y máximo de las variables numéri cas. Para variables categóricas, se utilizaron agregaciones (groupBy().count()) que permitieron conocer la frecuencia de cada categoría. Asimismo, se evaluó la distribución de la variable objetivo (clase a predecir) para identificar posibles desbalances en las clases; esto se logró extrayendo las frecuen cias de cada clase y, cuando fue necesario, visualizándolas en el notebook (por ejemplo, mediante un gráfico de barras usando Matplotlib que muestre la cantidad de ejemplos por clase). También se exploraron relaciones entre variables: en caso de variables numéricas, se calculó la correlación entre pares de atributos (utilizando funciones como corr de Spark o convirtiendo una muestra del DataFrame a Pandas para utilizar métodos de correlación y graficar heatmaps de cor relación con Seaborn). Para variables categóricas o mezclas de tipos, se hicieron tablas pivot o cruces con groupBy para ver cómo ciertas características se relacionaban con la vari able objetivo. Durante el EDA se generaron visualizaciones como histogramas, diagramas de caja (boxplots) y matrices de correlación, lo cual permitió identificar outliers (valores atípicos) y entender la distribución de los datos de forma visual. Cada visualización se obtuvo extrayendo una muestra manejable de los datos (usando df.limit().toPandas() cuando era necesario mover datos a Pandas) y empleando librerías de visualización (Matplotlib/Seaborn) dentro del notebook. Este análisis exploratorio guiado por visualizaciones y estadísticas apoyó la toma de decisiones para el modelado (por ejemplo, confirmar qué variables incluir, si era necesario normalizar alguna escala, o combinar categorías poco frecuentes). Consolidación y exportación del dataset: Tras la limpieza y el EDA, se preparó el dataset final listo para el modelado. En este paso se seleccionaron las características más rele vantes según el conocimiento obtenido (por ejemplo, descar tando columnas irrelevantes o altamente correlacionadas que podrían redundar). El DataFrame final se reparticionó o reor ganizó si era necesario (usando df.repartition() para optimizar el tamaño de las particiones) y finalmente se exportó a almacenamiento permanente. La exportación se realizó en un formato adecuado para ser leído por H2O; típicamente se empleó df.write.csv() para generar un archivo CSV limpio con los datos procesados. Este archivo final contiene todos los registros listos, con las variables en el formato requerido (numéricas y categóricas codificadas según necesidad) y sirvió como punto de entrada para la fase de entrenamiento de modelos en H2O. B. Entrenamiento de Modelos Predictivos Con el conjunto de datos preparado, la fase de modelado se llevó a cabo usando la plataforma H2O, aprovechando su capacidad de distribuir el entrenamiento en múltiples núcleos/ nodos. A través de la interfaz H2O Flow se entrenaron dos modelos de aprendizaje supervisado en paralelo para abordar la tarea de predicción: Modelo de XGBoost: En paralelo, se entrenó un modelo basado en XGBoost (eXtreme Gradient Boosting) utilizando H2O, configurado para resolver el problema como una clasi ficación multiclase (multinomial). XGBoost es un algoritmo de aprendizaje en conjunto que genera un ensamble de árboles de decisión de forma secuencial, donde cada nuevo árbol corrige los errores del ensamble anterior. Para este proyecto, se aprovechó la implementación distribuida de XGBoost pro vista por H2O, que permite entrenar el modelo eficientemente sobre el clúster. En H2O Flow se especificaron los parámetros del modelo XGBoost descritos posteriormente en la tabla, utilizando en gran medida los valores predeterminados opti mizados del framework. En particular, se utilizó la función de objetivo softmax propia de XGBoost para manejar múltiples clases, la cual optimiza la pérdida logarítmica multinomial durante el entrenamiento. A medida que los árboles se agre gaban, H2O evaluó internamente el error en el conjunto de entrenamiento y en la porción de validación para seguir el progreso. El resultado tras el entrenamiento fue un modelo de ensamble de árboles con capacidad para modelar relaciones no lineales y capturar interacciones entre variables, adecuado para predecir la clase objetivo de cada instancia con buena precisión. a) Parámetros del modelo XGBoost: El modelo XGBoost fue configurado con los parámetros que se detallan en la Tabla 1. Estos parámetros fueron ajus tados para balancear el desempeño predictivo y la eficiencia computacional durante el entrenamiento en H2O Flow. Parámetro Valor Descripción “ntrees” “92” “Número total de árboles de de cisión en el en samble.” “max_depth” “20” “Profundidad máxima permitida para cada árbol individual.” “min_rows” “5” “Cantidad mín ima de instancias necesarias en una hoja.” “distribution” “multinomial” “Tipo de distribu ción para clasi ficación clase.” “categorical coding” en multi “Enum” “Método de cod ificación de vari ables categóri cas.” “calibration method” “PlattScaling” “Método de cal ibración de las probabilidades de salida.” “histogram_type” “UniformAdap tive” “Tipo de his tograma usado para encontrar puntos de corte óptimos.” “seed” “406964802017” “Semilla para la generación pseudoaleatoria.” “model_id” “xgboost v2” “Identificador del modelo generado en H2O Flow.” “training_frame” “train_ml_ready. hex” “Conjunto de datos utilizado para el entre namiento.” Durante el proceso de entrenamiento , se llevó un registro continuo de las métricas en un conjunto de validación para revisar el desempeño. Esto permitió realizar un ajuste de hiperparámetros iterativo. C. Validación del Modelo y Métricas de Evaluación Para asegurar la validez y generalización del modelo entre nado, se implementó un riguroso procedimiento de evaluación empleando métricas de rendimiento sobre datos no utilizados en el entrenamiento. En primer lugar, se separó una porción del dataset original para usarla como conjunto de validación (un 20% de los datos). Esta divisióninterna garantizó que los modelos fuesen evaluados en instancias que no habían visto durante su ajuste de parámetros, proporcionando una medida honesta de su desempeño predictivo. Se emplearon métricas de evaluación múltiples para medir el rendimiento de los modelos en la tarea de clasificación multiclase. La métrica principal considerada fue la exactitud global (accuracy), que refleja el porcentaje de casos correctamente clasificados en el conjunto de validación. Sin embargo, dado que la exactitud por sí sola puede no reflejar plenamente el comportamiento en cada clase (especialmente porque el conjunto de datos está desbalanceado), se analizaron también métricas por clase derivadas de la matriz de confusión. En particular, para cada clase se calculó la precisión (precision, proporción de aciertos entre las predicciones positivas de esa clase) y la recuperación o sensibilidad (recall, proporción de aciertos entre los casos verdaderos de esa clase). A partir de estos valores se computó el puntaje F1 por clase (media armónica de precisión y recall), así como un F1 macro promedio para tener una visión global del desempeño equilibrado en todas las clases. Además, dado que los modelos generaban probabilidades para cada clase, se consideró la pérdida logarítmica (log loss) como métrica de rendimiento: esta métrica penaliza los errores de clasificación teniendo en cuenta la confianza de las predicciones, siendo especialmente útil en contextos multiclase para comparar la calidad probabilística de los modelos. Todas estas métricas fueron obtenidas directamente a través de las herramientas de H2O, que al finalizar el entrenamiento reporta la matriz de confusión y valores de métricas en el frame de validación. El modelo XGBoost mostró un rendimiento bueno en la mayoría de las métricas de validación (mayor exactitud y F1 general, y errores más bajos en la pérdida logarítmica), indicando una mejor capacidad para generalizar las relaciones en los datos. XGBoost fue seleccionado como el mejor modelo para el proyecto. En la etapa siguiente del proyecto (fuera del alcance de esta sección metodológica), el modelo XGBoost final sería utilizado para generar predicciones sobre nuevos datos y someter su desempeño a evaluación externa. D. Flujo general del proyecto El desarrollo del proyecto siguió un pipeline estructurado que abarcó desde la ingesta de datos brutos en un entorno distribuido hasta el entrenamiento y evaluación de modelos de clasificación multiclase en H2O Flow. La Figura X resume las etapas clave del flujo de trabajo. Fig. 5: Pipeline general del procesamiento y modelado del proyecto utilizando Spark y H2O XGBoost. VII. Resultados A. Desempeño general del modelo El modelo seleccionado fue un XGBoost multinomial, entre nado para predecir la severidad de un accidente vial a partir de múltiples variables ambientales, meteorológicas y de infraestructura. Tras el entrenamiento y validación en H2O.ai, se exportaron las predicciones sobre un conjunto de prueba, permitiendo una evaluación detallada del rendimiento del modelo. Se obtuvieron métricas clave como precisión, recall y F1 score para cada clase. La clase 2, que representa la mayoría de los accidentes registrados, mostró un desempeño sobresaliente (Precisión: 0.95, Recall: 0.99), mientras que las clases 1 y 4 presentaron un recall más bajo, lo que evidencia dificultades del modelo para identificar correctamente los casos menos frecuentes o extremos. Los valores permiten observar que el modelo tiene un buen desempeño general, aunque la capacidad de detección de accidentes severos (clase 4) aún puede mejorarse. D. Comparación visual: Precisión vs Recall La Figura 2 presenta un gráfico comparativo de precisión y recall por clase, lo cual permite visualizar rápidamente las fortalezas y debilidades del modelo en cuanto a clasificación específica. B. Matriz de confusión La Figura 1 muestra la matriz de confusión que permite ob servar el número de aciertos y errores por clase. Se evidencia que la mayoría de los errores se concentran en la confusión entre clases vecinas (por ejemplo, clase 3 mal clasificada como clase 2), mientras que la clase 2 presenta la mayor tasa de aciertos. Fig. 7: Figura 2. Comparación de precisión y recall por clase. E. Curvas ROC por clase Las curvas ROC (Figura 3) evidencian el desempeño del modelo para distinguir correctamente cada clase frente al resto (estrategia One vs Rest). Los valores del área bajo la curva (AUC) superan los 0.90 en la mayoría de las clases, destacando nuevamente la clase 2 con un AUC cercano a 0.99. Fig. 6: Figura 1. Matriz de confusión para predicciones del modelo XGBoost. C. Métricas por clase La Tabla 1 resume los valores obtenidos para precisión, recall y F1 score en cada clase de severidad: Fig. 8: Figura 3. Curvas ROC por clase (One vs Rest). Clase Precisión Recall F1 score “1” “0.81” “0.53” “0.64” F. Distribución de probabilidades “2” “0.95” “0.99” “0.97” “3” “0.93” “0.81” “0.87” “4” “0.93” “0.60” “0.73” La Figura 4 muestra la distribución de las probabilidades de predicción generadas por el modelo para cada clase. Las clases más frecuentes tienen distribuciones más concentradas, mientras que las clases minoritarias presentan mayor disper sión, lo cual se alinea con su menor recall. [3] C. R. Team, “Car accidents statistics 2025.” [Online]. Available: https:// www.consumeraffairs.com/automotive/car accident statistics.html [4] EMS, highway Safety and Post Crash care, “EMS, highway Safety and Post Crash care.” [Online]. Available: https://www.ems.gov/issues/ems highway safety and post crash care/ Fig. 9: Figura 4. Distribución de probabilidades por clase predicha. G. Discusión de resultados Los resultados obtenidos demuestran que el modelo XGBoost ofrece un alto rendimiento en la predicción de la severidad de accidentes vehiculares, especialmente para los casos más comunes. Sin embargo, la detección de eventos severos aún representa un desafío. Se sugiere implementar técnicas de balanceo de clases y ajustar los umbrales de decisión para mejorar la sensibilidad en casos críticos, optimizando así el uso de recursos por parte de los servicios de emergencia. VIII. Conclusiones Respecto al escenario de enfoque del proyecto, que se centra en un sistema de alertas de emergencia la prioridad es maxi mizar la métrica de recall para la severidad 4. De acuerdo a los resultados XGBoost multinomial, las cifras demuestran que funciona bien detectando casos moderados con severidad tipo 2 y 3, puesto que son las clases dominantes en el conjunto de datos. Sin embargo, en la clase 4 de la columna de severidad, el modelo falla en identificar el 40% de los casos que realmente generan un retraso en el tráfico, es decir solo el 60% de los casos que presentan riesgos reales para la atención de emergencias están siendo correctamente identificados. Las implicaciones de acuerdo al objetivo planteado son críticas, pues si un accidente muy grave no se identifica correctamente, la capacidad de respuesta del sistema de emergencias puede ser insuficiente y afectar gravemente a los involucrados. Como lecciones aprendidas el modelo generaliza bien las clases que contienen mayor cantidad de datos pero pierde capacidad en clases críticas, nuevamente se considera a trabajo futuro usar técnicas de resampling como estrategias directas para contrarrestar el desbalanceo de clases para penalizar más los errores en las severidades tipo 3 y 4. References [1] A. Chand, S. Jayesh, and A. Bhasi, “Road traffic accidents: An overview of data sources, analysis techniques and contributing factors,” Materi als Today Proceedings, vol. 47, pp. 5135–5141, 2021, doi: 10.1016/ j.matpr.2021.05.415. [2] M. Carlier, “Road accidents in the United States Statistics & Facts.” [Online]. Available: https://www.statista.com/topics/3708/road accidents in the us/#topicOverview
0
You can add this document to your study collection(s)
Sign in Available only to authorized usersYou can add this document to your saved list
Sign in Available only to authorized users(For complaints, use another form )