Nella baseaperta e disaccoppiata di EvoX, un intero flusso evolutivo viene scomposto in due «mattoni» intercambiabili:il modulo algoritmorisponde a «come cercare»,il modulo problemarisponde a «cosa valutare e come l'ambiente fornisce il feedback». I due si collegano tramite un insieme chiaro di contratti di interfaccia, componendo flussi evolutivi riutilizzabili, sostituibili e trasferibili.
Modulo algoritmo: incapsula il «come cercare»
- Generazione delle soluzioni candidate e aggiornamento della popolazione: la logica evolutiva come inizializzazione, mutazione, crossover, selezione ed elitismo è implementata in modo unitario dal modulo algoritmo.
- Controllo della ricerca: numero di iterazioni, dimensione della popolazione, criteri di riavvio e convergenza e programmazione dei parametri degli operatori sono tutte decisioni a carico dell'algoritmo.
- Il modulo algoritmo dipende solo dal presupposto astratto che «le soluzioni candidate verranno valutate» e non si interessa del significato fisico né della forma concreta della funzione obiettivo.
Modulo problema: definisce «cosa valutare e come l'ambiente fornisce il feedback»
- Trasformare le soluzioni candidate in feedback confrontabili: valori obiettivo, fitness, entità della violazione dei vincoli o il risultato di un'interazione con l'ambiente.
- Dichiarare i confini del problema e i vincoli: dimensionalità delle variabili, intervallo di valori e regole della regione ammissibile, così che l'algoritmo sappia dove generare le soluzioni candidate.
- Fornire una valutazione coerente per lo stesso lotto di soluzioni candidate, rendendo confrontabili individui, generazioni e algoritmi diversi.
Contratto di interfaccia: lotto di soluzioni candidate ⇄ risultato della valutazione
Il modulo algoritmo invia al modulo problemaun lotto di soluzioni candidate; il modulo problema restituisceun risultato di valutazione strutturato(vettore obiettivo, violazione dei vincoli e informazioni diagnostiche aggiuntive opzionali); sulla base di ciò, il modulo algoritmo aggiorna la popolazione e passa alla generazione successiva. Questo ciclo di «invio–restituzione» costituisce una generazione evolutiva.
I vantaggi del disaccoppiamento
- Estensione indipendente: aggiungere o sostituire un algoritmo non influisce sulla definizione del problema; modificare o aggiungere un problema non richiede di riscrivere il modulo algoritmo.
- Componibilità: lo stesso modulo problema può essere collegato a diversi algoritmi evolutivi e lo stesso modulo algoritmo può passare a moduli problema differenti.
- Trasferibilità: purché il contratto di interfaccia resti stabile, algoritmo e problema possono essere riutilizzati, sostituiti e trasferiti tra attività diverse.
Perché è particolarmente importante in questo contesto: compromessi multiobiettivo e feedback costosi
Questa lezione si concentra su problemi ingegneristici del mondo fisico reale, come il profilo alaresupercritico di COMAC. Tali problemi presentano di norma tre caratteristiche simultanee: obiettivi molteplici in conflitto tra loro (ad esempio, aumentare la portanza comporta spesso un aumento della resistenza e una riduzione della stabilità), vincoli annidati tra loro (come il coefficiente di portanza critico di buffeting e il vincolo che la sollecitazione massima non superi il valore ammissibile del materiale) efeedback costosi e radi(il costo di una singola valutazione con simulazioni ad alta precisione è molto elevato). La suddivisione in moduli nasce proprio per affrontare questi tre aspetti.
Dal lato del modulo problema, obiettivi multipli e vincoli vengono ricondotti in modo unitario a risultati di valutazione confrontabili: il vettore obiettivo descrive i vari indicatori, la violazione dei vincoli descrive il grado di sforamento e, quando necessario, si ricorre amodelli surrogatiper fornire valutazioni approssimative a costi inferiori, alleviando il collo di bottiglia del feedback dovuto alle simulazioni ad alta precisione. Dal lato del modulo algoritmo, la ricerca non punta più a una convergenza prematura verso un'unica «risposta ottimale», ma mantieneun insieme diversificato di soluzioni candidate, consentendo agli esperti di ottimizzare le preferenze e operare compromessi tra portanza, resistenza e margine di sicurezza.
Pertanto, il contratto «lotto di soluzioni candidate ⇄ risultato della valutazione» non deve poter veicolare solo un singolo valore di fitness scalare, ma anche il vettore obiettivo e la violazione dei vincoli: i compromessi multiobiettivo richiedono che l'algoritmo sappia fare confronti non dominati, mentre la gestione dei vincoli richiede che sappia distinguere soluzioni ammissibili e non ammissibili. Se il contratto è incompleto, le informazioni su obiettivi multipli e vincoli si perdono definitivamente nell'interfaccia, e con esse la capacità di riutilizzo e trasferimento offerta dal disaccoppiamento.
