Aprendizaje Federado

El aprendizaje federado entrena un modelo compartido sin reunir los datos: cada cliente calcula una actualización con lo que tiene en local y un servidor central coordina la agregación de esas actualizaciones. El término lo introdujeron H. Brendan McMahan y sus colegas de Google en 2016, y el estudio de referencia del campo —firmado por Peter Kairouz, el propio McMahan y varias decenas de investigadores— lo define con una frase que conviene leer despacio: encarna los principios de recogida enfocada y minimización de datos, y puede mitigar muchos de los riesgos sistémicos de privacidad del aprendizaje centralizado. Mitigar, no eliminar. Ahí empieza todo lo interesante.

El ciclo, paso a paso

Una ronda de entrenamiento federado tiene cinco fases, y saberlas cambia la conversación. El servidor selecciona clientes entre los que cumplen requisitos —un móvil suele entrar solo si está enchufado, con wifi sin coste por datos y sin que nadie lo esté usando—. Les envía el modelo actual y un programa de entrenamiento. Cada dispositivo calcula su actualización con sus propios datos. El servidor agrega lo que recibe, descartando a los rezagados en cuanto tiene suficientes respuestas. Y con ese agregado actualiza el modelo compartido, que vuelve a salir en la ronda siguiente.

La fase de agregación es la más importante y la que peor se cuenta. No es un detalle de ingeniería: es el punto donde se integran las técnicas que hacen del federado algo más que un reparto de cálculo — agregación segura, compresión con pérdida para ahorrar comunicación, y adición de ruido y recorte de actualizaciones cuando se quiere privacidad diferencial. Nada de eso viene incluido por defecto: son piezas que hay que poner, y cada una cuesta.

Qué aportó el algoritmo original

El artículo que fundó el campo —presentado en la conferencia AISTATS de 2017— proponía el promediado federado y medía dos cosas concretas. La primera: el método aguanta datos desbalanceados y no idénticamente distribuidos, que sus autores describen como el rasgo que define este escenario; el móvil de cada persona escribe cosas distintas, y eso no es ruido a corregir sino la situación de partida. La segunda: el cuello de botella es la comunicación, y su enfoque reduce las rondas necesarias entre diez y cien veces frente al descenso de gradiente estocástico sincronizado. Esa es su aportación medida, y no dice nada sobre privacidad.

De qué tamaño estamos hablando

El estudio de Kairouz da los órdenes de magnitud de un despliegue típico en móviles, y son útiles porque desmontan la imagen de «unos cuantos dispositivos colaborando». La población total va de un millón a diez mil millones de dispositivos. En cada ronda se seleccionan entre 50 y 5.000. A lo largo del entrenamiento de un solo modelo participan entre cien mil y diez millones. Hacen falta entre 500 y 10.000 rondas para converger, y el reloj marca entre uno y diez días.

Con esas cifras aparecen restricciones que no existen en un centro de datos. Los clientes son poco fiables: se espera que un 5 % o más de los seleccionados en una ronda falle o se caiga a mitad, porque el móvil deja de estar enchufado, pierde la wifi o su dueño lo coge. No tienen estado: lo normal es que un dispositivo participe una sola vez en toda la tarea, así que cada ronda trabaja con gente nueva. Y no son direccionables: el sistema no puede llamar a un cliente concreto. Todo eso obliga a diseñar el entrenamiento para que nadie note nada — el modelo que se descarga durante una ronda es efímero y no se usa para dar respuestas al usuario, precisamente porque un entrenamiento mal configurado produce predicciones malas.

Dos mundos con el mismo nombre

El mismo término cubre dos situaciones que conviene no mezclar. En el federado entre dispositivos, los clientes son millones de móviles o aparatos conectados, la comunicación suele ser el cuello de botella y el reparto de datos viene fijado por quién genera qué. En el federado entre organizaciones, los clientes son entre dos y cien entidades —hospitales, bancos, centros de datos de una misma empresa— que sí tienen identidad, sí participan en todas las rondas y pueden repartir los datos por ejemplos o por variables. Lo que ambos comparten es lo esencial: los datos permanecen descentralizados y un servidor de orquestación organiza el entrenamiento sin ver nunca los registros en bruto.

No es teoría: el estudio documenta que Google usa federado en el teclado Gboard y en funciones de sus teléfonos y de Android Messages, que Apple lo emplea desde iOS 13 en aplicaciones como el teclado predictivo y el clasificador de voz de «Hey Siri», y que hay despliegues en investigación médica y detección de palabras clave. También enumera el otro mundo: predicción de riesgo para reaseguros, descubrimiento de fármacos, minería de historiales clínicos, segmentación de imagen médica y fabricación inteligente.

Por qué «los datos no salen» no significa «es privado»

Esta es la inferencia que hay que romper, y no con opiniones sino con dos resultados publicados.

El primero mira hacia dentro. Deep Leakage from Gradients, de Ligeng Zhu, Zhijian Liu y Song Han, parte de una creencia extendida —compartir gradientes es seguro, los datos no se filtran— y muestra que es posible obtener datos privados de entrenamiento a partir de los gradientes compartidos públicamente. En sus experimentos la reconstrucción es exacta píxel a píxel en imágenes y token a token en texto. Los propios autores discuten estrategias de defensa; el mensaje no es que todo gradiente filtre, sino que compartir gradientes ya no puede darse por inocuo sin decir bajo qué condiciones.

El segundo mira hacia fuera. How To Backdoor Federated Learning, de Eugene Bagdasaryan y sus colegas, demuestra que cualquier participante puede introducir una funcionalidad oculta en el modelo global: que un clasificador de imágenes asigne la etiqueta que el atacante elija a las imágenes con cierto rasgo, o que un predictor de palabras complete determinadas frases con la palabra que el atacante quiera. La puerta trasera entra por la misma vía por la que entra el aprendizaje legítimo: una actualización enviada por un cliente.

Ninguno de los dos experimentos prueba que todo despliegue filtre o acabe envenenado. Lo que invalidan es el salto automático: «los datos no salen del dispositivo, luego el sistema es privado y confiable». Entre esas dos afirmaciones hay un modelo de amenaza que alguien tiene que escribir.

La capacidad que se lleva el lector

Ante cualquier sistema que se presente como federado —y cada vez habrá más— hay cinco preguntas que devuelven la conversación al terreno comprobable, y ninguna exige ser criptógrafo.

¿Entre dispositivos o entre organizaciones? Cambia todo: la escala, quién puede ser malicioso y qué garantías son realistas. ¿Qué sale exactamente de cada cliente? No basta con «no salen los datos»: ¿sale un gradiente en bruto, un agregado, algo con ruido añadido o con las actualizaciones recortadas? ¿Quién agrega, y puede ver las contribuciones una a una? Un servidor que ve cada actualización individual está en una posición muy distinta de uno que solo ve la suma cifrada. ¿Qué modelo de amenaza se está asumiendo? Es decir, quién se supone que puede mentir: un observador de la red, un cliente cualquiera, el propio servidor. Y ¿qué pasa con las caídas y con quién se elige? Si un 5 % o más se descuelga cada ronda y solo participan dispositivos enchufados por la noche, el modelo aprende de una muestra que no es la población.

Esa lista no depende de ninguna tecnología concreta y sobrevive a la próxima ola de productos. El aprendizaje federado es una arquitectura seria, con despliegues reales y una aportación medible en comunicación; lo que no es —y su propia literatura lo dice antes que nadie— es una garantía de privacidad que venga de fábrica. La diferencia entre las dos lecturas la marca quien pregunta qué sale, quién agrega y qué amenaza sigue abierta.