La investigación en federated learning (FL) suele empezar con una pregunta engañosamente simple: ¿qué probamos a continuación? Una nueva regla de agregación, un coeficiente de FedProx, una configuración del optimizador del servidor, una variante de SCAFFOLD o un ajuste de arquitectura pueden parecer prometedores antes de correr el experimento.
Cuando la corrida termina, empiezan las preguntas difíciles: ¿el cambio mejoró realmente la métrica? ¿La comparación fue justa? ¿El lift justificó el tiempo de cómputo? ¿La idea se mantiene, se acota o se descarta?
NVIDIA acaba de publicar un nuevo ejemplo de NVIDIA FLARE que muestra cómo las acciones acotadas de un agente IA, los contratos fijos de benchmark, los ledgers de experimentos, la recuperación basada en literatura y los reportes reproducibles ayudan a los investigadores de FL a evaluar más ideas en menos tiempo.
¿Qué es Auto-FL dentro de NVIDIA FLARE?
NVIDIA FLARE Auto-FL es un loop automatizado de investigación dirigido por IA que está diseñado para probar y optimizar estrategias de aprendizaje federado.
La idea es directa: arrancar desde un benchmark comparable, darle al agente un plano de control explícito, fijar un presupuesto de entrenamiento, acotar la superficie de mutación y registrar cada resultado en un ledger de experimentos. Desde ahí, el agente itera autónomamente por estrategias candidatas de FL preservando los contratos de la Client API y la Recipe API de FLARE.
En vez de entregarle al agente un problema abierto, Auto-FL parte de una simulación FL acotada con presupuesto de entrenamiento fijo y scoring consistente. Desde ese baseline compartido, el agente explora estrategias dentro de un workflow estructurado que mantiene la estabilidad del protocolo, hace las comparaciones medibles y deja trazabilidad sobre los resultados.
Un loop útil de experimentación guiado por agentes debe ser lo suficientemente acotado para no romper el contrato de FL, lo suficientemente medible para comparar ideas, lo suficientemente estable para campañas autónomas largas y lo suficientemente detallado como para convertir una campaña terminada en un reporte reproducible y con fuentes, no en una carpeta llena de logs.
La Figura 1 muestra el progreso de una campaña Auto-FL en el harness de simulación CIFAR-10 de NVIDIA FLARE. Cada punto representa una corrida candidata anotada en el ledger; los grises son corridas descartadas, los azules son candidatas activas, los verdes son corridas conservadas y la línea verde en escalera marca la mejor evaluación cross-site observada en el tiempo, con líneas púrpuras que indican eventos de revisión bibliográfica.
¿Cómo hace Auto-FL explícito el loop de investigación?
Los agentes de coding son útiles para hacer cambios complejos de código rápido. Los experimentos FL se diferencian del tuning local porque la correctitud del experimento depende de un contrato entre servidor, clientes, actualizaciones del modelo, metadata, particiones de datos y lógica de evaluación. Un candidato puede subir el score reportado y al mismo tiempo cambiar silenciosamente qué está siendo comparado, por ejemplo alterando los datos de evaluación, la capacidad del modelo, el presupuesto de comunicación, el cómputo local o la semántica de actualización servidor-cliente.
Auto-FL fuerza al loop a ser explícito. El agente arranca leyendo program.md, que funciona como plano de control. Después propone un cambio acotado, ejecuta el mismo presupuesto de benchmark, extrae un score comparable, agrega el resultado a results.tsv y usa el ledger para decidir qué corridas conservar o descartar. El humano puede interrumpir la campaña en cualquier punto y analizar el historial del experimento.
¿Qué componentes trae Auto-FL?
Auto-FL empaqueta los componentes necesarios para correr ese modelo operativo en un solo lugar. Incluye un harness experimental listo para ejecutar dentro de un task profile. Hay recipes baseline de FLARE en job.py, un loop de entrenamiento Client API en client.py, hooks de agregación FL custom y utilidades de modelo y entrenamiento, además de guardrails de mutación. El paquete suma scripts de ejecución, utilidades de plotting, templates y una skill de reporting para campañas terminadas.
Un task profile puede definir una superficie de estrategia que soporte FedAvg, actualizaciones de servidor estilo FedOpt, FedAdam, SCAFFOLD, agregación por mediana y hooks de FedProx. Auto-FL también acepta búsqueda de arquitectura acotada. Esto importa porque la búsqueda de arquitectura sin restricciones puede transformar la comparación entre algoritmos federados en una comparación descontrolada de capacidad de modelo.
Coding agente convertido en workflow experimental controlado
El cambio más importante es operacional. Auto-FL convierte el coding dirigido por agente en un workflow experimental controlado. El agente lee el plano de control, revisa la literatura, propone un candidato, muta solo la superficie permitida, corre el experimento, extrae un score, registra el resultado y decide si lo conserva, lo acota o lo descarta.
El plano de control vive en program.md. Los archivos de skill locales incluidos instruyen al agente sobre las reglas operativas. Esto deja al humano en el rol de líder de investigación, definiendo la pregunta, fijando el presupuesto, decidiendo qué mutaciones se permiten y revisando el ledger, mientras el agente IA hace el trabajo repetitivo de probar candidatos acotados y anotar resultados.
La Figura 2 muestra el loop de investigación Auto-FL con recuperación basada en literatura. El workflow arranca desde la intención investigativa, program.md, un task profile activo, un presupuesto fijo y una superficie de mutación acotada. Las corridas FLARE candidatas suman resultados a results.tsv; los lotes revisados se conservan, se acotan, se descartan o se usan para elegir el próximo candidato.
Cuando el progreso se estanca, el workflow entra a un loop de revisión bibliográfica estructurado que ejecuta búsqueda con fuentes, extrae challenge cards, filtra y puntúa proposal cards, registra un evento de literatura y devuelve propuestas seguras al contrato hacia el mismo loop experimental acotado.
¿Para qué sirve la recuperación basada en literatura?
Auto-FL guarda el desempeño en un ledger (results.tsv). Una campaña útil no debería seguir haciendo cambios locales pequeños después de que el ledger muestra que la dirección de búsqueda se estancó. Por eso se incluyó un camino de recuperación basado en literatura para ese momento.
El agente usa el ledger para resumir el mejor stack actual, los candidatos recientes, los crashes repetidos, las ideas nulas o peores y el contrato de mutación activo. Cuando la corrida parece amesetarse, el workflow pasa de los barridos locales a un loop bibliográfico con fuentes. El objetivo es dejar de adivinar, identificar qué tipo de modo de falla está enfrentando la campaña y volver con un conjunto chico de propuestas seguras al contrato.
En el loop de literatura, el agente completa una hoja de trabajo estructurada, busca métodos relevantes, extrae challenge cards, crea proposal cards, filtra duplicados e ideas previamente fallidas y puntúa propuestas contra ganancia esperada, riesgo de implementación, seguridad del contrato, evidencia, novedad y costo en tiempo de cómputo. Las propuestas elegidas vuelven al mismo loop acotado: mutar solo la superficie permitida, correr bajo el contrato de tarea fijo, extraer un score comparable y agregar el resultado al ledger.
¿Qué incluye el reporte final de Auto-FL?
Después de que un humano detiene manualmente una campaña Auto-FL, la skill de reporting se aplica sobre el branch experimental que contiene results.tsv. Genera el plot final de progreso, escribe un reporte y commitea los artefactos de reporting.
Ese reporte es el puente entre la iteración autónoma y la revisión del investigador. Resume el baseline y el mejor score, el lift absoluto y relativo, el costo en tiempo, el stack final, las notas de crashes, las ideas nulas o peores y los próximos experimentos recomendados. Dentro del loop Auto-FL, los candidatos descartados quedan visibles en el ledger commiteado, mientras que los cambios de código conservados quedan commiteados en el branch experimental. El agente y la investigadora humana pueden usar esa memoria para evitar probar de nuevo una idea de bajo valor.
¿Cómo se adapta Auto-FL a otros datasets y tareas?
Más allá de la simulación CIFAR-10 por defecto, el patrón Auto-FL es altamente adaptable. Al desacoplar el plano de control primario del task profile (que define el dataset, las métricas y las restricciones de mutación), los investigadores pueden aplicar la misma disciplina de experimentación autónoma a familias de modelos distintas sin reconstruir el harness subyacente.
Para mostrar esta flexibilidad, el ejemplo incluye una tarea con un modelo médico de lenguaje y visión (VLM). Integra un workflow de entrenamiento LoRA federado sobre Qwen3-VL en las APIs Client y Recipe de NVIDIA FLARE. El setup simula tres sitios distintos de datos médicos: VQA-RAD, SLAKE y PathVQA. El enfoque federado se concentra en adapters LoRA y usa token-F1 como métrica de evaluación.
El task profile vuelve a ser intencionalmente acotado. Fija el mapeo de sitios, la semántica de prompt y evaluación, la referencia del modelo, el rank del adapter, los límites de datos, el número de rondas, la política de seeds, los clientes de evaluación final y el cap de tiempo. Dentro de ese contrato, el agente puede explorar opciones seguras como learning rate, pasos del optimizador local, escalado del learning rate por sitio, acumulación de gradientes, regularización estilo FedProx y variantes de agregación LoRA.
Usando las mismas skills de Auto-FL y el mismo punto de entrada, el agente mejora los resultados para ese task profile específico, comparado con desempeño zero-shot y baseline. Las barras muestran token-F1 sobre cada split de evaluación. Las ganancias de Auto-FL se concentran en los sitios fuera de distribución, más duros, en vez de ser uniformes en los datasets.
Datos clave para integradores LATAM
El paquete viene bajo NVIDIA Open Model License, lo que permite uso comercial con atribución. El harness por defecto corre con 8 clientes FL simulados sobre CIFAR-10, suficiente para reproducir en un servidor con una GPU H100 o A100. Para el caso médico, las 3 sources VQA-RAD/SLAKE/PathVQA son públicas en HuggingFace, lo que hace replicable el setup en universidades chilenas y latinoamericanas que estén explorando colaboración multicéntrica en datos clínicos sin compartir registros directamente. La carga de cómputo para el LoRA federado sobre Qwen3-VL es alcanzable con clusters universitarios de 4-8 GPUs y no exige las decenas de nodos de un pretraining tradicional.
