MLEvolve interessa perché, se i risultati saranno confermati, potrebbe ridurre una parte del lavoro manuale necessario per progettare pipeline di machine learning competitive.
Il preprint si intitola MLEvolve: A Self-Evolving Framework for Automated Machine Learning Algorithm Discovery. È stato pubblicato su arXiv il 4 giugno 2026 da Shangheng Du, Xiangchao Yan, Jinxin Shi, Zongsheng Cao e altri autori.
La premessa è necessaria: è un preprint, quindi non è ancora passato attraverso peer review. I numeri vanno letti come risultati dichiarati dagli autori, non come verdetto definitivo della comunità scientifica.
MLEvolve e il problema degli agenti AI che dimenticano le strade già provate
MLEvolve affronta un limite pratico degli agenti AI per machine learning: spesso cercano soluzioni per tentativi separati, senza condividere davvero ciò che funziona tra una strada e l’altra. Il risultato è una ricerca costosa, ripetitiva e poco stabile quando il compito dura molte ore.
Quando un ingegnere ML lavora su una competizione o su un modello reale, non scrive una soluzione perfetta al primo colpo. Prova preprocessing diversi, cambia modelli, controlla errori, confronta metriche e conserva intuizioni utili.
Gli agenti basati su LLM provano a fare qualcosa di simile, ma incontrano tre ostacoli. Il primo è l’isolamento tra rami di ricerca: una soluzione promettente resta confinata nel suo percorso. Il secondo è la memoria debole: l’agente non riusa abbastanza bene i tentativi passati. Il terzo è la confusione tra strategia e codice: decidere cosa cambiare e scrivere come cambiarlo vengono trattati come un unico gesto.
Du e colleghi descrivono questo problema in modo diretto. Gli autori scrivono, tradotto fedelmente: “Gli agenti MLE esistenti soffrono di isolamento delle informazioni tra rami, ricerca senza memoria e mancanza di controllo gerarchico”.
Come funziona MLEvolve: una squadra AI che costruisce memoria
Il modo più chiaro per leggere MLEvolve è immaginarlo come un laboratorio con più ricercatori artificiali. Uno propone strade, uno conserva gli appunti, uno decide quando cambiare approccio e uno scrive codice in modo più o meno invasivo.
Il primo componente è Progressive MCGS, cioè una ricerca a grafo. In una ricerca ad albero classica, ogni ramo procede quasi per conto proprio. Qui, invece, i rami possono collegarsi con edge di riferimento, cioè collegamenti che permettono a una soluzione di prendere spunti da un’altra.
La metafora è quella di una mappa di sentieri. Se trovi una scorciatoia in un percorso, non devi ripartire da zero su ogni altro sentiero: puoi segnare quel passaggio sulla mappa e usarlo altrove.
Il secondo componente è Retrospective Memory. Non è una memoria generica del modello linguistico, ma una memoria costruita durante la ricerca. Conserva piani, risultati, analisi ed errori, poi li recupera quando un nuovo tentativo somiglia a qualcosa già visto.
Questo punto si collega bene al tema della stabilità dell’AI e del rischio di dimenticare. Nei sistemi che iterano per molte ore, ricordare male può essere quasi dannoso quanto non ricordare.
Dalla strategia al codice: perché MLEvolve separa cosa fare e come farlo
La terza parte del framework riguarda il rapporto tra pianificazione e scrittura del codice. MLEvolve non chiede all’agente di riscrivere tutto a ogni tentativo. Prima il planner decide cosa modificare. Poi il coder sceglie come intervenire.
Gli autori parlano di tre modalità. La prima genera codice completo da zero, utile quando non esiste ancora una base affidabile. La seconda lavora per moduli, adatta a pipeline lunghe. La terza usa modifiche mirate, simili a patch, quando una soluzione funziona ma va rifinita.
Questa separazione riduce un problema noto nei coding agent: una correzione utile può rompere parti già buone del progetto. Per chi sviluppa software, è una situazione familiare. Non sempre la scelta migliore è riscrivere tutto; spesso conviene cambiare poco, misurare, poi iterare.
Qui entra una keyword secondaria importante: automated machine learning. MLEvolve si inserisce in quella famiglia, ma si spinge oltre la scelta automatica di modelli o iperparametri. Il bersaglio è una pipeline end to end, dal trattamento dei dati fino alla previsione finale.
È la stessa direzione che rende più concreta la discussione sull’IA in azienda: non basta generare testo o codice, serve produrre risultati misurabili. Su questo punto, il confronto con l’approccio di Google Cloud all’IA orientata al valore è naturale: la metrica conta più della promessa.
I risultati dichiarati: 65,3% su MLE Bench e confronto con AlphaEvolve
La parte più forte del preprint è sperimentale. MLEvolve viene testato su MLE Bench, un benchmark introdotto da OpenAI per valutare agenti su compiti di machine learning in stile competizione Kaggle.
Gli autori dichiarano un 65,3% di average medal rate su 75 task MLE Bench, con budget di 12 ore per compito. Nel paper, questo tempo viene presentato come metà del runtime standard usato in altri confronti.
Il confronto include sistemi proprietari e open source. MLEvolve, con Gemini 3.1 Pro preview come modello di base, supera nel paper diversi agenti MLE riportati nella tabella principale. Il dato più utile da portare al lettore non è la classifica in sé, ma la combinazione tra risultato e tempo: più performance con un budget limitato, almeno nei test dichiarati.
C’è anche un secondo banco di prova: 15 task di ottimizzazione matematica collegati ad AlphaEvolve. Gli autori affermano che MLEvolve supera o eguaglia AlphaEvolve su 14 task su 15 e ottiene il miglior risultato tra i metodi confrontati in 11 task su 15.
Sono cifre rilevanti, ma vanno trattate con cautela. Un benchmark misura un ambiente specifico, con regole specifiche, modelli specifici e risorse hardware specifiche. Nel paper, ogni task usa fino a 500 espansioni, 12 ore, 21 vCPU, 234 GB di RAM e una GPU NVIDIA H200.
I limiti di MLEvolve: cosa non sappiamo ancora
Il primo limite è la dipendenza dal contesto sperimentale. MLEvolve viene valutato su benchmark noti, non su ogni possibile problema industriale. Pipeline reali possono avere dati sporchi, vincoli legali, costi cloud, limiti di privacy e metriche difficili da tradurre in una singola classifica.
Il secondo limite riguarda il modello di base. I risultati principali usano Gemini 3.1 Pro preview. Se cambi LLM, costo delle API, disponibilità del modello o capacità di function calling, il comportamento dell’agente può cambiare.
Il terzo limite è computazionale. Dodici ore con una H200 e centinaia di espansioni non sono un setup leggero. Per un laboratorio può essere accettabile. Per una piccola azienda, ogni iterazione ha un costo economico ed energetico.
Il quarto limite riguarda la fiducia nel codice generato. Anche quando una pipeline ottiene un buon punteggio, restano domande su robustezza, leggibilità, sicurezza e manutenzione. Questo punto richiama un problema più ampio: gli agenti AI non sempre rispettano vincoli esterni o regole umane non espresse bene, come accade anche nei chatbot IA alle prese con norme e istruzioni.
Cosa sapere prima di parlare di AI che scopre algoritmi
MLEvolve non dimostra che l’AI possa sostituire l’ingegnere ML. Dimostra, se i test saranno confermati, che un agente con memoria, ricerca a grafo e controllo gerarchico può cercare soluzioni in modo più disciplinato rispetto a molti approcci lineari.
La differenza è sottile ma decisiva. Non stiamo guardando una macchina che inventa dal nulla. Stiamo guardando un sistema che prova, misura, conserva tracce, confronta rami diversi e decide dove spendere calcolo.
- Repliche indipendenti su MLE Bench e altri benchmark
- Test con modelli linguistici diversi da Gemini 3.1 Pro preview
- Valutazione dei costi reali per task
- Analisi della qualità, sicurezza e manutenzione del codice prodotto
- Prove su dataset aziendali non preparati per competizioni
I prossimi step sono chiari. Servono repliche indipendenti, test con altri modelli linguistici, valutazioni di costo per task, prove su dati aziendali reali e analisi della qualità del codice prodotto. Il codice è indicato dagli autori come disponibile nel repository GitHub di MLEvolve, quindi la riproducibilità sarà un punto da osservare.
La domanda aperta è questa: un framework come MLEvolve diventerà uno strumento per accelerare i team ML, o resterà una soluzione forte solo nei benchmark? La risposta dipenderà meno dal nome del modello usato e più dalla capacità di produrre codice verificabile, economico e stabile fuori dal laboratorio.
