# EvoX Sistema di Evoluzione Intelligente e Pratica di Ricerca Scientifica AI Native — Dispense del Corso
Durata: 1 · Pagine del materiale: 16
## Navigazione di Lettura
- [Lezione 5｜Tema: Evoluzione dei Metodi: Dall'Ottimizzazione della Soluzione all'Ottimizzazione dell'Algoritmo Stesso](#lecture-lesson-1)
---
## Lezione 5｜Tema: Evoluzione dei Metodi: Dall'Ottimizzazione della Soluzione all'Ottimizzazione dell'Algoritmo Stesso
### Evoluzione dei Metodi: Dall'Ottimizzazione della Soluzione all'Ottimizzazione dell'Algoritmo Stesso
*Pagina 1*
> **Obiettivo della pagina:** Esplorare meccanismi di evoluzione dei metodi come MetaDE e AutoPSO, imparando come incorporare i metodi che generano candidati nell'oggetto dell'ottimizzazione, realizzando l'auto-evoluzione dell'algoritmo.
> **Obiettivo della pagina**
>
> Comprendere l'idea centrale dell'evoluzione dei metodi (Meta-Evolution), padroneggiare l'architettura che affida strategie di mutazione e iperparametri all'ottimizzazione evolutiva esterna, realizzando il salto dell'algoritmo dall'ottimizzazione della soluzione all'ottimizzazione dell'algoritmo stesso.
> **Ordine di presentazione**
>
> Dato un problema, ottimizzare le soluzioni candidate.
>
> Le strategie di mutazione e gli iperparametri di algoritmi (come Differential Evolution DE, Particle Swarm Optimization PSO) dipendono tipicamente da progettazione manuale o regolazione empirica.
>
> Trattare la configurazione dell'algoritmo (strategia, parametri) come individui dell'evoluzione esterna, mentre l'algoritmo interno si occupa di risolvere il problema originale.
>
> L'evoluzione esterna cerca automaticamente la migliore combinazione di strategie di mutazione e iperparametri.
>
> 5. Riassumere l'architettura di ottimizzazione a doppio livello e il significato dell'auto-evoluzione.
**Punti chiave della lezione**
- L'oggetto dell'ottimizzazione si sposta dalla "soluzione" al "metodo/algoritmo". Ottimizzazione a doppio livello. L'algoritmo evolutivo esterno ottimizza la configurazione dell'ottimizzatore interno (come strategia di mutazione, tasso di crossover, peso d'inerzia, fattori di apprendimento, ecc.)
- La fitness esterna è la prestazione dell'ottimizzatore interno sul problema di validazione (come valore ottimo medio, velocità di convergenza). Selezionare o generare automaticamente strategie di mutazione per DE e regolarne i parametri
- Configurare automaticamente parametri e topologia di PSO. Ridurre la regolazione manuale dei parametri, scoprire strategie innovative, migliorare la capacità di generalizzazione cross-problema
- L'ottimizzazione annidata causa un aumento significativo del costo computazionale.
**Verifica della comprensione**
Chiedere agli studenti di rispondere — Nell'evoluzione dei metodi, cosa rappresentano gli individui dell'algoritmo esterno? Quale ruolo svolge l'algoritmo interno? Come si definisce la fitness?
> **Suggerimento di transizione**
>
> Dopo aver compreso l'architettura a doppio livello, i contenuti successivi possono approfondire i dettagli implementativi e i risultati sperimentali di MetaDE o AutoPSO.
### Contesto Fondamentale e Motivazione dell'Evoluzione dei Metodi
*Pagina 2*
> **Obiettivo della pagina:** Gli studenti devono comprendere i limiti della preimpostazione manuale nei metodi di ottimizzazione tradizionali quando la potenza di calcolo si espande.
**Punti chiave della lezione**
- La versione in una frase dell'evoluzione dei metodi è: le soluzioni si evolvono, anche i metodi che generano soluzioni si evolvono. Di fronte a qualsiasi approccio che "regola solo parametri senza cambiare il meccanismo", si può usare questo criterio per giudicare se ci si è fermati al primo livello o si è saliti al secondo.
- La regolazione degli iperparametri è tipicamente una ricerca offline eseguita una volta prima dell'esecuzione, e una volta selezionato un valore questo viene fissato, rimanendo essenzialmente una preimpostazione manuale; l'evoluzione dei metodi invece tratta il metodo stesso come oggetto di ricerca durante l'esecuzione, adattandosi continuamente in base al feedback. Il criterio di giudizio è: questo meccanismo che genera candidati cambia durante l'esecuzione?
- Sapete spiegare la differenza tra i due lati? Se riuscite solo a dire "a destra si calcola più velocemente e si trova meglio", significa che non avete colto il punto; il punto è che l'oggetto di ricerca a destra ha un livello in più — il metodo stesso entra nel ciclo di ricerca, valutazione e aggiornamento.
【Obiettivo della pagina】
Quando la scala della potenza di calcolo non costituisce più un collo di bottiglia, ciò che realmente limita l'effetto evolutivo è che "il metodo stesso che genera soluzioni candidate è ancora preimpostato manualmente e fissato a lungo termine". Solo comprendendo questa carenza si può poi includere strategie di mutazione, fattori di scala, tassi di crossover e altri meccanismi nell'oggetto dell'evoluzione.
【Ordine di presentazione】
Si suggerisce di procedere seguendo la linea "apertura della potenza di calcolo → spostamento del collo di bottiglia → confini dell'ottimizzazione tradizionale → innalzamento del livello del problema → analisi e preparazione", concludendo con esercizi in classe e discussione di casi.
【Punti chiave della lezione】
1. Perché il collo di bottiglia si sposta. Sulla base di calcolo moderna di EvoX, popolazioni, risultati di valutazione e stati dell'algoritmo possono entrare integralmente in dispositivi acceleratori o cluster distribuiti, e decine di migliaia di valutazioni candidate non richiedono più elaborazione seriale una per una. Una volta aperto questo livello di potenza di calcolo, il limite rimanente ricade sul "modo di ricerca": il metodo che genera soluzioni candidate è ancora preimpostato dall'uomo e rimane invariato durante l'esecuzione.
2. I confini dell'ottimizzazione tradizionale. Gli algoritmi di ottimizzazione tradizionali sono molto bravi a trovare soluzioni in uno spazio di ricerca dato — data una strategia di mutazione, un set di parametri, una struttura di vicinato, essi generano ripetutamente soluzioni candidate, le valutano e selezionano. Ma attenzione: questo meccanismo di generazione dei candidati è una costante progettata esternamente, e l'algoritmo non lo modifica durante l'intero processo di esecuzione. In altre parole, ciò che viene cercato è solo la "soluzione", mentre il "modo di generare soluzioni" non viene cercato. Questo comporta due conseguenze: il sistema può solo ripetere schemi prestabiliti, difficilmente si adatta e si espande in base a problemi, ambienti e feedback; l'algoritmo può cercare soluzioni, ma esso stesso non partecipa al miglioramento del processo di ricerca.
Il problema si innalza di un livello. L'evoluzione dei metodi trasforma il "come generare soluzioni candidate" da scelta progettuale esterna in un oggetto ricercabile ed evolvibile. Prendendo come esempio il Differential Evolution, impostazioni originariamente fisse come la strategia di mutazione, il fattore di scala F e il tasso di crossover CR possono entrare nel ciclo evolutivo e essere continuamente adattate in base al feedback. Così il sistema cerca simultaneamente a due livelli: la "soluzione" e il "modo di generare soluzioni". Quando la forma del problema cambia, l'ambiente deriva o il segnale di feedback varia, anche il livello del metodo può essere riscritto, invece di far fronte a tutte le situazioni con una strategia euristica fissa.
4. Suggerimento di analisi. L'evoluzione dei metodi non equivale a "cambiare con un algoritmo migliore". Cambiare algoritmo rimane una scelta manuale una tantum, che una volta selezionata viene nuovamente fissata; l'evoluzione dei metodi enfatizza che questo meccanismo di generazione dei candidati si trova in uno stato di ricerca e adattamento continuo. Il criterio di giudizio può essere condensato in una frase: questo meccanismo che genera candidati cambia durante l'esecuzione?
5. Perché questa motivazione è la fondazione dei contenuti successivi. Essa traccia la linea di demarcazione tra EvoX e gli ottimizzatori comuni — come il confine dell'oggetto evolutivo continua a espandersi verso l'esterno, come l'algoritmo stesso viene migliorato, come il sistema si dirige verso la cascata e l'evoluzione continua, tutto si basa su questo livello di "innalzamento". Si può dire che la base di calcolo risolve "se si può calcolare su larga scala", mentre l'evoluzione dei metodi risolve "se, mentre si calcola su larga scala, anche il modo di ricerca può progredire insieme".
【Ancora di memoria】
Le soluzioni si evolvono, anche i metodi che generano soluzioni si evolvono. Di fronte a qualsiasi approccio che "regola solo parametri senza cambiare il meccanismo", si può usare questo criterio per giudicare se ci si è fermati al primo livello o si è saliti al secondo.
【Gestione degli esercizi】
Questa pagina include cinque domande a scelta multipla, che possono essere gestite in modo concentrato dopo la spiegazione, indicando per ciascuna la base di giudizio:
Riguardo ai limiti fondamentali dell'ottimizzazione tradizionale, l'opzione corretta è "cerca soluzioni solo nello spazio di ricerca prestabilito, il meccanismo di generazione dei candidati è preimpostato manualmente e non viene migliorato". Se gli studenti scelgono "calcola lentamente" o "non può parallelizzare", ricordare loro che quello è un problema a livello di base di calcolo, mentre questa pagina discute se il modo di ricerca può essere migliorato.
Riguardo al perché il collo di bottiglia diventa evidente dopo l'apertura della potenza di calcolo, la chiave è "un metodo fisso può solo ripetere schemi prestabiliti, difficilmente si adatta e si espande in base a problemi, ambienti e feedback". La tensorizzazione e il Runtime sono proprio per un calcolo batch efficiente, quindi il collo di bottiglia non è "se si può calcolare", ma "se il modo di ricerca può cambiare".
Riguardo a "il problema si innalza di un livello", sottolineare che l'oggetto di ricerca si estende dalla "soluzione" al "metodo che genera soluzioni", non a cambiare hardware o riscrivere la forma del problema.
Riguardo agli oggetti evoluti nel Differential Evolution, la risposta è strategia di mutazione, fattore di scala F e tasso di crossover CR; il valore ottimo è il risultato della ricerca, mentre hardware e dati sono condizioni esterne.
Riguardo alla base che la motivazione di questa pagina fornisce ai contenuti successivi, si concentra su "l'espansione del confine dell'oggetto evolutivo, il miglioramento dell'algoritmo stesso e l'evoluzione continua a livello di sistema".
【Discussione di casi】
Il team ha fissato la strategia di mutazione, F=0.5, CR=0.9 dopo prove offline, senza più modificarli a lungo; dopo sei mesi la città ha aggiunto zone a traffico limitato, la struttura degli ordini è passata da "piccoli lotti, molti punti" a "grandi lotti, pochi punti", la qualità delle soluzioni è costantemente peggiorata, e ogni regolazione dei parametri richiede di rifare le prove offline, con cicli di risposta settimanali.
Il problema è che cercano solo a livello di "percorso candidato", mentre il meccanismo di "come generare percorsi candidati" è preimpostato manualmente e fissato a lungo termine, che è esattamente il confine dell'ottimizzazione tradizionale. Se si introducesse l'evoluzione dei metodi, entrerebbero nello spazio di ricerca la selezione della strategia di mutazione, F, CR, e le relative combinazioni di parametri e regole di scheduling delle strategie, tutte trasformate da costanti in oggetti adattabili continuamente tramite il feedback dei risultati di valutazione.
Il team è già in grado di completare milioni di valutazioni candidate al giorno su dispositivi acceleratori, il che indica che il collo di bottiglia del "non riuscire a calcolare" è sostanzialmente aperto, e la carenza rimanente è proprio "il modo di ricerca fisso". Dopo aver incluso il livello del metodo nell'evoluzione, il costo aggiuntivo della ricerca sul metodo può condividere la stessa capacità di parallelizzazione batch con la ricerca della soluzione, con costi marginali controllabili. Un modo ragionevole di implementazione è trattare strategia di mutazione, F e CR come stati evolvibili aggiunti al tensore della popolazione, entrando insieme agli altri stati nel grafo computazionale batch; i risultati di valutazione vengono restituiti come segnali di feedback al livello del metodo, aggiornando strategie e distribuzioni di parametri con un certo ritmo; contemporaneamente si mantiene una configurazione baseline offline come controllo, valutando il guadagno netto in termini di qualità della soluzione e tempo di risposta con lo stesso budget di calcolo.
【Verifica della comprensione】
Chiedere agli studenti di spiegare la differenza tra ottimizzazione tradizionale a singolo livello ed evoluzione dei metodi. Se riescono solo a dire "a destra si calcola più velocemente e si trova meglio", significa che non hanno colto il punto; il punto è che l'oggetto di ricerca a destra ha un livello in più — il metodo stesso entra nel ciclo di ricerca, valutazione e aggiornamento.
【Suggerimento di transizione】
Successivamente, questo livello di "innalzamento" verrà applicato a meccanismi concreti, per vedere come l'algoritmo stesso può essere migliorato.
### Evoluzione Tecnica e Origini Storiche dei Sistemi Intelligenti
*Pagina 3*
> **Obiettivo della pagina:** Gli studenti devono padroneggiare la posizione del calcolo evolutivo come fonte tecnica nella confluenza di molteplici percorsi.
> **Obiettivo della pagina**
>
> Riportare la storia tecnologica dei sistemi intelligenti fuori dalla lettura errata di "evoluzione a linea singola", facendo comprendere agli studenti la posizione del calcolo evolutivo nella confluenza di quattro filoni, e da qui comprendere l'orientamento architetturale di EvoX — trattare l'"evoluzione continua" come capacità di sistema eseguibile, non come piccolo trucco a livello di algoritmo.
**Punti chiave della lezione**
- I. Quattro filoni, quattro modi di porre domande. Leggere la storia tecnologica come una linea retta porta a gravi errori di valutazione dei sistemi intelligenti di oggi. Il simbolismo si occupa di "regole e simboli", caratterizzando l'intelligenza con rappresentazione esplicita della conoscenza e ragionamento logico, mettendo "spiegare chiaramente" prima di "calcolare", con il costo di difficoltà ad affrontare realtà sfocate, ad alta dimensionalità e rumorose
- Il connessionismo si occupa di "dati e rappresentazioni", usando reti neurali e rappresentazioni distribuite per l'apprendimento dei parametri, abile nell'adattare mappature complesse, ma tipicamente richiede un obiettivo ed etichette specificati esplicitamente
- La cibernetica si occupa di "feedback e ciclo chiuso", comprendendo l'intelligenza come processo di regolazione continua tra sistema e ambiente, fornendo il meccanismo di "correzione continua", ma lasciando alla strategia di ricerca "cosa esplorare"
- Il calcolo evolutivo si occupa di "popolazione, mutazione, selezione", usando la popolazione per portare diversità, mutazione e ricombinazione per generare cambiamento, valutazione e selezione per preservare strutture efficaci; non risponde a "qual è la risposta corretta", ma a "come migliorare continuamente in uno spazio aperto". Di fronte a qualsiasi narrativa storica della tecnologia, usare prima queste quattro parole chiave per localizzare a quale filone appartiene, e il giudizio sarà molto più rapido. II. La confluenza non è sostituzione. Le tre classiche linee forniscono capacità di rappresentazione, generazione e adattamento, il calcolo evolutivo fornisce meccanismi di ricerca aperta, adattamento e miglioramento continuo
- Le due si sovrappongono, coprendo esattamente i problemi di due livelli diversi: "saper calcolare" e "saper dove andare". Pertanto qualsiasi affermazione che "una certa scuola è stata eliminata" si discosta dal giudizio di questa pagina: la confluenza è una sovrapposizione collaborativa di meccanismi a diversi livelli nello stesso sistema, non il predominio di una scuola sulle altre. Si può utilizzare il diagramma "quattro filoni → un punto di confluenza" della pagina, seguendo le frecce dai quattro riquadri a sinistra verso il punto di confluenza centrale, poi a destra verso il "sistema intelligente", e infine verso il basso fino al "punto di accesso EvoX: calcolo evolutivo × GPU × grandi modelli". L'intelligenza può essere sia consegnata come "prodotto preimpostato" — definire prima etichette e output ottimale unico, far avvicinare il modello
- Sia coltivata come "processo ambientale" — definire solo spazio di ricerca e criteri di valutazione, lasciando che la popolazione scopra autonomamente soluzioni utilizzabili nell'iterazione. EvoX sceglie la seconda. Per giudicare a quale categoria appartiene un nuovo sistema, basta chiedere: il suo obiettivo è predefinito manualmente in modo fisso, o viene selezionato dall'ambiente attraverso valutazione continua? IV. Posizionamento architetturale di EvoX. EvoX si colloca al punto di confluenza, adottando il calcolo evolutivo come filone tecnico diretto, combinandolo con GPU, grandi modelli e altre basi ingegneristiche contemporanee, rendendo l'evoluzione continua ingegneristicamente eseguibile. Questa pagina fornisce solo la preparazione sui filoni e il posizionamento, mentre dettagli come la base di tensorizzazione, l'evoluzione dei metodi, MetaDE verranno sviluppati nelle pagine successive.
**Copertura delle parole chiave**
- Simbolismo, connessionismo, cibernetica, calcolo evolutivo, punto di confluenza, prodotto preimpostato, processo ambientale, punto di accesso EvoX.
**Gestione degli esercizi**
Cinque domande a scelta multipla da porre subito dopo la spiegazione, con enfasi sulla richiesta delle motivazioni piuttosto che sulla semplice comunicazione delle risposte. Domanda uno, la risposta è il simbolismo; se gli studenti scelgono male, suggerire "quale linea ha come parole chiave regole, simboli, logica, invece di dati, feedback o popolazione". Domanda due, l'affermazione corretta è che la popolazione genera cambiamento, valutazione e selezione preservano strutture efficaci, non si presuppone una soluzione ottimale unica; la differenza chiave è "chi decide la risposta". Domanda tre, la risposta è far salire l'evoluzione continua da trucco algoritmico a capacità di sistema eseguibile; si può ricordare che "posizionamento architetturale" significa non sostituire nessuna scuola, ma far funzionare e durare realmente il meccanismo evolutivo. Domanda quattro, conforme alla visione dell'intelligenza come processo ambientale è "definire solo spazio di ricerca e criteri di valutazione, lasciando che la popolazione scopra autonomamente soluzioni utilizzabili nell'iterazione".
Domanda cinque, il giudizio accurato è che le linee classiche forniscono rappresentazione, generazione e adattamento, il calcolo evolutivo fornisce ricerca aperta, adattamento e miglioramento continuo. La causa comune degli errori è leggere "confluenza" come "sostituzione", o fraintendere il calcolo evolutivo come metodo supervisionato che richiede etichette, ed è necessario tornare alla spiegazione di questa pagina per riposizionarsi.
Sistema di dispatch per consegne urbane in tempo reale: soluzione A (apprendimento supervisionato che approssima le decisioni ottimali storiche annotate da esperti) e soluzione B (definire solo spazio di ricerca e criteri di valutazione multi-indicatore, con ricerca iterativa della popolazione e valutazione parallela tramite GPU). Prima domanda: confrontare le due visioni dell'intelligenza: la differenza sostanziale non è nella complessità dell'algoritmo, ma nel fatto che la risposta sia predeterminata dall'uomo o selezionata dall'ambiente attraverso valutazione continua; EvoX è più vicino alla soluzione B. Seconda domanda sui rischi a lungo termine dei criteri di valutazione e le contromisure: possibili risposte includono progettazione inadeguata degli indicatori che porta a ottimizzare precisamente l'obiettivo sbagliato, calo della diversità della popolazione e stagnazione della ricerca dopo il consolidamento degli standard, indicatori soddisfatti in modo opportunistico con soluzioni inaccettabili a livello aziendale;
le contromisure corrispondenti includono ponderazione multi-obiettivo o fronte di Pareto con ricalibrazione periodica dei pesi, introduzione di mantenimento della diversità e reinizializzazione periodica, imposizione di vincoli rigidi e verifiche di sicurezza sulle soluzioni candidate, e retroazione delle prestazioni effettive delle soluzioni adottate come ciclo chiuso per i criteri di valutazione.
**Verifica della comprensione**
Chiedere a uno studente di spiegare con parole proprie cosa risolve ciascuno dei quattro filoni, e poi ripetere la differenza tra "prodotto preimpostato" e "processo ambientale"; il docente integra le parole chiave mancanti in base alla risposta, in particolare "valutazione e selezione" e "non presupporre una soluzione ottimale unica".
> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno esprimere la relazione tra i quattro filoni e il punto di confluenza, passare alla pagina successiva sullo sviluppo concreto dell'evoluzione dei metodi e della base di tensorizzazione.
### L'Espansione dei Confini Evolutivi da Parte dei Grandi Modelli e della Potenza di Calcolo
*Pagina 4*
> **Obiettivo della pagina:** Gli studenti devono comprendere come la parallelizzazione GPU e i grandi modelli espandono insieme lo spazio di generazione ed esplorazione dei candidati.
> **Obiettivo della pagina**
>
> Comprendere come la potenza di calcolo parallela delle GPU e la generazione semantica dei grandi modelli costituiscano insieme la doppia base ingegneristica del calcolo evolutivo, ed espandano i confini dei candidati da parametri numerici a programmi, strutture di modelli e meccanismi algoritmici.
> **Ordine di presentazione**
>
> Prima presentare le due domande generali — la potenza di calcolo determina "quanti candidati si possono esplorare in una volta", i grandi modelli determinano "quali forme di candidati si possono esplorare"; poi spiegare separatamente le due basi, e infine illustrare la relazione complementare, l'espansione a tre livelli e i costi.
**Punti chiave della lezione**
- La valutazione tradizionale della popolazione è un ciclo seriale su CPU, con overhead di scheduling che si accumula con la scala. La valutazione batch tensorizzata organizza candidati, risultati di valutazione e stati dell'algoritmo in tensori calcolabili integralmente, rendendo l'esplorazione simultanea di decine di migliaia di candidati una pratica routine. Risolve il throughput, non giudica la bontà dei candidati, ed è il supporto di base per l'espansione dello spazio dei candidati. Il valore dei grandi modelli non è calcolare più velocemente, ma comprendere codice, conoscenza di dominio e contesto del compito, potendo generare candidati strutturalmente complessi come frammenti di codice e topologie di modelli surrogati, aprendo così lo spazio delle forme dei candidati. Parametri numerici → struttura di programma/modello → meccanismo algoritmico. I primi due livelli sono guidati dalla capacità generativa dei grandi modelli, il terzo livello include il processo stesso di "come generare, come valutare" nell'oggetto evolutivo, ed è il presupposto per la validità di percorsi come MetaDE e AutoPSO che "usano l'evoluzione per migliorare l'evoluzione". La potenza di calcolo espande l'ampiezza della ricerca, i grandi modelli migliorano la qualità dei candidati e la complessità delle forme
- Mancando una delle due parti, l'espansione dei confini è incompleta. Aumento dei costi di valutazione, difficoltà nella verifica di correttezza, criteri più sfumati per determinare la "risposta utilizzabile", che richiedono integrazione con compromessi multi-obiettivo e decisioni di esperti. Nell'ottimizzazione di profili alari, l'oggetto di ricerca si sposta dai parametri numerici preimpostati al codice di risoluzione, alla struttura del modello surrogato, e persino allo schema di generazione e valutazione stesso
- Contemporaneamente è necessario aggiungere gestione del budget di valutazione, verifica di sintassi/interfacce/vincoli, fallback in caso di errore e interfacce per le decisioni degli esperti. Trattare i grandi modelli come calcolatori di fitness più veloci, o credere che con sufficiente potenza di calcolo si possano automaticamente trovare candidati a livello di programma. Il primo perde lo spazio delle forme, il secondo ignora da dove provengono i candidati.
**Gestione degli esercizi**
Cinque domande a scelta multipla per verificare in sequenza il ruolo della potenza di calcolo, le capacità dei grandi modelli, l'ordine dell'espansione a tre livelli, la relazione complementare e le capacità di supporto. Domanda 1: selezionare "calcolo batch tensorizzato"; Domanda 2: selezionare "comprendere codice, conoscenza di dominio e contesto"; Domanda 3: selezionare "parametri numerici→struttura di programma/modello→meccanismo algoritmico"; Domanda 4: selezionare "complementari, entrambi indispensabili"; Domanda 5: selezionare "controllo dei costi di valutazione, verifica di correttezza e criteri per determinare la risposta utilizzabile". Se gli studenti scelgono male, ricordare di distinguere "calcolare molto" e "calcolare bene", e che "generare forme" e "throughput di valutazione" non sono la stessa cosa.
**Verifica della comprensione**
Chiedere agli studenti di rispondere in una frase a due domande — da cosa è determinato quanti candidati si possono esplorare in una volta, e da cosa è determinato quali forme di candidati si possono esplorare; poi fare un esempio di passaggio dall'ottimizzazione di parametri al meccanismo algoritmico.
> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno esprimere la divisione complementare tra potenza di calcolo e modelli, passare alla sezione successiva sui meccanismi concreti dell'evoluzione dei metodi.
### Conflitti Multidimensionali e Compromessi nei Problemi del Mondo Reale
*Pagina 5*
> **Obiettivo della pagina:** Gli studenti devono comprendere la necessità di preservare candidati differenziati e gestire conflitti multi-obiettivo nei compiti di ricerca scientifica reali.
**Punti chiave della lezione**
- I punti sul fronte di Pareto non si dominano a vicenda, sono solo "più adatti sotto una certa preferenza". Quando si vede un grafico del fronte, prima chiedere quali sono le preferenze e i vincoli, poi discutere se una soluzione è buona.
- Se la popolazione collassa rapidamente in una regione ristretta, verificare prima se la pressione selettiva e i meccanismi di mantenimento della diversità sono sbilanciati. Una volta che la copertura diminuisce, quando i vincoli cambiano non si hanno alternative tra cui scegliere.
- Quando la valutazione reale è costosa e i segnali sono sparsi, destinare prioritariamente il budget a soluzioni candidate con alta incertezza e che potenzialmente espandono la copertura dello spazio dei compromessi, piuttosto che rifinire ripetutamente attorno alla soluzione ottimale corrente.
> **Obiettivo della pagina**
>
> Comprendere la necessità di gestire conflitti multi-obiettivo, compromessi di Pareto e preservazione di candidati differenziati nella ricerca scientifica e nell'ottimizzazione ingegneristica reale.
>
> Ordine di presentazione e punti chiave:
>
> 1. Partire dal conflitto. I compiti reali raramente hanno un singolo obiettivo e vincoli chiari, spesso hanno molteplici obiettivi che si vincolano a vicenda. Ad esempio, ridurre il tempo di ricarica rapida comporta calore e perdita di durata, l'aumento della portanza è spesso accompagnato da un aumento della resistenza, assottigliare il profilo alare migliora l'aerodinamica ma indebolisce la resistenza strutturale. Quindi non esiste un ottimo gratuito, e il cosiddetto ottimo deve specificare "sotto quale preferenza è ottimale".
>
> 2. Comprendere la soluzione come un insieme di soluzioni di compromesso. L'insieme delle soluzioni di un problema multi-obiettivo è il fronte di Pareto. Ogni punto sul fronte è una soluzione non dominata, che rappresenta un orientamento di preferenza ragionevole; senza peggiorare gli altri obiettivi, nessun obiettivo può essere ulteriormente migliorato. Tra i punti non c'è una classifica assoluta, solo "più adatto sotto una certa preferenza". Le soluzioni dominate sono quelle per cui esiste una soluzione che le migliora completamente.
>
> 3. L'esplorazione ha priorità sulla convergenza. Convergere prematuramente a un singolo punto comprime lo spazio delle soluzioni in un punto, perdendo informazioni strutturali; una volta che vincoli, costi o rischi cambiano, non ci sono alternative tra cui scegliere, e si deve ricercare da capo. Bisogna mantenere la diversità della popolazione, far sì che diverse direzioni di preferenza siano campionate e valutate simultaneamente, evitando che tutti gli individui collassino in una regione ristretta del fronte. Il valore della differenziazione sta nella risposta al cambiamento.
>
> 4. La base di calcolo supporta l'espansione multi-direzionale. EvoX organizza candidati, risultati di valutazione e stati dell'algoritmo in tensori calcolabili integralmente, facendo entrare mutazione, valutazione e aggiornamento dello stato nel grafo computazionale per l'ottimizzazione della compilazione; lo scheduler Runtime distribuisce il calcolo batch su GPU, dispositivi acceleratori o cluster distribuiti. La valutazione batch ad alto throughput rende ingegneristicamente fattibile mantenere grandi popolazioni e coprire l'intero fronte.
>
> 5. Quando la valutazione è costosa e il feedback è sparso, la strategia di allocazione del budget deve cambiare. Le valutazioni reali spesso provengono da simulazioni, banchi di prova o prototipazione, con costi unitari elevati e segnali sparsi. Bisogna usare modelli surrogati per sostituire parte delle valutazioni ad alta fedeltà, destinando il budget limitato a candidati con alta incertezza e che espandono la copertura dello spazio dei compromessi, piuttosto che rifinire ripetutamente attorno alla soluzione ottimale corrente.
>
> 6. Attribuzione del potere decisionale. L'algoritmo si occupa di espandere lo spazio dei compromessi e fornire un insieme comparabile di candidati; gli esperti umani prendono la decisione finale in base a preferenze di scenario, normative e vincoli commerciali. I due sono complementari e non sostituibili. Ingegneristicamente, consegnare un insieme di soluzioni di Pareto con una descrizione della corrispondenza "preferenza—soluzione" è più affidabile che consegnare un singolo punto apparentemente preciso.
> **Spunti per i materiali**
>
> - Il diagramma del fronte di Pareto usa come coordinate "portanza ↑ / resistenza ↓", indicando il fronte composto da soluzioni non dominate, le soluzioni dominate, il collasso della diversità causato da convergenza prematura, e il campionamento parallelo lungo diverse direzioni di preferenza. Durante la spiegazione, si può prima chiedere agli studenti di giudicare quali punti nel grafico potrebbero trovarsi sul fronte, poi spiegare che il decisore deve scegliere i punti in base ai vincoli di scenario.
**Gestione degli esercizi**
Q1 l'opzione corretta è "il fronte è composto da un insieme di soluzioni di compromesso mutuamente non dominate, ogni punto corrisponde a un ragionevole orientamento di preferenza". Si può chiedere: se un punto può ancora essere migliorato completamente, allora non è sul fronte. Q2 l'opzione corretta è "la convergenza prematura perde informazioni strutturali dello spazio delle soluzioni, impossibilitando il rapido passaggio ad alternative quando vincoli o preferenze cambiano". Sottolineare che è un problema di informazione, non solo di potenza di calcolo. Q3 l'opzione corretta è "coprire uno spazio di compromesso più ampio con un budget di valutazione limitato, usando modelli surrogati per sostituire parte delle valutazioni ad alta fedeltà". Q4 l'opzione corretta è "l'algoritmo espande lo spazio dei compromessi e fornisce un insieme di candidati, gli esperti umani decidono in base a preferenze e vincoli". Q5 l'opzione corretta è "aumentare la portanza è solitamente accompagnato da un aumento della resistenza, assottigliare il profilo alare favorisce l'aerodinamica ma indebolisce la struttura, richiedendo un compromesso".
Conflitto di obiettivi, la ricarica rapida produce calore e accelera il degrado della durata; le preferenze cambiano, diversi modelli di veicolo, sistemi di batterie, potenze delle colonnine di ricarica rapida e politiche di garanzia modificano i pesi tra tempo di ricarica e durata; la valutazione reale è costosa e sparsa, consegnare un insieme di soluzioni che copre il fronte permette di riutilizzare il budget di valutazione. Processo operativo: eseguire prima un piccolo numero di valutazioni ad alta fedeltà e calibrazione dei parametri, costruire strategie di base e campioni di perturbazione; addestrare e validare il modello surrogato; abilitare in EvoX il mantenimento della diversità e il campionamento multi-direzionale, destinando le valutazioni supplementari alle regioni sparse e ad alta incertezza in base alla copertura del fronte; produrre il gruppo di strategie candidate e la tabella di corrispondenza preferenza—soluzione;
infine ingegneri di veicoli e batterie selezionano in base ad autonomia, potenza di ricarica rapida, garanzia, normative di sicurezza e costi, con piccole rifiniture nel vicinato.
**Verifica della comprensione**
Far dire agli studenti con parole proprie "perché l'ottimizzazione multi-obiettivo consegna un insieme di soluzioni invece di un punto", e fare un esempio del valore di questo insieme quando le preferenze cambiano. Se gli studenti ricordano solo "conflitto di obiettivi", suggerire di aggiungere "fronte di Pareto", "la diversità è informazione" e "il budget di valutazione va destinato a coprire i confini".
### Idea Centrale e Salto dell'Evoluzione dei Metodi
*Pagina 6*
> **Obiettivo della pagina:** Gli studenti devono comprendere la svolta teorica dell'inclusione dei metodi di generazione dei candidati nell'oggetto evolutivo.
**Punti chiave della lezione**
- Il criterio di giudizio dell'evoluzione dei metodi è semplice: le variabili di ottimizzazione includono il metodo, l'operatore o la strategia che genera i candidati? Se solo le soluzioni cambiano, è ancora ottimizzazione tradizionale; se anche il livello del metodo riceve feedback e si aggiorna, allora è evoluzione dei metodi.
- Il livello della soluzione risponde a "quanto è buono questo candidato", il livello del metodo risponde a "come generare candidati migliori". I due livelli sono connessi dal segnale di valutazione, non confondere l'aggiornamento del livello del metodo con la rifinitura di una singola soluzione.
- L'evoluzione dei metodi non persegue l'ottimo singolo, ma la generalizzazione cross-task, la robustezza, la diversità e il costo computazionale. In fase di ripasso, usare "un risolutore più abile nel trovare soluzioni" per verificare se si è veramente compreso.
> **Obiettivo della pagina**
>
> Trasformare il "metodo che genera soluzioni candidate" stesso in oggetto di ottimizzazione, facendo passare l'algoritmo da strumento fisso a risolutore in continua evoluzione.
>
> Ordine di presentazione e punti chiave:
>
> 1. Localizzare prima il punto di salto. Il percorso tradizionale è "problema→algoritmo fisso→soluzione candidata", l'algoritmo è preselezionato dal ricercatore e non cambia durante la ricerca, l'oggetto dell'ottimizzazione è la soluzione x. L'evoluzione dei metodi riscrive il percorso come "famiglia di problemi/ambiente→spazio di metodi evolvibili→generatore di candidati→valutazione delle soluzioni candidate→aggiornamento del metodo→rigenerazione", con le variabili di ottimizzazione estese a metodi, operatori, regole di iper-euristica o processi di generazione di candidati m. Qui il "metodo" può essere concretamente la strategia di mutazione del Differential Evolution, il peso d'inerzia e la topologia del Particle Swarm, operatori di ricerca locale, o può salire al livello di selezione e regole di scheduling degli algoritmi.
>
> L'oggetto evolutivo si estende da soluzioni, parametri, strutture a metodi, operatori, regole di iper-euristica o processi di generazione di candidati; il problema viene riformulato come "evolvere, nei compiti o negli ambienti, un risolutore più abile nel trovare soluzioni"; il metodo genera candidati e riceve la valutazione del compito, la valutazione guida la mutazione, selezione e ricombinazione del metodo, formando un feedback continuo tra livello del metodo e livello della soluzione; i criteri di valutazione migrano dall'ottimo singolo alla generalizzazione cross-task e cross-ambiente, robustezza, diversità e costo computazionale; il ruolo del ricercatore si trasforma nella progettazione di spazi di metodi evolvibili, segnali di feedback e meccanismi di selezione.
>
> 3. Spiegare in dettaglio il ciclo chiuso di feedback. Il livello del metodo genera generatori di candidati, il livello della soluzione li usa per produrre candidati su compiti specifici e ottenerne la valutazione; la valutazione, dopo aggregazione o assegnazione del credito, ritorna al livello del metodo, guidando mutazione, selezione e ricombinazione del metodo stesso. Se il feedback è troppo sparso o premia solo l'ottimo a breve termine, il livello del metodo tende a sovradattarsi a un singolo compito; solo se il feedback include generalizzazione cross-task e diversità si può apprendere una meta-strategia "più abile nel trovare soluzioni". Si può comprendere come un ulteriore livello di ricerca evolutiva sullo spazio dei metodi, ma la sua valutazione non può prescindere dalle prestazioni reali del livello della soluzione.
>
> MetaDE rende evolvibili le strategie, i parametri e persino le combinazioni di operatori del Differential Evolution; AutoPSO include nella ricerca automatica la struttura, i parametri o la topologia del Particle Swarm. Entrambi condividono lo stesso punto di partenza: includere il metodo che genera candidati nell'oggetto dell'ottimizzazione, realizzando l'auto-evoluzione dell'algoritmo. Questa pagina stabilisce prima il concetto unificato, le architetture concrete e l'evoluzione delle strutture algoritmiche verranno sviluppate successivamente.
>
> Se il metodo rimane fisso, il sistema sta ancora cercando soluzioni sotto un algoritmo dato; solo quando anche il livello del metodo riceve feedback e si aggiorna si entra nell'evoluzione dei metodi. Il livello della soluzione risponde a "quanto è buono questo candidato", il livello del metodo risponde a "come generare candidati migliori". I due livelli sono connessi dal segnale di valutazione, non confondere l'aggiornamento del livello del metodo con la rifinitura di una singola soluzione.
> **Spunti per i materiali**
>
> - Si può utilizzare il diagramma della struttura concettuale della pagina — a sinistra la catena tradizionale a percorso singolo, a destra il ciclo chiuso dell'evoluzione dei metodi, con al centro "salto: il metodo diventa oggetto di ottimizzazione" per evidenziare la differenza
> - In basso sono annotati MetaDE / AutoPSO come direzioni implementative. Spunti per esercizi e verifica della comprensione: La domanda concettuale dovrebbe selezionare la svolta teorica "includere il metodo di generazione dei candidati nell'oggetto evolutivo". Una risposta corretta indica comprensione coerente con il programma
> - Se sbagliata, rivedere prima i concetti chiave e riprovare. Nel giudicare affermazioni come "l'algoritmo passa da strumento fisso a risolutore in continua evoluzione", la scelta più ragionevole è poter spiegare i concetti di questa pagina con prove o esempi, e saperne indicare le motivazioni
> - Evitare di saltare i materiali e recitare a memoria, concludere solo per sensazione, o cambiare simultaneamente tutti i fattori per confrontare. Piattaforma di ottimizzazione combinatoria multi-task che introduce l'evoluzione dei metodi. Riformulazione del problema: da "trovare la soluzione ottimale per ogni compito sotto un algoritmo genetico fisso" a "evolvere, nella famiglia di compiti o nell'ambiente, un risolutore più abile nel trovare soluzioni". Lo spazio di metodi evolvibili può includere tipi e intensità di operatori di crossover e mutazione, strategie di selezione, operatori di ricerca locale, regole di iper-euristica, strategie di controllo dei parametri, processi di generazione di candidati, e combinazioni di strategie in stile MetaDE, strutture di topologia e parametri in stile AutoPSO. Ciclo chiuso di feedback: il livello del metodo campiona o muta un insieme di metodi o configurazioni di operatori, il livello della soluzione genera candidati su più compiti e calcola la fitness
> - Le prestazioni cross-task vengono aggregate in segnali di feedback, che tornano al livello del metodo per selezione, mutazione e ricombinazione, aggiornando la distribuzione dei metodi, e poi entrano nel ciclo successivo di generazione. Migrazione della valutazione: non solo l'ottimo singolo per singolo compito, ma generalizzazione cross-task, robustezza, diversità, costo computazionale e stabilità. Rischio principale: il meta-livello si sovradatta a pochi compiti o a ricompense a breve termine, causando il collasso della diversità dello spazio dei metodi
> - Le contromisure includono campionamento dei compiti, regolarizzazione, mantenimento della diversità e validazione gerarchica.
**Attività in classe**
Far ripetere agli studenti con parole proprie la catena "famiglia di problemi/ambiente→spazio di metodi evolvibili→generatore di candidati→valutazione delle soluzioni candidate→aggiornamento del metodo→rigenerazione", e fare esempi che distinguano il livello del metodo dal livello della soluzione. Chiedere a uno studente a caso di riassumere i punti chiave di questa pagina, con il docente che integra le parole chiave mancanti.
> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno esprimere il criterio di giudizio — se le variabili di ottimizzazione includono il metodo, l'operatore o la strategia che genera i candidati, e se il livello del metodo riceve feedback e si aggiorna — passare alla pagina successiva sull'architettura concreta, le applicazioni o il riepilogo.
**Copertura delle parole chiave**
- Evoluzione dei metodi, Meta-Evolution, spazio di metodi evolvibili, generatore di candidati, livello del metodo e livello della soluzione, ciclo chiuso di feedback, MetaDE, AutoPSO, generalizzazione cross-task, robustezza, diversità, costo computazionale.
### Evoluzione a Doppio Livello e Meccanismi Adattivi
*Pagina 7*
> **Obiettivo della pagina:** Gli studenti devono padroneggiare il meccanismo di collaborazione a doppio livello tra risoluzione dei compiti interna e ottimizzazione delle strategie esterna.
**Punti chiave della lezione**
- Per memorizzare, chiedere prima: chi risolve il problema? Chi modifica il metodo? Il livello interno produce soluzioni e prestazioni, il livello esterno produce configurazioni e strategie. Poi collegare in un ciclo chiuso "prestazioni interne → fitness esterna → aggiornamento della configurazione interna".
- La fitness esterna valuta la prestazione di un insieme di configurazioni interne su compiti batch, non il valore ottimale di un singolo compito. Comprendere questo evita di fraintendere il livello esterno come un altro risolutore diretto.
- Se la varianza della valutazione interna è elevata, il livello esterno potrebbe scambiare configurazioni fortunate per configurazioni realmente migliori. In fase di ripasso, riflettere su come prestazioni medie, statistiche robuste e l'aumento dei campioni di valutazione possano aiutare il livello esterno a decidere in modo stabile.
Obiettivo della pagina
Questa pagina si sviluppa attorno all'evoluzione a doppio livello e ai meccanismi adattivi, richiedendo agli studenti di comprendere che l'evoluzione dei metodi non ottimizza solo soluzioni, ma aggiunge un livello meta-evolvibile di controllo sopra il livello di risoluzione dei compiti, permettendo al sistema di adattare automaticamente i metodi di risoluzione in base a cambiamenti di compito e ambiente. Al termine si deve saper spiegare la divisione dei ruoli tra livello interno ed esterno, la formazione del ciclo chiuso di feedback e il ruolo della parallelizzazione GPU.
Ordine di presentazione
Chi risolve il problema? Chi modifica il metodo? Da qui si introduce che il livello interno produce soluzioni e prestazioni, il livello esterno produce configurazioni e strategie. Poi si collega "prestazioni interne → fitness esterna → aggiornamento della configurazione interna" in un ciclo chiuso, aiutando gli studenti a cogliere complessivamente la struttura a doppio livello.
Punti chiave della lezione
1. Il livello interno è il livello di risoluzione dei compiti. Si occupa di risolvere compiti reali, eseguendo in parallelo un gran numero di compiti specifici, producendo soluzioni candidate, valori obiettivo f e prestazioni di esecuzione, come risorse temporali, passi di convergenza, tasso di successo. Il punto di ancoraggio mnemonico è "risolvere il problema".
2. Il livello esterno è il livello di evoluzione dei metodi. Non risolve direttamente il compito originale, ma evolve configurazioni, strategie e parametri dell'algoritmo interno, includendo operazioni di valutazione, selezione, mutazione, aggiornamento. Il punto di ancoraggio mnemonico è "migliorare il metodo di risoluzione".
3. Il ciclo chiuso di feedback è la chiave della struttura a doppio livello. Le prestazioni dei compiti batch interni vengono aggregate in segnali di fitness esterna, usati per selezionare, mutare e aggiornare configurazioni interne migliori; le configurazioni aggiornate tornano al livello interno, formando un ciclo chiuso.
4. Il meccanismo adattivo si manifesta nel fatto che il livello esterno adatta continuamente le strategie interne al variare di compiti e ambiente. Non è una semplice concatenazione di due algoritmi, ma l'aggiunta di un controllo meta-evolvibile sopra il livello di risoluzione dei compiti, spostando il sistema da algoritmi impostati manualmente ad algoritmi che si adattano automaticamente ai compiti.
Il livello interno produce "soluzioni", il livello esterno produce "metodi migliori per generare soluzioni". La fitness esterna non è il valore ottimale del compito originale stesso, ma la valutazione della prestazione di un insieme di configurazioni interne su compiti batch.
La GPU può eseguire in parallelo un gran numero di compiti interni, fornendo feedback statistico più ricco per l'evoluzione esterna e riducendo i costi di attesa della ricerca. Qui va sottolineato che il parallelismo migliora il supporto statistico e l'efficienza, non elimina la valutazione, né garantisce l'ottimo globale.
DE interno si occupa dei compiti di ottimizzazione concreti, il livello esterno seleziona e adatta la configurazione e le strategie di DE in base alle prestazioni del livello interno, come strategia di mutazione, tasso di crossover, dimensione della popolazione; i risultati di un gran numero di compiti interni guidano inversamente la selezione della configurazione esterna, formando un ciclo chiuso a doppio livello che "usa l'evoluzione per migliorare l'evoluzione".
Spunti per i materiali
A sinistra il livello interno di risoluzione dei compiti, a destra il livello esterno di evoluzione dei metodi. A sinistra vengono prodotti soluzioni candidate, valori obiettivo e prestazioni di esecuzione, che attraverso "dati di prestazione → segnale di fitness" entrano a destra; a destra, dopo valutazione, selezione, mutazione e aggiornamento, attraverso "aggiornamento della configurazione e delle strategie interne" tornano a sinistra. In basso è annotata la parallelizzazione GPU, per l'esecuzione batch dei compiti interni.
Verifica della comprensione
Come influiscono le prestazioni interne sul livello esterno? Se gli studenti dicono solo "esegue compiti in parallelo", ricordare di aggiungere "aggregate in segnali di fitness, che guidano selezione, mutazione e aggiornamento".
Gestione degli esercizi
Gli esercizi di questa pagina vertono su divisione dei ruoli, ciclo chiuso di feedback, ruolo del parallelismo e "usare l'evoluzione per migliorare l'evoluzione".
Il ruolo principale del livello interno è risolvere compiti reali, generando soluzioni candidate, valori obiettivo e dati di prestazione. Sottolineare che il livello interno produce prima soluzioni e prestazioni, poi il livello esterno evolve configurazioni e strategie.
Il livello esterno non risolve direttamente il compito originale, perché il suo ruolo è evolvere configurazioni, strategie e parametri dell'algoritmo interno, appartenendo al controllo meta-livello. Cogliere "come si evolve il metodo", non "cos'è la soluzione".
I risultati di valutazione interni vengono aggregati in segnali di fitness esterna, usati per selezionare, mutare e aggiornare configurazioni interne. La chiave della struttura a doppio livello è il ciclo chiuso di feedback, non il parallelismo a ciclo aperto.
Il ruolo più importante della parallelizzazione GPU di un gran numero di compiti interni è fornire feedback statistico più ricco e ridurre i costi di attesa della ricerca. Il parallelismo migliora il supporto statistico e l'efficienza, non equivale a eliminare la valutazione o garantire l'ottimo globale.
"Usare l'evoluzione per migliorare l'evoluzione" significa che il livello esterno evolve configurazioni e strategie dell'algoritmo interno, e le prestazioni interne alimentano inversamente la fitness esterna, formando un ciclo chiuso bidirezionale.
In caso di risposta corretta, lodare gli studenti per aver collegato i concetti della pagina e averne indicato le motivazioni; in caso di errore, guidarli a tornare ai due punti di giudizio: divisione dei ruoli e ciclo chiuso di feedback.
Gestione del caso
DE risolve su istanze di scheduling concrete, producendo soluzioni candidate, valori obiettivo, passi di convergenza e altre prestazioni di esecuzione. Ruolo del livello esterno: non pianificare direttamente la produzione, ma evolvere configurazioni e strategie di DE, come strategia di mutazione, tasso di crossover, dimensione della popolazione. Ciclo chiuso di feedback: le prestazioni dei compiti batch interni vengono aggregate in segnali di fitness esterna, in base ai quali il livello esterno seleziona, muta e aggiorna configurazioni interne migliori; le configurazioni aggiornate tornano al livello interno.
Se la varianza della valutazione interna è elevata, la fitness esterna può usare medie di ripetizioni multiple o compiti batch, mediane, statistiche robuste o limiti inferiori di confidenza con penalità, riducendo le selezioni errate dovute all'alta varianza; se necessario, aumentare il numero di campioni di valutazione per ogni configurazione. La parallelizzazione GPU può eseguire in batch un gran numero di compiti interni, ampliando la dimensione del campione e riducendo i tempi di attesa, rendendo più stabile la stima della fitness esterna.
Suggerimento di transizione
Dopo aver confermato che gli studenti sanno dire "il livello interno produce soluzioni e prestazioni, il livello esterno produce configurazioni e strategie, le prestazioni interne alimentano la fitness esterna", passare alla pagina successiva su applicazioni, esempi o riepilogo.
### Implementazione Tipica dell'Evoluzione dei Metodi: l'Architettura MetaDE
*Pagina 8*
> **Obiettivo della pagina:** Gli studenti devono comprendere come MetaDE affida all'ottimizzazione esterna le strategie di mutazione e i parametri del Differential Evolution.
**Punti chiave della lezione**
- Il livello esterno cerca configurazioni algoritmiche, il livello interno cerca soluzioni al problema. Vedere "strategia, modalità di crossover, F, CR vengono ottimizzati" significa livello esterno; vedere "questa soluzione è buona" significa livello interno. Per giudicare a quale livello appartiene qualsiasi descrizione, chiedere prima se ottimizza configurazioni o soluzioni.
- Una singola esecuzione del livello interno ha casualità, e usarla direttamente per confrontare due configurazioni porta facilmente a conclusioni accidentali. Prima del confronto, far eseguire più volte in modo indipendente le configurazioni e prendere la media (o mediana), poi sottoporle alla selezione esterna, altrimenti il livello esterno seleziona solo rumore casuale.
- Il costo di valutazione è approssimativamente uguale a numero di individui esterni × generazioni × numero di ripetizioni interne. Calcolare prima questo conto, poi decidere l'investimento in parallelizzazione, tensorizzazione e scheduling runtime; altrimenti, prima che il livello esterno converga, il budget di tempo e calcolo sarà già esaurito.
【Obiettivo della pagina】Comprendere come MetaDE affida all'evoluzione esterna l'ottimizzazione delle strategie di mutazione e dei parametri chiave del Differential Evolution, trasformando il "come evolvere" da preimpostazione manuale a ricerca adattiva.
【Ordine di presentazione】Prima chiarire la struttura a doppio livello (livello esterno cerca algoritmi, livello interno risolve problemi), poi spiegare gli oggetti dell'evoluzione esterna e il ciclo chiuso di verifica, quindi confrontare con DE fisso e illustrare costi e prerequisiti, infine fornire un esempio minimo e il posizionamento.
【Punti chiave della lezione】
Il livello di evoluzione esterno tratta una configurazione dell'algoritmo DE come un individuo, eseguendo selezione, crossover, mutazione ed eliminazione sullo spazio delle configurazioni; il livello dei compiti interno è il normale processo di risoluzione del Differential Evolution sul compito di ottimizzazione originale. L'oggetto dell'ottimizzazione esterna è la configurazione dell'algoritmo (decide "come cercare"), l'oggetto dell'ottimizzazione interna è la soluzione del problema (decide "quanto bene si cerca"). Si può spiegare con il diagramma: il livello esterno include strategie rand/1, best/1, current-to-best/1, modalità di crossover, F, CR ecc.; le configurazioni candidate vengono inviate, le prestazioni reali restituite.
Un individuo esterno codifica un intero insieme di comportamenti algoritmici, inclusi strategia di mutazione, modalità di crossover, fattore di scala F, probabilità di crossover CR, dimensione della popolazione ecc. Le differenze tra individui corrispondono alle tendenze comportamentali della stessa famiglia di algoritmi sotto diverse caratteristiche del problema.
Ogni configurazione candidata deve essere inviata all'esecuzione reale del compito originale, sottoposta alla verifica delle prestazioni reali; il livello esterno seleziona, elimina e conserva in base alla fitness restituita dal livello interno. Si forma un ciclo chiuso iterativo "generazione della configurazione→verifica sul compito→selezione tramite feedback". La fitness esterna può provenire solo dai risultati reali di esecuzione interna, non da meta-indicatori o giudizi a priori.
Le strategie e i parametri del DE tradizionale sono preimpostati dal ricercatore e fissati per tutto il processo; MetaDE affida questo potere decisionale all'evoluzione esterna, dotando l'algoritmo di capacità adattiva alle caratteristiche del problema — ad esempio preferendo rand/1 con maggiore esploratività e F più grande nelle fasi iniziali della ricerca, e passando a best/1 con convergenza più rapida e F più piccolo nelle fasi successive.
Ogni configurazione candidata deve eseguire completamente un compito interno (tipicamente con più esecuzioni indipendenti per la media, per sopprimere la casualità), e il costo di valutazione si moltiplica con la dimensione della popolazione esterna e le generazioni. Il budget di valutazione è approssimativamente uguale a numero di individui esterni × generazioni × ripetizioni interne. Pertanto MetaDE dipende fortemente da basi ingegneristiche come parallelizzazione, tensorizzazione e scheduling runtime.
Un individuo nella popolazione esterna è codificato come "rand/1 + crossover binomiale + F=0.5, CR=0.9", questa configurazione viene inviata all'esecuzione di più run indipendenti del compito interno, e la fitness media viene presa come fitness dell'individuo esterno; il livello esterno seleziona, muta e conserva le configurazioni migliori in base a questa, formando un ciclo chiuso iterativo "generazione della configurazione—verifica sul compito—selezione tramite feedback". Questo passo è la forma minima eseguibile di "usare un algoritmo evolutivo per migliorare un algoritmo evolutivo".
MetaDE è l'implementazione concreta del passaggio da idea ad architettura realizzabile dell'"evoluzione a doppio livello interno-esterno e meccanismi adattivi", e fornisce anche un paradigma metodologico per la successiva evoluzione delle strutture algoritmiche (AutoPSO, EvoGO).
La configurazione algoritmica del Differential Evolution, incluse strategia di mutazione, modalità di crossover e parametri di controllo), la ragione per cui deve essere realmente eseguita (risposta: solo i risultati reali di esecuzione possono costituire una base affidabile di fitness per la selezione esterna, i giudizi a priori sono facilmente incoerenti con le prestazioni reali), il cambiamento chiave rispetto al DE fisso (risposta: strategie e parametri di controllo non più fissi per tutto il processo, ma determinati dinamicamente dall'evoluzione esterna), la principale fonte di costo computazionale (risposta: ogni configurazione candidata deve eseguire completamente un compito interno, il costo di valutazione si moltiplica con la scala esterna e le generazioni), la relazione con il lavoro successivo (risposta: MetaDE fornisce un paradigma di implementazione di "usare un algoritmo evolutivo per migliorare un algoritmo evolutivo", offrendo un riferimento metodologico per la successiva evoluzione delle strutture algoritmiche).
Se si sceglie male, tornare prima alla divisione "il livello esterno cerca configurazioni, il livello interno risolve problemi" e alla definizione del "ciclo chiuso di verifica". Le due domande del caso: il punto della prima domanda è che non c'è garanzia di coerenza affidabile tra meta-indicatori o esperienza a priori e prestazioni reali sul compito, ed è necessario usare il feedback reale interno come base di selezione, altrimenti si conserveranno configurazioni apparentemente ragionevoli ma con prestazioni reali scarse, e la direzione evolutiva sarà sistematicamente deviata;
il punto della seconda domanda è stimare prima il budget totale di valutazioni (dimensione popolazione esterna×generazioni×ripetizioni interne), comprimere opportunamente la dimensione o le generazioni della popolazione esterna, garantire prioritariamente che le ripetizioni interne non siano inferiori al livello per una stima stabile della media (ad esempio 5-10 volte), aumentando contemporaneamente il grado di parallelismo, usando early stopping o modelli surrogati per il pre-filtraggio se necessario, ma qualsiasi candidato che entri nel confronto finale e decida l'adozione o il rifiuto deve comunque passare per la verifica reale sul compito originale. Riferimenti per il feedback: in caso di risposta corretta, lodare la capacità di collegare i concetti della pagina e indicarne le motivazioni; in caso di errore, suggerire di tornare alla spiegazione della pagina, trovare prove chiave o esempi prima di giudicare.
【Verifica della comprensione】Chiedere a uno studente a caso di riassumere con parole proprie la struttura a doppio livello e il ciclo chiuso di verifica di MetaDE, con il docente che integra le parole chiave mancanti in base alla risposta, come "il livello esterno ottimizza la configurazione dell'algoritmo", "il livello interno ottimizza la soluzione del problema", "le configurazioni candidate devono essere realmente eseguite una volta", "la fitness può provenire solo da risultati reali di esecuzione".
【Suggerimento di transizione】Dopo aver confermato che gli studenti sanno dire "il livello esterno cerca configurazioni algoritmiche, il livello interno cerca soluzioni al problema" e il ciclo chiuso "generazione della configurazione→verifica sul compito→selezione tramite feedback", passare alla pagina successiva su esempi, applicazioni o riepilogo.
### Evoluzione della Struttura Algoritmica: AutoPSO ed EvoGO
*Pagina 9*
> **Obiettivo della pagina:** Gli studenti devono comprendere il modo in cui avviene il salto dall'ottimizzazione dei parametri all'evoluzione della struttura algoritmica.
**Punti chiave della lezione**
- Di fronte a un nuovo metodo, localizzare prima il suo spazio di ricerca esterno: se cerca configurazioni numeriche, è regolazione di parametri; se cerca combinazioni di componenti e modalità di generazione dei candidati, è modifica strutturale. Questo ordine di domande permette di giudicare in una frase il livello del metodo.
- Per quanto si allarghi l'intervallo di ricerca dei fattori di apprendimento o della dimensione della popolazione, la struttura rimane fissa, la forma comportamentale non cambia, e in sostanza si rimane al livello dei parametri. Il criterio di giudizio è "se la combinazione di componenti è variabile", non "se l'intervallo di valori è più ampio".
- L'evoluzione a livello strutturale ha uno spazio di ricerca più ampio e valutazioni più costose, quindi la selezione esterna deve basarsi su campioni sufficientemente densi di confronto "struttura—prestazione". Prima di iniziare, chiedersi: c'è capacità di parallelizzazione batch per valutare simultaneamente molti compiti interni? Senza questo, l'evoluzione strutturale viene facilmente sommersa dal rumore di esecuzione.
> **Obiettivo della pagina**
>
> Questa pagina si concentra sull'"evoluzione della struttura algoritmica". Gli studenti devono comprendere il modo in cui avviene il salto dall'ottimizzazione dei parametri all'evoluzione della struttura algoritmica, e saper usare il "livello dello spazio di ricerca esterno" come criterio per distinguere regolazione di parametri e modifica strutturale.
>
> Ordine di presentazione e punti chiave:
>
> 1. Confrontare prima MetaDE con AutoPSO / EvoGO. Lo spazio di ricerca esterno di MetaDE è la configurazione e le strategie dell'algoritmo interno (fattori di apprendimento, probabilità di mutazione, pressione selettiva ecc.), appartenendo al livello dei parametri: struttura fissa, solo regolazione numerica, ciò che cambia è l'intensità comportamentale. Lo spazio di ricerca esterno di AutoPSO / EvoGO è la struttura algoritmica stessa: quali componenti partecipano alla combinazione, come appare il processo di generazione dei candidati, come si aggiorna lo stato. A livello strutturale ciò che è variabile sono i componenti e le modalità di connessione, ciò che cambia è la forma comportamentale. La chiave del giudizio non è il nome del metodo, ma cosa cerca effettivamente il livello esterno.
>
> La formula di aggiornamento velocità—posizione del PSO classico è fissa. AutoPSO la scompone in un pool di componenti combinabili, inclusi termine di velocità, topologia di vicinato, termine di perturbazione, strategia di riavvio ecc.; poi l'evoluzione esterna seleziona e assembla in un nuovo generatore di candidati. Così la "struttura di aggiornamento" stessa diventa una variabile ricercabile. Sottolineare: regolare i fattori di apprendimento cambia solo l'intensità comportamentale, modificare la combinazione di componenti cambia la forma comportamentale.
>
> Enfatizzare l'integrazione del feedback storico nel percorso di evoluzione strutturale. Le tracce di ricerca passate e i record di prestazione non servono più solo a "selezionare soluzioni", ma a decidere "dove modificare la struttura nel prossimo passo". Il feedback passa da filtro dei risultati a volante dell'aggiornamento strutturale — ciò che cambia è la direzione dei candidati strutturali del prossimo ciclo, non la selezione di risultati da un insieme di candidati già completati.
>
> Entrambi condividono lo stesso scheletro — l'algoritmo interno opera su compiti reali, il livello esterno evolve la struttura in base alle prestazioni interne. Il prerequisito chiave è la densità dei campioni: la parallelizzazione GPU esegue in batch un gran numero di compiti interni, rendendo sufficientemente densi i campioni di confronto "struttura—prestazione", e solo allora la selezione esterna ha significato statistico, non essendo influenzata dal rumore di singole esecuzioni. Implicazione ingegneristica: l'algoritmo passa da "scelta a priori una tantum" a "oggetto migliorabile in modo sostenibile"; il costo è uno spazio di ricerca strutturale più ampio e costi di valutazione più elevati, che dipendono dalla base di parallelizzazione tensorizzata, ed è anche la motivazione diretta della sezione successiva sul tema della parallelizzazione GPU.
> **Spunti per i materiali**
>
> - A sinistra il pool di componenti (operatori combinabili), al centro l'assemblaggio strutturale (selezione strutturale guidata dal feedback storico), a destra il generatore di candidati (istanziato dalla struttura esterna)
> - In basso la valutazione dei compiti interni e l'esecuzione batch parallela su GPU, con frecce di feedback che riportano le prestazioni interne al livello esterno. Durante la spiegazione si può seguire l'ordine "combinazione—istanziazione—valutazione—feedback".
**Gestione degli esercizi**
Questa pagina ha 5 domande a scelta multipla. Domanda 1, l'opzione corretta è "se lo spazio di ricerca esterno è la configurazione e le strategie dell'algoritmo interno, o la struttura algoritmica stessa"; punto di feedback: cercare numeri = regolazione di parametri, cercare combinazioni di componenti e modalità di generazione dei candidati = modifica strutturale. Domanda 2, l'opzione corretta è "scomporre il Particle Swarm Optimization in un pool di componenti combinabili, che l'evoluzione esterna seleziona e assembla in un nuovo generatore di candidati". Domanda 3, l'opzione corretta è "da solo 'selezione di soluzioni' a decidere 'dove modificare la struttura nel prossimo passo'". Domanda 4, l'opzione corretta è "rendere sufficientemente densi i campioni di confronto 'struttura—prestazione', perché la selezione esterna abbia significato statistico". Domanda 5, l'opzione corretta è "ricombinare termine di velocità, topologia di vicinato, termine di perturbazione e strategia di riavvio in un nuovo generatore di candidati".
Per ogni domanda, una risposta corretta può essere lodata per la capacità di collegare i concetti della pagina e indicarne le motivazioni; una risposta errata suggerisce di tornare alla spiegazione della pagina per trovare prove chiave o esempi.
Gestione del caso:
Il caso richiede di aggiornare un risolutore PSO a struttura fissa a un sistema a struttura evolvibile. Domanda 1, criterio: guardare il livello dello spazio di ricerca esterno. Se si regolano solo peso d'inerzia, fattori di apprendimento, dimensione della popolazione, numero di iterazioni e altri valori numerici, si rimane al livello dei parametri; solo quando il livello esterno può cambiare la combinazione di componenti e la modalità di generazione dei candidati, ad esempio riselezionando e assemblando termine di velocità, topologia di vicinato, termine di perturbazione, strategia di riavvio, facendo cambiare la forma comportamentale, si ha il salto al livello strutturale. Verifica operativa: congelare tutti gli iperparametri numerici, permettere al livello esterno di modificare solo la combinazione di componenti, se il comportamento di ricerca cambia sostanzialmente, allora si è saliti al livello strutturale.
Organizzare i record di esecuzione interni dopo ogni istanziazione strutturale in caratteristiche di feedback strutturate (combinazione di componenti, traiettoria di convergenza, forma della curva di fitness, pattern di fallimento o stagnazione ecc.), facendo sì che queste caratteristiche guidino direttamente le regole di aggiornamento strutturale esterno, ad esempio decidendo "quale componente modificare prioritariamente nel prossimo passo, quale connessione aggiungere o rimuovere", invece di un semplice ordinamento per prendere il migliore. Differenza rispetto a "solo per selezionare soluzioni": quando è solo per selezionare soluzioni, il feedback è un filtro dei risultati a posteriori; nell'uso in stile EvoGO, il feedback è un controllore di direzione a priori. Ricordare inoltre che è necessario abbinare la parallelizzazione GPU per eseguire in batch un gran numero di compiti interni, accumulando campioni di confronto sufficientemente densi.
**Copertura delle parole chiave**
- AutoPSO, EvoGO, MetaDE, livello dei parametri, livello strutturale, pool di componenti, generatore di candidati, feedback storico, parallelizzazione GPU, campioni di confronto struttura—prestazione. Verifica della comprensione e attività in classe: Come giudicare se un metodo appartiene alla regolazione di parametri o alla modifica strutturale? Cosa fanno rispettivamente AutoPSO ed EvoGO? Si può anche chiedere agli studenti di ripetere con un esempio vicino alla loro esperienza l'ordine di domande "cosa cerca il livello esterno".
> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno esprimere la differenza tra livello dei parametri e livello strutturale, e la dipendenza dell'evoluzione strutturale dalla densità dei campioni paralleli, passare alla pagina successiva sui contenuti relativi alla parallelizzazione GPU o al riepilogo delle applicazioni successive.
### Parallelizzazione GPU e l'Uso dell'Evoluzione per Migliorare l'Evoluzione
*Pagina 10*
> **Obiettivo della pagina:** Gli studenti devono padroneggiare come, con la parallelizzazione GPU, l'auto-ottimizzazione algoritmica diventi un processo computazionale eseguibile.
> **Obiettivo della pagina**
>
> Comprendere come, nell'architettura a doppio livello di "usare l'evoluzione per migliorare l'evoluzione", la parallelizzazione GPU trasformi il throughput di valutazione interno in feedback statistico utilizzabile dal livello esterno, rendendo l'auto-ottimizzazione algoritmica un processo eseguibile.
> **Ordine di presentazione**
>
> Prima stabilire l'intuizione del ciclo chiuso a doppio livello — esecuzione e punteggio batch interni, aggregazione delle prestazioni a livello intermedio, selezione, mutazione o aggiornamento delle configurazioni a livello esterno; poi spiegare perché la parallelizzazione GPU è insostituibile; infine usare punti critici ed esercizi per verificare se gli studenti distinguono realmente le responsabilità dei due livelli.
**Punti chiave della lezione**
- 1. Struttura a doppio livello. Il livello interno si occupa di eseguire in batch su GPU un gran numero di configurazioni algoritmiche candidate, ad esempio diversi iperparametri, operatori o strategie di ricerca, completando esecuzione e punteggio per ogni istanza di compito. La granularità del compito è piccola e il numero è grande, corrispondendo esattamente alle caratteristiche di throughput del calcolo batch. Il livello intermedio aggrega le prestazioni grezze di un gran numero di compiti interni in indicatori statistici, stimando la bontà di ogni configurazione sull'intera distribuzione dei compiti, formando la fitness per il livello esterno. Il livello esterno usa il feedback statistico come input per eseguire selezione, mutazione o aggiornamento, generando la configurazione della generazione successiva e rinviandola al livello interno, costituendo un ciclo chiuso. Throughput parallelo → feedback sulle prestazioni → selezione delle configurazioni. Maggiore è il grado di parallelismo, più abbondanti sono i campioni di feedback, più stabile è la stima della fitness da parte del livello esterno, più affidabile è la direzione di miglioramento delle configurazioni
- Le configurazioni migliorate vengono rinviate al livello inferiore, entrando nel successivo ciclo di throughput parallelo. 3. La parallelizzazione GPU è insostituibile. In un ciclo seriale tradizionale, il tempo wall-clock di una singola iterazione è determinato congiuntamente da "numero di configurazioni candidate × numero di campioni di compito", diventando insostenibile anche con scale moderate, e il ciclo seriale diventa così il principale collo di bottiglia che limita lo spazio delle configurazioni e la dimensione dei campioni di compito. La parallelizzazione GPU fa eseguire simultaneamente un gran numero di algoritmi interni, riducendo il ciclo seriale da collo di bottiglia principale a overhead batch accettabile, ampliando così simultaneamente lo spazio delle configurazioni esplorabili e la dimensione dei campioni di compito.
> **Spunti per i materiali**
>
> - Il diagramma del ciclo chiuso, dal basso verso l'alto rappresenta prestazioni del compito e feedback di fitness, dall'alto verso il basso rappresenta l'invio delle configurazioni
> - Ogni单元 rappresenta un'esecuzione parallela e un punteggio di una configurazione algoritmica su un'istanza di compito. Durante la spiegazione si può sottolineare che i due flussi di dati in alto e in basso hanno direzioni opposte, ma nessuno dei due può mancare. Il livello interno "esegue compiti con l'algoritmo e assegna punteggi", il livello esterno "seleziona configurazioni con l'evoluzione", non confondere i due livelli. Il feedback può provenire solo dalle prestazioni reali di esecuzione interna, non da ipotesi casuali del livello esterno o costanti impostate artificialmente. La stabilità della fitness esterna dipende dal volume di campioni fornito dal parallelismo interno
> - Più è sufficiente il parallelismo, più stabile è la stima
> - Quando i campioni sono pochi, controllare prima il throughput interno, invece di regolare frettolosamente i parametri esterni.
**Gestione degli esercizi**
Domanda 1, l'opzione corretta è "dati di prestazione aggregati dall'esecuzione parallela dei compiti interni su GPU". Se gli studenti scelgono male, tornare alla catena del ciclo chiuso e sottolineare: il feedback proviene necessariamente dai risultati reali di esecuzione di un gran numero di compiti interni, non da numeri casuali o etichette artificiali.
Domanda 2, l'opzione corretta è "il tempo wall-clock di una singola iterazione accumulato da un gran numero di configurazioni candidate e campioni di compito in un ciclo seriale". Se gli studenti scelgono male, suggerire che il collo di bottiglia è nel throughput di valutazione, non in questioni indipendenti dalla scala di calcolo come definizione di operatori, approssimazione di distribuzioni o interpretabilità.
Domanda 3, l'opzione corretta è "esecuzione e valutazione parallela interna → aggregazione del feedback sulle prestazioni → selezione o mutazione delle configurazioni esterna". Se gli studenti scelgono male, sottolineare che i dati vengono prima prodotti dal livello interno, poi aggregati in feedback, e infine usati dal livello esterno per la selezione delle configurazioni, e l'ordine non può essere invertito; i due livelli devono scambiarsi informazioni per funzionare.
Domanda 4, l'opzione corretta è "feedback statistico insufficiente, aumento del rumore nella stima della fitness esterna, convergenza rallentata". Se gli studenti scelgono male, spiegare che un parallelismo insufficiente non equivale a un arresto del sistema, ma rende il feedback statistico più sparso e la varianza maggiore, rallentando o persino fuorviando la ricerca esterna.
Domanda 5, l'opzione corretta è "un'esecuzione parallela e un punteggio di una configurazione algoritmica su un'istanza di problema specifica". Se gli studenti scelgono male, ricordare che l'unità del compito interno è un'esecuzione e un punteggio di "configurazione × istanza di problema", e che migliaia di tali compiti eseguiti in parallelo formano il throughput.
Domanda 1 del caso: spiegare che il livello interno esegue in batch parallelo su GPU configurazioni algoritmiche e completa i punteggi, gli indicatori vengono aggregati in feedback statistico per stimare la fitness, e il livello esterno esegue selezione, mutazione o aggiornamento e rinvia la configurazione della generazione successiva, formando il ciclo chiuso "throughput parallelo—feedback sulle prestazioni—selezione delle configurazioni". Domanda 2 del caso: combinare throughput e qualità del feedback: il ciclo seriale su CPU limita il numero di configurazioni candidate e la dimensione dei campioni di compito al throughput di singolo thread, e il tempo wall-clock di una singola iterazione diventa rapidamente insostenibile con la crescita della scala; i campioni di feedback diminuiscono, la varianza aumenta, il giudizio del livello esterno sulla bontà delle configurazioni diventa instabile, la direzione di ricerca tende a deviare, la convergenza rallenta o si blocca. La parallelizzazione GPU, aumentando il throughput interno, amplia sia le configurazioni e i compiti esplorabili, sia garantisce la qualità statistica del feedback.
**Verifica della comprensione**
Chiedere agli studenti di ripetere con parole proprie "throughput parallelo → feedback sulle prestazioni → selezione delle configurazioni", e di indicare di cosa si occupano rispettivamente livello interno ed esterno. Se gli studenti ricordano solo che la GPU è veloce, ma non spiegano chiaramente che il feedback proviene dall'esecuzione reale interna, tornare al diagramma del ciclo chiuso per integrare la spiegazione.
> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno distinguere le responsabilità dei due livelli e dire che la qualità del feedback dipende dal volume di campioni paralleli interni, passare alla pagina successiva su applicazioni, esempi o riepilogo.
### Progettare un Progetto Sperimentale di Ottimizzazione a Doppio Livello
*Pagina 11*
> **Obiettivo della pagina:** Gli studenti devono progettare attraverso la pratica un piano sperimentale che usi il fattore di mutazione del Differential Evolution come oggetto dell'evoluzione esterna.
**Punti chiave della lezione**
- Senza un confronto sullo stesso banco con F = 0.5 fisso e DE adattivo classico, qualsiasi "vittoria del livello esterno" è solo rumore. La baseline deve usare lo stesso budget di valutazione, lo stesso hardware e lo stesso insieme di seed casuali del vostro schema.
- La valutazione interna è naturalmente rumorosa: eseguire più volte e osservare contemporaneamente media, mediana e quantile peggiore, riportando se necessario intervalli di confidenza; separare compiti di training e di validazione, evitando che il livello esterno ricordi solo alcuni seed fortunati.
- Ogni mappatura da gene a configurazione runtime deve essere scritta come regola direttamente eseguibile, e registrata insieme all'esperimento con seed, budget, ID del compito, hardware e condizioni di stop. Solo se altri possono riprodurre esattamente secondo questi record, il progetto è veramente valido.
> **Obiettivo della pagina**
>
> Elevare il fattore di mutazione F del Differential Evolution (DE) da iperparametro fisso a oggetto evolvibile esterno, progettando un progetto sperimentale di ottimizzazione a doppio livello eseguibile e riproducibile.
>
> Ordine di presentazione e punti chiave:
>
> 1. Presentare prima il ciclo chiuso a doppio livello. Il livello esterno si occupa di evolvere la strategia F, il livello interno usa una configurazione F per eseguire il DE su un compito, restituendo le prestazioni del compito al livello esterno. Il livello esterno aggiorna la configurazione in base al feedback, formando il ciclo "configurazione → esecuzione → valutazione → aggiornamento".
>
> 2. Il livello interno deve essere reso un esperimento riproducibile. Dopo aver scelto funzioni di benchmark o compiti, bloccare la struttura principale del DE, la dimensionalità, il budget di valutazione e l'insieme di seed casuali, e l'unica quantità che varia è la configurazione F inviata dal livello esterno. Ogni esecuzione registra valore ottimale, generazioni di convergenza, tasso di successo, violazione di vincoli, ipervolume, diversità dei candidati e altri indicatori; queste sono tutte le informazioni che il livello esterno può vedere.
>
> 3. Il livello esterno non cerca un valore numerico, ma una strategia F. Le codifiche comuni includono F costante, F costante a fasi (come [F1,F2,F3] commutati per intervalli di generazioni) e funzioni di scheduling controllate da pochi geni (come triggerati da tasso di successo, varianza della popolazione o proporzione di generazioni). Le codifiche a strategia devono specificare chiaramente caratteristiche di input e regole di output.
>
> 4. La mappatura da genotipo a configurazione runtime deve essere esplicita e riproducibile. Ad esempio [F_inizio, F_fine, decadimento] può mappare a F(t)=F_inizio+(F_fine−F_inizio)×e^(−decadimento×t/T), dove t è la generazione corrente e T la generazione totale; [F1,F2,F3] può mappare a tre segmenti costanti. Lo stesso genotipo deve sempre produrre la stessa configurazione runtime, altrimenti il "buon gene" appreso dal livello esterno non è interpretabile né trasferibile.
>
> 5. L'esecuzione del ciclo chiuso dipende dalla valutazione batch. Dopo che la popolazione esterna ha generato un insieme di configurazioni F, lo scheduler distribuisce in parallelo i compiti DE interni, valutati in batch tensorizzato su GPU, aggregando gli indicatori prima di entrare nella selezione, mutazione, crossover e aggiornamento esterni. È necessario registrare seed, budget, ID del compito, modello hardware e condizioni di stop, permettendo ad altri di riprodurre con le stesse condizioni.
>
> 6. L'aggregazione delle valutazioni deve essere robusta. Il livello interno è naturalmente rumoroso, quindi si possono eseguire più run indipendenti, riportando media, mediana, quantile peggiore o intervalli di confidenza; contemporaneamente è necessario distinguere compiti di training e di validazione, evitando che il livello esterno ricordi solo alcuni seed fortunati.
>
> Filtrare prima con modelli a bassa fedeltà o valutazioni surrogate, poi rivalutare ad alta fedeltà pochi candidati; protezione della baseline: F=0.5 fisso e DE adattivo classico devono essere confrontati sullo stesso banco, con esperimenti di ablazione per confermare che il guadagno proviene dall'evoluzione esterna stessa, non da un maggior numero di valutazioni. Se lo spazio di ricerca esterno è troppo piccolo, l'ottimizzazione a doppio livello degenera in regolazione manuale dei parametri, e a quel punto è necessario ampliare lo spazio di codifica.
**Copertura delle parole chiave**
- Ottimizzazione a doppio livello, evoluzione esterna, valutazione interna, strategia F, mappatura esplicita, valutazione batch su GPU, baseline, ablazione, riproducibilità, protezione dal rumore.
> **Spunti per i materiali**
>
> - La pagina usa un diagramma a ciclo chiuso "ciclo esterno—compito interno—mappatura delle configurazioni—feedback dal compito" per mostrare il progetto, elencando i campi obbligatori: obiettivo del compito interno, oggetto della strategia esterna, modalità di mappatura F, indicatori di valutazione, parallelismo e budget, condizioni di baseline/ablazione/stop. Spunti per esercizi e guida alle risposte: Domanda 1, l'opzione corretta è "bloccare struttura principale DE, dimensionalità, budget di valutazione e insieme di seed casuali". Il punto è che solo bloccando gli altri fattori, le differenze dovute a diverse configurazioni F possono essere attribuite a F. Domanda 2, l'opzione corretta è "scheduling continuo F(t) con decadimento esponenziale per generazione". I tre geni [F_inizio,F_fine,decadimento] controllano rispettivamente punto di partenza, punto di arrivo e velocità di decadimento. Domanda 3, l'opzione corretta è "lo scheduler distribuisce in parallelo i compiti DE interni e valuta in batch tensorizzato su GPU". Le configurazioni devono prima essere eseguite e misurate, poi si può aggiornare la fitness esterna. Domanda 4, l'opzione corretta è "eseguire più run indipendenti e aggregare per mediana, quantile peggiore ecc., distinguendo compiti di training e validazione". Questa è la chiave per gestire il rumore interno e prevenire l'overfitting a seed fortunati. Domanda 5, l'opzione corretta è "confrontare sullo stesso banco con baseline come F=0.5 fisso, DE adattivo classico, ed eseguire esperimenti di ablazione per confermare la fonte del guadagno". Solo confrontando con lo stesso budget, hardware e insieme di seed, le conclusioni sono valide. L'esercizio del caso richiede di fornire regole di mappatura e schemi di aggregazione delle valutazioni. Si può progettare uno scheduling continuo o costante a fasi, ma deve essere esplicito e riproducibile
> - Il livello interno registra valore ottimale, generazioni di convergenza, tasso di successo e varianza, il livello esterno può aggregare in ranking, termine di convergenza e penalità di varianza
> - Usare F fisso e DE adattivo come baseline, poi eseguire un gruppo di ablazione "disattivando l'evoluzione esterna, campionando casualmente lo stesso numero di configurazioni", verificando che il guadagno non provenga dall'aumento del numero di valutazioni.
**Attività in classe**
Far progettare agli studenti in gruppi un progetto sperimentale di ottimizzazione a doppio livello che usi il fattore di mutazione DE come oggetto dell'evoluzione esterna, disegnando alla lavagna il ciclo chiuso tra livello esterno e interno; ogni gruppo deve almeno scrivere le regole di mappatura da genotipo a F, gli indicatori di valutazione, il modo di aggregazione della fitness esterna, e lo schema di baseline e ablazione.
**Verifica della comprensione**
Chiedere a uno studente a caso di spiegare in due frasi "perché tutto tranne F deve essere fissato" e "perché la mappatura esplicita è il presupposto della riproducibilità". Se gli studenti sanno collegare attribuzione, trasferibilità e riproduzione, significa che hanno padroneggiato il nucleo di questa pagina.
> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno disegnare il ciclo chiuso "mappatura delle configurazioni → esecuzione interna → feedback dal compito → aggiornamento esterno" e spiegare il ruolo di baseline e ablazione, passare alla pagina successiva su esempi o riepilogo.
### Sviluppo Continuo dei Sistemi Intelligenti e Sfide Ambientali
*Pagina 12*
> **Obiettivo della pagina:** Gli studenti devono comprendere le sfide di adattamento ambientale a lungo termine che i sistemi guidati da grandi modelli devono affrontare.
**Punti chiave della lezione**
- Sintetizzare lo sviluppo continuo in una formula: generazione dei candidati → verifica nell'ambiente reale → selezione (accettazione / rifiuto) → conservazione dei risultati. Se manca un anello, anche i componenti intelligenti forti possono solo fermarsi alla "capacità puntuale".
- L'aumento del punteggio di benchmark indica solo che i candidati sono migliori sui vecchi dati, non che siano più adatti nel nuovo ambiente. Per giudicare se un cambiamento merita di essere conservato, guardare la sua prestazione nell'ambiente reale, non il ranking sul set di replay.
- Chiedetevi: il mio sistema conserva e riutilizza i risultati già verificati? Ha mai rifiutato modifiche che avrebbero danneggiato le capacità esistenti? Se entrambe le risposte sono "no", allora non ha ancora veramente iniziato lo "sviluppo continuo".
Obiettivo della pagina
Questa pagina discute lo sviluppo continuo e le sfide ambientali dei sistemi intelligenti; il nucleo non è continuare a chiedere quanto sia forte un singolo componente intelligente, ma comprendere che i componenti intelligenti forti sono solo materiali, che devono essere organizzati in un quadro di sistema in grado di adattarsi all'ambiente a lungo termine.
Punti chiave della lezione
1. Un componente forte non equivale a un sistema sostenibile. Modelli più grandi, capacità di generazione e ragionamento più forti, punteggi di benchmark più alti non portano automaticamente ad adattamento a lungo termine. Collegare componenti intelligenti a un sistema è solo il primo passo.
Generazione dei candidati, verifica nell'ambiente reale, selezione dei cambiamenti, persistenza dei risultati. La generazione dei candidati richiede di produrre continuamente candidati realmente diversi in termini di strategie, strutture o parametri; se i candidati sono altamente omogenei, l'evoluzione perde la materia prima. La verifica nell'ambiente reale fa entrare i candidati in compiti e feedback reali, esponendo derive di distribuzione, condizioni al contorno e scenari a coda lunga che gli indicatori offline non vedono. La selezione dei cambiamenti deve accettare cambiamenti efficaci e rifiutare modifiche che danneggerebbero le capacità esistenti, quest'ultima spesso la principale fonte di degrado a lungo termine. La persistenza dei risultati conserva schemi, strategie o esperienze già verificate come efficaci, per il riutilizzo nella generazione di candidati successivi, formando una traiettoria di sviluppo accumulabile.
Gli indicatori offline descrivono solo le prestazioni sui dati passati, mentre nell'ambiente reale la distribuzione dei compiti deriva, i vincoli sulle risorse cambiano, nuove esigenze affluiscono continuamente. Ottimizzando solo entro obiettivi preimpostati o indicatori offline, il sistema gira attorno a obiettivi proxy chiusi; al cambiare dell'ambiente, modifiche non verificate realmente possono silenziosamente erodere le capacità esistenti. Quindi selezione e memoria sono ugualmente cruciali.
Estendere da ciò che i componenti intelligenti possono fare a come il sistema organizza lo sviluppo continuo e affronta le sfide dell'ambiente reale. Senza le quattro categorie di meccanismi, anche gli agenti intelligenti forti possono ripetere errori in compiti a lungo termine, o danneggiare le capacità esistenti negli aggiornamenti; solo con le quattro categorie di meccanismi in ciclo chiuso, le capacità forti possono essere accumulate stabilmente.
Spunti per i materiali
Il diagramma può evidenziare il passaggio dai componenti intelligenti forti al quadro di sistema di sviluppo continuo, con l'ambiente esterno che esercita pressione continua attraverso deriva dei compiti, vincoli sulle risorse, afflusso di nuove esigenze, e le frecce del ciclo chiuso corrispondenti a candidati batch, feedback reali, cambiamenti selezionati, sedimentazione e riutilizzo.
Errori comuni
Scambiare un miglioramento del punteggio di un benchmark per un'evoluzione completata del sistema. Il miglioramento del punteggio indica solo che i candidati sono migliori sui vecchi dati; se meritino di essere accettati e conservati richiede ancora verifica nell'ambiente reale e selezione.
Spunti per gli esercizi
La risposta più accurata è stabilire un quadro di organizzazione del sistema in grado di affrontare cambiamenti ambientali a lungo termine, facendo sì che i candidati siano sottoposti a verifica reale e vengano selezionati, accumulati e conservati. Domanda 2: deve esserci una verifica reale, perché l'ottimizzazione offline non può esporre i modi in cui i candidati falliscono nell'ambiente reale. Domanda 3: il ruolo centrale dopo la verifica è accettare cambiamenti efficaci, rifiutare modifiche che danneggiano le capacità esistenti, e conservare persistentemente i risultati verificati. Domanda 4: in assenza delle quattro categorie di meccanismi, è più probabile che si verifichino errori ripetuti a lungo termine o il danneggiamento delle capacità esistenti negli aggiornamenti. Domanda 5: il focus si sposta da ciò che i componenti intelligenti possono fare a come il sistema organizza lo sviluppo continuo e affronta le sfide ambientali.
Nella diagnosi di un sistema di gestione automatizzata in ambiente produttivo, si dovrebbe indicare la mancanza di generazione dei candidati, verifica nell'ambiente reale, selezione dei cambiamenti e persistenza dei risultati, spiegando separatamente le conseguenze: l'omogeneità delle strategie porta a fallimenti ripetuti su guasti simili, il replay offline non riesce a esporre la deriva produttiva, gli aggiornamenti distruttivi vengono messi in produzione integralmente, la mancata conservazione dell'esperienza fa ripartire da zero le nuove sessioni. Le contromisure possono usare shadow traffic o canali di rilascio graduale per la verifica reale, impostare gate di cambiamento, costruire una base di esperienze per conservare schemi verificati e condizioni di applicabilità; spiegando contemporaneamente i compromessi: rilascio graduale e gate rigorosi riducono la velocità di evoluzione e l'efficienza del rilascio, aumentando i costi, ed è necessario bilanciare velocità di esplorazione e non regressione delle capacità esistenti.
Verifica della comprensione
Il mio sistema conserva e riutilizza i risultati verificati? Ha rifiutato modifiche che avrebbero danneggiato le capacità esistenti? Se entrambe le risposte sono no, il sistema non ha ancora veramente iniziato lo sviluppo continuo.
Suggerimento di transizione
Dopo aver confermato che gli studenti sanno ripetere il ciclo chiuso in quattro fasi e la sua necessità, passare alla pagina successiva su esempi, applicazioni o riepilogo.
### Avvio Rapido e Configurazione Semplificata dell'Ambiente
*Pagina 13*
> **Obiettivo della pagina:** Gli studenti devono comprendere come accedere rapidamente al framework EvoX tramite strumenti e interfacce snelli.
**Punti chiave della lezione**
- Dopo aver configurato l'ambiente, usare prima un esempio minimo per confermare che la catena "problema → algoritmo → esecuzione → risultato" sia fluida, poi passare agli esperimenti reali. Molti problemi che sembrano "l'algoritmo non converge" derivano in realtà da dipendenze mancanti o dispositivi non correttamente richiamati.
- Dopo l'installazione, verificare immediatamente che le versioni delle dipendenze corrispondano al tipo di dispositivo target (CPU / GPU / cluster). Prima vengono esposti i problemi ambientali, minore è il costo di riparazione; attendere errori a metà di un esperimento lungo spreca molto più tempo dell'investimento nella verifica preliminare.
- Far dipendere i moduli algoritmo e problema solo da interfacce standardizzate, senza hard-codare dispositivi specifici o dimensioni di parallelismo nel codice. Così, estendendo da singola macchina a cluster distribuito, spesso basta regolare la configurazione di scheduling del Runtime, senza riscrivere la logica dell'algoritmo.
Obiettivo della pagina
Come completare l'installazione e l'inizializzazione di EvoX con un processo minimale assistito dall'AI, e collegare risorse di calcolo di base e ambiente evolutivo tramite interfacce standardizzate, riportando rapidamente i ricercatori a "progettare il problema".
Ordine di presentazione
Prima evidenziare la contraddizione centrale — quando si inizia realmente a fare esperimenti, ciò che si incontra per primo spesso non è un problema di algoritmo, ma problemi ambientali come installazione di pacchetti, allineamento delle dipendenze, selezione dei dispositivi e localizzazione degli errori. Poi presentare il processo minimo in quattro passi "installazione → configurazione → verifica → esecuzione", quindi introdurre la progettazione disaccoppiata delle interfacce standardizzate, e infine consolidare con errori comuni ed esercizi.
Punti chiave della lezione
Completare l'inizializzazione dell'ambiente, specificando se questo esperimento usa CPU, GPU o cluster; verifica: controllare se le dipendenze sono complete e se il dispositivo di calcolo target è riconoscibile e richiamabile; esecuzione: far girare l'esempio minimo, confermando che la catena "problema → algoritmo → esecuzione → risultato" sia completa. Al termine dei quattro passi si ottiene una linea di base affidabile, utilizzabile come riferimento per anomalie successive, per giudicare se il problema è nell'ambiente o nella progettazione dell'esperimento.
2. Accesso minimale assistito dall'AI. Gli strumenti AI possono comprimere installazioni multi-passo, recupero di dipendenze e configurazioni di base in una o due istruzioni in linguaggio naturale, e fornire suggerimenti di riparazione mirati in caso di conflitti di versione, dipendenze mancanti o dispositivi non disponibili. Il loro valore non è fare ricerca al posto del ricercatore, ma abbassare la soglia di accesso al framework e comprimere i costi ingegneristici non di ricerca.
3. Interfacce standardizzate. Algoritmo, moduli del problema e workflow sono scritti solo per interfacce unificate, e se alla base ci sia GPU, multi-core locale o cluster distribuito è affidato allo scheduling del Runtime. Cambiando hardware o regolando la scala di parallelismo, tipicamente non è necessario riscrivere il codice dell'algoritmo, e i costi di accoppiamento tra algoritmo, problema e potenza di calcolo diminuiscono significativamente.
4. Errori comuni. Interpretare la "configurazione minimale" come "non preoccuparsi dello strato inferiore" è l'errore più facile. Il minimalismo affida solo il lavoro ripetitivo agli strumenti, e la corrispondenza tra dispositivi e versioni, e se la potenza di calcolo sia realmente schedulata, vanno comunque confermati nella fase di verifica. Più semplice è la configurazione, più bisogna coltivare l'abitudine di "far girare prima l'esempio minimo, poi iniziare l'esperimento formale", altrimenti i problemi ambientali possono scoppiare a metà di un esperimento lungo, con costi molto superiori alla verifica preliminare.
Attività in classe
Si può chiedere agli studenti di ripetere con parole proprie il processo di questa pagina, e fare un esempio di una situazione in cui "sembra che l'algoritmo non converga, ma in realtà mancano dipendenze o il dispositivo non è correttamente richiamato", verificando la comprensione del ruolo della fase di verifica.
Gestione degli esercizi
Le 5 domande a scelta multipla di questa pagina vertono su valore degli strumenti AI, scopo delle interfacce standardizzate, punti chiave della fase di verifica, ruolo dell'esempio minimo, strategia di migrazione da singola macchina a cluster. Nella gestione, far prima scegliere la risposta, poi chiedere la motivazione. Domanda 1, l'opzione corretta è "comprimere installazione multi-passo, dipendenze e configurazione in poche istruzioni, con suggerimenti di riparazione in caso di errore", guidando gli studenti a distinguere configurazione ingegneristica da progettazione algoritmica e scheduling di esecuzione. Domanda 2, selezionare "algoritmo, problema e potenza di calcolo", sottolineando che il livello di interfaccia si colloca tra ambiente evolutivo e risorse di calcolo di base. Domanda 3, selezionare "se le dipendenze sono complete e le versioni corrispondono, se il dispositivo di calcolo target è riconoscibile e richiamabile", ricordando che la verifica riguarda l'ambiente e le risorse stesse.
Domanda 4, selezionare "serve a confermare che la catena end-to-end tra installazione, configurazione, chiamata ai dispositivi e output dei risultati sia collegata", l'esempio minimo stabilisce una linea di base affidabile, non un benchmark di prestazioni. Domanda 5, selezionare "mantenere pressoché invariati algoritmo e moduli del problema, regolando solo scheduling e configurazione dei dispositivi del Runtime", perché la scalabilità orizzontale cambia solo la configurazione di scheduling, senza toccare il codice di algoritmo e problema. Lodare in caso di risposta corretta, guidare gli studenti a tornare al paragrafo corrispondente per trovare prove in caso di errore.
Gestione del caso
"Completare la messa in produzione dell'ambiente sperimentale EvoX entro una settimana" richiede di progettare un processo minimale di avvio e spiegare il ruolo degli strumenti AI. Si suggerisce di sviluppare in quattro passi: l'installazione, con l'AI che genera i comandi di installazione di EvoX e delle dipendenze in base all'ambiente della macchina e uniforma le versioni; la configurazione, con l'AI che genera la configurazione di base combinando versione di Python e tipo di dispositivo, specificando l'uso di una workstation GPU; la verifica di completezza delle dipendenze, compatibilità delle versioni, riconoscibilità e richiamabilità della GPU; l'esecuzione dell'esempio minimo per completare la catena end-to-end. Il ruolo degli strumenti AI attraversa i quattro passi: tradurre operazioni multi-passo di consultazione della documentazione e risoluzione di errori uno per uno in poche istruzioni eseguibili, fornendo suggerimenti di riparazione in caso di errori.
La seconda domanda riguarda la riduzione dei costi di accoppiamento tramite interfacce standardizzate; il punto è che l'algoritmo è scritto solo per interfacce unificate, e quale GPU, quanti processi locali o quali nodi del cluster eseguano è deciso dal Runtime, quindi la migrazione tipicamente cambia solo scheduling e configurazione dei dispositivi, senza riscrivere il codice di algoritmo e problema. Prima della migrazione è necessario verificare: coerenza delle versioni delle dipendenze tra ambiente nuovo e originale, riconoscibilità e richiamabilità dei dispositivi target, corretto funzionamento della distribuzione dei dati e della comunicazione tra nodi, e rieseguire l'esempio minimo nella nuova topologia per completare la catena end-to-end, registrando le prestazioni prima e dopo la migrazione, per evitare di scambiare differenze ambientali per miglioramenti algoritmici.
Verifica della comprensione
Chiedere a uno studente a caso di riassumere con parole proprie i punti chiave di questa pagina, con il docente che integra le parole chiave mancanti in base alla risposta, come "processo minimo in quattro passi", "interfacce standardizzate", "disaccoppiamento", "linea di base affidabile", "far girare prima l'esempio minimo" ecc.
Suggerimento di transizione
Dopo aver confermato che gli studenti sanno esprimere le due relazioni "configurazione minimale non significa non preoccuparsi dello strato inferiore" e "scrivere algoritmi sopra le interfacce, schedulare la potenza di calcolo sotto le interfacce", passare alla pagina successiva su esempi, applicazioni o riepilogo.
### Competenze Chiave e Trasformazione del Pensiero del Ricercatore
*Pagina 14*
> **Obiettivo della pagina:** Gli studenti devono comprendere il passaggio del ruolo centrale del ricercatore nella ricerca scientifica assistita dall'AI dalla scrittura manuale di codice alla formulazione di domande chiave.
**Punti chiave della lezione**
- Prima di ogni esperimento, chiedersi: il livello di questo cambiamento è parametro, programma, struttura algoritmica o processo di ricerca? Se il livello non è chiaro, tutti i risultati successivi saranno difficili da interpretare.
- Indicatori, segnali proxy, soglie di accettazione, criteri di fallimento. Impostare un solo indicatore principale è il rischio più comune: non si sa né "quanto buono è abbastanza buono", né "quanto cattivo è da scartare", e le conclusioni non reggono alle domande.
- La baseline è allo stesso livello? Il budget è uguale? I seed sono stati rieseguiti più volte? Le condizioni di calcolo sono coerenti? I test statistici sono appropriati? Provate a pensare: cambiando un seed casuale, la vostra conclusione regge ancora?
> **Obiettivo della pagina**
>
> Comprendere che nella ricerca scientifica assistita dall'AI, il ruolo centrale del ricercatore si sposta dalla "scrittura manuale dell'implementazione" alla "formulazione di domande chiave, definizione dei criteri di valutazione e giudizio critico sulle prove". Questa pagina usa un radar delle competenze e tre tipi di domande chiave per illustrare i punti concreti di questa trasformazione del pensiero.
>
> Ordine di presentazione e punti chiave:
>
> In passato la capacità era misurata da "saper scrivere personalmente l'implementazione"; oggi codice e script sperimentali possono essere prodotti rapidamente dall'AI, e ciò che è veramente scarso è formulare domande chiave, definire valutazioni e criteri di confronto equo, e giudicare criticamente le prove prodotte dall'AI. Il radar confronta "ricercatore tradizionale" e "ricercatore AI Native": il primo enfatizza l'implementazione del codice, il secondo si distingue maggiormente in definizione del problema, progettazione della valutazione, confronto equo, giudizio critico e gusto scientifico, rispecchiando "l'AI implementa le risposte, l'uomo controlla la direzione".
>
> Una volta abbassato il costo di implementazione, il ruolo del ricercatore si sposta da "implementatore" a definitorе del problema, progettista dell'esperimento e arbitro delle prove. Il definitorе del problema giudica quali problemi hanno valore scientifico; il progettista dell'esperimento trasforma idee vaghe in protocolli sperimentali eseguibili, riproducibili e comparabili; l'arbitro delle prove mantiene il dubbio su curve, indicatori e conclusioni, indagando i confini di affidabilità e le condizioni di fallimento.
>
> 3. Tre tipi di domande chiave a cui solo l'uomo può rispondere:
>
> Si vuole modificare parametri di ottimizzazione, implementazione del programma, struttura algoritmica, o il processo di ricerca stesso? Livelli diversi danno alle conclusioni significati completamente diversi.
>
> Indicatori, segnali proxy, soglie di accettazione, criteri di fallimento, tutti e quattro indispensabili. Impostare un solo indicatore principale rende facile non sapere né "quanto buono è abbastanza buono", né "quanto cattivo è da scartare".
>
> Baseline, budget, casualità, condizioni di calcolo e test statistici sono allineati. Confronti non allineati spesso scambiano fluttuazioni casuali o vantaggi di calcolo per progressi algoritmici.
>
> L'AI può generare molte soluzioni "che girano", ma fattibile non significa di valore. Taste matters — tra molte soluzioni fattibili, giudicare quale problema, quale ipotesi, quale prova abbia realmente valore scientifico. Il baricentro delle competenze si sposta dalla velocità di codifica al pensiero critico, all'astrazione di sistema, al giudizio di dominio e alla divisione uomo-macchina.
>
> Compiti in stile EvoX / MetaDE. L'AI può generare in un giorno decine di varianti di operatori di mutazione e relativi script sperimentali, ma il ricercatore deve decidere se migliorare l'operatore di mutazione, ottimizzare il processo di valutazione, o ristrutturare lo spazio di ricerca, e impostare su questa base indicatori multi-obiettivo e baseline eque; altrimenti si ottengono solo risultati "che girano", non conoscenza affidabile.
>
> Trasformazione del pensiero, definitorе del problema, progettista dell'esperimento, arbitro delle prove, oggetto del cambiamento, valutazione e feedback, confronto equo, Taste matters, l'AI implementa le risposte/l'uomo controlla la direzione.
> **Spunti per i materiali**
>
> - Radar a sei dimensioni — implementazione del codice, definizione del problema, progettazione della valutazione, confronto equo, giudizio critico, gusto scientifico
> - In quali dimensioni si concentrano le differenze tra ricercatore tradizionale e ricercatore AI Native?
**Gestione degli esercizi**
L'opzione corretta è "da 'implementatore' a 'definitorе del problema, progettista dell'esperimento e arbitro delle prove'". Punto di feedback: l'implementazione può essere ampiamente assunta dall'AI, ciò che è scarso è giudicare quale problema merita risposta e quale prova merita fiducia.
Se si sta ottimizzando un parametro, riscrivendo un programma, adattando la struttura algoritmica, o ristrutturando il processo di ricerca". Punto di feedback: chiedere prima il livello del cambiamento, poi parlare di bontà dei risultati; se il livello non è chiaro, non si può spiegare se il miglioramento è affidabile.
L'opzione corretta è "indicatori, segnali proxy, soglie di accettazione e criteri di fallimento". Punto di feedback: i quattro definiscono rispettivamente modalità di osservazione, segnali approssimati, criteri di accettazione e condizioni di fallimento, tutti indispensabili.
L'opzione corretta è "baseline, budget, casualità, condizioni di calcolo e test statistici". Punto di feedback: queste sono le variabili di controllo del confronto equo; la mancata coerenza fa scambiare fluttuazioni casuali o vantaggi di calcolo per miglioramenti algoritmici.
L'opzione corretta è "giudicare se modificare l'operatore di mutazione, il processo di valutazione o lo spazio di ricerca, e impostare su questa base indicatori multi-obiettivo e baseline eque". Punto di feedback: i giudizi di direzionalità e valutazione incarnano il gusto scientifico, e solo così si trasforma "ciò che gira" in "conoscenza affidabile".
Gestione del caso di studio:
Livello dei parametri (intensità di mutazione), livello degli operatori (sostituire l'operatore di mutazione), livello strutturale (ristrutturare la spina dorsale dell'algoritmo) o livello di processo (processo di valutazione e selezione). Valutazione e feedback: indicatore principale e segnali proxy (come ipervolume, numero di valutazioni per la convergenza), soglie di accettazione (miglioramento relativo alla baseline), criteri di fallimento (significativamente peggiore della baseline o varianza eccessiva = scartare).
Stessa baseline, stesso budget di valutazione; seed casuali fissati e rieseguiti più volte; stesse condizioni di calcolo; test statistici appropriati (come il test di ranghi). Conseguenze della negligenza: scambiare fluttuazioni casuali o dividendi di calcolo per progressi algoritmici, ottenendo infine solo risultati "che girano".
**Verifica della comprensione**
Chiedere agli studenti di rispondere in una frase — "il livello di questo cambiamento è parametro, programma, struttura algoritmica o processo di ricerca?" e spiegare perché se il livello non è chiaro i risultati successivi sono difficili da interpretare. Si può anche chiedere di ripetere il kit in quattro parti della valutazione e feedback e la checklist di autoverifica del confronto equo.
> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno distinguere i tre tipi di domande chiave: oggetto del cambiamento, valutazione e feedback, confronto equo, e comprendono lo spostamento del ruolo del ricercatore, passare alla pagina successiva su esempi, applicazioni o ulteriore sviluppo dell'evoluzione dei metodi.
### Costruire un'Infrastruttura Evolutiva per lo Sviluppo Sostenibile
*Pagina 15*
> **Obiettivo della pagina:** Gli studenti devono comprendere il posizionamento di EvoX come infrastruttura che connette il mondo reale e l'evoluzione a lungo termine.
> **Obiettivo della pagina**
>
> Comprendere che EvoX non è un risolutore una tantum, ma un'infrastruttura aperta che connette il mondo reale e l'evoluzione a lungo termine.
> **Ordine di presentazione**
>
> Confrontare prima "risolutore una tantum" e "infrastruttura a lungo termine". L'ottimizzazione tradizionale affronta benchmark statici, eseguendo una volta e ottenendo una soluzione per finire; il mondo reale invece cambia continuamente, con obiettivi che derivano, vincoli che si aggiornano, costi di valutazione elevati e feedback ritardati, richiedendo quindi una base eseguibile a lungo termine, riutilizzabile ed estensibile.
>
> Connettere il mondo reale, accedendo ad ambienti e feedback reali; sostenere l'evoluzione a lungo termine, generando continuamente candidati, verificando l'efficacia, sedimentando i miglioramenti; affrontare problemi complessi in cambiamento, gestendo scenari dinamici, conflitti multi-obiettivo ed esplorazione continua; essere aperta e sostenibile, portando algoritmi, problemi, runtime e meccanismi di feedback su capacità pubbliche.
>
> Esecuzione continua—verifica—conservazione—ri-evoluzione. Il sistema genera continuamente candidati e li distribuisce nell'ambiente reale, l'ambiente restituisce segnali di valutazione, i candidati e i miglioramenti efficaci vengono conservati e sedimentati, e quando obiettivi e ambiente cambiano si continua a schedulare nuove esplorazioni sulla stessa base.
>
> Collegare a EvoX simulazioni ingegneristiche costose o compiti robotici, ricevendo continuamente segnali di valutazione e conservando i candidati efficaci; algoritmo, operatori, runtime e meccanismi di feedback non devono essere ricostruiti da zero, ma estesi e mantenuti come una rete urbana.
**Punti chiave della lezione**
- L'attenzione dell'apprendimento dovrebbe concentrarsi su interfacce, scheduling, ciclo chiuso di feedback e meccanismi di sedimentazione dei risultati, non solo su un singolo algoritmo. Mancando un passo, il sistema degenera in risolutore una tantum, incapace di accumulare miglioramenti a lungo termine. Quando ambiente o obiettivo cambiano, controllare prima se i moduli del problema e i meccanismi di feedback possono essere riutilizzati, poi decidere se cambiare algoritmo, evitando di ricostruire da zero l'intera pipeline. Si può usare un diagramma per evidenziare la relazione ciclica tra ambiente reale, infrastruttura aperta EvoX, scheduling di algoritmi e runtime, sedimentazione dei risultati di miglioramento a lungo termine.
> **Spunti per gli esercizi**
>
> - Le domande a scelta multipla vertono su posizionamento dell'infrastruttura, ordine del ciclo chiuso, connessione al mondo reale, vantaggio di riutilizzo quando l'ambiente cambia, caratteristiche di apertura e sostenibilità. Nel feedback, cogliere: il mondo reale cambia continuamente
> - il ciclo chiuso inizia dall'esecuzione continua
> - deve accedere a feedback reale, non solo simulare
> - quando cambia, continuare a schedulare e riutilizzare sulla stessa base
> - le capacità pubbliche devono essere estensibili, riutilizzabili, continuabili. Simulatori e piattaforme sperimentali robotiche come ambienti reali collegati, generando continuamente candidati di strategie di controllo, raccogliendo segnali di valutazione come consumo energetico, precisione, adattabilità, conservando miglioramenti efficaci, ed entrando in un nuovo ciclo di evoluzione. Se l'obiettivo diventa un'ottimizzazione multi-obiettivo che bilancia precisione e consumo energetico, il livello algoritmico viene sostituito con un algoritmo evolutivo multi-obiettivo, i moduli del problema modificano funzione obiettivo e vincoli, i meccanismi di feedback estendono i canali di valutazione, e lo scheduling runtime continua a operare sulla stessa base.
**Verifica della comprensione**
Chiedere agli studenti di spiegare con parole proprie "perché serve un'infrastruttura invece di un risolutore", poi ripetere i quattro passi del ciclo chiuso. Se gli studenti sanno dire che EvoX è la base, che il ciclo chiuso è accumulabile, e che quando cambia si riutilizza prima e si sostituisce l'algoritmo poi, possono passare alla pagina successiva.
### Riepilogo e Prospettive: Verso Forme di Intelligenza di Ordine Superiore
*Pagina 16*
> **Obiettivo della pagina:** Gli studenti devono rivedere il meccanismo complessivo dell'evoluzione dei metodi, comprendendo il suo grande significato nel guidare i sistemi intelligenti verso l'auto-evoluzione.
> **Obiettivo della pagina**
>
> Rivedere il meccanismo complessivo dell'evoluzione dei metodi, comprendendo come spinge i sistemi intelligenti da "risolvere risposte" a "migliorare metodi", e verso forme di auto-evoluzione di ordine superiore.
**Punti chiave della lezione**
- Questa pagina può essere colta con una formula — "spazio delle soluzioni → spazio dei metodi". Il criterio di giudizio è: l'oggetto attualmente iterato è la "soluzione" o il "metodo che genera soluzioni"? Se la risposta diventa la seconda, si è entrati nell'evoluzione dei metodi. L'evoluzione interna cerca soluzioni nello spazio delle soluzioni per un dato problema, portando il metodo corrente al massimo, producendo soluzioni candidate e risultati di valutazione
- L'evoluzione esterna, nello spazio dei metodi, usa il feedback dei compiti per migliorare i metodi di risoluzione, e l'oggetto di ricerca diventa algoritmi, operatori o strutture. La direzione del ciclo chiuso è: il feedback dei compiti va dal livello interno al livello esterno, l'aggiornamento del metodo va dal livello esterno al livello interno. Così, la qualità della soluzione diventa il segnale di valutazione esterno, e il metodo migliorato torna al livello interno, formando un ciclo chiuso continuo dallo spazio delle soluzioni allo spazio dei metodi. Per realizzare concretamente l'evoluzione dei metodi, è necessario organizzare popolazione, risultati di valutazione e stati dell'algoritmo in tensori calcolabili integralmente, e su questa base schedulare potenza di calcolo eterogenea. EvoX, attraverso il calcolo tensorizzato e l'architettura di base unificata, disaccoppia "come evolvere" e "come schedulare efficientemente", rendendo l'evoluzione dei metodi e l'evoluzione continua a livello di sistema ingegneristicamente realizzabili, spingendo i sistemi intelligenti da "risolvere risposte" a "migliorare metodi", e persino verso un'auto-evoluzione di ordine superiore. MetaDE. MetaDE risolve problemi con DE (Differential Evolution) interno, e cerca configurazioni o strutture di DE con l'evoluzione esterna, facendo partecipare all'iterazione il "metodo di risoluzione stesso". Ciò che cerca non è la soluzione di un problema specifico, ma il meccanismo che genera soluzioni, che è l'espressione intuitiva del passaggio dallo spazio delle soluzioni allo spazio dei metodi. Forme di intelligenza di ordine superiore non significano ottenere una volta la soluzione ottimale, ma poter generare continuamente metodi più forti e capacità di sistema più forti. La chiave del prossimo passo è rendere il ciclo chiuso interno-esterno più stabile e trasferibile, e supportare paradigmi di ricerca AI Native su basi come EvoX. Errori comuni: Il livello interno cerca "soluzioni di un dato problema", il livello esterno cerca "algoritmi, operatori o strutture". La direzione del feedback dei compiti è interno→esterno, la direzione dell'aggiornamento del metodo è esterno→interno. Non confondere l'evoluzione dei metodi con la normale regolazione dei parametri. Se il sistema cerca solo soluzioni migliori in uno spazio di soluzioni fisso, senza modificare il metodo di risoluzione stesso, non appartiene all'evoluzione dei metodi. Quando non si è sicuri se un sistema appartiene all'evoluzione dei metodi, vedere se sta anche cercando il "metodo che genera soluzioni". Se sì, sta facendo evoluzione dei metodi
- altrimenti è solo normale regolazione di parametri.
> **Spunti per gli esercizi**
>
> - Far diventare il metodo di risoluzione stesso — algoritmo, operatore, struttura o strategia — oggetto di iterazione e miglioramento. Se si sceglie male, distinguere "cercare soluzioni migliori nello spazio delle soluzioni" e "far partecipare il metodo stesso all'iterazione". Il livello interno cerca soluzioni nello spazio delle soluzioni, il livello esterno usa il feedback dei compiti per migliorare i metodi di risoluzione, cioè lo spazio dei metodi. Direzione del feedback interno→esterno, direzione dell'aggiornamento esterno→interno. Fornire calcolo tensorizzato e base unificata, rendendo l'evoluzione dei metodi e l'evoluzione continua a livello di sistema ingegneristicamente realizzabili
> - La chiave è organizzare popolazione, valutazione e stato in tensori calcolabili integralmente, e disaccoppiare "come evolvere" e "come schedulare". Cercare con l'evoluzione esterna configurazioni o strutture di DE, facendo partecipare all'iterazione il metodo di risoluzione stesso, incarnando così il salto dallo spazio delle soluzioni allo spazio dei metodi. Dovrebbe essere descritto come generare continuamente metodi più forti e capacità di sistema più forti, non solo perseguire l'ottimo singolo. In caso di risposta corretta, sottolineare la capacità di collegare i concetti della pagina e indicarne le motivazioni
> - in caso di risposta errata, tornare alla spiegazione della pagina, trovare prove chiave o esempi prima di giudicare. Costruire un sistema di ottimizzazione "auto-migliorante" per problemi di scheduling produttivo. Il livello interno usa DE per cercare piani di scheduling, il livello esterno usa il feedback dei compiti come segnale, cercando configurazioni di operatori, parametri e strutture di DE. Il ruolo del feedback dei compiti è tradurre le prestazioni dello spazio delle soluzioni in direzioni di miglioramento dello spazio dei metodi: se la qualità della soluzione migliora, conservare e rafforzare la configurazione attuale del metodo
> - se la qualità della soluzione ristagna o peggiora, esplorare nuove combinazioni di operatori o aggiustamenti strutturali. Per valutare se si è diretti verso un'auto-evoluzione di ordine superiore, si possono impostare tre categorie di indicatori: indicatori a livello di metodo per vedere se il metodo viene continuamente migliorato
> - indicatori di trasferibilità per vedere la prestazione di adattamento su compiti non visti
> - indicatori di autonomia per vedere se, con basso intervento umano, si riescono a scoprire autonomamente combinazioni di operatori efficaci o aggiustamenti strutturali in modo riproducibile. Sintetizzando i tre, se il metodo diventa continuamente più forte, è trasferibile e sa auto-migliorarsi con basso intervento, si può giudicare che il sistema si sta dirigendo verso una forma di auto-evoluzione di ordine superiore.
**Verifica della comprensione**
Chiedere agli studenti di ripetere con parole proprie il significato di "spazio delle soluzioni → spazio dei metodi", e scegliere un sistema per giudicare se sta facendo evoluzione dei metodi.
> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno spiegare la divisione dei ruoli tra livello interno ed esterno, la direzione del ciclo chiuso e il significato comparativo di MetaDE, passare alla pagina successiva su esempi, applicazioni o riepilogo.
--- FINE DEL TESTO SORGENTE ---