Cuando una organización industrial se plantea un proyecto de visión artificial, la conversación suele empezar por el modelo: qué red neuronal usar, cuánta precisión promete, si hace falta entrenar desde cero o si un modelo preentrenado es suficiente. Es una conversación legítima, pero está mal ordenada. Entrenar el modelo es, con diferencia, la parte más corta del proyecto. Lo que determina si el sistema funciona de verdad en producción pasa por decisiones que no tienen nada que ver con el algoritmo: cómo se ilumina la pieza, desde qué ángulo se mira, con qué imágenes se entrena, dónde se pone el umbral de aviso y si el operario de línea acaba confiando en lo que el sistema le dice.
Iluminación y ángulo, la decisión que se toma antes que el modelo
Un sistema de visión artificial no ve la pieza, ve lo que la cámara captura bajo unas condiciones de luz concretas. Un defecto que es evidente a simple vista puede desaparecer por completo bajo la iluminación equivocada, y un reflejo o una sombra puede generar un falso positivo constante. La iluminación (difusa, direccional, de campo oscuro, coaxial, según el material y el tipo de defecto que se busca) y el ángulo de captura se deciden antes de escribir una sola línea de entrenamiento, y rara vez se pueden resolver después con software. Cambiar de modelo es barato. Cambiar la disposición física de cámaras y luces en una línea que ya está operando, no.
Esto convierte la fase de diseño óptico en la fase que más condiciona el resultado final, y también en la que más se subestima cuando el proyecto se plantea como un problema de inteligencia artificial en lugar de como un problema de ingeniería de percepción.
El dataset propio no se sustituye
Los modelos preentrenados y los conjuntos de datos públicos sirven para arrancar, pero ninguna pieza defectuosa de un dataset abierto se parece exactamente a la pieza defectuosa que sale de una línea concreta, con su material, su acabado y sus modos de fallo específicos. Construir un dataset propio implica recoger imágenes reales en las condiciones reales de producción, incluyendo variabilidad de lote, de turno y de desgaste de la maquinaria, y etiquetarlas con criterio de quién conoce el proceso, no solo de quién entrena el modelo.
La European Machine Vision Association mantiene estándares abiertos de caracterización de cámaras y sensores para aplicaciones de visión industrial, útiles como referencia técnica a la hora de documentar qué equipo se ha usado para capturar ese dataset y en qué condiciones, algo que conviene registrar desde el primer día para poder reproducir o auditar el sistema más adelante.
El umbral de falsos positivos es una decisión de proceso, no de modelo
Todo sistema de inspección se mueve entre dos errores: dejar pasar un defecto real (falso negativo) o marcar como defectuosa una pieza que está bien (falso positivo). Bajar el umbral de detección reduce los falsos negativos pero dispara los falsos positivos, y subirlo hace lo contrario. No existe un punto que resuelva las dos cosas a la vez, y elegir ese punto no es un ajuste técnico del modelo: es una decisión sobre qué error resulta más caro para ese proceso concreto.
Esa decisión no la puede tomar en solitario quien entrena el modelo. La tiene que tomar, o al menos validar, quien conoce el coste real de una devolución, el coste de una parada de línea y el coste de que un operario deje de fiarse del sistema. Fijar el umbral antes de desplegar, con planta en la conversación, evita tener que ajustarlo después bajo la presión de las primeras quejas.
Aceptación del operario: si se apaga la alerta, el proyecto ha terminado
El fallo más silencioso de un proyecto de visión artificial no aparece en ninguna métrica de precisión. Aparece cuando el operario, harto de falsos positivos o de alertas que no aportan información útil, empieza a ignorar el sistema o directamente lo desactiva. En ese momento el proyecto ha terminado, aunque el modelo siga funcionando en el servidor y aunque las métricas de laboratorio sigan siendo buenas.
Evitarlo pasa por dos cosas que rara vez figuran en la propuesta técnica inicial: interfaces pensadas para el ritmo de la línea, con información que el operario pueda actuar en segundos y no en minutos, y un canal para que la planta reporte errores del sistema y esos errores se revisen. Un sistema de visión artificial que no incorpora ese ciclo de retroalimentación se degrada con el tiempo, aunque nadie lo haya tocado.
Más allá de la cámara
Lo que rodea a la cámara pesa tanto como la propia cámara. Las imágenes tienen que llegar por una red de planta que comparte cables y accesos con el resto de sistemas, y el modelo tiene que decidir dentro del ciclo de la máquina, lo que obliga a pensar con tiempo dónde se ejecuta cuando no puede esperar a la nube. La visión artificial no falla por el algoritmo, falla por las condiciones físicas y organizativas en las que se le pide trabajar, y esas condiciones se diseñan, no se improvisan.
