Después del entrenamiento
Ahora estás cerca de desplegar tu modelo: es el momento en que conviertes “números” en un modelo que realmente funcione en tu flujo de trabajo real.
1) Encuentra los resultados del entrenamiento (weights + config + names)
Cuando termina el entrenamiento, los mensajes de registro/estado muestran dónde se escriben los resultados.
En AugeLab Studio, los resultados de entrenamiento se crean normalmente en una carpeta llamada:
XXX_config
justo al lado de tu carpeta de dataset (XXX es el nombre de la carpeta del dataset).
Estructura típica:
XXX_config/
XXX.names
XXX.cfg
backup/
XXX_last.weights (si está disponible)
XXX_best.weights (si está disponible)Como mínimo, debes conservar estos archivos juntos:
Archivo de weights:
.weights(a veces hay un archivo estilo best vs last)Archivo de configuración:
.cfgArchivo de nombres de clases:
.names
No renombres ni reordenes las clases en tu archivo .names después del entrenamiento a menos que también reasignes los IDs de etiquetas. El orden de clases debe coincidir con los IDs de etiquetas.
¿Qué weights debo usar: best vs last?
Si tu entrenamiento reporta mAP durante el proceso, muchos flujos de trabajo YOLO/Darknet mantienen un punto de control “mejor hasta ahora”.
Usa best cuando la mAP mejoró y luego bajó (overfitting).
Usa last si el entrenamiento terminó mientras la mAP aún mejoraba y estaba estable.
Si no tienes un archivo “best”, elige primero los weights finales y luego valida.
2) Valida el modelo antes de desplegarlo
Antes de integrar el modelo en la lógica de producción, haz una pasada de validación rápida.
Conjuntos de validación recomendados:
Validation set: 30–100 imágenes que representen la vida real (buena + mala iluminación, desenfoque, desorden, casos límite)
Videos cortos o imágenes: video corto de la cámara real (si vas a desplegar en una cámara fija)
Qué debes comprobar:
El modelo detecta el objeto correcto de forma consistente
Las cajas son “lo suficientemente buenas” para tu lógica (no necesariamente perfectas)
Los falsos positivos son aceptables (o pueden filtrarse)
Los casos raros pero importantes se detectan
Una mAP alta puede fallar en producción si tu split de validación fue demasiado pequeño o demasiado limpio. La comprobación con el conjunto de validación / metraje real previene eso.
3) Carga el modelo en Studio (Inferencia)
En AugeLab Studio, el siguiente paso habitual es construir (o actualizar) un escenario .pmod que ejecute la inferencia.
A) Usa “Object Detection - Custom” (recomendado)
Usa este nodo cuando quieras ejecutar tu propio modelo entrenado con YOLO/Darknet dentro de un workflow.
Flujo de trabajo:
Añade Object Detection - Custom a tu grafo (categoría AI Applications).
En la UI del bloque:
Haz clic en Open Weight File y selecciona tu
.weightsHaz clic en Open Config File y selecciona tu
.cfgHaz clic en Open Class File y selecciona tu
.names
Selecciona qué clases quieres detectar (lista con checkboxes).
Ajusta el Confidence Threshold (comienza alrededor de 0.5–0.8 y ajústalo).
Conecta una fuente de imagen a la entrada del bloque y previsualiza la imagen de salida.
Salidas que puedes usar en tu lógica:
Imagen de salida con detecciones dibujadas
Object Count
Object Locations / Sizes
Object Classes
Rectangles
Si “Object Detection - Custom” no está disponible, es posible que tu build no tenga habilitado el soporte CUDA/OpenCV DNN. Prueba el bloque CPU más abajo, o instala los módulos necesarios desde el Module Downloader (ver ai-training.md).
B) Usa “Object Detection - Custom (CPU)” (alternativa)
Usa este bloque cuando quieras el mismo workflow pero sin aceleración por GPU.
Usa inferencia por CPU, por lo que será más lento.
La configuración es la misma: weights + cfg + names.
4) Ajusta los umbrales (lo que realmente importa)
La mayoría de las mejoras de “calidad de despliegue” provienen del ajuste de umbrales, no de prolongar el entrenamiento.
Comienza con estos pasos prácticos:
Aumenta el confidence threshold si ves demasiados falsos positivos.
Reduce el confidence threshold si te faltan objetos.
Evalúa en el golden set y al menos en un clip real de cámara.
No ajustes basándote en una sola imagen. Siempre ajusta en un pequeño conjunto. De lo contrario, “sobreajustarás tu umbral” a una sola escena.
5) Empaqueta para compartir / reproducibilidad
Si quieres que el modelo sea usable más tarde (o por otra persona), empaquétalo intencionalmente.
Estructura de carpeta recomendada:
Qué incluir en el README:
En qué dataset se entrenó el modelo (versión/fecha)
Qué significan las clases (si son ambiguas)
Rango recomendado de confidence threshold
Casos de fallo conocidos (reflejos, objetos pequeños, oclusión extrema)
Si tu escenario .pmod referencia estos recursos, considera mantenerlos como recursos relativos del proyecto para que el escenario siga siendo portable. Ver también: headless-studio (comportamiento de carga de recursos faltantes).
6) Si falla en producción (qué hacer a continuación)
Cuando un modelo falla tras el despliegue, la solución suele ser una de estas (en este orden):
Recopila los fallos (guarda frames que muestren la falta/detección errónea)
Etiquétalos correctamente
Retrén o afina con los nuevos datos
Así es como los modelos se vuelven robustos.
Modos comunes de fallo y la solución más rápida
Falsos positivos por textura de fondo → añade negativos de ese entorno exacto
Faltas en objetos pequeños → aumenta el tamaño de entrada (si la GPU lo permite) y recopila más ejemplos de objetos pequeños
Faltas por reflejos/desenfoque → añade esos casos intencionalmente al dataset (no te fíes solo de la augmentación)
Las cajas son consistentemente demasiado holgadas/ajustadas → corrige la consistencia del estilo de anotación y luego reentrena
Última actualización