Prueba retrospectiva de receta

Recipe Backtesting te permite reproducir un conjunto curado de imágenes a través de la receta activa y obtener un informe objetivo de su desempeño, imagen por imagen. Ejecuta la receta completa, cada modelo, cada regla de Node-RED, cada umbral de pass/fail, de modo que la salida refleje exactamente lo que la producción habría hecho.

Piénselo como una suite de pruebas de regresión para su receta de visión.

Why this matters

Antes de Backtesting, la única forma de verificar un cambio en la receta era esperar a que llegaran nuevas piezas a la línea. Con Backtesting, mantiene una biblioteca permanente de capturas difíciles, ejecuta la nueva receta contra todas ellas en segundos y compara la corrida anterior con la nueva corrida lado a lado. La aceptación por parte del cliente se convierte en una conversación objetiva, no en una corazonada.

Objetivos de aprendizaje

Al final de esta guía usted podrá:

• Construir un test set de imágenes representativas con ground truth de pass/fail
• Ejecutar un backtest contra la receta activa y leer la matriz de confusión
• Profundizar en escapes and overkills para diagnosticar qué salió mal
• Agrupar los resultados de rendimiento por etiqueta, línea de producción o semana de captura para detectar deriva del modelo
• Disparar ejecuciones de backtest vía HTTP para automatización programada o estilo CI

Conceptos centrales

Backtesting de Recetas tiene dos bloques de construcción. Están detrás de la entrada Recipe Backtesting en la navegación de la izquierda.

Concepto	Qué es
Test Set	Un conjunto reutilizable de JPEGs además de sus etiquetas de ground truth. Los Test Sets son independientes de cualquier receta específica, el mismo conjunto de pruebas puede ejecutarse contra diferentes recetas o diferentes versiones de la misma receta. Los Test Sets pueden ser importados, exportados y compartidos entre cámaras.
Backtest Run	Un instantáneo en el tiempo de un conjunto de pruebas ejecutado contra la receta activa actualmente. Las corridas son inmutables; volver a etiquetar el conjunto de pruebas después no cambia los resultados de una corrida anterior.

Crear un conjunto de pruebas

Desde la navegación de la izquierda, abra Recipe Backtesting → Test Sets, luego haga clic en Create Test Set. Déle un nombre y una descripción; la descripción se vuelve buscable y se muestra en el informe de ejecución.

Una vez creado, el conjunto de pruebas se abre en el editor sin imágenes todavía. La barra de encabezado tiene las acciones clave: Agregar Imágenes, Importar desde Biblioteca (en el desplegable junto a Agregar Imágenes), Exportar, y Iniciar Backtest (deshabilitado hasta que el conjunto tenga imágenes).

Agregar imágenes

Dos formas de poblar un conjunto de pruebas:

1. Haga clic o arrastre imágenes JPEG al área de subida. Solo se aceptan JPEG, y cada imagen debe coincidir exactamente con la resolución de captura de la cámara.
2. Importar desde Biblioteca, la opción más rápida para cámaras de producción. Esto toma capturas previas directamente de la cámara con todos sus metadatos incrustados intactos (hora de captura, ID de disparo, pass/fail original, etiquetas, objetivo de inspección).

El cuadro de diálogo Import from Library le permite filtrar por número de captura, ID de disparo, rango de fechas de captura (atajos 5m / 30m / 1h / 12h / 1d), notas, nombre de receta, pass/fail, y un panel de Filtros Avanzados para objetivo de inspección / región / área de búsqueda. El interruptor Include Trainset Images está activado por defecto. El interruptor Alignment Fails Only es útil cuando está verificando específicamente una corrección del alineador.

Las capturas de producción llevan su historial

Las imágenes traídas desde la Biblioteca conservan el número de serie de la cámara, la hora de captura original, la versión de la receta que las produjo y los full JSON metadata del resultado de producción original. Eso significa que puedes reutilizar el pass/fail original como ground truth en lugar de volver a etiquetarlas desde cero. También puedes corregirlo si los estándares han cambiado desde entonces.

Después de la importación, el editor muestra las imágenes con un resumen rápido (conteo de imágenes, conteo de ground-truth, tamaño total) y un desglose de Test Set Distribution por semana de captura y nombre del sistema.

Etiquetado de Ground Truth

Ground Truth es el real veredicto de Pass/Fail para cada imagen, lo que usted, el operador, cree que el resultado debería haber sido. Ground Truth es lo que hace posibles las cifras de precisión, escape y overkill.

