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