Clasificación SKU: aceptación y desconocidos

Objetivo y límites de uso

Evalúe cobertura conocida, productos nuevos y asociación física aparte, sin una única cifra favorable de precisión.

Este tutorial describe una evaluación de ingeniería, no una certificación de producto listo para funcionar. El ejemplo público actual de PC de Deyi Vision cubre un flujo EAN-13 con imágenes de muestra confirmadas. Antes de utilizar OCR o detección nativos del código de ingeniería, compruebe el entorno instalado, los modelos vinculados y el trabajo. Una plantilla de navegador no demuestra ejecución en él: el backend OpenCV.js previsto requiere verificación independiente. El reconocimiento en la nube exige aprobar expresamente las imágenes, el proveedor, el modelo y el coste. Un archivo de revisión no es un paquete ejecutable de publicación. Verifique por separado la compatibilidad de cámara, firmware y controlador. Todos los valores de la hoja son hipotéticos; no son mediciones ni resultados de clientes de Deyi Vision.

Preparar las pruebas

Congele clases, política desconocida, máscaras y catálogo con muestras independientes; simule y supervise rutas, bloqueando ejecución sin verificar. Defina el instante inicial del plazo y el acuse que demuestra finalización. Guarde colas y comunicaciones junto al procesamiento para no ocultar resultados tardíos con un algoritmo rápido. Use reloj monotónico para intervalos y documente correspondencia entre relojes de equipos. Registre colas largas, ausencias y reconexión, no solo la media. Una nueva receta no debe reinterpretar resultados pendientes: termine con la revisión registrada o aplique bloqueo acordado. Relacione salida, posición y confirmación, separando clasificación, comunicación y encaminamiento físico. Clasificar por color y reconocer SKU responde preguntas distintas. Una región puede coincidir con el rojo de referencia y pertenecer al tamaño, etiqueta o envase equivocados. Defina si se clasifica el color físico, se verifica el SKU esperado o se exigen ambos controles independientes. Use imágenes de color con orden de canales conocido y guarde exposición, balance de blancos y espectro de luz en la receta. Pruebe lotes admisibles, brillo, sombras y productos ajenos, no solo una carta limpia. Con baja saturación el tono es poco fiable; los reflejos saturados pierden información irrecuperable. Defina una ruta para artículos desconocidos, no observables y multicolor. Valide el modelo de SKU aparte del umbral cromático y apruebe previamente toda transferencia a la nube. Escriba el contrato de línea antes de conectar el veredicto al actuador. Defina identidad de adquisición, revisión de receta, estado, plazo, acuse y tratamiento de datos ausentes o tardíos. Pruebe el protocolo con salidas bloqueadas y después haga un ensayo supervisado según la aceptación de planta. Mida desde el mismo evento definido en cada ejecución; el tiempo de proceso omite colas, transferencia y retardo de salida. Un identificador de producto repetido no identifica de forma única un fotograma. Pruebe parada, reinicio, reconexión y cambio de receta con trabajos pendientes. Conserve la secuencia completa para relacionar la pieza rechazada con las pruebas que motivaron la acción.

Procedimiento

1. Cree matriz con desconocido y conserve ausentes, Review y errores.
2. Evalúe color aparte del SKU; colores iguales no prueban mismo producto.
3. Envíe evento, clase/motivo y revisión; verifique acuse y destino observado.
4. Inyecte color ambiguo, SKU nuevo, imagen ausente y demora; confirme desconocido/bloqueo sin sustituir clase cercana.

Interpretar el ensayo

Ejemplo: 20 rojos, 20 azules, 10 nuevos. Cobertura conocida 37 de 40 = 92.5%, no precisión global. Nuevos mal asignados a conocido: 2 de 10 = 20%. Mostrar esos errores descubre fallos ocultos al reportar solo rutas conocidas exitosas.

Hoja de registro

known_coverage = (18 + 19) / (20 + 20) = 37 / 40 = 92.5%
novel_wrong_known = (1 + 1) / 10 = 2 / 10 = 20%
N = 20 + 20 + 10 = 50

Dos vistas de ingeniería

Diagnóstico de fallos

• Un tablero sin desconocidos infla rendimiento.
• Clase correcta en evento o contenedor errado falla aceptación.

Aceptación y entrega

Acepte límites separados de conocidos, nuevos, contabilidad y ruta. Hoja ilustra métricas; resultado desplegado requiere muestras reales independientes y línea observada.

Conserve juntos imágenes originales, decisión esperada, revisión exacta y registro completo. Congele el conjunto de evaluación antes de elegir los parámetros finales. Si después utiliza sus respuestas para ajustar el flujo, márquelo como datos de desarrollo y obtenga otro conjunto independiente de aceptación. Mantenga Review, NoResult, error de ejecución y adquisición ausente en el denominador; no los convierta en aprobaciones filtrando filas. Guarde un fallo reproducible junto al caso satisfactorio. La entrega debe identificar quién puede cambiar la receta, cómo restaurar una revisión aprobada y qué salida del equipo seguirá bloqueada hasta la aceptación. Un resultado de software no demuestra que una pieza en movimiento haya llegado al destino correcto.