Integrare un task reale in EvoX non è mai stato difficile per la scelta di «un operatore evolutivo più potente», ma perché occorre primadefinire il contratto del task: quali oggetti possono essere modificati (spazio di ricerca), quali risultati possono essere osservati (canale di feedback) e quali cambiamenti vanno conservati (criterio di valutazione). Questi tre confini determinano insieme la validità del ciclo evolutivo, quindi vanno stabiliti prima del go-live, non esplorati gradualmente durante l'evoluzione.
1. Il confine degli oggetti modificabili: delimitare lo spazio di ricerca
Dichiarare in modo esplicito le variabili decisionali e la loro struttura (genotipo), insieme alla loro mappatura verso il prodotto reale (fenotipo), indicando al contempo i vincoli di sola lettura su ambiente, dati, interfacce e hardware. Un confine troppo ampio immette nella ricerca un gran numero di candidati non validi; un confine troppo stretto, invece, non lascia alcun margine di evoluzione. Prendiamo una pipeline di elaborazione dati: ciò che è modificabile è la scelta degli operatori, l'ordine di esecuzione e gli iperparametri, mentre la struttura dei dati di input e i vincoli di conformità fanno parte della porzione in sola lettura.
2. Il confine dei risultati osservabili: aprire il canale di feedback
Ogni candidato deve poter generare segnali catturabili dal programma. Occorre definire il canale di osservazione, la latenza, il livello di rumore e la riproducibilità. Le dimensioni non osservabili non possono fungere da criterio di ottimizzazione, ma solo da spiegazione a posteriori: inserire nella fitness ciò che non è osservabile fa sì che l'evoluzione tenda verso il rumore.
3. Criterio di valutazione e regola di conservazione: definire cosa merita di restare
Definire fitness o vettore degli obiettivi, vincoli e criteri di ammissibilità, chiarendo se comprimere tutto in un unico valore o conservare secondo il criterio paretiano multi-obiettivo, e stabilendo come penalizzare, correggere o interrompere anticipatamente i candidati falliti, andati in crash o scaduti. Una volta fissato il criterio di valutazione, si decide di fatto la direzione verso cui l'evoluzione convergerà.
4. La cadenza della valutazione: parallelismo, costi e budget
Verificare se la valutazione può essere eseguita in batch o in modo asincrono, il costo per singola valutazione e il budget totale. Il parallelismo e la latenza singola determinano direttamente la cadenza del ciclo evolutivo e il numero di generazioni sostenibili: la valutazione seriale allunga il ciclo e riduce bruscamente le generazioni sostenibili, mentre quella in batch o asincrona accelera notevolmente le iterazioni. Anche arresto e budget vanno definiti con chiarezza: specificare budget di valutazione, criteri di convergenza e condizioni di arresto previene sia il consumo illimitato di risorse di calcolo sia la terminazione prematura di soluzioni non ancora consolidate.
5. Affidabilità della valutazione: attenzione a «ottimizzare la metrica senza risolvere il problema»
Occorre guardarsi da tre tipi di rischio: disallineamento tra metriche surrogate e obiettivo reale, target leakage e sfruttamento inverso del valutatore da parte dei candidati (gonfiare il punteggio sfruttando falle nella valutazione). La contromisura consiste nel mantenere un set di validazione indipendente o una fase di revisione manuale, e nel rendere il processo di valutazione il più possibile senza stato e riproducibile, così da poter riprodurre i fallimenti e attribuire i risultati.
6. Il contratto di integrazione
Infine, incapsulare il task in un'interfaccia richiamabile da EvoX: in input un candidato, in output metriche e vincoli, garantendo che la valutazione sia il più possibile senza stato e riproducibile. Solo con un contratto stabile il ciclo resta stabile. Se si assume il punteggio sul set di training come unico criterio di conservazione, l'evoluzione si adatterà rapidamente in modo eccessivo a quella metrica: è proprio per questo che il confine della valutazione va determinato prima di quello della ricerca.
Le questioni chiave nell'integrazione di un task in EvoXL'illustrazione si sviluppa attorno ai tre confini dell'integrazione di un task in EvoX: gli oggetti modificabili delimitano lo spazio di ricerca, i risultati osservabili aprono il canale di feedback, il criterio di valutazione decide cosa merita di essere conservato, estendendosi poi a cadenza di valutazione, budget e affidabilità, per confluire infine nel contratto di integrazione composto da candidato in input, metriche e vincoli in output. Sottolinea che i confini vanno stabiliti prima degli operatori, perché sono i confini a determinare la direzione dell'evoluzione.
