Visión por computador con YOLOv8 en el borde

Entrenar un detector de objetos es la parte fácil. La parte difícil empieza cuando ese modelo tiene que correr lejos de tu GPU de desarrollo: en una cámara, en un dispositivo industrial, sobre una conexión que se cae. Estas son las lecciones que he ido sacando al llevar visión por computador con YOLOv8 a entornos reales sobre infraestructura.

Por qué “en el borde” cambia las reglas

En el laboratorio mides accuracy. En producción mides latencia, consumo y robustez ante lo inesperado. Procesar el vídeo en el propio dispositivo (edge) en lugar de mandarlo a un servidor central tiene ventajas claras:

• Latencia baja y predecible, porque no dependes de la red para cada frame.
• Menos ancho de banda, porque transmites eventos y metadatos, no vídeo bruto.
• Privacidad por diseño, porque la imagen puede no salir nunca del dispositivo.

El precio es que trabajas con cómputo limitado. Eso obliga a tomar decisiones que en una GPU de escritorio ni te planteas.

El modelo no es el problema (casi nunca)

YOLOv8 ofrece varias tallas, de la nano a la extra-large. La tentación es ir a por el modelo más grande “por si acaso”. En el borde, suele ser un error: un modelo más pequeño bien alimentado supera a uno grande mal alimentado.

Donde de verdad se gana o se pierde calidad es en el preprocesado y las condiciones de captura:

• Resolución y encuadre. Un objeto que ocupa pocos píxeles no lo detecta ni el mejor modelo. A veces la solución no es reentrenar: es mover la cámara.
• Iluminación. Contraluces, sombras duras y cambios de luz a lo largo del día generan más falsos negativos que cualquier limitación del modelo.
• Dominio de entrenamiento. Un modelo entrenado con imágenes limpias se hunde ante la suciedad, la lluvia o el polvo del mundo real. Si tus datos de entrenamiento no se parecen a lo que verá la cámara, las métricas mienten.

En visión por computador real, la mayoría de los “fallos del modelo” son en realidad fallos de los datos o del montaje físico.

Falsos positivos: el coste oculto

Un detector que dispara alarmas constantes es peor que no tener detector, porque entrena a los operarios a ignorarlo. Gestionar falsos positivos es tan importante como detectar de verdad:

• Umbrales de confianza por clase, no uno global.
• Persistencia temporal: confirmar una detección a lo largo de varios frames antes de dar el evento por bueno reduce el ruido de forma drástica.
• Zonas de interés: limitar la detección a la región donde el evento tiene sentido evita reaccionar a cosas que pasan por el fondo.

Estas ideas las he aplicado en sistemas de monitorización donde el vídeo alimenta paneles de control en tiempo real, como el dashboard de monitorización que construí para visualizar el estado de los sensores, y en despliegues de cámaras conectadas por 4G donde el ancho de banda es un recurso escaso y caro.

Una pauta de despliegue que me funciona

1. Empieza por el dato, no por el modelo. Recopila imágenes del entorno real antes de entrenar nada.
2. Mide latencia de extremo a extremo, no solo la inferencia: captura, preprocesado, postprocesado y entrega del evento.
3. Define qué es un falso positivo aceptable con quien va a usar el sistema. Es una decisión de negocio, no técnica.
4. Monitoriza en producción. El rendimiento se degrada con el tiempo: cámaras que se mueven, estaciones que cambian, escenas que evolucionan.

Qué me llevo

La visión por computador en el borde es un ejercicio de ingeniería de sistemas tanto como de machine learning. El modelo es un componente; el resultado depende de la cámara, la luz, la red y de cómo conviertes detecciones en decisiones útiles.

Si tienes un caso de visión por computador sobre infraestructura o procesos industriales y quieres una valoración honesta de lo que es viable, hablemos.