Mi veredicto por adelantado: cuando una IA de visión de almacén pierde precisión después del despliegue, el modelo casi nunca es el verdadero problema. El verdadero problema es todo lo que rodea al modelo: la luz, las cámaras, los datos y la forma en que lanzas las nuevas versiones.
He visto esta escena demasiadas veces. Un proveedor hace una demo en un portátil: 99% de precisión en el conjunto de entrenamiento, gráficos bonitos en un proyector, toda la sala aplaude. Dos meses después del lanzamiento, la precisión en campo ha caído a poco más del 90%, los operarios están revisando manualmente cada pedido, y el jefe quiere saber dónde se fue el dinero. El proveedor se encoge de hombros: "Sus condiciones de sitio cambiaron."
La precisión en el conjunto de entrenamiento es un examen a libro cerrado. Producción es un examen a libro abierto donde alguien no para de apagar y encender las luces.
Repasemos las causas raíz, una por una. Primera: la luz. La luz de un almacén nunca se queda quieta. Una puerta de muelle se abre y el sol pega en el transportador. El turno de noche trabaja con una iluminación distinta a la del turno de día. En otoño el sol está en otro ángulo y una estación que funcionaba bien en junio de repente se llena de reflejos. Recuerdo bien un caso publicado: un sistema de inspección visual montado en hardware Jetson Orin obtuvo 99.8% en laboratorio, y tras el despliegue los falsos positivos subieron a 15–20% — el culpable era la luz del sol entrando por una ventana, que hacía que los reflejos en las piezas metálicas parecieran defectos. Cartón, cinta, film estirable: las superficies de un almacén son espejos. Nadie escapa a esta.
Segunda: las cámaras se mueven. Una carretilla roza un soporte y el ángulo cambia unos grados. El polvo se acumula en la lente durante tres meses. La vibración del transportador emborrona la imagen. Unos grados suenan triviales, pero para un modelo que posiciona o cuenta, un ángulo nuevo es efectivamente un conjunto de datos nuevo.
Tercera: la mercancía cambia. Llegan nuevos SKU, una marca cambia el color de su caja, un logotipo se rediseña, el film estirable pasa de transparente a negro — nada de eso estaba en los datos de entrenamiento. Cuarta, y más traicionera: el preprocesamiento en producción no coincide con el de entrenamiento. El modelo se entrenó con imágenes normalizadas; un ingeniero se saltó el paso de normalización para ahorrar unos milisegundos de latencia. Un sesgo de entrenamiento-servicio (training-serving skew) como este no lanza ningún error. Solo devora tu precisión en silencio.
La quinta es una que incluso muchos equipos de algoritmos pasan por alto: las propias etiquetas derivan. El mismo equipo de control de calidad juzga "¿este arañazo cuenta como defecto?" de forma distinta en enero que en julio. El modelo está aprendiendo de un objetivo en movimiento.
Así que aquí va el resumen en una línea: el modelo no empeoró. El mundo cambió. Y la mayoría de los despliegues de visión en almacén están completamente desprevenidos para un mundo que cambia.
Versiona los modelos como versionas el slotting
Empieza con un hábito feo. En demasiados proyectos, la gestión de modelos es una carpeta que contiene model_final_v2_real_final.pth. ¿Qué conjunto de datos lo entrenó? ¿Qué hiperparámetros? ¿Cambió el preprocesamiento? Nadie puede decirlo. Algo se rompe y quieres revertir — ¿revertir a qué, exactamente?
La gestión de versiones tiene una regla no negociable: cualquier modelo que haya estado en producción debe ser totalmente reproducible. Un número de versión tiene que enlazar tres cosas: la versión del conjunto de datos, la versión del código y los hiperparámetros más las semillas aleatorias. Los datos de entrenamiento se guardan como un artefacto inmutable que nadie toca después. Si falta algún eslabón, el día que algo se rompa estarás adivinando qué eslabón cambió.
¿Cómo tomas una instantánea de un conjunto de datos sin complicarte la vida? Simple: cada entrenamiento almacena la lista de archivos más los valores hash del conjunto de entrenamiento, con las proporciones de muestreo y los métodos de aumento escritos en el registro de entrenamiento. Si alguien pregunta "¿con qué se entrenó exactamente esta versión?" y puedes responder en tres minutos, apruebas. Los equipos que no pueden responder terminan depurando con superstición.
El segundo elemento de supervivencia es la reversión (rollback). El estándar para la iteración de modelos de visión es la reversión en un clic: una mala versión nueva se sustituye por la última estable en cuestión de minutos — sin reentrenar, sin cambios de código. Si no puedes hacer esto, no hables de iteración. Mira las historias de terror donde la precisión se desplomó: a menudo el desastre no fue que la nueva versión fuera mala, fue que la nueva versión era mala y no había forma de volver atrás, así que el sitio funcionó con un modelo roto durante semanas.
Luego viene la decisión de la estrategia de despliegue, y te doy mi veredicto directamente. Tres patrones estándar de la industria: modo shadow, despliegue canary, despliegue blue-green. El modo shadow ejecuta el nuevo modelo sobre el tráfico real junto al antiguo — las salidas del nuevo modelo se registran pero nunca se actúa sobre ellas. Riesgo cero, diseñado para responder "cómo se comporta este modelo con tráfico real". El despliegue canary deja que el nuevo modelo atienda una pequeña porción del tráfico real — digamos 5% durante una semana — y luego sube por etapas como 20%, 50%, 100% si todo se mantiene, manteniendo pequeño el radio de impacto. El despliegue blue-green es un cambio instantáneo entre dos entornos completos, adecuado para momentos de "hay que cambiar sí o sí" como cambiar el modelo de cámara o rehacer el preprocesamiento.
Mi recomendación para la visión en almacén: la ruta estándar es dos semanas en modo shadow, luego una rampa canary. Nunca te saltes el shadow y vayas directo a canary — cada pedido que atiende un canary es negocio real, y una mala llamada de control de calidad es un envío equivocado. Una mala predicción en shadow es solo una línea en un log. El orden importa.
Esas dos semanas de shadow tampoco son ociosas. Observa tres números: la tasa de desacuerdo entre el modelo nuevo y el antiguo, en qué SKU se concentran los desacuerdos, y si el nuevo modelo es claramente más estable en las muestras de alta confianza. Si el desacuerdo se mantiene alto y pasas a canary de todos modos, estás volando a ciegas. Durante el canary, observa métricas de negocio, no solo técnicas: ¿bajaron las horas de revisión manual?, ¿se movió la tasa de envíos erróneos? Una mejora con buenas métricas técnicas y métricas de negocio planas no es una mejora. Es ruido.
Demasiadas alertas es lo mismo que ninguna alerta
Después del lanzamiento llega el segundo campo de batalla: el monitoreo. Muchos proyectos tocan techo el día del lanzamiento porque nadie nota cuándo el modelo empieza a pudrirse. Para cuando el equipo de operaciones siente que algo va mal, el modelo lleva dos meses degradándose.
Primero, observa las métricas correctas. La tasa de falsos positivos y la tasa de falsos negativos deben rastrearse por separado, porque queman dos tipos distintos de dinero. Los falsos positivos queman mano de obra: el modelo marca un problema que no existe, y cada pedido marcado obliga a alguien a parar y revisar. Si subes bastante la tasa de falsos positivos, los operarios empiezan a ignorar el sistema — tu inversión en IA muere al nacer. Los falsos negativos queman dinero de verdad: la mercancía defectuosa se cuela y se envía a los clientes, convirtiéndose en devoluciones y contracargos. Un panel que solo muestra la "precisión general" es autoengaño: un modelo con 95% de precisión podría ser 2.5% de falsos positivos más 2.5% de falsos negativos, o 4.5% y 0.5%. Son dos negocios completamente distintos.
También hay que distinguir cuatro tipos distintos de "roto": deriva de datos (cambiaron las entradas — iluminación, empaques nuevos), deriva de predicción (cambió la distribución de salidas del modelo), deriva de concepto (la relación entrada-respuesta en sí cambió, p. ej. se endurecieron los estándares de control de calidad), y simples errores de ingeniería (se cayó un pipeline de features). Causas distintas, remedios distintos. Recurrir a "agregar más datos y reentrenar" en cuanto la precisión baja trata la enfermedad equivocada nueve de cada diez veces — si la cámara está torcida, cien reentrenamientos no ayudarán.
Por último, la fatiga de alertas, que destaco porque es la forma más común de que estos sistemas mueran. Si pones los umbrales demasiado flojos, un modelo que se pudre no alerta a nadie. Si los pones demasiado estrictos, la persona de guardia recibe docenas de alertas al día y empieza a descartarlas en masa sin leerlas. Mi experiencia: dos niveles de alerta, ni uno más. Nivel uno: la precisión cayó por debajo de la línea base, ocúpate hoy. Nivel dos: la tendencia se está deteriorando, míralo esta semana. Cualquier esquema de alertas con más de dos niveles es efectivamente ningún esquema de alertas.
Sin grandes teorías para el final. Solo una cosa que puedes hacer mañana.
A partir de hoy, haz que el sistema guarde sus imágenes de producción, extrae 100 al día al azar, haz que un humano las revise de nuevo, y registra cuántas fueron falsos positivos y cuántas falsos negativos. Manténlo durante dos semanas. Lo que obtendrás es el activo más valioso de todo este proyecto: una curva de precisión real desde el campo. Todo lo anterior — versionado, despliegue canary, umbrales de alerta — solo funciona una vez que existe esa curva. Sin ella, cada parámetro que ajustes es una suposición.
En este negocio, el ganador nunca es el equipo con el modelo más preciso. Es el equipo que se entera primero cuando el suyo deja de ser preciso.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