Haga clic en una imagen para abrir el Visor de Imágenes. Si la imagen se importó desde una captura de producción, las áreas de búsqueda originales y el resultado Pass/Fail ya están disponibles y puede reutilizarlas o corregirlas. Si la imagen no tiene metadatos embebidos (p. ej., una exportación antigua, una carga manual), haga clic en Set Up Labeling para vincular la imagen a las áreas de búsqueda de la receta actualmente activa.

Una vez que la imagen está vinculada, cada área de búsqueda obtiene su propio Pass / Fail / Unknown. Deje una área de búsqueda en Unknown si no está seguro; esas filas se excluyen del cálculo de precisión, pero siguen contribuyendo al rendimiento general.

Cada área de búsqueda está etiquetada de forma independiente

Si su receta tiene tres áreas de búsqueda en una pieza, cada imagen en el conjunto de pruebas necesita tres etiquetas de Ground Truth, una por área. Las estadísticas en el lado derecho distinguen Images (conteo de capturas) de Ground Truth Labels (conteo de áreas de búsqueda etiquetadas).

También puede asignar a cada imagen una descripción (qué es interesante de esta captura) y etiquetas (número de línea, shift, tipo de defecto, lo que sea). Las etiquetas son buscables en el informe de ejecución y pueden agrupar el desglose del rendimiento.

Inicio de una ejecución de Backtest

Una vez que el conjunto de pruebas tenga al menos una imagen, haga clic en Start Backtest. Déle un nombre a la ejecución. La cámara will:

1. Pausar cualquier inspección activa, los disparadores entrantes se ignorarán durante la duración de la ejecución.
2. Recorrer cada imagen en el conjunto de pruebas.
3. Ejecutar la entera receta activa para cada imagen, incluyendo cada nodo de Node-RED, cada regla de pass/fail y cualquier actuación o integración de I/O que la receta normalmente conduciría en producción.
4. Almacenar cada resultado de nuevo en la Library y Haystack, exactamente como si se tratara de una captura de producción.

Los backtests disparan las mismas E/S que la producción

Debido a que la ejecución realiza la receta completa, cada nodo de salida de Node-RED se dispara, se realizan escrituras Modbus, se publican mensajes MQTT y se realizan llamadas HTTP. No ejecute backtests en una cámara conectada a una línea de producción en vivo a menos que esté preparado para esos efectos secundarios. Idealmente, ejecute backtests en una segunda cámara dedicada a la validación.

Leer el informe de ejecución

Las ejecuciones son permanentes. Abra Recipe Backtesting → Backtest Runs para ver cada ejecución histórica, filtrar por conjunto de pruebas y abrir cualquiera de ellas.

El informe de ejecución tiene tres partes: la matriz de confusión, el informe de rendimiento y un desglose por imagen.

Matriz de confusión

	Ground Truth: Pass	Ground Truth: Fail
Recipe: Pass	True Positive	Escape
Recipe: Fail	Overkill	Correct Reject

• True Positive, la receta y Ground Truth coinciden en un Pass. Esto es lo que quieres.
• Correct Reject, la receta y Ground Truth coinciden en un Fail. Esto es lo que quieres.
• Escape, la receta dijo Pass, pero la imagen era defectuosa. Este suele ser el peor modo de fallo, significa que una pieza defectuosa salió de la línea.
• Overkill, la receta dijo Fail, pero la imagen era buena. Esto es false-rejection: la línea está descartando piezas buenas.

Haga clic en cualquier celda para filtrar la lista de imágenes para esas capturas, luego haga clic en una imagen para ir a su entrada en Library con la traza completa de Haystack.

Escapes y overkills son ambos síntomas, la solución es diferente

Escapes normalmente significan que el modelo pasó por alto un defecto, o un umbral de Node-RED es demasiado permisivo. Overkills normalmente significan que un umbral es demasiado estricto, o que el conjunto de entrenamiento está sesgado hacia positivos difíciles. La matriz de confusión le indica qué fallo es dominante; corrígalo primero.

Rendimiento y tiempo de ciclo

La cabecera de ejecución muestra el rendimiento global (total de pases / total de capturas) y el tiempo de ciclo promedio, medido como la duración total de la ejecución dividida por la cantidad de imágenes. Esta es la estimación de tiempo de ciclo más precisa que puede generar la cámara, ya que ejecuta el mismo flujo de Node-RED que la producción usaría.

Desglose de rendimiento por tag o sistema

La vista Yield Report → Advanced Distribution agrupa el rendimiento por tag o por sistema (línea de producción). Así es como se detectan dos tipos de problemas que el número total oculta:

