El DFL es más que aprendizaje federado sin servidor

El aprendizaje federado suele explicarse con una imagen sencilla: varios clientes entrenan localmente y envían sus actualizaciones a un servidor. Esa imagen es útil, pero no cubre todo el espacio de diseño. El aprendizaje federado descentralizado (DFL) cambia quién coordina la colaboración, cómo circula la información y dónde se concentra la confianza.

La diferencia importa en entornos donde un coordinador permanente resulta impracticable, demasiado atractivo para un atacante o incompatible con la operación del sistema. Una flota de dispositivos, un conjunto de nodos edge o varias plataformas móviles pueden necesitar aprender juntas y mantener únicamente conexiones con sus vecinos.

El servidor no es la única diferencia

En una federación centralizada, el servidor suele recibir actualizaciones, calcular una agregación y difundir el siguiente modelo. DFL reparte parte de esas responsabilidades entre los participantes. Los nodos intercambian información con sus vecinos, entrenan localmente y participan en un protocolo que debe mantener el avance hacia un modelo compartido.

Un paso local abstracto puede escribirse así:

$$\theta_i^{t+1} = \operatorname{LocalUpdate}(\theta_i^t, D_i) + \eta \sum_{j \in \mathcal{N}_i} w_{ij}^t(\theta_j^t-\theta_i^t),$$Si no ves la fórmula completa, enfócala y usa las flechas izquierda y derecha, o desliza horizontalmente.

donde $D_i$ son los datos que conserva el participante $i$, $\mathcal{N}_i$ es su vecindad actual y $w_{ij}^t$ describe la influencia de un vecino en la ronda $t$. No es una única implementación de DFL, sino un modelo explicativo. Su utilidad consiste en hacer visible una responsabilidad de diseño: aprendizaje y coordinación quedan ligados a la red.

Cuatro consecuencias de descentralizar

1. La topología pasa a formar parte del algoritmo

En un sistema basado en servidor, el patrón lógico de comunicación suele ser fácil de describir. En DFL, un anillo, una malla, un grafo aleatorio o un conjunto cambiante de vecinos pueden modificar la velocidad con la que se propaga la información y la resiliencia de la colaboración. La conectividad no es solo una cuestión de infraestructura. También afecta a la convergencia, al retraso de las actualizaciones y a la diversidad de datos que ve cada nodo.

2. La confianza se distribuye, pero no desaparece

Eliminar el servidor no convierte automáticamente en confiables a los participantes. Un protocolo descentralizado sigue necesitando decidir qué actualizaciones acepta, cómo limita la influencia de un vecino poco fiable y qué hace cuando un nodo ha sido comprometido. La agregación robusta, las señales de reputación y las políticas de conexión se convierten en componentes del protocolo.

3. Privacidad y observabilidad deben equilibrarse

Mantener los datos brutos en local reduce una exposición importante, pero los modelos, gradientes o prototipos intercambiados todavía pueden revelar información. Al mismo tiempo, un sistema de defensa necesita suficiente contexto para identificar deriva, poisoning o un enlace que está fallando. Por eso DFL exige describir qué se comparte, con quién, durante cuánto tiempo y para qué decisión.

4. La evaluación tiene varios ejes

La precisión por sí sola no basta. Una evaluación útil debería informar, como mínimo, sobre calidad del modelo, volumen de comunicación, comportamiento de convergencia, uso de recursos, sensibilidad a la topología y efecto de participantes no fiables o adversarios. Un modelo que funciona bien en un grafo estático de laboratorio puede no ser operativo cuando desaparecen enlaces o cambian las distribuciones locales.

Un modelo mental práctico

Puede ser útil separar tres capas:

1. Inteligencia local: preparación de datos, entrenamiento e inferencia permanecen cerca de su fuente.
2. Protocolo entre pares: los nodos intercambian información acotada y acuerdan cómo progresa la colaboración.
3. Guardas operativas: el sistema observa fiabilidad, límites de recursos, exposición de privacidad y vías de recuperación.

La tesis de la que parte esta serie estudia esas capas conjuntamente. Primero caracteriza el espacio de diseño de DFL. Después examina la fiabilidad en un escenario dinámico de reconocimiento aéreo y, finalmente, explora el intercambio de prototipos compactos cuando los clientes tienen modalidades heterogéneas o ausentes. El hilo conductor es que la descentralización solo resulta útil cuando protocolo de aprendizaje y contexto operativo se diseñan como un único sistema.

La pregunta adecuada

En lugar de preguntar si DFL es automáticamente mejor que el aprendizaje federado centralizado, conviene preguntar qué dependencia se quiere eliminar. Puede ser un punto único de fallo, una restricción de soberanía de datos, una conectividad intermitente, una cuestión de gobernanza o el coste de mover modelos completos. La respuesta debería determinar la topología, la representación que se comparte y el modelo de amenaza.

DFL no es un eslogan para borrar un servidor. Es un problema de coordinación diferente. Su promesa consiste en acercar el aprendizaje al entorno, mientras que su dificultad está en hacer explícitos los supuestos sobre comunicación, confianza y heterogeneidad.

Robust Decentralized Federated Learning in Heterogeneous Environments* y en sus publicaciones asociadas. No reproduce el texto de la tesis.*

Consenso no significa identidad instantánea de modelos

En una red conectada, las actualizaciones pueden tardar varias rondas en propagarse. Durante ese intervalo, los clientes mantienen parámetros diferentes. Esto puede ser compatible con el algoritmo, pero obliga a indicar qué modelo se evalúa: el de cada cliente, una media calculada para el análisis o un modelo destinado a despliegue.

La revisión de DFL organiza las decisiones arquitectónicas. El análisis de topologías cambiantes y actualizaciones locales ayuda a separar aprendizaje y mezcla bajo supuestos explícitos. La mera conectividad en una ronda no demuestra que todo el conocimiento ya haya circulado.

Una prueba para descubrir centralización oculta

Como ejercicio de diseño, enumera los servicios que intervienen en un experimento: descubrimiento, certificados, configuración, agregación, métricas y recuperación. Para cada servicio, especifica qué ocurre si deja de responder. Un dashboard central no invalida por sí solo un protocolo de agregación descentralizada, pero su caída puede impedir observarlo.

También importa quién admite nuevos participantes. Una red puede distribuir el cálculo y conservar una única autoridad de membresía. Esa decisión puede ser adecuada, siempre que no se confunda con una propiedad que el sistema no ofrece.

El artefacto útil es una tabla de dependencias y modos degradados: inferencia local disponible, colaboración suspendida, entrada de miembros bloqueada o métricas ausentes. Así la discusión sobre descentralización se convierte en una prueba concreta.

La guía de diseño DFL desarrolla el protocolo, mientras NEBULA permite plantear experimentos sobre esas dependencias.