Scegliere un algoritmo di federated learning (FL) è un esercizio di precisione che somiglia più a un raffinato gioco di equilibri che a una sequenza lineare. Tipo di ottimizzatore, regole di aggregazione lato server, schemi di training locale, normalizzazione, regolarizzazione, architettura del modello: ogni piccola variazione può alterare il percorso di addestramento distribuito senza mai dichiararsi apertamente. La ricerca manuale costa tempo e i confronti equi restano una chimera.

Per aggirare l’impasse, un gruppo di ricercatori ha costruito Auto-FL-Research (AFR), un workflow vincolato in cui agenti basati su LLM propongono e implementano ricette algoritmiche per FL, comprese regole di aggregazione, schedule di aggiornamento client, obiettivi locali e varianti di modello. Ogni esperimento è incapsulato in una campagna che registra metriche, runtime, file modificati, artefatti e stato di fallimento. Il banco di prova include cinque task sanitari cross-silo del benchmark FLamby e profili grouped-client sui dataset LEAF, più un task sintetico LEAF. Su quattro task FLamby e cinque profili LEAF emergono miglioramenti, ma la ripetizione su cinque semi rivela anche casi sensibili al seme e fallimenti selezionati dalla ricerca stessa.

La parte più istruttiva viene dai controlli a parità di budget: diverse performance positive dipendono da cambi effettivi nella ricetta FL, mentre altri guadagni sono recuperati da regolazioni scalari su una superficie di mutazione fissa, oppure svaniscono sotto valutazione ripetuta o su dati held-out. Gli stessi autori parlano di “outcome misti” e li considerano parte del contributo: permettono di distinguere i meccanismi FL ripetibili dalla semplice messa a punto locale e dagli artefatti legati a una singola esecuzione.

Per chi gestisce infrastrutture di federated learning on-premise, spesso in ambito sanitario o finanziario dove i dati non possono lasciare il perimetro aziendale, il segnale è duplice. Da un lato l’automazione via agenti codificatori può accorciare il ciclo di sperimentazione ed esplorare combinazioni che un team umano trascurerebbe. Dall’altro, la presenza di risultati non ripetibili e di guadagni confinati a un singolo seme suggerisce cautela: validare le ricette con più semi e su dati trattenuti è indispensabile prima di mettere in produzione qualsiasi modifica.

L’analisi dei costi non è esplicitata nella fonte, ma in un contesto on-premise il TCO beneficia di una riduzione del tempo-uomo speso in ricerca manuale degli iperparametri. Tuttavia, va messo a budget anche il costo computazionale delle campagne di agenti: l’inference dei LLM e la replicazione degli esperimenti su molteplici semi possono assorbire GPU e CPU locali, sollevando interrogativi sulla reale efficienza di questi workflow quando l’hardware è limitato.

In definitiva, Auto-FL-Research non è una bacchetta magica, ma uno strumento analitico che costringe a guardare dietro le quinte di un miglioramento dichiarato. Per le organizzazioni che distribuiscono FL su nodi proprietari, il valore sta proprio nella capacità di separare i segnali robusti dai fuochi fatui di un singolo run — un filtro che nessuna dashboard cloud è in grado di offrire.