• Sesgo de línea, la línea 37 muestra un rendimiento del 98%, la línea 59 muestra un 40%. Es probable que su conjunto de entrenamiento esté sobremuestreado en la línea 37.
• Deriva del modelo, el rendimiento es correcto en capturas de hace 2 meses pero cae en capturas de esta semana. Las piezas se han desplazado, o la iluminación ha cambiado, y la receta necesita una actualización.

Filtrado, etiquetado y exportación

Las etiquetas y descripciones le permiten segmentar el informe de ejecución de maneras prácticas:

• Filtrar por line-37 para confirmar una corrección antes de implementarla en las otras líneas
• Filtrar por defect:crack para verificar que un modo de fallo específico ya se detecta
• Filtrar por la semana de captura para ver cómo se desempeña la receta con piezas recientes frente al conjunto dorado

El informe completo de ejecución puede exportarse como un PDF para compartir con los clientes, muy útil en reuniones de aprobación donde los números objetivos superan las comparaciones de capturas lado a lado.

Automatizar con HTTP

Cada acción en Recipe Backtesting está disponible a través de la API HTTP de la cámara. Patrones de automatización comunes:

• Node-RED interval trigger, en un horario semanal, Node-RED añade las capturas de producción de los últimos 7 días a un conjunto de pruebas continuo y lanza una ejecución. Si el rendimiento cae por debajo de un umbral, genera una alerta.
• CI gate, antes de que una versión de la receta pueda desplegarse a través del endpoint de importación, un script dispara una ejecución de backtest y bloquea el despliegue si la precisión retrocede por debajo de la versión anterior.
• PLC trigger, el PLC puede activar una entrada digital en un ID específico; Node-RED la captura y inicia un backtest. El PLC lee el resultado pass/fail de vuelta a través de Modbus o Ethernet/IP una vez que la corrida termina.

Consulte la sección API Reference de la Swagger UI de la cámara en http://CAMERA_IP/edge/v2/docs para el endpoint POST /backtest_sets/{id}/runs y los endpoints CRUD relacionados para conjuntos de pruebas. Reemplace CAMERA_IP con la IP real de su cámara.

Construcción de un buen conjunto de pruebas

La diferencia entre un conjunto de pruebas que detecta regresiones reales y uno que le da una confianza falsa se reduce al equilibrio.

• Balance pass/fail, apunte a contar aproximadamente igual cantidad de muestras buenas y malas. Un conjunto que tenga ~95% de pases hará que cada receta parezca excelente.
• Cobertura de defectos, cada modo de fallo al que el cliente le presta atención necesita al menos unos cuantos ejemplos. Si nunca ha visto un defecto dado en el conjunto de pruebas, no tiene evidencia de que la receta lo detecte.
• Balance temporal, recoja capturas a lo largo de semanas o meses, no solo de hoy. Las líneas de producción pueden sufrir deriva (cambia la iluminación, cambian los proveedores de piezas) y su conjunto de pruebas debe representar esa deriva.
• Balance por línea, si la receta se ejecuta en 50 líneas de producción, el conjunto de pruebas debe incluir capturas de cada una de esas líneas, no solo de la que está en su banco de pruebas.
• Casos límite, las capturas difíciles que apenas pasan o apenas fallan son donde el reentrenamiento ofrece ganancias reales. Incluya esas muestras en el conjunto de pruebas.
• Volumen, 10 imágenes es suficiente para una prueba de humo de un cambio; 100+ es suficiente para hacer afirmaciones de precisión estadísticamente significativas.

Varias pruebas para criterios en evolución

Si el cliente cambia sus criterios de aprobación, actualmente debe volver a etiquetar las imágenes una por una. Una solución práctica: mantenga un conjunto de pruebas estable con el que todos estén de acuerdo y un segundo conjunto de pruebas actual que siga los criterios en evolución. Cuando los criterios actuales se asienten, pueden integrarse de nuevo al conjunto estable.

Qué prueba hoy y qué no prueba

Backtesting se ejecuta a nivel de receta completa y evalúa la salida final agregada de aprobado/reprobado. Esto significa:

• Funciona para, recetas de Clasificación, Segmentación, Medición y OCR. Cualquier cosa que fluya a través de Node-RED hacia un único resultado de aprobado o reprobado es verificable.
• Hoja de ruta, el backtesting a nivel de modelo está en camino. En futuras versiones podrás etiquetar ground truth a nivel de ROI y comparar directamente la salida del segmenter o classifier, sin depender de los umbrales de Node-RED. Las salidas numéricas (p. ej., distancias de medición, clasificación multi-clase) recibirán métricas dedicadas más allá de aprobado/no aprobado.

Artículos Relacionados

• Waterfall Principle
• Improving Models
• Node-RED Basics