Modalis: intercambio de prototipos para DFL multimodal heterogéneo

Cuando un cliente federado carece de una de las modalidades que usan sus vecinos, compartir un modelo completo no siempre es la forma más útil de colaborar. El enfoque Modalis estudia un intercambio más específico: prototipos multimodales conscientes de la clase que transportan conocimiento de representación y permiten conservar los ejemplos y el entrenamiento local.

El método se evalúa en un escenario descentralizado con clientes conectados mediante un grafo entre pares. Está diseñado para dos dificultades simultáneas: las distribuciones de clase pueden ser non-IID y algunos clientes pueden carecer de una o varias modalidades. Por ello, el protocolo no solo debe decidir cómo combinar información, sino también cómo interpretar una vista incompleta.

De embeddings locales a prototipos compartidos

Sea $h_r(x_r)$ el embedding producido por el codificador de la modalidad $r$. Un cliente puede resumir los ejemplos de la clase $c$ mediante un prototipo:

$$p_{i,c}^{(r)} = \frac{1}{|D_{i,c}^{(r)}|} \sum_{x\in D_{i,c}^{(r)}} h_r(x).$$

El prototipo es un resumen semántico, no una copia de los datos brutos. Puede alinearse con prototipos de otros clientes y utilizarse para regularizar una representación local. Si falta una modalidad, el protocolo necesita un sustituto explícito, no fingir que un vector de ceros contiene evidencia equivalente.

Cuatro mecanismos que trabajan juntos

Embeddings contextuales nulos

Modalis representa una modalidad ausente con un placeholder contextual aprendido. El placeholder comunica que la modalidad no está disponible y ofrece a la fusión una forma de entrada estable. No se trata como una observación ni debe interpretarse como una lectura reconstruida del sensor.

Gating adaptativo

La contribución de cada modalidad se ajusta según su disponibilidad y utilidad para el ejemplo. Una abstracción sencilla es:

$$g_{i,r}=\frac{m_{i,r}\exp(a_{i,r})} {\sum_{s=1}^{R}m_{i,s}\exp(a_{i,s})+\varepsilon}, \qquad z_i=\sum_{r=1}^{R}g_{i,r}h_r(x_r).$$

Aquí $m_{i,r}$ es una máscara de presencia y $a_{i,r}$ una puntuación aprendida de relevancia. La expresión ilustra el papel de la compuerta: las modalidades ausentes no reciben peso y las disponibles pueden reforzarse o reducirse.

Fusión multimodal

La fusión lleva las representaciones disponibles a un espacio común donde pueden compararse embeddings locales y prototipos intercambiados. Esto resulta importante para la transferencia entre modalidades. Un cliente que solo dispone de imágenes puede beneficiarse del conocimiento de un vecino que también observó audio, pero la transferencia debe pasar por una representación compatible.

Objetivos de alineación

La pérdida de la tarea local se complementa con objetivos que mantienen la representación próxima a prototipos útiles de los vecinos. Una pérdida ilustrativa es:

$$\mathcal{L}=\mathcal{L}_{task} +\lambda_p\mathcal{L}_{proto} +\lambda_a\mathcal{L}_{align},$$

donde los pesos equilibran predicción local, consistencia de prototipos y alineación entre clientes. La implementación y los hiperparámetros exactos pertenecen al experimento; el principio es hacer explícito el objetivo de colaboración.

Qué significan los resultados comunicados

En los conjuntos y configuraciones de heterogeneidad evaluados, el método informa de una mejora relativa de F1 de hasta aproximadamente un 4,0% frente al mejor competidor de cada comparación. En AVMNIST, el cliente que solo dispone de imágenes alcanza un F1 del 82,1%, con una mejora relativa del 19,9% frente a FedAvg en la configuración comunicada.

Son resultados alentadores para clientes con una vista parcial, pero deben leerse con sus límites experimentales: cuatro conjuntos de referencia, 20 clientes, probabilidades controladas de modalidad ausente y un grafo de pares especificado. Muestran que transferir prototipos puede ser útil, pero no demuestran generalización zero-shot a sensores o dominios arbitrarios.

Por qué resulta interesante el diseño

La aportación no es solo un mensaje más pequeño. Cambia la unidad de colaboración, que pasa de ser un vector completo de parámetros a una representación consciente de clase y modalidad. Esa elección puede ser valiosa cuando:

• los datos locales están sesgados por clase,
• las modalidades faltan de forma asimétrica,
• intercambiar modelos completos es caro,
• un vecino necesita conocimiento semántico y no otro estado del optimizador.

También crea nuevas responsabilidades. Los prototipos pueden quedar desactualizados, mal alineados o revelar información sobre los datos de origen. Un sistema de producción necesitaría versionado, análisis de filtración, intercambio seguro y una política para clases con poco soporte.

Una interpretación prudente

El DFL multimodal basado en prototipos se entiende mejor como un puente entre aprendizaje de representaciones y coordinación descentralizada. No elimina la necesidad de agregación robusta, gestión de topología o análisis de privacidad. Ofrece un objeto compacto alrededor del cual diseñar esos mecanismos cuando los clientes ven partes diferentes de una misma tarea.

Esta nota es una síntesis original de la contribución Modalis de la tesis doctoral y de su publicación en Information Fusion. No reproduce el texto de la fuente.