/ Proyectos / Industria / Detección de casco de seguridad
Detección de uso de casco de seguridad con YOLOv5
Detección automática de casco de seguridad en imágenes de obra con transfer learning, y cómo simplificar las clases del modelo elevó el mAP de 0.61 a 0.917.
El objetivo era detectar automáticamente si los trabajadores en una imagen de obra llevaban puesto el casco de seguridad, entrenando un modelo de detección de objetos con transfer learning sobre YOLOv5. El problema real no fue de arquitectura, fue de datos: el dataset original tenía tres clases (casco, cabeza sin casco, y persona completa), pero la clase "persona" tenía muy pocas instancias etiquetadas respecto a las otras dos.
La decisión que definió el resultado final del proyecto fue remover la clase "persona" por completo. El mAP saltó de aproximadamente 0.61 a 0.917, sin tocar la arquitectura del modelo ni los hiperparámetros de entrenamiento. La clase mal representada no solo aportaba poco, estaba arrastrando hacia abajo el promedio general de las otras dos clases que sí funcionaban bien.
Mapa del casoContenido
- Diagrama de la solución. Los bloques del pipeline, de la imagen de entrada a la detección final
- Construcción de la solución. Cómo el desbalance de clases dirigió la decisión más importante del proyecto
- Condiciones del proyecto. Restricciones reales y opciones descartadas antes de construir
- Pasos. Qué se dejó al agente y qué criterio se aplicó en cada uno
- Proceso de iteración. El límite real de cómputo que detuvo el entrenamiento
- Descargables. Notebook, diagrama y repositorio del proyecto
- Lecciones importantes. La lección concreta que deja este caso
Estructura de alto nivelDiagrama de la solución
Pasa el cursor sobre cada bloque para ver que hace ese paso.
La decisión de pasar de 3 a 2 clases se tomó antes de la fase de sintonización de hiperparámetros, porque ajustar el modelo sobre un desbalance de clases sin corregir habría optimizado la configuración equivocada.
De la teoría a la prácticaConstrucción de la solución
Condiciones del proyecto
| Restricción | Dato |
|---|---|
| Fuente del dataset | Dataset público de detección de cascos de seguridad, alojado en Roboflow |
| Clases originales | Casco, cabeza sin casco, persona completa |
| Balance de clases | La clase "persona" tenía muy pocas instancias etiquetadas frente a las otras dos |
| Cómputo disponible | GPU de Google Colab, con límites de uso continuo |
| Opción | Por qué se descartó |
|---|---|
| Mantener las 3 clases originales y ajustar hiperparámetros | El desbalance de clases seguía arrastrando el mAP promedio hacia abajo, sin importar el ajuste |
| Sobremuestrear artificialmente la clase "persona" | Con muy pocas instancias base, el sobremuestreo repite las mismas imágenes sin agregar variabilidad real |
| Remover la clase "persona" y entrenar solo con casco / sin casco | Es exactamente la información que el caso de uso necesita, sin la clase que estaba dañando el promedio |
Pasos
Manejo de la API key de Roboflow
Agente: escribió la API key directamente en el código para simplificar la descarga del dataset.
Criterio aplicado: mover la key a una variable de entorno, y agregar una validación explícita que detiene la ejecución si la variable no está definida, en vez de fallar más adelante de forma confusa.
Definición de clases del modelo
Agente: propuso entrenar con las 3 clases originales del dataset sin cuestionar el balance.
Criterio aplicado: revisar el conteo de instancias por clase antes de entrenar, y remover la clase "persona" al confirmar que estaba muy subrepresentada frente a las otras dos.
Elección del checkpoint base
Agente: sugirió entrenar desde cero para tener control total sobre los pesos.
Criterio aplicado: usar transfer learning desde `yolov5s.pt` preentrenado en COCO, porque el dataset de cascos es pequeño para entrenar una arquitectura de este tamaño desde cero con buenos resultados.
Evaluación del modelo
Agente: propuso reportar solo el mAP final como métrica de éxito.
Criterio aplicado: comparar explícitamente el mAP con y sin la clase "persona", para que la decisión de removerla quedara respaldada por un número, no solo por intuición.
Proceso de iteración
Ajuste documentado, no forzado
El entrenamiento se detuvo en 100 épocas por las limitaciones de uso continuo de GPU en Google Colab, no porque el modelo hubiera dejado de mejorar. Es probable que más épocas hubieran subido el mAP todavía más allá de 0.917. Esta es una restricción real de infraestructura, documentada explícitamente en vez de presentar el resultado final como si fuera el techo del enfoque — la diferencia entre un proyecto honesto y uno que exagera sus resultados está exactamente en admitir esto.
CierreLecciones importantes
Una clase mal representada no es neutral, activamente arrastra hacia abajo el promedio de las clases que sí funcionan bien. Simplificar el problema al mínimo necesario para el caso de uso real, en vez de mantener todas las clases "por si acaso", mejoró tanto el desempeño como la simplicidad del sistema final. Y ninguna API key debería vivir escrita directamente en un notebook, sin importar qué tan informal parezca el proyecto.
Si quieres ver un enfoque publicado con una idea similar, detección de equipo de protección personal con YOLO en entornos industriales, este artículo es una buena referencia del nivel de la contribución: Deep learning-based safety helmet detection in construction sites.
Termina ya tu proyecto
¿Tienes un proyecto similar y no sabes por dónde empezar? Yo te ayudo a diseñarlo.
El 92% de los profesionales de datos desbloquea sus proyectos al ver ejemplos completos resueltos.
Sin registro. Acceso inmediato