Luis San
Martín

St. Andrews necesitaba saber cuántos paquetes de cada formato salían de sus estaciones de empaque y cuánto tiempo se detenía la línea. El conteo lo hacía un operario a la vista, sobre una línea de 13.000 kg diarios.

Sistema multicámara para 3 estaciones: cuenta los paquetes que cruzan la línea, los clasifica por formato y registra los estancamientos de la cinta. Opera con iluminación cambiante, cámaras que se mueven y superficies mojadas. El modelo se entrena en la nube pero corre en los equipos de la propia planta, no en un servidor remoto: si se cae internet, la línea sigue contando.

Las 3 estaciones operaron en producción toda la temporada, sin intervención manual.

Contar las larvas de una muestra bajo lupa tomaba 45 minutos. De ese número dependen las decisiones de siembra, y el resultado variaba según quién hiciera el conteo y cuánto tiempo llevara mirando.

Modelo de detección que localiza y numera cada larva en una sola pasada, entrenado con un dataset capturado en la propia planta. La dificultad es la densidad: cientos de individuos superpuestos, translúcidos y del tamaño del ruido de fondo.

Prueba de concepto validada. Quedó demostrado que el conteo se puede automatizar —696 individuos en 2,93 segundos con 85% de acierto— pero no llegó a desplegarse como sistema de operación diaria, a diferencia del caso anterior.

La distribuidora operaba sobre un punto de venta cerrado, con base de datos local y sin API. La información no salía del computador del local. El dueño no podía consultar las ventas del día a distancia, el cuadre de caja se hacía a mano y los documentos tributarios se descargaban del SII uno por uno.

Mapeé el esquema del punto de venta y construí la sincronización hacia PostgreSQL en la nube: hoy hay 11.900 ventas y 40.000 líneas de producto consultables, que antes no salían del computador del mesón.

Encima, un ETL desatendido que se autentica en el SII y calcula los indicadores mensuales de impuestos: 305 facturas clasificadas sobre 87 proveedores. Y un control de calidad que cruza tres fuentes —documentos tributarios, pagos electrónicos y ventas— y emite alertas cuando no calzan: 283 hasta hoy. Por diseño no corrige ningún dato del cliente.

Dashboard en tiempo real, informe mensual y Excel de gastos categorizado, generados sin intervención. La reportería tributaria se volvió un producto aparte.

También lo opero: diagnostiqué y corregí incidentes de integridad en producción y recuperé los datos afectados.

El centro operaba sobre una plataforma comercial de pago mensual que no daba acceso a su propia base de datos. ~170 alumnos activos, con su historial de asistencia y sus planes, estaban en un sistema de terceros. Las comisiones se calculaban a mano y las reglas de negocio propias del centro no cabían en el producto arrendado.

Extraje la base completa por web scraping, la normalicé y trasladé clientes e historial sin pérdida de registros.

Diseñé el modelo de datos en PostgreSQL —multi-sede, con control de acceso por fila y migraciones versionadas— y construí el panel de administración: asistencia, ocupación, ingresos y liquidación de comisiones. Las reglas se levantaron con los dueños y los profesores antes de modelarlas.

Sistema propio sin licencia mensual a terceros, con la liquidación de 14 profesionales sobre 768 sesiones calculada automáticamente. La migración continúa sede por sede, sin interrumpir la operación.

El modelo distingue scooter, casco y sin casco. Separar el vehículo de la persona permite contar cuántos circulan y qué proporción va protegida, que es el dato que sirve para decidir, en vez de una alarma suelta.

YOLOv8 afinado durante 80 épocas a 640 píxeles. Medido contra el conjunto de prueba: mAP@50 de 85,5%, precisión 85,0% y recall 80,9%.

En la matriz de confusión, scooter acierta 0,99 y casco 0,86, pero sin casco se queda en 0,65: se confunde con el fondo. Es justo la clase que justifica el sistema, así que el trabajo pendiente no es subir el promedio sino esa clase, con más ejemplos reales de cabezas descubiertas en movimiento.

El entrenamiento se hizo en la nube y la inferencia corre en una GPU local sobre el video que entrega la placa. La placa es barata y va montada en el scooter; el cómputo queda en tierra. Es el mismo criterio de los otros casos: el modelo termina donde está el problema, no en un servidor remoto.

Sobre cada escena va dibujada su propia línea, calibrada a mano sobre la imagen real de esa cámara. Quien la cruza en un sentido suma una entrada; en el otro, una salida. Contar personas presentes en el cuadro no serviría: alguien parado frente a la góndola sumaría en cada cuadro.

El sistema toma el sub-stream H.264 de cada cámara en vez del principal en H.265 a 1080p. Aguanta mejor la red del local y para el modelo da lo mismo: la detección trabaja a 640x360. Pedir más resolución habría sumado caídas de conexión sin sumar aciertos.

Cada canal tiene su propio seguimiento multiobjeto, con una tolerancia de 45 cuadros antes de dar por perdida a una persona. Esa holgura es la que sostiene el identificador cuando alguien queda tapado detrás de una góndola y reaparece dos segundos después.

Las cámaras que necesitan inferencia se agrupan y se procesan en una sola pasada, en vez de una llamada por canal. Y si el ciclo corre más rápido que la cámara, reutiliza el resultado anterior en lugar de detectar dos veces sobre el mismo cuadro.

En cada ciclo se descartan las etiquetas de las personas que ya salieron de escena: sin eso la memoria crece indefinidamente y el sistema se cae a los días. Aparte, un hilo liviano consulta el grabador cada 30 segundos para marcar cámaras caídas sin frenar el video. La diferencia entre una demo y algo que queda corriendo está en esos dos detalles, no en el modelo.