L'espansione dei confini dell'oggetto evolutivo: dai parametri ai programmi

L'oggetto evolutivoindica quella parte del sistema evolutivo che viene effettivamente codificata, mutata, valutata e selezionata. Gli algoritmi evolutivi classici presuppongono che questo oggetto sia semplicemente un insieme di parametri numerici; ma sulla base moderna costituita da GPU e grandi modelli, questo confine si sta spingendo verso l'esterno: dai parametri numerici agli iperparametri e all'architettura del modello, poi ai meccanismi algoritmici e agli operatori, e infine ai programmi e allo stato persistente dell'ingegneria del software.

La chiave per comprendere questa scala è tenere a mente tre cose contemporaneamente: come l'oggettoviene rappresentato, a qualivincoli è soggetto, con qualisegnali viene valutato. Ogni volta che l'oggetto sale di un livello, queste tre cose cambiano di pari passo.

1. Livello dei parametri numerici: l'oggetto è un vettore reale continuo θ \in \mathbb{R}^d, ad esempio il tasso di apprendimento, i pesi o il fattore di mutazione dell'evoluzione differenziale. I vincoli riguardano principalmente l'intervallo di valori, e la valutazione è di solito un obiettivo scalare f(θ).
2. Livello degli iperparametri e dell'architettura del modello: l'oggetto contiene scelte discrete, come il numero di livelli, la larghezza, il tipo di connessioni e le strategie di data augmentation. Lo spazio di ricerca diventa di tipo misto ed esplode rapidamente in combinazioni, e la valutazione deve prestare particolare attenzione alla capacità di generalizzazione e all'overfitting.
3. Livello dei meccanismi algoritmici e degli operatori: l'oggetto stesso è il meccanismo da eseguire, ad esempio la strategia di mutazione dell'evoluzione differenziale, il modo in cui si combinano i coefficienti di inerzia nello sciame di particelle, o la forma specifica della funzione di perdita. I candidati devono soddisfare vincoli sintattici e semantici, e la valutazione passa da «chi ha il punteggio più alto» alla robustezza, alla stabilità e ai compromessi multi-obiettivo.
4. Livello dei programmi e dello stato ingegneristico: l'oggetto diventa lo script di addestramento, la configurazione della pipeline, le dipendenze e lo stato del progetto. Un candidato è considerato valido solo se supera compilazione, test e verifica, e la valutazione si eleva a feedback a livello di sistema: quanto migliora la precisione, se il costo in risorse è accettabile e se i risultati sono riproducibili.

Perché il confine si espande verso l'esterno

Due forze spingono insieme in questa direzione. Primo, la scala della potenza di calcolo ha aperto la possibilità dell'esplorazione parallela: i cicli sequenziali un tempo scritti attorno a un singolo candidato sono stati sostituiti dalla tensorizzazione e dal parallelismo in batch, e l'intera popolazione può essere generata e valutata in un'unica operazione. Secondo, i grandi modelli sono in grado di comprendere il linguaggio naturale, il codice e il contesto di dominio, permettendo al sistema di costruire candidati dalla struttura complessa: modalità di codifica e mutazione un tempo necessariamente progettate a mano oggi possono essere generate con la partecipazione del modello.

Quando il «metodo che genera i candidati» può esso stesso essere espresso e valutato, sorge spontanea una domanda: se le soluzioni candidate possono essere evolute, anche il metodo che le genera può diventare un oggetto evolutivo? Questo è esattamente il gradino che porta da «ottimizzare le soluzioni» a «ottimizzare l'algoritmo stesso».

I segnali di valutazione devono evolvere insieme all'oggetto

A livello dei parametri, un singolo obiettivo scalare è sufficiente a guidare la ricerca, ad esempio \min f(θ). A livello dei programmi, nessun scalare può riassumere «se questo codice merita di essere conservato»: la valutazione diventa un compromesso multi-obiettivo con vincoli, che deve considerare contemporaneamente la precisione f₁, il costo di valutazione f₂ e la stabilità f₃, e, sotto i vincoli C(x) ≤ 0 , trovare un insieme di candidati mutualmente non dominati. La lista di controllo comunemente usata in ingegneria include: se la compilazione passa, se i test sono coperti, se il benchmark migliora, se il costo in risorse è accettabile e se i risultati sono riproducibili.

Fraintendimento comune: espandere non significa generare a caso

Spingere il confine dell'oggetto verso l'esterno non significa poter generare codice arbitrariamente. Più l'oggetto è libero, più i vincoli non scompaiono, ma si spostano dall'«intervallo di valori» alla «sintassi, interfacce ed eseguibilità»; e la responsabilità di verifica non si alleggerisce, ma si aggrava. I team che aprono all'evoluzione a livello di script di solito si scontrano subito con due problemi concreti: l'esplosione dello spazio di ricerca e una grande quantità di candidati «che girano ma non portano benefici» che consuma il budget di valutazione.

Pertanto l'approccio più affidabile è aprire per livelli: ampliare gradualmente l'ambito consentito di cambiamento, escludere prima i candidati palesemente inefficaci con una selezione a basso costo o con modelli surrogati, riservare poi la valutazione ad alta fedeltà a poche soluzioni promettenti, e operare un compromesso esplicito tra precisione e costo.