La verdad incómoda del aprendizaje federado en almacenes: para un único centro de distribución, es tirar el dinero. Solo se justifica en una situación: cuando los datos no pueden moverse pero el modelo aún necesita aprender. Ese es el día a día de un 3PL que opera almacenes para media docena de clientes que antes cerrarían que permitir que sus datos de pedidos se mezclen.
Vi cómo se desarrollaba esto en 2023 con un 3PL en el Inland Empire de California. Cuatro almacenes, tres clientes ancla, seis meses quemados negociando un acuerdo de intercambio de datos. Ni un solo modelo entrenado. El aprendizaje federado habría hecho innecesario ese medio año. Este artículo explica qué hace realmente la tecnología, cuándo vale la pena pagar por ella y qué obstáculos encontrarás si decides seguir adelante. Sin exageraciones.
El modelo viaja. Los datos se quedan en casa.
El enfoque convencional lleva los datos de cada almacén a un lago central y entrena allí. El aprendizaje federado lo invierte: un servidor coordinador envía un modelo, cada almacén entrena ese modelo localmente con sus propios datos, y solo las actualizaciones del modelo —gradientes o pesos— regresan. El servidor promedia las actualizaciones de todos en un nuevo modelo global y el ciclo se repite. Los datos crudos nunca salen del edificio.
La idea viene de un artículo de 2017 de McMahan y colegas en Google, "Communication-Efficient Learning of Deep Networks from Decentralized Data", que introdujo el algoritmo FedAvg. El caso de uso original fue la predicción del teclado de los smartphones: nadie quiere subir todo lo que escribe, pero todos quieren un mejor autocorrector. Los almacenes tienen el mismo problema idéntico: el cliente A de un 3PL jamás permitirá que su historial de pedidos fluya a la base de datos del cliente B.
Trasladado a una operación multialmacén, cada instalación actúa como un "cliente" y la sede del 3PL o el departamento de TI corporativo hace de servidor coordinador. Los pedidos, los perfiles de SKU y las tasas de recogida se quedan en local; solo viajan los parámetros del modelo. Una nota práctica: el entrenamiento local necesita cómputo local. En muchos almacenes, el "servidor de IA" es una estación de trabajo con GPU metida en un rincón: sirve para modelos pequeños, pero cualquier cosa seria requiere hardware de borde adecuado en el sitio.
Cuándo vale la pena pagarlo — y cuándo solo estás donando a tu proveedor
Tres situaciones justifican el gasto. Primero, múltiples propietarios de datos que no pueden ponerse de acuerdo: almacenes 3PL multicliente, entidades legales separadas en distintas regiones, propietarios de marca y sus fabricantes por contrato. Cuando el cumplimiento normativo o los secretos comerciales matan el entrenamiento centralizado, el aprendizaje federado es la única forma de beneficiarse de los datos de todos los demás. Segundo, tareas idénticas con datos complementarios: todos los sitios haciendo detección de anomalías en la recogida o pronóstico de entradas, uno en temporada alta mientras otro va lento: combinados, el modelo simplemente ha visto más mundo. Tercero, datos que legalmente no pueden salir: farmacéuticos, alimentos, mercancías de alto valor, donde las regulaciones descartan el lago central antes de que empiece la conversación.
Y tres situaciones en las que debes retirarte. Primero, un único almacén con todos los datos ya en tus manos: centraliza y entrena directamente. Es más rápido y barato; el aprendizaje federado aquí es puro sobrecoste. Segundo, muy pocos datos: un sitio con unos pocos cientos de pedidos al día nunca recuperará el coste de comunicación y gestión de la federación. Tercero, sitios haciendo trabajos fundamentalmente distintos: uno pronosticando demanda, otro haciendo inspección visual de calidad. Forzarlos a un solo modelo deja a ambos peor. Los investigadores llaman a esto el problema non-IID —datos que no están independiente e idénticamente distribuidos— y lo señalaron como la debilidad número uno de FedAvg hace años. Los almacenes con mezclas de productos muy distintas se promedian en un modelo que puede rendir peor que lo que cada sitio entrenaría por separado.
La regla de decisión cabe en una frase: ¿tus datos son a la vez indispensables e inmóviles? Si sí, habla de federación. Si no, centraliza primero.
La industria farmacéutica ya demostró el concepto a escala. En 2019, diez farmacéuticas competidoras —Amgen, AstraZeneca, Novartis entre ellas— lanzaron el proyecto MELLODDY, entrenando modelos de descubrimiento de fármacos con aprendizaje federado sobre más de 2,600 millones de puntos de datos experimentales cubriendo más de 21 millones de compuestos, según el artículo publicado del proyecto. Nadie entregó sus datos. Si competidores jurados pueden lograrlo, los clientes de un 3PL en teoría también pueden —pero el consorcio tardó tres años en construir su plataforma. Mide tu propio presupuesto y paciencia contra eso.
Tres obstáculos que superar antes de empezar
Obstáculo uno: definiciones de datos. El aprendizaje federado no puede rescatar datos sucios. Reglas de codificación de SKU, definiciones de estados de pedido, zonas horarias de las marcas de tiempo: alínealas entre sitios antes de entrenar nada. El fallo más común que he visto: un modelo aprende de maravilla en el sitio A, y luego descubre en el sitio B que "recogido" y "verificado" son el mismo valor de campo. El modelo aprende basura.
Obstáculo dos: prueba en pequeño. Elige una tarea concreta —detección de anomalías en la recogida, pronóstico de volumen de entradas, cualquiera vale— y ejecútala en dos almacenes. Existen frameworks de código abierto para exactamente esto: Flower y NVIDIA FLARE son ambos de código abierto, así que puedes montar un prototipo y validar el efecto tú mismo. No compres una plataforma comercial antes de que el piloto dé resultados. Expande a la red solo cuando el piloto salga limpio.
Obstáculo tres: escribe quién decide qué. ¿Quién es dueño del modelo? ¿Con qué frecuencia se actualiza? ¿Qué pasa cuando la mala calidad de datos de un sitio arrastra al modelo global? ¿Cuál es el mecanismo de salida? Los problemas técnicos tienen solución; los problemas de personas son los difíciles. Firma primero el acuerdo.
Tres trampas más que conviene conocer de antemano. Non-IID, cubierto arriba: perfila primero las distribuciones de datos, y no lo fuerces si los sitios divergen demasiado. Comunicación y operaciones: cada ronda sincroniza modelos, así que las redes en sitio y el cómputo de borde tienen que estar a la altura, y los sitios pequeños rara vez tienen TI dedicado: decide de antemano quién responde cuando el trabajo de entrenamiento muere a las 2 a.m. Y no mitifiques la seguridad: "solo transmitimos actualizaciones del modelo" no es lo mismo que "fuga cero". Los investigadores llevan tiempo discutiendo la reconstrucción de datos de entrenamiento a partir de gradientes. Para datos realmente sensibles, añade privacidad diferencial o agregación segura en lugar de creer la promesa de "cero exposición de datos" de un folleto comercial.
Una cosa que puedes hacer mañana
No llames aún a un proveedor. Haz esto en su lugar: haz una tabla de los almacenes que federarías: volumen diario de pedidos, número de SKU, si usan el mismo WMS, si los datos pueden salir, quién es el propietario. Una vez llena esa tabla, sabrás si necesitas aprendizaje federado o solo centralizar tus datos primero. Lleva menos de una mañana, y puede ahorrarte seis meses de vueltas en falso.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
