/ Proyectos / Seguridad / Detección de violencia en video
Detección de violencia en video de vigilancia: pose estimation, ingeniería de movimiento y GRU
Cómo reutilizar un modelo de pose ya entrenado, construir features explícitas de velocidad y aceleración del movimiento, y entrenar un clasificador ligero, todo con los recursos gratuitos de Google Colab.
El objetivo era detectar comportamiento violento en video de cámaras de vigilancia, con una o varias personas en escena, sin depender de miles de horas de video propio etiquetado. El problema real: la escena específica a monitorear no se parece del todo a las escenas de los datasets públicos de violencia, y entrenar un clasificador de video desde cero exige mucho más cómputo del que ofrece el tier gratuito de Google Colab.
La solución no fue entrenar un modelo más grande, fue cambiar qué le enseñamos al modelo. En vez de mostrarle video crudo, se usó un modelo de pose ya resuelto para extraer el esqueleto de cada persona, y sobre ese esqueleto se construyeron features explícitas de movimiento. La ingeniería de características no está muerta ni siquiera en la era de los modelos preentrenados, cuando el problema es específico, a veces la mejor jugada es aprovechar lo que un modelo ya te da y construir encima con criterio propio.
Mapa del casoContenido
- Diagrama de la solución. Los bloques del pipeline, del video crudo a la predicción
- Construcción de la solución. Por qué reutilizar un modelo de pose ganó frente a entrenar desde cero
- Condiciones del proyecto. Restricciones reales y opciones descartadas antes de construir
- Pasos. Qué se dejó al agente y qué criterio se aplicó en cada uno
- Proceso de iteración. Qué confirmó el estudio de ablación y dónde se quedó corto el modelo
- Descargables. Notebook, diagrama y repositorio del proyecto
- Lecciones importantes. La lección concreta que deja este caso
Estructura de alto nivelDiagrama de la solución
Pasa el cursor sobre cada bloque para ver qué hace ese paso.
El modelo de pose nunca se reentrenó. Todo el criterio propio del proyecto vive después de ese punto, en cómo se convierten los keypoints en una señal de movimiento que sí describe si algo violento está pasando.
Cómo se construyóConstrucción de la solución
Condiciones del proyecto
| Restricción | Dato |
|---|---|
| Escena a monitorear | Cámara fija con una o varias personas, distinta al encuadre de los datasets públicos de violencia |
| Cómputo disponible | Únicamente el tier gratuito de Google Colab, sin GPU dedicada de forma permanente |
| Video propio etiquetado | Insuficiente para entrenar un clasificador de video desde cero |
| Objetivo del sistema | Señalar comportamiento violento con la mayor rapidez posible, no solo clasificar video ya grabado |
| Opción | Por qué se descartó |
|---|---|
| Entrenar un clasificador de video end to end sobre los frames crudos | Necesita mucho más dato etiquetado y cómputo del que el tier gratuito de Colab puede sostener |
| Usar un dataset abierto de violencia tal cual, sin adaptar features a la escena real | El ángulo de cámara y el contexto no coinciden, el modelo generaliza mal fuera de ese dataset |
| Clasificar directamente sobre las coordenadas crudas de los puntos clave | La posición por sí sola no describe qué tan brusco es un movimiento |
| Extraer keypoints con un modelo de pose ya entrenado y construir features explícitas de velocidad y aceleración sobre esa salida | Aprovecha un problema ya resuelto (detección y pose) y concentra el entrenamiento propio en una señal compacta y relevante |
Pasos
Convertir "clasificar video" en "clasificar una serie numérica"
Agente: propuso entrenar un clasificador de video end to end sobre los frames crudos.
Criterio aplicado: usar un modelo de pose ya entrenado para extraer los puntos clave de cada persona, y trabajar sobre esa serie numérica en vez de sobre la imagen completa, mucho más barata de entrenar con los recursos disponibles.
Mantener identidad por persona entre frames
Agente: generar keypoints frame a frame sin ligarlos entre sí.
Criterio aplicado: aplicar tracking para asignar un identificador consistente a cada persona detectada, de forma que la serie de movimiento describa a un mismo individuo a lo largo del video y no frames sueltos sin relación.
Ingeniería de features de movimiento
Agente: propuso usar las coordenadas crudas de los puntos clave como entrada directa al modelo.
Criterio aplicado: calcular los ángulos entre articulaciones y, sobre esos ángulos, la velocidad y la aceleración entre frames consecutivos. Un cambio brusco en ese flujo de movimiento es un indicador mucho más directo de un golpe o forcejeo que la postura estática, y evita que el modelo dependa de aprender patrones visuales desde el video mismo.
Suavizar antes de clasificar, y comprobarlo con un estudio de ablación
Agente: alimentar las features de ángulo directamente, sin filtrar, al modelo secuencial.
Criterio aplicado: aplicar un filtro de Kalman sobre la serie de ángulos para reducir el ruido propio de la detección de pose, y entrenar dos versiones del clasificador, con y sin ese suavizado, para comprobar con datos si de verdad aportaba antes de dejarlo fijo en el pipeline.
No conformarse con la primera configuración que funcionó
Agente: dejar los hiperparámetros del modelo GRU en los valores del primer entrenamiento razonable.
Criterio aplicado: correr una búsqueda bayesiana de hiperparámetros con Optuna, combinada con validación cruzada, sobre la variante con mejor desempeño del paso anterior.
Proceso de iteración
Ajuste documentado, no forzado
El estudio de ablación confirmó que el filtro de Kalman sí mejoraba la estabilidad del entrenamiento y el desempeño del clasificador frente a la versión sin suavizar, así que se quedó fijo en el pipeline. Aun así, al probar el modelo contra grabaciones que no formaban parte del conjunto de entrenamiento, el desempeño bajó de forma notoria. El ángulo de cámara, la resolución y el número de personas en escena cambian la distribución de las features, y ese salto de dominio no se resuelve solo ajustando hiperparámetros. Todo el entrenamiento, incluidas las variantes del estudio de ablación y la búsqueda de hiperparámetros, se corrió con los recursos gratuitos de Google Colab, con las pausas y reinicios de sesión que eso implica.
Descargables
Nota: el dataset del repositorio es sintético, generado para fines demostrativos. Replica la estructura de una serie de ángulos articulares ruidosa por segmento de video, pero no proviene de video real ni de ningún proyecto entregado a un cliente.
CierreLecciones importantes
La ingeniería de características no está muerta, aunque hoy existan modelos como YOLO capaces de resolver detección y pose de forma directa. La lección de este proyecto no fue entrenar un modelo más sofisticado, fue reconocer qué parte del problema ya venía resuelta por un modelo preentrenado y dedicar el esfuerzo propio a la parte que sí era específica de la escena: convertir esa pose en una señal de movimiento que un clasificador ligero pudiera aprender con pocos datos y poco cómputo.
La segunda lección es de honestidad metodológica: cada paso extra del pipeline, como el filtro de suavizado, se validó con un estudio de ablación en vez de asumirse por intuición. Y todo esto, entrenamiento incluido, se hizo con los recursos gratuitos de Google Colab, con las limitaciones de tiempo que eso trae, no con infraestructura dedicada.
Si quieres ver un enfoque publicado con una idea similar, esqueletos y features de movimiento en vez de video crudo para detectar violencia, este paper es una buena referencia del nivel de la contribución: Human skeletons and change detection for efficient violence detection in surveillance videos.
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