# Sistema di evoluzione intelligente EvoX e pratica di ricerca scientifica AI Native — Dispense del corso

Durata: 1 · Pagine della presentazione: 16

## Navigazione di lettura

- [Lezione 7 | Tema: Paradigma di ricerca AI Native e approccio pratico a EvoX](#lecture-lesson-1)

---

<a id="lecture-lesson-1"></a>

## Lezione 7 | Tema: Paradigma di ricerca AI Native e approccio pratico a EvoX

<a id="lecture-page-1"></a>

### Paradigma di ricerca AI Native e approccio pratico a EvoX

*Pagina 1*

> **Obiettivo della pagina:** Padroneggiare un percorso pratico per approcciare EvoX in un ambiente AI Native, e comprendere il principio fondamentale della ricerca "Code is cheap. Taste matters."

> **Obiettivo della pagina**
>
> Questa è la pagina di apertura della settima lezione e definisce il tono dell'intera unità "Paradigma di ricerca AI Native e pratica EvoX". Il discente deve acquisire due consapevolezze: primo, un percorso pratico per condurre esperimenti EvoX in modo efficiente con strumenti AI come Codex in un ambiente AI Native; secondo, quando il codice può essere generato automaticamente, la capacità veramente insostituibile del ricercatore — il gusto e la capacità di porre domande chiave, ovvero la frase ripetutamente enfatizzata in questa pagina: Code is cheap. Taste matters.

> **Ordine espositivo**
>
> 1. Prima lo scenario. Spiegare che nel modo di lavorare AI Native, il "lavoro pesante" come scrivere script di esperimenti, costruire pipeline di ottimizzazione EvoX e condurre esperimenti comparativi può essere in gran parte affidato a strumenti AI, e il ricercatore non deve più scrivere riga per riga. Questo cambia direttamente il ritmo della ricerca: da "si riesce a scriverlo" a "vale la pena farlo".
>
> 2. Poi il metodo. Quando si conducono esperimenti EvoX con strumenti come Codex, l'approccio tipico è esprimere chiaramente la propria intenzione sperimentale, la formulazione del problema e i criteri di valutazione, lasciare che lo strumento generi uno scheletro di programma eseguibile, e concentrarsi sul verificare se il disegno sperimentale regge e se i risultati sono credibili.
>
> 3. Infine il principio fondamentale. Dal momento che il codice diventa economico, ciò che è scarso diventa il giudizio: se il tema ha valore, se la baseline è equa, se le metriche spiegano il problema, se le conclusioni sono solide. Il Taste determina la direzione della ricerca, la capacità di porre domande determina la profondità della ricerca.

**Punti chiave dell'insegnamento**

- Gli strumenti AI riducono il costo di implementazione, non la soglia della ricerca
- La soglia si è spostata dalla "competenza di programmazione" al "gusto per i problemi". Quando si usano strumenti come Codex, il ruolo umano è porre buone domande, stabilire criteri di valutazione, esaminare i risultati generati, non accettare passivamente l'output. "Code is cheap. Taste matters." non nega le capacità ingegneristiche, ma ricorda: nell'era della programmazione automatizzata, il gusto e la capacità di porre domande sono il vero fossato del ricercatore.

**Verifica della comprensione**

Chiedere a un discente di spiegare con parole proprie dove dovrebbe essere reinvestito il tempo del ricercatore negli esperimenti EvoX se il codice può essere generato automaticamente. Una risposta adeguata dovrebbe indicare il lavoro di giudizio come la scelta del problema, il disegno sperimentale, la valutazione dei risultati, non semplicemente "far scrivere più veloce all'AI".

> **Suggerimento di transizione**
>
> Dopo aver confermato che il discente sa esprimere la relazione centrale "costo di implementazione in calo, valore del giudizio in aumento", passare alle pagine successive per sviluppare i passi pratici e gli esempi concreti di EvoX.

<a id="lecture-page-2"></a>

### Paradigma di ricerca AI Native e approccio pratico a EvoX

*Pagina 2*

> **Obiettivo della pagina:** Comprendere il percorso complessivo per approcciare EvoX in un ambiente AI Native e i principi fondamentali della ricerca.

> **Obiettivo della pagina**
>
> Collegare "paradigma di ricerca AI Native" e "approccio pratico a EvoX" in un unico percorso — quando il costo di implementazione diminuisce, il ricercatore deve spostare l'attenzione dallo scrivere codice al porre domande, definire valutazioni, giudicare direzioni e criticare risultati, ricordando il principio fondamentale "Code is cheap. Taste matters.".

> **Ordine espositivo**
>
> Prima il cambio di paradigma, poi la lettura del diagramma architetturale, quindi spiegare che EvoX non è uno strumento per un singolo algoritmo, ma un sistema di evoluzione intelligente eseguibile, componibile e sostenibilmente esplorabile; infine l'approccio pratico: passare da "scegliere l'algoritmo" a "progettare il processo".

**Punti chiave dell'insegnamento**

- Grandi modelli, GPU, Agent e workflow automatizzati diventano infrastruttura di ricerca predefinita. Implementare codice, esperimenti in batch, ampliare la ricerca diventano sempre più economici
- L'AI si occupa di implementare risposte, accelerare esperimenti, ampliare la ricerca
- L'uomo si occupa di direzione, vincoli, gusto e decisioni chiave. L'attenzione umana si sposta dallo "scrivere codice" al "definire standard, fare scelte, esaminare risultati". Partendo da "problema reale · gusto per la ricerca", l'uomo pone domande, definisce standard, giudica direzioni
- Una volta trasformato in esplorazione eseguibile, viene preso in carico dall'infrastruttura AI, poi affidato a EvoX. All'interno di EvoX quattro fasi: definizione del problema (conflitti di obiettivo, vincoli), progettazione della valutazione (metriche, pesi, soglie), processo evolutivo (soluzioni candidate, iterazioni in batch), scheduling Runtime (potenza di calcolo, concorrenza, riproducibilità). L'output è molteplici soluzioni candidate, risultati verificabili, evoluzione continua, formando un output di ricerca criticabile e riproducibile, che attraverso il ciclo di feedback "critica e accettazione" torna al punto di partenza. Erede della tradizione del calcolo evolutivo, orientato a multi-obiettivo complessi, esplorazione aperta ed evoluzione continua a livello di sistema. Non è un singolo solver, ma una base ingegneristica eseguibile, componibile e sostenibilmente esplorabile: il prodotto di un esperimento può essere ereditato dal successivo, il processo di ricerca stesso può evolvere continuamente. I quattro perni restano definizione del problema, progettazione della valutazione, processo evolutivo, scheduling Runtime. L'equivoco tipico è considerare il punto di partenza come "scegliere uno tra diversi algoritmi". Il punto di partenza corretto è identificare prima i conflitti di obiettivo e i vincoli, trasformare il problema in un processo di esplorazione eseguibile, comparabile e sostenibilmente evolutivo. L'uomo definisce prima conflitti di obiettivo, condizioni di vincolo e criteri di accettazione
- L'AI genera e itera rapidamente il codice
- EvoX esegue in batch e confronta le soluzioni candidate
- Infine si formano risultati criticabili e verificabili. Ad esempio, in un esperimento di ottimizzazione multi-obiettivo, non si dovrebbe far scrivere tutto il codice all'AI e accettarne direttamente l'output, ma far sì che la macchina si occupi di implementazione ed esplorazione e l'uomo di definizione e giudizio. Code is cheap. Taste matters. Quando il codice non è più scarso, il gusto per i problemi, i criteri di valutazione, il giudizio sui compromessi e la capacità di accettazione sono le competenze di ricerca più difficili da sostituire.

**Gestione degli esercizi**

Questa pagina include 5 domande a scelta multipla. La risposta corretta della domanda 1 è "passare dall'implementazione del codice al porre domande, definire criteri di valutazione e giudicare la direzione"; punto di feedback: implementazione ed esplorazione in batch possono essere affidate all'AI, il compito centrale dell'uomo è porre domande, definire standard e giudicare risultati. La risposta corretta della domanda 2 è "sistema di evoluzione intelligente e base ingegneristica eseguibile, componibile e sostenibilmente esplorabile"; se errata, ricordare di non ridurre EvoX a un algoritmo. La risposta corretta della domanda 3 è "identificare prima i conflitti di obiettivo e i vincoli, trasformare il problema in un processo di esplorazione eseguibile"; sottolineare che il punto di partenza non è la scelta dell'algoritmo o l'impostazione dei parametri. La risposta corretta della domanda 4 è "quando il codice non è più scarso, il gusto per i problemi, i criteri di valutazione e il giudizio di accettazione diventano competenze più scarse";

non nega implementazione e verifica, ma sottolinea lo spostamento della scarsità. La risposta corretta della domanda 5 è "far scrivere tutto il codice all'AI e adottarne direttamente i risultati di esecuzione, senza più definire manualmente obiettivi e standard"; questo è in conflitto con la divisione "AI implementa ed esplora, l'uomo definisce e giudica".

Progettare un esperimento di ottimizzazione multi-obiettivo con EvoX. Lo scenario richiede di ottimizzare contemporaneamente costo, prestazioni e robustezza, con tre metriche in conflitto reciproco, soggette a vincoli di budget computazionale e scadenze di consegna. La divisione uomo-macchina dovrebbe essere scritta così: l'uomo si occupa di definizione e giudizio — pone domande, scrive esplicitamente conflitti di obiettivo e vincoli, progetta metriche di valutazione e soglie di accettazione, e di fronte ai risultati fa giudizi di direzione e accettazione critica; l'AI si occupa di implementazione ed esplorazione — genera e itera rapidamente il codice, esegue in batch le soluzioni candidate, amplia la ricerca e accelera gli esperimenti. I due formano un ciclo chiuso "l'uomo definisce la direzione — l'AI amplia l'esplorazione — l'uomo fa l'accettazione".

Se i conflitti di obiettivo non sono definiti esplicitamente, i criteri di valutazione sono vaghi, i vincoli vengono ignorati, i risultati sono difficili da giudicare in termini di qualità, riproducibilità e sedimentazione; si dovrebbe invece concentrarsi sulla progettazione del processo, chiarire la definizione del problema e il metodo di valutazione, pianificare la generazione di soluzioni candidate, il confronto tramite esecuzione in batch e lo scheduling Runtime, e includere i risultati di ogni ciclo nella critica e nell'accettazione.

**Attività in classe**

Chiedere agli studenti di scegliere un problema familiare, scrivere in una frase i conflitti di obiettivo e i criteri di accettazione, poi spiegare quale parte è gestita dall'AI e quale da EvoX. Verifica della comprensione: chiedere a uno studente a caso di ripetere "perché prima definire la valutazione e poi toccare il codice", e indicare la funzione del ciclo di feedback nel diagramma architetturale. Suggerimento di transizione: dopo aver confermato che gli studenti sanno distinguere capacità economiche da capacità scarse, passare alla pagina successiva con esempi, applicazioni o riepilogo.

<a id="lecture-page-3"></a>

### Confini delle capacità dei grandi modelli e sistemi a evoluzione continua

*Pagina 3*

> **Obiettivo della pagina:** Comprendere il divario tra la crescita delle capacità dei grandi modelli e la costruzione di sistemi in grado di adattarsi al mondo reale a lungo termine.

**Punti chiave dell'insegnamento**

- Quando si sente un'espressione come "miglioramento delle capacità del modello", porre due domande di approfondimento: dove si sedimentano i <em>risultati efficaci</em> di questo ciclo? Chi li erediterà nel prossimo ciclo? Se non si sa rispondere, ciò che è migliorato è solo la capacità di singola chiamata, non la capacità di adattamento a lungo termine del sistema.
- Prima produrre candidati → poi verificare nella realtà → sedimentare nell'archivio → ereditare ed evolvere ancora. L'ordine non si può cambiare: senza candidati non c'è nulla da verificare, senza verifica non si può parlare di sedimentazione, senza sedimentazione non c'è un punto di partenza ereditabile.
- Due malintesi frequenti: considerare "buona prestazione in un singolo compito" come "il sistema può adattarsi a lungo termine"; considerare "candidati non verificati" come "conclusioni già stabilite". Il metodo di autocontrollo è vedere se questo risultato ha superato la verifica reale e se è stato scritto in una versione di progetto ereditabile.

Obiettivo della pagina**

La "crescita delle capacità" dei grandi modelli e l'"adattamento a lungo termine" del sistema non sono la stessa cosa. Il discente deve comprendere perché rendere forti le capacità del modello non equivale automaticamente a far evolvere il progetto nel mondo reale in modo sostenibile, e da quali fasi dovrebbe essere composto un ciclo chiuso a livello di sistema.

Ordine espositivo**

Si suggerisce di procedere nell'ordine "componente di capacità → perché non basta → ciclo chiuso in quattro passi → relazione tra componente e sistema → autocontrollo degli errori". Prima spiegare cosa possono fare i grandi modelli, poi creare il divario cognitivo (forte una volta ≠ stabile a lungo termine), quindi fornire la struttura del ciclo chiuso come soluzione, infine chiudere con la coppia concettuale "componente—sistema".

Punti chiave dell'insegnamento**

Uno, le tre categorie di capacità fornite dai grandi modelli. Sono già in grado di sostenere stabilmente comprensione forte, generazione e chiamata di strumenti: analizzare obiettivi e vincoli in descrizioni di compiti eseguibili; produrre ipotesi candidate, codice, disegni sperimentali e documentazione; connettere risorse esterne come ricerca, calcolo, compilazione e simulazione. Quindi integrare i grandi modelli come "componenti intelligenti" nei processi di ricerca e ingegneria è già una pratica utilizzabile nella realtà. Ma va chiarito: queste tre categorie di capacità rispondono a "se un singolo compito può essere svolto correttamente", non a "se un compito a lungo termine può essere svolto correttamente in modo continuativo".

Due, perché una capacità forte in una singola esecuzione non basta. I progetti reali durano spesso mesi o addirittura anni, e il contesto di un singolo Agent alla fine si esaurisce. Se l'esperienza non può essere sedimentata, ogni ciclo di lavoro riparte da zero e la crescita delle capacità non si trasformerà automaticamente in capacità di adattamento a lungo termine. Qui si può introdurre: è necessario estendere l'oggetto dell'evoluzione a un "mondo software" persistente e fare affidamento sulla persistenza a livello di progetto, affinché l'esperienza non vada persa con ogni singolo esperimento.

Le componenti intelligenti propongono ipotesi, modifiche o implementazioni; in quel momento sono solo candidate, non conclusioni; verifica reale: i candidati devono passare attraverso ambiente reale, simulazione o esperimenti, e superare checkpoint come compilazione, test, controllo comportamentale e accettazione di livello superiore; sedimentazione dei risultati: solo i risultati efficaci che superano la verifica vengono scritti nella versione di progetto accettata, diventando risorse riutilizzabili; evoluzione successiva: il lavoro successivo eredita i risultati già sedimentati e su questa base continua a proporre candidati. La formula è "prima produci candidati → poi verifica nella realtà → sedimenta nell'archivio → eredita ed evolve ancora". Va sottolineata la dipendenza logica: senza candidati non c'è nulla da verificare, senza verifica non si può parlare di sedimentazione, senza sedimentazione non c'è un punto di partenza ereditabile.

Quattro, prendere un sistema multi-Agent collaborativo come Genesis come esempio di ciclo chiuso. Gli Agent che partecipano al lavoro hanno un ciclo di vita limitato; gli esecutori di livello superiore comprendono l'obiettivo e decompongono ricorsivamente i compiti, gli esecutori di livello inferiore completano l'implementazione locale e i test, ricorrendo ulteriormente verso il basso se necessario; le modifiche candidate vengono inviate solo come candidati, e devono superare compilazione, test, controllo comportamentale e accettazione di livello superiore per essere accettate, i tentativi falliti vengono rifiutati, i risultati verificati vengono scritti nella versione di progetto, diventando la base storica per gli esecutori successivi. In scenari come il refactoring di compilatori e l'aggiornamento di software scientifico, questo meccanismo mostra elevata affidabilità e rapporti di accelerazione operativa.

Le componenti di capacità si occupano di produrre candidati di alta qualità in un singolo punto, il ciclo chiuso di sistema si occupa di determinare quali candidati meritano di essere conservati, come conservarli e come essere ereditati dal ciclo successivo. Senza il ciclo chiuso, più forti sono le capacità, più candidati non verificati verranno prodotti; senza componenti forti, il ciclo chiuso manca di fonti di candidati di alta qualità.

Sei, errori comuni e metodi di autocontrollo. La lettura errata più comune è equiparare direttamente "miglioramento delle capacità del modello" a "il sistema può adattarsi a lungo termine". Il criterio di giudizio non è quanto bene il modello si comporti in un certo compito, ma se i risultati efficaci possono essere stabilmente sedimentati ed ereditati dal lavoro successivo. Si possono insegnare al discente due domande di approfondimento: dove si sedimentano i risultati efficaci di questo ciclo? Chi li erediterà nel prossimo ciclo? Se non si sa rispondere, ciò che è migliorato è solo la capacità di singola chiamata. Un altro errore è considerare "candidati non verificati" come "conclusioni già stabilite", il metodo di autocontrollo è vedere se hanno superato la verifica reale e sono stati scritti in una versione di progetto ereditabile.

Spunti per i materiali**

A sinistra c'è l'area delle componenti "capacità dei grandi modelli", che elenca comprensione, generazione, chiamata di strumenti; a destra c'è il "ciclo chiuso del sistema a evoluzione continua", composto da quattro nodi in ciclo: generazione di candidati, verifica reale, sedimentazione dei risultati, evoluzione successiva, con al centro l'annotazione "le componenti di capacità devono essere organizzate dal sistema". Durante la spiegazione si può percorrere il ciclo chiuso con gli studenti seguendo le frecce, poi tornare a indicare la parte sinistra, spiegando che le componenti hanno valore a lungo termine solo se organizzate dal sistema.

Spunti per gli esercizi e guida alle risposte**

La corretta collocazione dei grandi modelli nel processo (componenti intelligenti organizzabili dal sistema, che si occupano di comprensione, generazione e chiamata di strumenti); perché la crescita delle capacità non equivale all'adattamento a lungo termine (il contesto di una singola sessione si esaurisce, e i risultati non verificati non possono essere sedimentati come risorse ereditabili); l'ordine corretto delle fasi del ciclo chiuso (generazione di candidati → verifica reale → sedimentazione dei risultati → evoluzione successiva); la soglia per l'ingresso del codice nella storia del progetto in Genesis (superare compilazione, test e controllo comportamentale e ottenere l'accettazione di livello superiore); e l'esatta formulazione della relazione "componente—sistema".

Il caso di studio richiede di progettare un ciclo chiuso a livello di sistema per un laboratorio di calcolo scientifico a lungo termine, e di fornire meccanismi per "soluzioni fallite ritentate ripetutamente" e "nuovi membri che non riescono a ereditare le conclusioni precedenti". I punti chiave della risposta sono: usare un gateway di accettazione rigoroso e registri decisionali per respingere i candidati non approvati e conservare le ragioni del fallimento, usare la persistenza a livello di progetto per scrivere i risultati accettati nella versione di progetto accettata; e sottolineare che — migliorare semplicemente le capacità del modello può solo aumentare la qualità del singolo candidato, mentre la radice di questi due problemi è la mancanza di verifica, registrazione e sedimentazione.

Verifica della comprensione**

Perché un modello più forte non equivale a un progetto che può evolvere a lungo termine, e quale problema risolve ciascuno dei quattro passi del ciclo chiuso. Se la risposta si ferma a "il modello è molto potente", si può suggerire di tornare alle due domande di approfondimento "dove si sedimentano i risultati efficaci, chi li eredita" per completare.

Suggerimento di transizione**

Dopo aver confermato che il discente sa distinguere "la qualità del singolo candidato" dalla "selezione, sedimentazione ed eredità a livello di sistema", passare alla pagina successiva con applicazioni, esempi o esercitazioni pratiche.

<a id="lecture-page-4"></a>

### Trasformare problemi reali in processi di esplorazione EvoX

*Pagina 4*

> **Obiettivo della pagina:** Padroneggiare come definire oggetti variabili, criteri di valutazione e meccanismi di conservazione di fronte a problemi reali.

> **Obiettivo della pagina**
>
> Padroneggiare come definire oggetti variabili, criteri di valutazione e meccanismi di conservazione di fronte a problemi reali, e comprendere l'ordine "prima la trasformazione del problema, poi la scelta dell'algoritmo".

> **Ordine espositivo**
>
> Problema reale (esigenza descrivibile) → definizione degli oggetti variabili (variabili campionabili) → costruzione dei criteri di valutazione (obiettivo calcolabile) → meccanismo di conservazione e selezione (candidati ereditabili) → esplorazione iterativa EvoX (ogni generazione riproducibile) → output delle soluzioni candidate (conclusioni misurabili).
>
> Quando la valutazione è distorta, tornare alla costruzione dei criteri di valutazione; quando la diversità collassa, tornare al meccanismo di conservazione.
>
> 3. Poi sviluppare in sequenza le quattro condizioni di accettazione, e illustrare la modalità di mappatura con la progettazione di profili alari supercritici.
>
> 4. Infine verificare la comprensione con cinque domande vero/falso e il caso della piastra di raffreddamento del pacco batteria.

**Punti chiave dell'insegnamento**

- Trasformare problemi reali in processi di esplorazione EvoX significa, prima di scrivere qualsiasi configurazione di algoritmo, riscrivere una vaga esigenza ingegneristica o di ricerca in una definizione di problema evolutivo "campionabile, valutabile, conservabile, iterativamente verificabile". EvoX si occupa di una pipeline di esplorazione, ha bisogno di sapere in quale spazio campionare, con quale criterio valutare, quali risultati meritano di essere continuati. Queste informazioni possono venire solo dal problema stesso. L'algoritmo può cercare risposte solo all'interno della definizione, non può recuperare la risposta corretta da un problema definito in modo errato. Tradurre l'esigenza reale in variabili decisionali, determinare forma di rappresentazione, dimensione e confini, e distinguere parametri continui, strutture discrete e persino oggetti a livello di programma. Confini troppo stretti escludono la soluzione veramente ottimale dallo spazio di ricerca
- Variabili campionabili. Scomporre obiettivi vaghi in funzioni obiettivo calcolabili e vincoli, chiarire metriche da massimizzare, vincoli rigidi e compromessi multi-obiettivo. Quando il feedback è scarso o la simulazione è costosa, introdurre modelli surrogati per sostituire il calcolo ad alto costo. Condizione di accettazione: l'obiettivo è calcolabile, e con lo stesso input i risultati sono stabili e riproducibili. Definire come i candidati vengono conservati, confrontati e continuati, affinché il processo evolutivo abbia memoria, direzione e diversità, invece di essere una serie di tentativi ed errori usa e getta tra loro scollegati. Condizione di accettazione: i candidati sono ereditabili. Il risultato della trasformazione deve essere riproducibile, misurabile e iterativamente verificabile, ogni passo deve poter rispondere a "questo cambiamento è davvero migliore". Variabili omesse portano a fraintendere lo spazio delle soluzioni, valutazione distorta fa deviare l'intera ottimizzazione
- Questi due tipi di deviazione non possono essere compensati da operatori successivi o più iterazioni. Nella progettazione di profili alari supercritici, gli oggetti variabili sono i parametri di perturbazione geometrica del profilo di base
- I criteri di valutazione sono metriche multi-obiettivo come rapporto portanza-resistenza, divergenza di resistenza, robustezza, con modelli surrogati per controllare il costo di simulazione
- Il meccanismo di conservazione è l'output di un insieme diversificato di soluzioni candidate che bilanciano le varie metriche, lasciato agli esperti di dominio per la decisione di compromesso. Lo stesso problema reale, cambiando un insieme di confini delle variabili o criteri di valutazione, porta a conclusioni di esplorazione completamente diverse.

**Copertura delle parole chiave**

- Trasformazione del problema, definizione degli oggetti variabili, variabili campionabili, costruzione dei criteri di valutazione, obiettivo calcolabile, meccanismo di conservazione e selezione, candidati ereditabili, esplorazione iterativa EvoX, ogni generazione riproducibile, valutazione distorta, collasso della diversità, modello surrogato, profilo alare supercritico.

**Gestione degli esercizi**

La risposta corretta è "perché la trasformazione determina lo spazio di ricerca e i criteri di valutazione, l'algoritmo può cercare risposte solo all'interno di questa definizione". Nella spiegazione sottolineare che la trasformazione risponde a "cosa può cambiare" e "come valutare dopo il cambiamento", il limite superiore dello spazio di esplorazione e la direzione dell'ottimizzazione sono determinati da essa; il costo di campionamento o il tipo di operatore non sono il punto chiave.

La risposta corretta è "lo spazio di ricerca è troppo stretto, la soluzione veramente ottimale non è al suo interno, gli operatori e le iterazioni successive non possono compensare". L'omissione di variabili è una deviazione nella fase di trasformazione, funzione di valutazione, meccanismo di conservazione e operatori non possono creare dal nulla dimensioni non definite.

La risposta corretta è "usare modelli surrogati per approssimare la valutazione a basso costo, preservando esplicitamente le relazioni di compromesso multi-obiettivo e i vincoli rigidi". Quando la valutazione è costosa e gli obiettivi sono in conflitto, l'approccio corretto è ridurre il costo della singola valutazione ed esprimere esplicitamente conflitti e vincoli, non ridurre il numero di generazioni o combinare semplicemente con pesi.

La risposta corretta è "far sì che i candidati vengano conservati, confrontati e continuati, affinché il processo evolutivo abbia memoria, direzione e diversità". Il meccanismo di conservazione non si occupa di valutazione, né di correggere i confini delle variabili.

La risposta corretta è "ogni passo dovrebbe essere riproducibile e poter rispondere a 'questo cambiamento è davvero migliore', altrimenti la deviazione verrebbe amplificata nelle iterazioni". La valutazione complessiva a posteriori non può sostituire la verifica passo per passo, omissione di variabili e valutazione distorta avvengono nella fase di trasformazione, le iterazioni amplificano solo la deviazione.

Quando la risposta è corretta, lodare lo studente per aver collegato i concetti di questa pagina e aver fornito motivazioni; quando è errata, chiedere allo studente di tornare al paragrafo corrispondente, trovare prove chiave o esempi prima di giudicare.

> **Spunti per gli esercizi**
>
> - Ottimizzazione della geometria dei canali di raffreddamento della piastra del pacco batteria. Considerare solo la larghezza del canale come variabile decisionale, ignorando gradi di libertà strutturali discreti come andamento del canale, forma topologica, numero di ramificazioni, posizione di ingresso e uscita, costituisce una definizione troppo stretta degli oggetti variabili, la geometria veramente ottimale potrebbe non essere nello spazio di ricerca
> - Considerare solo la temperatura massima come unico obiettivo, lasciando caduta di pressione e uniformità di temperatura al giudizio empirico, costituisce una valutazione distorta, i conflitti multi-obiettivo non sono modellati esplicitamente
> - Una singola simulazione di 3 ore moltiplicata per 200 generazioni, mancando controllo del costo di valutazione e criteri di verifica riproducibili, scegliendo direttamente dai risultati l'individuo "che sembra migliore", non si può rispondere a "questo cambiamento è davvero migliore". Sugli oggetti variabili, includere insieme parametri continui (larghezza, profondità, spessore del canale) e strutture discrete (topologia del canale, numero di ramificazioni, posizione di ingresso e uscita), specificare intervalli di valori o modalità di codifica, e distinguere le quantità fisse, condizione di verifica: variabili campionabili. Sui criteri di valutazione, scrivere temperatura massima, caduta di pressione, uniformità di temperatura come funzioni obiettivo multi-obiettivo esplicite, scrivere limite superiore di caduta di pressione e fattibilità produttiva come vincoli rigidi, usare modelli surrogati per la maggior parte della valutazione e calibrare periodicamente con simulazioni reali, condizione di verifica: obiettivo calcolabile, stabile e riproducibile con lo stesso input. Sul meccanismo di conservazione, conservare un insieme di candidati diversificati che bilanciano gli obiettivi, non una singola soluzione ottimale, definire regole di confronto e regole di continuazione, e monitorare l'omogeneizzazione con misure di diversità, condizione di verifica: candidati ereditabili. Nell'esecuzione e verifica, registrare per ogni generazione metriche riproducibili
> - Se l'affidabilità della valutazione diminuisce, tornare alla costruzione dei criteri di valutazione per ricalibrare
> - Se la diversità collassa, tornare al meccanismo di conservazione per adattare le strategie di selezione e continuazione.

**Attività in classe**

Chiedere agli studenti di riscrivere in una frase "rendere questo progetto migliore" in una definizione di problema di esplorazione che includa oggetti variabili, criteri di valutazione e meccanismo di conservazione, poi verificare reciprocamente se soddisfa "campionabile, calcolabile, ereditabile, riproducibile".

**Verifica della comprensione**

Chiedere a uno studente a caso di riassumere con parole proprie i punti chiave di questa pagina, l'insegnante integra le condizioni di accettazione e i cicli di feedback mancanti in base alla risposta.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno dire "prima definire, poi avviare l'ottimizzatore" e i due tipi di meccanismi di ritorno, passare alla pagina successiva con esempi, applicazioni o riepilogo.

<a id="lecture-page-5"></a>

### Ottimizzazione multi-obiettivo ed esplorazione multi-soluzione

*Pagina 5*

> **Obiettivo della pagina:** Riconoscere la complessità dei compromessi multi-obiettivo nel mondo reale e la necessità di conservare un insieme di soluzioni candidate.

> **Obiettivo della pagina**
>
> Riconoscere la complessità dei compromessi multi-obiettivo nel mondo reale, comprendere perché è necessario conservare un insieme di soluzioni candidate, e padroneggiare la dominanza di Pareto, il fronte di Pareto, il costo della scalarizzazione e la valutazione bidimensionale di convergenza e diversità.

**Punti chiave dell'insegnamento**

- È davvero un problema multi-obiettivo? Il criterio di giudizio non è "il numero di obiettivi è maggiore di 1", ma se gli obiettivi sono in relazione di trade-off. Prendendo come esempio la progettazione di profili alari supercritici: rapporto portanza-resistenza, resistenza strutturale, margine di stallo e costo di produzione/simulazione si condizionano reciprocamente, aumentare il rapporto portanza-resistenza spesso significa aumentare contemporaneamente carichi strutturali e costi di produzione. Se tutti gli obiettivi possono essere migliorati simultaneamente senza perdite, il problema degenera in mono-obiettivo, l'esplorazione multi-soluzione è superflua e spreca potenza di calcolo. Direzioni opposte, trade-off reciproco, costituiscono un vero multi-obiettivo. Due, dominanza di Pareto e fronte di Pareto. La soluzione A domina la soluzione B se e solo se A non è peggiore di B su tutti gli obiettivi (per ogni obiettivo i si ha fᵢ(A) ≤ fᵢ(B)), e è strettamente migliore su almeno un obiettivo (esiste j tale che fⱼ(A) < fⱼ(B)). Per qualsiasi soluzione dominata esiste un'alternativa "almeno altrettanto buona, migliore in qualche punto", quindi non ha valore di conservazione. Tutte le soluzioni non dominate da nessuna soluzione costituiscono il fronte di Pareto — le soluzioni sul fronte non si dominano reciprocamente, quale sia più adatta dipende dalle preferenze, non dalla matematica. Tre, il costo della mono-obiettivizzazione. Metodi di scalarizzazione come somma pesata e ε-vincolo comprimono obiettivi vettoriali in uno scalare, convenienti in ingegneria, ma con costi concreti: nascondono la struttura dei compromessi — una volta fissati i pesi, la forma del fronte e le direzioni alternative diventano invisibili, il decisore vede solo un punteggio. I pesi devono essere specificati in anticipo — ma le preferenze reali spesso non possono essere formalizzate in anticipo, spesso diventano chiare solo in fase di revisione. Copertura limitata — la somma pesata di solito può raggiungere solo singoli punti di contatto sul fronte, alcune sezioni del fronte non convesso sono difficili da raggiungere. Una volta che la revisione successiva cambia i pesi, l'intera ricerca deve essere rieseguita, che è esattamente l'opposto di "un'esplorazione in cambio di più libertà decisionale". Convergenza e diversità. Convergenza (se l'insieme di soluzioni si avvicina al fronte reale) e diversità (se le soluzioni coprono diverse sezioni del fronte). Le due spesso si tirano reciprocamente: una volta che la pressione selettiva pende troppo verso "meglio", la popolazione collassa su un punto o una piccola sezione del fronte, sembra convergere rapidamente, ma perde le informazioni sui compromessi. Quindi è necessario mantenere esplicitamente la diversità della popolazione, con pressioni selettive basate su crowding distance, decomposizione, indicatori (come ipervolume). La posizione decisionale si sposta. L'ottimizzatore si occupa solo di produrre gruppi di candidati comparabili, la selezione finale è fatta dalle preferenze o dagli esperti di dominio, l'ottimizzatore non dovrebbe convergere prematuramente al posto del decisore. La ragione pratica per conservare gruppi di candidati differenziati è "copertura del rischio" — quando le preferenze sono sconosciute, cambiano con il contesto, o i vincoli vengono modificati in fase di implementazione, un gruppo diversificato di soluzioni è più prezioso di una singola "soluzione ottimale". A livello di interfaccia di implementazione, i problemi multi-obiettivo dovrebbero essere definiti come funzioni di valutazione a valori vettoriali (che restituiscono più valori obiettivo in una volta) e output di insiemi di soluzioni candidate, non come fitness scalare con valore di ritorno singolo. Il numero di valori di ritorno della funzione di valutazione determina la dimensionalità degli obiettivi, la struttura di output determina se la diversità può essere preservata.

> **Spunti per i materiali**
>
> - La pagina fornisce un grafico a dispersione del fronte di Pareto bidimensionale, con asse orizzontale l'obiettivo 1 massa strutturale (minore è meglio), asse verticale l'obiettivo 2 costo di produzione (minore è meglio). Nel grafico sono annotati soluzioni non dominate, soluzioni dominate, fronte di Pareto, punti colpiti dalla scalarizzazione, direzioni di miglioramento, zone sparse e zone dense. Con questo grafico si possono spiegare intuitivamente le relazioni di dominanza, la forma del fronte e la diversità, e illustrare che la somma pesata di solito può colpire solo singoli punti sul fronte.

> **Spunti per gli esercizi**
>
> - La pagina contiene 5 domande a scelta singola e 1 caso di studio. La domanda 1 verifica il criterio di dominanza di Pareto, la risposta corretta è "la soluzione A domina la soluzione B se e solo se A non è peggiore di B su tutti gli obiettivi, e è strettamente migliore su almeno un obiettivo". Nella guida sottolineare che entrambe le condizioni devono valere contemporaneamente, soluzioni con vantaggi e svantaggi reciproci non si dominano, rimangono entrambe sul fronte di Pareto. La domanda 2 verifica il criterio per giudicare un problema multi-obiettivo, la risposta corretta è "gli obiettivi hanno direzioni opposte, migliorare uno comporta necessariamente il peggioramento di un altro". Nella guida indicare che il conflitto è l'essenza del multi-obiettivo, il punto chiave non è il numero di obiettivi, ma la relazione di trade-off reciproco. La domanda 3 verifica il giudizio sui metodi di scalarizzazione, la risposta corretta è "la scalarizzazione nasconde la struttura dei compromessi e richiede che i pesi siano specificati in anticipo, mentre le preferenze reali spesso non possono essere formalizzate in anticipo". Nella guida ricordare due costi: nascondere la struttura dei compromessi, e dover specificare i pesi in anticipo. La domanda 4 verifica la relazione tra convergenza e diversità, la risposta corretta è "le due spesso si tirano reciprocamente, perseguire eccessivamente la convergenza facilita il collasso della popolazione su sezioni isolate del fronte". Si può chiedere: se tutte le soluzioni si ammassano su un punto del fronte, anche se sembra convergere, il decisore può ancora scegliere? La domanda 5 verifica la divisione del lavoro tra ottimizzatore e decisore, la risposta corretta è "l'ottimizzatore produce un insieme di candidati non dominati comparabili, la selezione finale è affidata alle preferenze o agli esperti di dominio". Nella guida spiegare che la posizione decisionale si è spostata, il valore dell'ottimizzazione multi-obiettivo sta proprio nel conservare il gruppo di candidati. Il caso di studio riguarda il compromesso multi-obiettivo di un profilo alare supercritico. La domanda 1 richiede di spiegare perché costituisce un vero problema multi-obiettivo, e il rischio di usare un punteggio pesato per produrre un unico "profilo alare ottimale" in fase di revisione. Punti chiave della risposta: gli obiettivi hanno direzioni opposte, si condizionano reciprocamente, non possono essere migliorati simultaneamente senza perdite
> - il punteggio pesato nasconde la struttura dei compromessi, richiede pesi specificati in anticipo, una volta modificati i pesi bisogna rieseguire, il budget di simulazione è difficile da sostenere. La domanda 2 richiede di spiegare come definire la funzione di valutazione e la struttura di output, e come selezionare in sede di revisione. Punti chiave della risposta: la funzione di valutazione diventa in forma vettoriale, restituisce una quadrupla (rapporto portanza-resistenza, massa strutturale, margine di stallo, costo di produzione e simulazione)
> - l'output è un insieme di soluzioni candidate, cioè un insieme di soluzioni del fronte di Pareto non dominate reciprocamente
> - a livello di algoritmo mantenere esplicitamente la diversità, con pressioni selettive basate su crowding distance, decomposizione o ipervolume
> - in sede di revisione scegliere dal gruppo di candidati secondo le preferenze reali. Quando la risposta è corretta, lodare lo studente per aver collegato i concetti di questa pagina e aver fornito motivazioni
> - quando è errata, chiedere allo studente di tornare alla spiegazione di questa pagina, trovare prove chiave o esempi prima di giudicare.

**Attività in classe**

Si può chiedere agli studenti di fare un esempio di conflitto multi-obiettivo nella vita quotidiana (come il compromesso tra prestazioni, prezzo e autonomia nell'acquisto di un telefono), spiegando perché non esiste una soluzione ottimale unica, e il valore di conservare un insieme di soluzioni candidate.

**Verifica della comprensione**

Chiedere a uno studente a caso di riassumere con parole proprie i punti chiave di questa pagina, l'insegnante integra le parole chiave mancanti in base alla risposta, come dominanza di Pareto, fronte di Pareto, convergenza, diversità, collasso della popolazione, funzione di valutazione a valori vettoriali.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno dire l'essenza del problema multi-obiettivo (conflitto di obiettivi) e il significato del fronte di Pareto e della diversità, passare alla pagina successiva con esempi, applicazioni o riepilogo.

**Riferimenti**

Da bozza EvoClass, pagina 7-7.

<a id="lecture-page-6"></a>

### MetaDE: migliorare gli algoritmi evolutivi con algoritmi evolutivi

*Pagina 6*

> **Obiettivo della pagina:** Comprendere come rendere l'oggetto dell'evoluzione il metodo stesso che genera soluzioni candidate.

**Punti chiave dell'insegnamento**

- Il livello interno risponde a "cosa si calcola", il livello esterno risponde a "come calcolare meglio". Tra i due livelli viene trasmesso solo un segnale — la prestazione del compito, cioè la fitness.
- Non considerare la soluzione ottenuta dal livello interno come il risultato finale di MetaDE. Il vero prodotto è una configurazione di algoritmo trasferibile: la configurazione rimane efficace su nuove istanze della stessa classe, mentre una singola soluzione spesso è già scaduta.
- Chiudendo le dispense, chiedetevi: una valutazione del livello esterno equivale approssimativamente a quante esecuzioni complete del livello interno? Se non sapete rispondere, significa che non avete ancora colto la struttura dei costi di MetaDE e perché il parallelismo è necessario.

【Obiettivo della pagina】

Comprendere come rendere l'oggetto dell'evoluzione il metodo stesso che genera soluzioni candidate, cioè il ciclo chiuso di ottimizzazione a due livelli in cui MetaDE migliora gli algoritmi evolutivi con algoritmi evolutivi.

【Ordine espositivo】

Strategia di mutazione, tasso di crossover CR, fattore di scala F, dimensione della popolazione NP — chi ha scelto queste configurazioni?

Il livello esterno codifica le configurazioni ed evolve, il livello interno esegue DE in parallelo su compiti reali e restituisce la valutazione delle prestazioni.

Dalla "ricerca della soluzione" alla "ricerca del metodo che sa trovare soluzioni".

Invio della configurazione → risoluzione del livello interno → restituzione delle prestazioni → aggiornamento del livello esterno; il costo di valutazione è elevato, il parallelismo GPU è la condizione abilitante chiave.

5. Riepilogare l'essenza in una frase e gli errori comuni, svolgere esercizi e verifica della comprensione.

【Punti chiave dell'insegnamento】

Il livello interno riceve un insieme di configurazioni DE specifiche, esegue una risoluzione completa su compiti reali, produce soluzioni candidate e restituisce valutazioni delle prestazioni comparabili; il livello esterno codifica configurazioni, iperparametri o combinazioni di strategie di DE come individui, usa la prestazione del compito come fitness, e con selezione, ricombinazione, mutazione aggiorna la configurazione della generazione successiva.

L'output del DE tradizionale è un vettore di soluzione; l'output di MetaDE è un insieme di configurazioni di algoritmo che possono produrre stabilmente soluzioni migliori su questa classe di compiti. L'oggetto della ricerca si eleva da "risposta" a "macchina che produce risposte", facendo sì che il risultato di una ricerca del livello esterno possa essere trasferito e riutilizzato su altre istanze della stessa famiglia.

L'intero sistema è collegato da un ciclo chiuso — il livello esterno invia la configurazione → il livello interno esegue la risoluzione → le prestazioni vengono restituite → il livello esterno aggiorna di conseguenza la configurazione della generazione successiva. Un individuo del livello esterno, per ottenere la fitness, deve pagare il costo di una (spesso più, in parallelo) esecuzione completa del livello interno, quindi la gestione del costo di valutazione e lo scheduling parallelo sono il cuore della progettazione del sistema. È proprio la capacità della GPU di eseguire simultaneamente un gran numero di compiti del livello interno che rende questa meta-ottimizzazione "costosa da valutare" ingegneristicamente praticabile.

Il livello interno si occupa di "cosa si calcola", il livello esterno si occupa di "come calcolare meglio". I due livelli condividono lo stesso segnale di fitness — la prestazione del compito, ed è proprio questo che permette loro di formare un ciclo chiuso.

【Copertura delle parole chiave】

Ottimizzazione a due livelli, livello interno, livello esterno, fitness, invio della configurazione, restituzione delle prestazioni, parallelismo GPU, costo di valutazione, configurazione dell'evoluzione differenziale (strategia di mutazione, tasso di crossover CR, fattore di scala F, dimensione della popolazione NP).

【Spunti per gli esercizi】

L'oggetto dell'evoluzione del livello esterno è la configurazione dell'algoritmo; il compito del livello interno è ricevere la configurazione, risolvere su compiti reali e restituire la valutazione delle prestazioni; l'ordine del ciclo chiuso informativo è invio della configurazione → risoluzione del livello interno → restituzione delle prestazioni → aggiornamento del livello esterno; rispetto al DE tradizionale lo spostamento dell'obiettivo è dalla ricerca della soluzione ottimale di un singolo problema alla ricerca di algoritmi e configurazioni che producono meglio soluzioni; il costo computazionale principale deriva dal fatto che valutare un individuo del livello esterno richiede il costo di un'esecuzione completa del livello interno, il parallelismo GPU esegue simultaneamente un gran numero di compiti del livello interno, rendendo la meta-ottimizzazione ingegneristicamente praticabile.

Quando la risposta è corretta, lodare la capacità di collegare i concetti di questa pagina e fornire motivazioni; quando è errata, suggerire di tornare alla spiegazione di questa pagina, trovare prove chiave o esempi prima di giudicare.

Configurazione MetaDE del risolutore di percorsi logistici. Il livello interno esegue DE in modo completo su compiti di consegna reali, ottenendo soluzioni di percorso e costo medio di trasporto, restituiti come valutazione delle prestazioni comparabile. Il livello esterno codifica le configurazioni DE (come [strategia di mutazione DE/best/1, CR = 0.7, F = 0.5, NP = 60]) come individui, usa il costo medio di trasporto come fitness, esegue selezione, ricombinazione e mutazione, generando la popolazione di configurazioni della generazione successiva. Con budget GPU limitato, si possono usare valutazione a livelli (prima selezione grossolana con pochi compiti rappresentativi, poi rivalutazione delle configurazioni migliori sull'insieme completo dei compiti) e scheduling parallelo in batch (impacchettare in batch le esecuzioni del livello interno corrispondenti a tutti gli individui della stessa generazione e inviarle alla GPU) per ridurre il costo di valutazione o migliorare l'efficienza della ricerca;

si può anche ridurre la dimensione della popolazione del livello esterno o usare modelli surrogati per approssimare la previsione delle prestazioni, ma bisogna bilanciare diversità della ricerca e bias di stima. Le motivazioni ruotano tutte intorno a "la fitness del livello esterno dipende dall'esecuzione completa del livello interno" e "il parallelismo può diluire il tempo di attesa del singolo individuo".

【Errori comuni】

Non considerare la soluzione ottenuta dal livello interno come il risultato finale di MetaDE. Il vero prodotto è una configurazione di algoritmo trasferibile: la configurazione rimane efficace su nuove istanze della stessa classe, mentre una singola soluzione spesso è già scaduta.

【Verifica della comprensione】

Una valutazione del livello esterno equivale approssimativamente a quante esecuzioni complete del livello interno? Se non sapete rispondere, significa che non avete ancora colto la struttura dei costi di MetaDE e perché il parallelismo è necessario. Si può anche chiedere agli studenti di riassumere con parole proprie i compiti dei livelli interno ed esterno e l'ordine del ciclo chiuso.

【Suggerimento di transizione】

Dopo aver confermato che gli studenti sanno dire "il livello interno risponde a 'cosa si calcola', il livello esterno risponde a 'come calcolare meglio', i due livelli condividono il segnale di fitness della prestazione del compito", passare alla pagina successiva con esempi, applicazioni o riepilogo.

<a id="lecture-page-7"></a>

### Modalità di lavoro AI Native e punto di accesso rapido

*Pagina 7*

> **Obiettivo della pagina:** Sperimentare un workflow AI nativo senza dover memorizzare comandi di installazione o interfacce complesse.

> **Obiettivo della pagina**
>
> Comprendere la modalità di lavoro AI Native e il punto di accesso rapido, spostando il punto di partenza dell'uso di EvoX dalla memorizzazione di comandi di installazione e interfacce complesse all'espressione dell'intenzione sperimentale in linguaggio naturale. Dopo lo studio si dovrebbe essere in grado di spiegare il significato di "la conversazione è l'ingresso", e distinguere le parti di cui si occupano rispettivamente gli strumenti AI e il ricercatore.

> **Ordine espositivo**
>
> Prima confrontare il modo tradizionale e il modo AI Native; poi spiegare il flusso completo "intenzione in linguaggio naturale → comprensione ed esecuzione da parte dell'AI → output dell'esperimento EvoX"; infine usare il caso del robot di magazzino che evita ostacoli e trova il percorso, per dimostrare come descrivere l'esperimento all'AI con il trio "obiettivo—vincoli—accettazione".

**Punti chiave dell'insegnamento**

- Esprimere in linguaggio naturale compito, vincoli e obiettivi di accettazione, l'AI si occupa di comprendere il codice ed eseguirlo. Non è necessario padroneggiare in anticipo comandi di installazione, configurazione delle dipendenze e chiamate di interfacce complesse. Installazione del framework, configurazione dell'esecuzione, scelta o generazione dell'algoritmo possono essere assistiti dall'AI. La conversazione diventa un punto di accesso rapido che collega l'intenzione del ricercatore con l'output sperimentale di EvoX. Il ricercatore si concentra sul gusto per i problemi, i compromessi multi-obiettivo, l'accettazione delle soluzioni e il giudizio critico. Nel modo tradizionale, per avviare un esperimento EvoX, bisogna prima ricordare comandi, dipendenze e interfacce
- La modalità di lavoro AI Native sposta il punto di accesso verso l'"espressione dell'intenzione". Descrivi su quale problema, con quali vincoli, con quali criteri di accettazione, strumenti come Codex si occupano di tradurre l'intenzione in codice eseguibile e operazioni sull'ambiente, e restituiscono lo stato di esecuzione. Così, il punto di partenza dell'esperimento non è più la memorizzazione di comandi, ma una chiara definizione del problema. Robot di magazzino che evita ostacoli e trova il percorso. Si può chiedere in linguaggio naturale all'AI di chiamare EvoX NSGA-II, fare ottimizzazione multi-obiettivo su GPU e produrre percorsi visualizzati. Qui bisogna distinguere tre tipi di informazione: l'intenzione è "per il robot di magazzino che evita ostacoli e trova il percorso, usare EvoX NSGA-II per fare ottimizzazione multi-obiettivo su GPU"
- gli obiettivi sono lunghezza del percorso minima, distanza di sicurezza massima, consumo energetico minimo
- il vincolo è restituire i risultati entro 5 minuti
- gli obiettivi di accettazione sono produrre il fronte di Pareto e percorsi visualizzati, e conservare risultati di esecuzione riproducibili. Gli strumenti AI si occupano di comprendere il codice, configurare ambiente e dipendenze, scegliere o generare algoritmi, eseguire su GPU e restituire lo stato
- il compito dell'uomo si sposta su definizione del problema, impostazione dei criteri di valutazione, compromessi multi-obiettivo, accettazione delle soluzioni e giudizio critico.

**Gestione degli esercizi**

Se si chiede "qual è il concetto chiave", bisogna cogliere "sperimentare un workflow AI nativo senza dover memorizzare comandi di installazione o interfacce complesse". Se si chiede di giudicare quale affermazione è più ragionevole, si dovrebbe scegliere l'opzione che collega i concetti di questa pagina e fornisce prove o esempi; basarsi solo sull'intuito, cambiare tutti i fattori contemporaneamente, saltare i materiali e memorizzare direttamente la risposta non soddisfano i requisiti. Anche su "completare rapidamente la configurazione dell'ambiente e la progettazione dell'algoritmo", bisogna saper spiegare con prove o esempi, non solo memorizzare la conclusione.

**Verifica della comprensione**

Chiedere agli studenti di spiegare con parole proprie la relazione "intenzione in linguaggio naturale → comprensione ed esecuzione da parte dell'AI → output dell'esperimento EvoX", e spiegare perché il ricercatore deve ancora verificare se i vincoli sono soddisfatti, se il fronte di Pareto è ragionevole, se il percorso è sicuro e percorribile. Dopo aver confermato che gli studenti sanno distinguere le responsabilità esecutive dell'AI dalle responsabilità di giudizio dell'uomo, passare ai contenuti pratici successivi.

<a id="lecture-page-8"></a>

### Pratica: compito di ricerca del percorso per robot di magazzino

*Pagina 8*

> **Obiettivo della pagina:** Comprendere come chiamare rapidamente EvoX tramite AI per risolvere uno specifico problema di ricerca del percorso con evitamento degli ostacoli.

> **Ordine espositivo**
>
> Scaffali, corridoi, ostacoli, punto di partenza e punto di arrivo sono già determinati, bisogna trovare un percorso senza collisioni e il più corto possibile.
>
> 2. Indicare che lunghezza del percorso e sicurezza nell'evitamento degli ostacoli di solito non sono coerenti, quindi è un tipico problema di ottimizzazione multi-obiettivo, non un problema di percorso più breve mono-obiettivo.
>
> 3. Spiegare che l'AI come "traduttore di compiti" trasforma la descrizione in linguaggio naturale del compito in chiamate EvoX eseguibili, riducendo codifica manuale e configurazione dei parametri.
>
> 4. EvoX NSGA-II completa in parallelo su GPU la valutazione della popolazione e la ricerca, conserva più soluzioni di compromesso, formando una famiglia di percorsi da "corto ma rischioso" a "lungo ma sicuro".
>
> Visualizza grafici delle rotte candidate e curve di tendenza della convergenza, per osservare fattibilità e progresso della ricerca.

**Punti chiave dell'insegnamento**

- Layout fisso del magazzino, ambiente con ostacoli, punto di partenza e arrivo del robot. Punti chiave del percorso, punti di controllo della curva, raggio di curvatura, profilo di velocità, ecc. Minimizzare la lunghezza del percorso
- Minimizzare il rischio di collisione o massimizzare la fattibilità senza collisioni. Il percorso deve rimanere all'interno dei corridoi, non può attraversare scaffali o ostacoli, e deve soddisfare i vincoli cinematici del robot. Trasformare automaticamente la descrizione in linguaggio naturale in chiamate EvoX eseguibili, riducendo i costi di configurazione
- Non sostituisce l'algoritmo di ottimizzazione stesso. Valutare in parallelo un gran numero di rotte candidate, accelerando le iterazioni di NSGA-II
- Non cambia il fatto che il multi-obiettivo ha soluzioni di compromesso. Visualizza grafici delle rotte per osservare fattibilità del percorso, diversità e rotte raccomandate senza collisioni
- Curve di tendenza della convergenza per giudicare se si è entrati in fase di plateau. Prima definire obiettivi e vincoli, poi regolare i parametri
- La fattibilità ha priorità sulla lunghezza del percorso
- Usare la tendenza della convergenza per decidere se continuare le iterazioni o fermarsi.

**Gestione degli esercizi**

Elementi di input del compito -> layout fisso del magazzino, ambiente con ostacoli, punto di partenza e arrivo. Feedback: l'input del compito definisce ambiente, vincoli e condizioni di partenza e arrivo.

I due obiettivi gestiti da NSGA-II -> lunghezza del percorso e sicurezza nell'evitamento degli ostacoli. Feedback: un percorso più corto può avvicinarsi di più agli ostacoli, i requisiti di sicurezza possono allungare il percorso.

Il valore principale dell'AI -> trasformare automaticamente la descrizione del compito in chiamate EvoX eseguibili. Feedback: l'AI è il livello di traduzione dei compiti e di generazione delle chiamate, riduce i costi di configurazione.

Il vantaggio della GPU -> valutazione parallela di un gran numero di rotte candidate, accelerazione delle iterazioni di NSGA-II. Feedback: la GPU accelera valutazione e ricerca, non cambia la natura del compromesso multi-obiettivo.

Grafici delle rotte e tendenza della convergenza -> osservare rispettivamente fattibilità del percorso, diversità e rotte raccomandate senza collisioni; se il processo di ottimizzazione converge. Feedback: il grafico delle rotte mostra la qualità spaziale delle soluzioni, la tendenza della convergenza mostra il progresso della ricerca nella dimensione temporale.

Definire variabili decisionali, due obiettivi di ottimizzazione, condizioni di vincolo; spiegare la divisione del lavoro tra AI, EvoX NSGA-II e GPU, e spiegare come la tendenza della convergenza assiste la decisione. Punti chiave della risposta: l'AI analizza la descrizione del compito in chiamate EvoX; NSGA-II valuta in parallelo su GPU, ordinamento non dominato e crowding distance mantengono le soluzioni di compromesso; output di rotte visualizzate e curve di convergenza; se la curva è piatta il guadagno è limitato, se continua a scendere si possono aumentare le iterazioni o la dimensione della popolazione.

**Verifica della comprensione**

Chiedere a uno studente a caso di riassumere con parole proprie i punti chiave di questa pagina, l'insegnante integra le parole chiave mancanti in base alla risposta.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno dire la relazione centrale di questa pagina, passare alla pagina successiva con esempi, applicazioni o riepilogo.

<a id="lecture-page-9"></a>

### Analisi dei risultati sperimentali e visualizzazione

*Pagina 9*

> **Obiettivo della pagina:** Imparare a interpretare la tendenza della convergenza e i dati completi dei risultati nel processo di ottimizzazione.

> **Obiettivo della pagina**
>
> Imparare a interpretare la tendenza della convergenza e i dati completi dei risultati nel processo di ottimizzazione, comprendendo che "tendenza del processo + risultato finale" devono corroborarsi reciprocamente, non si può concludere basandosi solo sul singolo risultato ottimale.

> **Ordine espositivo**
>
> 1. Prima leggere la curva di convergenza, giudicare se il processo di ricerca sta avanzando.
>
> 2. Poi guardare la rotta finale e la tabella delle metriche con layout fisso del magazzino, giudicare se la soluzione è utilizzabile.
>
> 3. Usare i dati completi dell'esperimento per sostenere conclusioni riproducibili.
>
> 4. Attraverso esercizi e casi, gestire gli errori di giudizio comuni.

**Punti chiave dell'insegnamento**

- Due tipi di prove, nessuna delle due può mancare. La curva risponde a "la ricerca si sta muovendo", rotta e metriche rispondono a "il risultato è utilizzabile". Solo la tendenza della convergenza spiega che la ricerca sta avanzando, la visualizzazione della rotta e la tabella delle metriche spiegano che la soluzione è utilizzabile, entrambe le condizioni devono valere contemporaneamente per concludere. Mancando una delle due metà, è solo una congettura. Miglioramento continuo, calo stabile nella fase iniziale e intermedia o aumento stabile dell'indicatore complessivo
- Oscillazione, fluttuazione su e giù senza andamento a lungo termine, può derivare da rumore di valutazione, conflitti di vincoli o diversità eccessiva
- Stagnazione, un intervallo quasi orizzontale ma con possibili miglioramenti successivi
- Convergenza prematura, appiattimento completo molto presto senza recupero, spesso dovuto a perdita di diversità della popolazione o compressione prematura dello spazio delle soluzioni. Quando la curva mostra nella fase finale "stagnazione tardiva/convergenza prematura?", bisogna distinguere con i log, non si può scrivere direttamente "convergenza raggiunta". Confronto delle rotte con layout fisso del magazzino, sovrapporre la rotta ottimale e le rotte di confronto sulla stessa mappa fissa del magazzino, verificare se il percorso è realmente percorribile, se l'aggiramento degli ostacoli è ragionevole, se l'ultimo tratto vicino al punto di arrivo è stabile. Il layout fisso è un vincolo chiave, fa sì che le differenze di rotta tra diverse esecuzioni o parametri siano attribuibili all'ottimizzazione stessa, non a cambiamenti della mappa. La tabella delle metriche può fornire un confronto intuitivo: lunghezza del percorso 128.4 contro 156.9, numero totale di svolte 6 contro 9, costo complessivo 1.00 contro 1.21, mostrando il vantaggio della rotta ottimale su più metriche. Configurazione di esecuzione e seed casuale, log delle iterazioni, valori di ciascun obiettivo per generazione, rotta finale e risultati di valutazione. Se la curva non mostra più miglioramenti evidenti nella fase finale, bisogna giudicare con i log completi se è convergenza prematura, saturazione della valutazione, o avvicinamento a una soluzione utilizzabile
- Se necessario rieseguire o fare verifiche incrociate. Una curva che si appiattisce presto e uniformemente non equivale automaticamente a trovare la soluzione ottimale, né automaticamente a fallimento dell'algoritmo
- Una rotta che sembra bella non equivale a ricerca stabile. Un singolo risultato ottimale può essere un miglioramento reale, ma anche fluttuazione casuale o prodotto di saturazione della valutazione, tendenza del processo e risultato finale devono corroborarsi reciprocamente.

**Copertura delle parole chiave**

- Tendenza della convergenza, verifica della rotta, layout fisso del magazzino, riproducibilità, convergenza prematura, saturazione della valutazione, indicatore di ipervolume, lunghezza del percorso, numero totale di svolte, costo complessivo.

> **Spunti per gli esercizi**
>
> - Cinque domande a scelta multipla ruotano intorno ai giudizi chiave di questa pagina. La domanda 1 chiede la relazione tra curva di convergenza e visualizzazione della rotta finale, la direzione corretta è "la curva riflette se il processo di ricerca sta avanzando, rotta e tabella delle metriche riflettono se la soluzione finale è utilizzabile, le due vanno giudicate insieme". La domanda 2 chiede come gestire quando dopo la 200ª generazione i valori obiettivo rimangono a lungo orizzontali, la direzione corretta è "giudicare con i log completi se è convergenza prematura, saturazione della valutazione, o avvicinamento a una soluzione utilizzabile, rieseguire con strategie adattate se necessario". La domanda 3 chiede cosa dovrebbe essere conservato e verificato per conclusioni riproducibili, la direzione corretta è "configurazione di esecuzione, seed casuale, log delle iterazioni, valori di ciascun obiettivo, rotta finale e risultati di valutazione". La domanda 4 chiede lo scopo del layout fisso del magazzino, la direzione corretta è "rendere le differenze di rotta tra diverse esecuzioni o algoritmi attribuibili all'ottimizzazione stessa, non a cambiamenti dell'ambiente". La domanda 5 chiede l'interpretazione rigorosa di "molto uniforme e che smette di cambiare molto presto", la direzione corretta è "verificare se esiste saturazione della valutazione o perdita prematura di diversità della popolazione, e validare incrociando con riesecuzioni e metriche". Feedback delle risposte: quando corretto, spiegare che il giudizio collega i concetti di questa pagina e fornisce motivazioni
> - quando errato, tornare alla spiegazione di questa pagina, trovare prove chiave o esempi prima di giudicare. Nel caso "riproduzione della ricerca multi-obiettivo del percorso con layout fisso del magazzino", se dopo la 180ª generazione la curva tende a appiattirsi e si ottiene una buona rotta candidata, bisogna raccogliere e verificare configurazione di esecuzione e seed casuale, log delle iterazioni, valori di ciascun obiettivo per generazione, rotta finale e risultati di valutazione con layout fisso, tabella delle metriche chiave, e si raccomanda di rieseguire o fare verifiche incrociate. Non si può usare solo il singolo risultato ottimale, perché il punto ottimale singolo può derivare da fluttuazione casuale o saturazione della valutazione, non può spiegare se la ricerca sta realmente avanzando, né può essere riprodotto da altri. Se dopo la riesecuzione la forma della curva è simile ma la rotta finale è diversa, bisogna confrontare la distribuzione delle metriche invece dei valori puntuali, verificare se seed e configurazione sono coerenti, controllare convergenza prematura o saturazione della valutazione, se necessario aumentare le generazioni, adattare le strategie di mantenimento della diversità o correggere la funzione di valutazione, e fornire nel rapporto rotte tipiche e riepiloghi statistici.

**Verifica della comprensione**

Chiedere a uno studente a caso di riassumere con parole proprie "la curva guarda la tendenza, la rotta guarda l'attuazione" e la relazione "tendenza del processo e risultato finale, nessuno dei due può mancare", l'insegnante integra le parole chiave mancanti in base alla risposta. Si può chiedere agli studenti di fare un esempio vicino alla loro esperienza per spiegare perché guardare solo la curva o solo la rotta può portare a giudizi errati.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno dire che curva di convergenza e visualizzazione della rotta vanno giudicate insieme, passare alla pagina successiva con esempi, applicazioni o riepilogo.

<a id="lecture-page-10"></a>

### Più gli strumenti sono facili da usare, più chiara è la responsabilità umana

*Pagina 10*

> **Obiettivo della pagina:** Riconoscere il cambiamento del ruolo e della responsabilità del ricercatore umano dopo la diffusione degli strumenti di automazione.

> **Obiettivo della pagina**
>
> Comprendere che dopo la diffusione degli strumenti di automazione, la responsabilità del ricercatore non è diminuita, ma si è spostata dall'"implementazione" alla "definizione e arbitraggio". Questa pagina deve far ricordare agli studenti una frase: più gli strumenti sono facili da usare, più chiara è la responsabilità umana.

**Punti chiave dell'insegnamento**

- L'AI e EvoX comprimono molto il costo di esecuzione di "idea→codice→esperimento", generare rapidamente implementazioni candidate, regolare i parametri in batch, disegnare curve diventano tutti facili. Ma il calo del costo di esecuzione non equivale alla scomparsa del costo di giudizio. Il modello non può rispondere al posto del ricercatore a tre domande preliminari: questo problema merita di essere studiato? L'obiettivo è accurato? Il confronto è equo? Riuscire a eseguire, passare la compilazione, passare i test, migliorare le metriche, sono solo segnali candidati, non equivalgono a conclusioni scientifiche valide. A sinistra c'è il livello di esecuzione AI/strumenti, che si occupa di generare codice candidato, esperimenti in batch e regolazione dei parametri, disegno e visualizzazione automatici, e far eliminare rapidamente le implementazioni di basso valore
- A destra c'è il livello di responsabilità umana, che si occupa di porre domande chiave, definire obiettivi e criteri di valutazione, garantire un confronto equo, verificare se le conclusioni sono valide, e giudizio di valore e gusto. Al centro c'è il gate del "giudizio non esternalizzabile", i criteri di accettazione non sono negoziabili, le modifiche candidate devono passare il giudizio umano. Il gateway di accettazione di Genesis è proprio l'ingegnerizzazione di questo confine: le modifiche candidate devono superare compilazione, test, controllo comportamentale e accettazione di livello superiore, per poter entrare nella storia del progetto. Negli esperimenti multi-obiettivo EvoX, l'Agent può generare rapidamente soluzioni candidate, regolare parametri e disegnare, ma il ricercatore deve ancora verificare: la funzione obiettivo rappresenta i bisogni reali? La diversità dei candidati è nascosta dalle metriche? I modelli di fallimento sono mostrati selettivamente? Qui il valore degli strumenti è far eliminare più rapidamente le implementazioni di basso valore, facendo diventare prima il collo di bottiglia il giudizio di alto valore. Anche il suggerimento di Turing cade su questo punto: c'è molto lavoro da fare davanti, Code is cheap. Taste matters. La competenza centrale è porre domande chiave e controllare le conclusioni in modo riproducibile
- Il gusto del ricercatore determina in quale valore scientifico si trasforma alla fine la convenienza tecnologica.

**Copertura delle parole chiave**

- Costo di esecuzione, costo di giudizio, giudizio non esternalizzabile, validità scientifica, gateway di accettazione, segnale candidato, confronto equo, giudizio di valore e gusto. Riferimenti: questa pagina si sviluppa intorno a "la responsabilità si sposta: dall'implementazione alla definizione e all'arbitraggio" e "la validità dei risultati ha priorità sul successo dell'esecuzione". Spunti per i materiali: si può usare un diagramma di confronto sinistra-destra per evidenziare la divisione tra livello di esecuzione AI/strumenti e livello di responsabilità umana, con al centro l'enfasi sul "giudizio non esternalizzabile".

**Gestione degli esercizi**

La domanda 1 dovrebbe scegliere "superare compilazione, test, controllo comportamentale e accettazione di livello superiore", il punto di feedback è: grafici più veloci o più belli sono solo segnali candidati, il punto chiave è il gateway di accettazione. La domanda 2 dovrebbe scegliere "scelta del problema, definizione dell'obiettivo e criteri di valutazione devono ancora essere assunti dall'uomo", il punto di feedback è: gli strumenti accelerano l'esecuzione, non eliminano il giudizio. La domanda 3 dovrebbe scegliere "se il problema merita di essere studiato, se l'obiettivo è accurato, se il confronto è equo", il punto di feedback è: queste tre categorie sono condizioni preliminari della validità scientifica. La domanda 4 dovrebbe dare priorità alla verifica di "se la funzione obiettivo rappresenta i bisogni reali, se la diversità dei candidati è nascosta dalle metriche, se i modelli di fallimento sono mostrati selettivamente", il punto di feedback è: metriche migliori non equivalgono a conclusioni valide.

La domanda 5 dovrebbe scegliere "dopo la riduzione del costo di implementazione, il gusto e il giudizio del ricercatore determinano in quale valore scientifico si trasforma la convenienza tecnologica", il punto di feedback è: Code is cheap si riferisce alla riduzione del costo di implementazione, Taste matters si riferisce al fatto che giudizio e gusto sono più importanti.

Nel progetto multi-Agent Genesis, l'Agent può proporre patch candidate, eseguire test e aggregare metriche, ma l'approvazione per l'ingresso nella storia del progetto, l'impostazione dei criteri di accettazione e l'interpretazione delle conclusioni devono essere di competenza umana. I giudizi non esternalizzabili includono: se il miglioramento della stabilità è un bisogno reale, come si definisce la stabilità, se il benchmark rappresenta scenari reali, e se baseline, variabili, modelli di fallimento sono trattati in modo coerente. Se si usa solo "miglioramento delle metriche di benchmark" come criterio di accettazione, i rischi possono derivare da bias della funzione obiettivo, overfitting sul benchmark, presentazione selettiva di casi di successo, occultamento di modelli di fallimento o confronti non equi.

La direzione di miglioramento è aggiungere al gateway di accettazione riproduzione della baseline, controllo delle variabili, esperimenti di ablazione, report dei modelli di fallimento, compromessi multi-obiettivo e verifiche dei limiti di estrapolazione, e richiedere agli umani di confermare se la funzione obiettivo rappresenta i bisogni reali, se il confronto è equo.

Prima chiedere se vale la pena, poi come implementare; considerare i criteri di accettazione come propria responsabilità; il gusto determina la destinazione della convenienza tecnologica. Verifica della comprensione: chiedere agli studenti di dire in una frase qual è il giudizio non esternalizzabile più importante di questa pagina, e spiegare come verificarlo. Suggerimento di transizione: dopo aver confermato che gli studenti sanno distinguere "segnale candidato" da "conclusione scientifica", e sanno dire il confine tra livello di esecuzione e livello di responsabilità, passare alla pagina successiva con applicazioni o riepilogo.

<a id="lecture-page-11"></a>

### Il cuore della ricerca: la capacità di porre domande chiave

*Pagina 11*

> **Obiettivo della pagina:** Padroneggiare la capacità di porre domande chiave, più importante della scrittura di codice nell'era della programmazione automatizzata.

> **Obiettivo della pagina**
>
> Questa pagina deve far comprendere agli studenti che nella ricerca AI Native, la programmazione automatizzata e i grandi modelli hanno già compresso molto il costo di "implementare risposte", il baricentro della ricerca si è quindi spostato da "si riesce a farlo" a "vale la pena farlo, dove farlo". La competenza centrale del ricercatore è porre domande chiave, e custodire direzione, criteri di scelta e significato scientifico.

**Punti chiave dell'insegnamento**

- 1. Il cambiamento nella struttura dei costi è il punto di partenza logico di questa pagina. Generazione di codice, ricerca di soluzioni, esecuzione di esperimenti possono tutti essere affidati all'AI
- quando le risposte diventano economiche, ciò che è scarso diventa "porre le domande giuste". L'AI si occupa di ampliare lo spazio delle risposte e i percorsi di esecuzione, l'uomo si occupa di definizione del problema e controllo della direzione, la responsabilità si sposta di conseguenza. 2. Usando la mappa mentale della pagina, scomporre la capacità di porre domande chiave in sei tipi di elementi, spiegandoli uno per uno: obiettivi e conflitti — quale quantità si vuole realmente migliorare, come scegliere tra multi-obiettivo, chi ha priorità
- vincoli e confini — quali condizioni non sono negoziabili, quanto è grande lo spazio delle soluzioni
- valutazione e verifica — se le metriche sono osservabili, quali sono il protocollo di verifica e il budget di valutazione
- candidati/spazio delle soluzioni — quale diversità e robustezza sono necessarie
- criteri di fallimento — quali risultati dovrebbero essere giudicati fallimenti
- divisione uomo-macchina e gusto — l'AI amplia le risposte, l'uomo controlla la direzione. Si può suggerire agli studenti di memorizzare queste sei categorie come una lista di autocontrollo. 3. L'essenza delle domande chiave non è indagare i dettagli di implementazione, ma trasformare l'intuizione vaga in una struttura di ricerca verificabile, evolvibile, dividibile. La qualità delle domande determina la qualità dello spazio delle soluzioni: più chiara è la definizione del problema, più probabile che ricerca ed evoluzione cadano in regioni significative, più probabile che l'output sia interpretabile e riutilizzabile
- più vaga è la definizione, più il modello può solo esplorare casualmente in uno spazio troppo grande, i risultati spesso sembrano fattibili ma non possono essere sedimentati. 4. Divisione uomo-macchina e gusto centrale del ricercatore. L'AI amplia lo spazio delle risposte e i percorsi di esecuzione, l'uomo controlla direzione, criteri di scelta e significato scientifico. Prendendo come esempio la pratica di evoluzione continua a livello di sistema come Genesis: le modifiche candidate devono superare compilazione, test e accettazione di livello superiore, per poter entrare nella versione di progetto accettata, diventando la base storica del lavoro successivo
- se nella fase di domanda non si definiscono chiaramente protocollo di valutazione e criteri di fallimento, il checkpoint di accettazione non ha basi per giudicare, l'output dell'AI può solo rimanere un prodotto di codice usa e getta, incapace di accumularsi attraverso contesti e cicli di compito. Il gusto centrale sono tre giudizi: cosa merita di essere chiesto, quali prove sono accettabili, quali soluzioni sebbene fattibili non meritano di essere fatte. Riscriverlo come "qual è il conflitto reale? Come quantificare obiettivi e vincoli? Quali sono il budget di valutazione e i criteri di verifica? Quale diversità e robustezza sono necessarie? Quali risultati dovrebbero essere giudicati fallimenti?" Così l'AI può implementare efficientemente le risposte, e l'uomo ha basi per l'accettazione. Le cinque domande a scelta multipla corrispondono ai cinque giudizi di questa pagina — perché il cuore della ricerca si è spostato, l'essenza delle domande chiave, gli elementi che una domanda chiave deve chiarire, la relazione tra qualità delle domande e spazio delle soluzioni, i tre giudizi del gusto centrale. Nella gestione non è necessario leggerle tutte, si può prima far rispondere gli studenti, poi correggere con feedback come "ciò che è stato compresso è il costo di implementazione, non il costo di giudizio" e "vago non significa libero". Il caso di studio richiede agli studenti di riscrivere "fare ottimizzazione con EvoX" in una scheda del problema che copra obiettivi e conflitti, vincoli e confini, valutazione e verifica, criteri di fallimento, e spiegare come la qualità delle domande determina se l'esperimento può sedimentarsi in risultati di progetto sostenibilmente evolutivi. Punti di riferimento: Genesis considera il codice inviato come modifica candidata, solo superando compilazione, test e accettazione di livello superiore entra nella versione accettata
- mancando metriche osservabili, protocollo di verifica e criteri di fallimento, l'accettazione non ha basi
- l'AI si occupa di generare candidati, ricerca e esecuzione dei test, l'uomo si occupa di definire obiettivi, vincoli rigidi, budget di valutazione e criteri di fallimento e di prendere la decisione di accettazione. Chiedere a uno studente a caso di ripetere con parole proprie i sei autocontrolli, e dare un'esigenza vaga della propria ricerca, provando a riscriverla sul momento. Dopo aver confermato che gli studenti sanno dire le due relazioni "riuscire a eseguire non equivale a valere l'investimento" e "la qualità delle domande determina la qualità dello spazio delle soluzioni", passare alla pagina successiva.

<a id="lecture-page-12"></a>

### Divisione uomo-macchina: l'AI implementa le risposte, l'uomo controlla la direzione

*Pagina 12*

> **Obiettivo della pagina:** Chiarire la relazione di divisione e collaborazione tra AI e ricercatore nel processo di esplorazione scientifica.

**Punti chiave dell'insegnamento**

- Prima di ogni esperimento chiedetevi tre cose: chi ha scelto questo problema? chi ha definito i criteri di valutazione? chi accetta le conclusioni? Se le risposte a tutte e tre puntano a "me", la divisione è sana; se puntano tutte al modello, il controllo della direzione è già perso.
- Una volta che i criteri di valutazione possono essere riscritti da un processo automatico, l'ottimizzazione si orienterà silenziosamente verso "la metrica più facile da migliorare". Impostare funzione obiettivo e vincoli come sola lettura è la prima barriera contro la deriva.
- L'AI amplia la larghezza di banda, l'uomo custodisce il significato — ciò che viene consegnato non sono più numeri, ma conclusioni solide.

### Obiettivo della pagina

Chiarire la relazione di divisione e collaborazione tra AI e ricercatore, definire il confine tra livello di esecuzione AI e livello di controllo umano, comprendere perché "l'AI amplia la larghezza di banda dell'esplorazione, l'uomo custodisce il significato scientifico".

### Ordine espositivo

Affidare implementazione ed esplorazione all'AI, lasciare direzione e giudizio al ricercatore.

Ciclo chiuso di collaborazione uomo-macchina. Il livello di esecuzione AI comprende implementazione di risposte, esecuzione in batch di esperimenti, ricerca di soluzioni candidate, feedback dei risultati; il livello di controllo umano comprende definizione del problema, scelta della direzione, giudizio sulle prove, accettazione del significato scientifico. I due lati sono accoppiati tramite "risultati verso l'alto, standard verso il basso": l'AI spinge soluzioni candidate e feedback sperimentali al ricercatore, il ricercatore restituisce obiettivi, vincoli e criteri di accettazione all'AI.

Implementare rapidamente risposte, eseguire in batch esperimenti, cercare soluzioni candidate e fornire feedback. Una volta che problema e criteri di valutazione sono chiari, l'AI può fornire in brevissimo tempo soluzioni eseguibili e verificabili, trasformando il tentativo ed errore da risorsa scarsa a operazione routine.

Porre domande chiave, impostare obiettivi, vincoli e criteri di valutazione, giudicare se le prove sono credibili, completare l'accettazione del significato scientifico. Bisogna saper distinguere "risultati che funzionano" da "risultati affidabili", identificando overfitting, data leakage e falsificazione delle metriche.

La mancanza di uno dei due lati porta al fallimento. Solo AI, si otterranno molti risultati privi di significato; solo umani, la larghezza di banda dell'esplorazione è limitata. Prendendo come esempio l'esplorazione evolutiva multi-obiettivo, l'AI può generare ed eseguire automaticamente un gran numero di soluzioni candidate, il ricercatore decide se obiettivi di ottimizzazione, condizioni di vincolo e metriche di valutazione riflettono il problema reale, e seleziona le direzioni scientificamente credibili che meritano ulteriore esplorazione.

Affidare anche i criteri di valutazione all'AI per la decisione automatica. Così il sistema ottimizzerà molto efficientemente un obiettivo che non riflette il vero problema scientifico, producendo molti risultati "apparentemente ragionevoli" ma privi di significato. Tutte le decisioni che cambiano "cosa è considerato buono" devono rimanere dal lato umano.

Chi ha scelto questo problema? chi ha definito i criteri di valutazione? chi accetta le conclusioni? Se le risposte a tutte e tre puntano a "me", la divisione è sana; se puntano tutte al modello, il controllo della direzione è già perso.

L'AI amplia la larghezza di banda, l'uomo custodisce il significato — ciò che viene consegnato non sono più numeri, ma conclusioni solide.

### Punti chiave dell'insegnamento

Implementazione di risposte, esecuzione in batch di esperimenti, ricerca di soluzioni candidate, feedback dei risultati, il cuore è comprimere il costo di implementazione a quasi zero.

Definizione del problema, scelta della direzione, giudizio sulle prove, accettazione del significato scientifico, il cuore è tenere il costo di giudizio nelle proprie mani.

L'AI amplia la larghezza di banda dell'esplorazione, l'uomo controlla direzione e criteri di accettazione.

Una volta che i criteri di valutazione possono essere riscritti da un processo automatico, l'ottimizzazione si orienterà silenziosamente verso "la metrica più facile da migliorare". Impostare funzione obiettivo e vincoli come sola lettura è la prima barriera contro la deriva.

Non si tratta di produrre più risultati numerici, ma che i risultati abbiano veramente significato scientifico, solo allora la quantità ha valore.

### Copertura delle parole chiave

Livello di esecuzione AI, livello di controllo umano, ciclo chiuso di collaborazione uomo-macchina, larghezza di banda dell'esplorazione, deriva dei criteri di valutazione, funzione obiettivo in sola lettura, accettazione del significato scientifico, tre domande di autocontrollo.

### Gestione degli esercizi

La risposta corretta è "implementare rapidamente risposte, eseguire in batch esperimenti e cercare soluzioni candidate". L'AI si occupa di implementazione ed esplorazione; decidere il valore del problema, giudicare la credibilità delle prove, accettare il significato scientifico appartengono al livello di controllo umano.

La risposta corretta è "perché solo quando i risultati hanno veramente significato scientifico, la quantità ha valore". La quantità deriva dalla larghezza di banda dell'esplorazione dell'AI, il valore deriva dal giudizio umano sul significato scientifico.

La risposta corretta è "se obiettivi di ottimizzazione, condizioni di vincolo e metriche di valutazione riflettono il problema reale". Generazione di candidati ed esecuzione in batch appartengono al livello di esecuzione AI; il ricercatore deve presidiare il livello "cosa è considerato buono".

La risposta corretta è "permettere al ricercatore di concentrare l'attenzione sul giudizio di direzione e sui criteri di accettazione". L'AI amplia l'ampiezza, l'uomo fornisce la direzione, i due si completano invece di sostituirsi.

La risposta corretta è "il sistema ottimizzerà efficientemente un obiettivo che non riflette il vero problema scientifico, producendo molti risultati apparentemente ragionevoli ma privi di significato". Affidare i criteri di valutazione al sistema equivale a far scrivere l'esame a chi viene valutato; tutte le decisioni che cambiano i criteri di valutazione devono mantenere la revisione umana.

### Gestione del caso

1. Il livello di esecuzione AI include la generazione di formulazioni candidate, l'esecuzione in batch di simulazioni, la raccolta delle metriche di prestazione e l'aggiornamento della popolazione, queste appartengono a implementazione ed esplorazione. Il livello di controllo umano include il sistema di materiali da cercare, obiettivi di prestazione e vincoli di processo, se le metriche riflettono il vero significato fisico, se i candidati finali meritano ulteriore investimento sperimentale, queste appartengono a direzione e giudizio. Il criterio di divisione è: tutte le decisioni che cambiano "cosa è considerato buono" devono rimanere dal lato umano; tutto il lavoro che esegue standard già definiti su scala più ampia può essere affidato all'AI.

2. Se si lascia che l'AI aggiusti automaticamente i pesi delle metriche di prestazione tramite meta-ottimizzazione, il rischio principale è la deriva dei criteri di valutazione: una volta che il sistema ottimizzato detiene anche il potere di valutare se stesso, si orienterà verso "la metrica più facile da migliorare", le formulazioni ad alto punteggio prodotte potrebbero essere fisicamente irrealizzabili o prive di valore reale, e superficialmente spesso sembrano molto ragionevoli, difficili da identificare a colpo d'occhio. Le misure di protezione includono: dichiarare funzione obiettivo e vincoli come controllati e in sola lettura; la meta-ottimizzazione può solo regolare pochi iperparametri entro confini specificati dall'uomo con limiti superiore e inferiore; impostare gateway di accettazione indipendenti dall'obiettivo di ottimizzazione, come esperimenti reali di sintesi e caratterizzazione; qualsiasi cambiamento di peso deve essere esplicitamente revisionato dal ricercatore con registrazione, garantendo la tracciabilità delle decisioni di direzione.

### Attività in classe

Chiedere agli studenti di usare un esempio vicino alla propria esperienza di studio o ricerca, ripetere la divisione "l'AI implementa le risposte, l'uomo controlla la direzione", e spiegare la relazione tra questo esempio e le tre domande di autocontrollo.

### Verifica della comprensione

Livello di esecuzione AI, livello di controllo umano, ciclo chiuso di collaborazione uomo-macchina, deriva delle metriche, tre domande di autocontrollo. Integrare le parole chiave mancanti in base alla risposta.

### Suggerimento di transizione

Dopo aver confermato che gli studenti sanno dire la relazione centrale "l'AI amplia la larghezza di banda dell'esplorazione, l'uomo controlla direzione e criteri di accettazione", passare alla pagina successiva con esempi, applicazioni o riepilogo.

<a id="lecture-page-13"></a>

### Principio fondamentale: Code is cheap. Taste matters

*Pagina 13*

> **Obiettivo della pagina:** Sperimentare la filosofia di Turing e l'obiettivo finale di EvoX di costruire infrastrutture aperte.

> **Obiettivo della pagina**
>
> Comprendere il principio fondamentale "Code is cheap. Taste matters", sperimentare la filosofia di Turing e l'obiettivo finale di EvoX di costruire infrastrutture aperte.

**Punti chiave dell'insegnamento**

- 1. Code is cheap è una descrizione oggettiva dello stato attuale dell'ingegneria. Quando il costo marginale di generazione e implementazione del codice viene compresso quasi a zero da grandi modelli e basi tensorizzate, il codice non è più una barriera, né un'unità di misura del contributo alla ricerca. "Riuscire a eseguire" degenera da risultato a presupposto, da successo mostrabile a biglietto d'ingresso per continuare il lavoro. 2. Taste matters è la riposizionamento della responsabilità umana dopo la divisione uomo-macchina. Quando "l'AI implementa le risposte, l'uomo controlla la direzione" diventa la divisione predefinita, ciò che è veramente scarso dal lato umano è la capacità di porre domande chiave, impostare criteri di valutazione, giudicare la direzione nei conflitti multi-obiettivo. 4. Scelta del problema — quale problema fare, più di con quale metodo farlo, determina il limite superiore, quando la direzione è sbagliata più veloce è l'implementazione più si spreca
- progettazione della funzione obiettivo e dei criteri di valutazione — una volta scelta male la metrica, il modello convergerà efficientemente nella direzione sbagliata
- criteri di scelta nei compromessi multi-obiettivo — le preferenze tra prestazioni, riproducibilità, manutenibilità, costo di implementazione devono essere dichiarate esplicitamente, non decise sul momento
- interpretazione e attribuzione dei risultati — distinguere "riuscito per caso" da "veramente capito", e giudicare da quali modifiche derivano effettivamente i benefici. 4. Il gusto deve essere verificabile. Il gusto non è un'asserzione estetica, né può essere deciso per anzianità o voto. Deve essere falsificabile attraverso "entrare nell'ambiente reale—ricevere feedback reali": scrivere il giudizio come ipotesi verificabile, rivederlo con fallimenti e successi in scenari reali. Altrimenti, la discussione si riduce a un litigio di preferenze. 5. Il significato dell'infrastruttura è dare al gusto un punto di atterraggio. L'obiettivo finale di EvoX è proprio costruire infrastrutture aperte in grado di entrare nell'ambiente reale e ricevere feedback reali. Una base aperta, disaccoppiata, componibile abbassa abbastanza il costo di implementazione, permettendo alle buone idee di entrare a basso costo in scenari reali, essere selezionate, sedimentate, ereditate — il giudizio ha così un supporto che può essere ripetutamente affinato. Code cheap non significa che l'ingegneria può essere omessa. Gateway di accettazione, riproducibilità, manutenibilità e cicli di feedback costituiscono ancora soglie reali. Il gusto si manifesta proprio nel giudizio di scelta su queste soglie: quali feedback meritano fiducia, quali metriche devono essere mantenute, quali tentativi falliti dovrebbero essere rifiutati invece che uniti. Il valore del meccanismo in stile Genesis è anche qui — le modifiche candidate solo superando compilazione, test, controllo comportamentale e accettazione di livello superiore possono diventare base storica ereditabile dagli esecutori successivi. Possiamo vedere solo una distanza molto breve davanti a noi, ma possiamo vedere che c'è molto lavoro da fare. Invece di discutere la forma specifica del fine dell'intelligenza, è meglio costruire prima infrastrutture aperte in grado di entrare continuamente in scenari reali e ricevere feedback reali, facendo sì che ogni ciclo di esplorazione possa essere verificato ed ereditato. La pagina mostra con un grafico di tendenza il calo continuo del costo di implementazione e l'aumento continuo del valore del giudizio, il loro punto di intersezione forma un punto di svolta, che significa che il giudizio diventa la variabile chiave. Sotto il grafico sono elencate le parole chiave della visione di EvoX: aperto, componibile, feedback reali, evoluzione continua.

**Gestione degli esercizi**

Questa pagina include cinque domande a scelta multipla, che verificano rispettivamente la comprensione del significato ingegneristico di Code is cheap, la direzione dello spostamento della scarsità, la falsificabilità del gusto, le quattro soglie ingegneristiche e lo scopo dell'infrastruttura EvoX. Dopo aver risposto, confrontare con il feedback, distinguendo in particolare "metriche del lato implementazione" e "capacità del lato giudizio": righe di codice, accuratezza del completamento, popolarità del framework, frequenza di commit non possono sostituire il giudizio su "cosa dovrebbe essere accettato". Il caso di studio richiede al team di elencare le fasi su cui investire prioritariamente e progettare un processo di accettazione delle modifiche candidate che verifichi il gusto;

le direzioni di riferimento includono scelta del problema e definizione degli obiettivi, progettazione di funzione obiettivo e criteri di valutazione, gateway di accettazione e criteri di scelta multi-obiettivo, interpretazione e attribuzione dei risultati, e il ciclo chiuso "modifica candidata—test isolati—punteggio di valutazione—accettazione di livello superiore—eredità storica—feedback di ritorno".

**Verifica della comprensione**

Chiedere a uno studente a caso di riassumere con parole proprie i punti chiave di questa pagina, l'insegnante integra le parole chiave mancanti in base alla risposta, come "riuscire a eseguire è solo il biglietto d'ingresso", "il gusto deve essere falsificabile", "le quattro soglie ingegneristiche".

> **Suggerimento di transizione**
>
> Questa pagina riprende la divisione della pagina precedente "l'AI implementa le risposte, l'uomo controlla la direzione", fornendo il principio fondamentale che sostiene questa divisione; la pagina successiva passerà alla pratica di guidare l'AI con la conversazione per completare compiti EvoX.

<a id="lecture-page-14"></a>

### Attività in classe: guidare l'AI con la conversazione per completare compiti EvoX

*Pagina 14*

> **Obiettivo della pagina:** Verificare attraverso la pratica il flusso di lavoro di base per compiti di ottimizzazione in ambiente AI Native.

**Attività in classe**

Guidare l'AI con la conversazione per completare compiti EvoX

> **Obiettivo della pagina**
>
> Completare il ciclo chiuso minimo "prompt → generazione → esecuzione → accettazione" in un ambiente EvoX reale. Il punto non è solo ottenere un frammento di codice leggibile, ma verificare la modalità di lavoro AI Native: l'uomo dà la direzione, l'AI dà l'implementazione, l'uomo fa l'accettazione.

> **Ordine espositivo**
>
> Prima spiegare il compito dell'attività, poi scomporre come costruire il prompt, quindi spiegare come verificare i risultati di esecuzione, infine gestire i risultati non ideali aggiungendo vincoli, e tornare alla divisione uomo-macchina.

**Punti chiave dell'insegnamento**

- Usare un prompt di conversazione per guidare l'AI a generare ed eseguire compiti di ottimizzazione EvoX di base, poi controllare l'output come un ingegnere. Problema di ottimizzazione e funzione obiettivo (ad esempio minimizzazione della funzione Rastrigin), spazio di ricerca e dimensione (ad esempio 10 dimensioni e intervallo di valori), algoritmo o operatore (ad esempio algoritmo DE, operatori di crossover e mutazione), dimensione della popolazione e numero di generazioni (ad esempio popolazione 128, 200 generazioni), piattaforma di calcolo (CPU o GPU tensorizzata), output atteso (valore ottimale, curva di convergenza, log di esecuzione). Troppo grossolano attiverà la configurazione predefinita, difficile giudicare se corrisponde all'intenzione
- troppo dettagliato degenera in codifica manuale. L'approccio adatto è chiarire vincoli e criteri di accettazione, lasciando i dettagli di implementazione all'AI. Ad esempio specificare problema, algoritmo, dimensione della popolazione e numero di iterazioni, ma senza prescrivere come chiamare le interfacce specifiche. Se viene realmente eseguito, non solo fornito il codice, si possono controllare i log del terminale e il tempo di esecuzione
- se la curva di convergenza è monotonicamente migliorativa e senza oscillazioni anomale
- se il valore ottimale è coerente con l'ordine di grandezza noto del problema, ad esempio l'ottimo globale della funzione Rastrigin è 0
- se seed casuale e configurazione sono riproducibili, con seed fisso ripetere l'esecuzione dovrebbe dare risultati uguali o simili. Quando i risultati non soddisfano le aspettative, dare priorità all'aggiunta di vincoli tramite conversazione, ad esempio "fissare seed=42 e rieseguire fornendo media e varianza di tre ripetizioni", osservando se l'AI sa iterare e correggere invece di riscrivere. L'uomo si occupa di definizione del problema, criteri delle metriche e giudizio sui risultati
- l'AI si occupa di scelta delle interfacce, organizzazione del codice ed esecuzione di debug. Solo verifica del flusso per compiti di base, senza sviluppare temi successivi come l'evoluzione a due livelli di MetaDE, i compromessi multi-obiettivo o il multi-Agent Genesis. Esempio di prompt di riferimento: "Usa EvoX per risolvere il minimo della funzione Rastrigin (10 dimensioni), con algoritmo DE, popolazione 128, 200 generazioni, backend GPU tensorizzato, seed fisso=42
- esegui direttamente e restituisci fitness ottimale, grafico della curva di convergenza e log di esecuzione." Se viene realmente eseguito, se la forma della curva di convergenza è ragionevole, se il valore ottimale è vicino a 0, se i risultati di esecuzioni ripetute sono coerenti.

> **Spunti per gli esercizi**
>
> - Non è necessario specificare il numero esatto di righe di codice per l'implementazione dell'algoritmo
> - la prova chiave della vera esecuzione sono log di iterazione del terminale e curva di convergenza
> - quando i risultati sono scarsi, il più efficace è aggiungere vincoli, ad esempio fissare il seed casuale e ripetere l'esecuzione
> - l'uomo si occupa principalmente di definire problema, criteri delle metriche e giudizio sui risultati
> - la granularità del prompt dovrebbe chiarire vincoli e criteri di accettazione, lasciando i dettagli di implementazione all'AI. Se lo studente risponde male, guidarlo a tornare a "elementi del prompt", "lista di controllo dell'esecuzione", "divisione uomo-macchina" per trovare le basi. Funzione Ackley 20 dimensioni, CMA-ES, popolazione 64, 500 iterazioni, CPU, seed fisso=123, se la curva oscilla violentemente nella fase iniziale e il valore ottimale è molto maggiore di 0, le possibili cause includono passo troppo grande, diversità della popolazione insufficiente, parametri dell'algoritmo non corrispondenti alla dimensione del problema, fluttuazioni esplorative iniziali dovute al seed casuale. I vincoli aggiuntivi possono fissare il seed e ripetere l'esecuzione tre volte, calcolare media e varianza
> - richiedere l'output della variazione del valore ottimale per ogni generazione
> - adattare passo o dimensione della popolazione e rieseguire. In fase di accettazione, oltre al valore ottimale, verificare anche se la vera esecuzione è avvenuta, la forma della curva di convergenza, l'ordine di grandezza del valore ottimale, la riproducibilità, la ragionevolezza del tempo di esecuzione. Si può chiedere agli studenti di dividersi in gruppi per i ruoli, uno si occupa di costruire il prompt, uno di osservare log di esecuzione e curva di convergenza, uno di fornire la conclusione di accettazione in base alla lista di controllo
> - registrare un risultato fallito o non ideale, e tentare di migliorarlo con vincoli aggiuntivi.

**Verifica della comprensione**

Chiedere a uno studente a caso di riassumere con parole proprie i punti chiave di questa pagina, l'insegnante integra elementi del prompt, le quattro domande di accettazione e il principio di iterare invece di riscrivere.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno dire la relazione centrale "l'uomo dà la direzione, l'AI dà l'implementazione, l'uomo fa l'accettazione", passare alla pagina successiva con esempi, applicazioni o riepilogo.

<a id="lecture-page-15"></a>

### Riepilogo del corso: workflow AI nativo e gusto scientifico

*Pagina 15*

> **Obiettivo della pagina:** Riassumere il workflow AI nativo di EvoX e il pensiero critico nella collaborazione uomo-macchina.

> **Obiettivo della pagina**
>
> Questa pagina, come chiusura dell'intero corso, converge il workflow AI nativo di EvoX e il gusto scientifico insostituibile del ricercatore in un'unica conclusione: quando gli strumenti comprimono a un livello estremamente basso il costo di "implementare risposte", "definire cosa vale la pena fare, giudicare quali risultati sono credibili" diventa lo spartiacque del valore della ricerca.

> **Ordine espositivo**
>
> A sinistra c'è il workflow AI nativo, che parte dalla conversazione in linguaggio naturale, completa configurazione dell'ambiente, costruzione di problema e vincoli, guida dell'esecuzione evolutiva e dell'esplorazione in batch, analisi e revisione della visualizzazione dei risultati; a destra c'è il gusto scientifico umano, che si occupa di definire il problema, impostare obiettivi e vincoli, scelte di compromesso multi-obiettivo, giudicare la credibilità dei risultati e la direzione dell'evoluzione.
>
> L'AI implementa le risposte, l'uomo controlla la direzione; in una frase: Code is cheap. Taste matters.
>
> Il workflow comprime il costo del percorso dall'idea al primo esperimento eseguibile; la responsabilità sale con la comodità; il gusto scientifico ha punti di atterraggio identificabili; il pensiero critico ha quattro domande strutturate; l'evoluzione continua a livello di progetto e di sistema richiede ancora che l'uomo imposti criteri di accettazione e direzione di evoluzione.
>
> Ciò che è scarso non è il codice, ma il giudizio; la padronanza del workflow determina quanto veloce si può correre, il gusto scientifico e il pensiero critico determinano se la direzione è giusta.

**Punti chiave dell'insegnamento**

- Usare la conversazione in linguaggio naturale come ingresso, per guidare l'esperimento EvoX a catena completa. Ciò che riduce è il costo del percorso da "idea" a "primo esperimento eseguibile", non l'esperimento stesso, né sostituisce definizione del problema e giudizio sui risultati. Scheletri di script, interfacce dei parametri e codice di graficazione possono prendere forma più rapidamente, il ricercatore ottiene così una frequenza di iterazione sperimentale più alta. Più gli strumenti sono facili da usare, più chiara è la responsabilità umana. L'automazione trasferisce il carico di esecuzione, non la responsabilità di giudizio. Quando l'AI produce soluzioni candidate in pochi minuti, "se i compromessi multi-obiettivo sono ragionevoli", "se il miglioramento delle metriche è credibile", "quale direzione esplorare dopo" devono ancora essere risposti dal ricercatore. La comodità aumenta il throughput del tentativo ed errore, e amplifica allo stesso modo la velocità di propagazione delle decisioni errate. Definizione del problema, decide cosa studiare, cosa abbandonare
- impostazione di obiettivi e vincoli, traduce l'intenzione vaga in funzione obiettivo ottimizzabile e vincoli rigidi
- scelte di compromesso multi-obiettivo, fornisce preferenze difendibili tra velocità di convergenza, diversità, robustezza, costo
- giudizio sulla credibilità dei risultati, distingue "è uscito" da "la conclusione è solida"
- impostazione della direzione dell'evoluzione, decide dove esplorare il prossimo ciclo, invece di accettare passivamente l'ottimo attuale. Questi non sono problemi di calcolo, ma problemi di valore e giudizio. Le ipotesi reggono? L'AI potrebbe aver silenziosamente completato premesse non dichiarate
- le metriche sono state fraintese? I miglioramenti potrebbero derivare da data leakage, cambiamenti nei criteri di valutazione o overfitting
- i risultati sono riproducibili? Seed casuale, scheduling parallelo, versioni delle dipendenze influenzano la riproducibilità
- confini e modelli di fallimento sono verificati? In vincoli estremi, dati sparsi o casi ad alta dimensionalità sono ancora validi. L'AI si occupa di implementazione ed esplorazione in batch, l'uomo di direzione e giudizio di valore. Indipendentemente dal livello di automazione, criteri di accettazione e direzione di evoluzione devono ancora essere impostati dall'uomo
- la mancanza prolungata di questo giudizio trasformerà la lacuna di gusto, amplificata dal tempo, in debito tecnico difficile da ripagare. L'AI implementa le risposte, l'uomo controlla la direzione. Prima di affidare ogni compito all'AI, pensare chiaramente a quali sono i criteri di accettazione.

**Copertura delle parole chiave**

- Workflow AI nativo, gusto scientifico, pensiero critico, divisione uomo-macchina, carico di esecuzione, responsabilità di giudizio, definizione del problema, obiettivi e vincoli, compromessi multi-obiettivo, credibilità dei risultati, direzione dell'evoluzione, debito tecnico, Code is cheap. Taste matters.

> **Spunti per gli esercizi**
>
> - Gli esercizi di questa pagina ruotano intorno a compressione dei costi, trasferimento della responsabilità, punti di atterraggio del gusto scientifico, verifica critica e rischi dell'evoluzione continua. Nella gestione, prima far giudicare agli studenti "cosa è stato sostituito dall'automazione, cosa non lo è stato", poi tornare al quadro in due passi "prima farlo funzionare, poi verificarlo".

**Gestione degli esercizi**

Gli strumenti comprimono il costo di implementazione dall'idea al primo esperimento eseguibile, ma non cambiano la difficoltà di definizione del problema e giudizio sui risultati. Nel feedback ricordare di distinguere "carico di esecuzione" e "responsabilità di giudizio".

La velocità di output aumenta, rendendo più facile che conclusioni non verificate vengano propagate come risultati confermati. Nel feedback sottolineare che la comodità aumenta il throughput del tentativo ed errore, e amplifica nella stessa proporzione la velocità di propagazione delle decisioni errate.

Definizione del problema, impostazione di obiettivi e vincoli, scelte di compromesso multi-obiettivo, giudizio sulla credibilità dei risultati, impostazione della direzione dell'evoluzione. Nel feedback spiegare che queste fasi sono problemi di valore e giudizio, non problemi di calcolo.

Le ipotesi implicite che l'AI ha silenziosamente completato senza dichiararle, e se i criteri di valutazione sono stati modificati. Nel feedback indicare che il focus della verifica critica sono ipotesi, criteri delle metriche, riproducibilità e condizioni al contorno, non la forma di presentazione.

La lacuna di gusto viene continuamente amplificata dal tempo, accumulandosi in debito tecnico difficile da ripagare. Nel feedback ribadire che l'automazione può solo garantire "riuscire a eseguire", non "correre nella direzione giusta".

Di fronte a soluzioni candidate e classifiche raccomandate fornite dall'AI, prima verificare se obiettivi e vincoli corrispondono alle reali esigenze del business, poi verificare criteri delle metriche e baseline, controllare distribuzione e robustezza delle soluzioni sul fronte dei compromessi, fare test di confini e modelli di fallimento, e fissare seed casuale, versioni delle dipendenze e configurazione sperimentale per garantire la riproduzione. Se si decide la soluzione principale completamente secondo la classifica raccomandata dall'AI e si procede automaticamente nella direzione, il rischio è esternalizzare il giudizio di valore del compromesso multi-obiettivo, la direzione errata viene ripetutamente ereditata dalle iterazioni successive, e "riuscire a eseguire" viene scambiato per "direzione corretta". Nel ridisegnare la divisione, far sì che l'AI si occupi di implementazione ed esplorazione in batch, e l'uomo definisca pesi degli obiettivi e vincoli rigidi, imposti criteri di accettazione, mantenga il diritto di revisione e veto, e specifichi ipotesi e modalità di verifica per il prossimo ciclo di esplorazione.

**Attività in classe**

Chiedere agli studenti di ripetere con parole proprie le "quattro domande di autocontrollo", e fare un esempio vicino alla propria esperienza di studio o ricerca, spiegando come saltare la verifica porterebbe a scambiare "è uscito" per "è solido".

**Verifica della comprensione**

Chiedere a uno studente a caso di riassumere i punti chiave di questa pagina, e rispondere a "cosa determina la padronanza del workflow, cosa determinano gusto scientifico e pensiero critico". L'insegnante integra le relazioni mancanti in base alla risposta: la prima determina la velocità, i secondi determinano direzione e valore.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno distinguere "riuscire a eseguire" da "essere solido", "implementare risposte" da "controllare la direzione", passare alla pagina successiva con esempi, applicazioni o riepilogo.

<a id="lecture-page-16"></a>

### Appendice e accesso alla community open source

*Pagina 16*

> **Obiettivo della pagina:** Ottenere i canali ufficiali di comunicazione di EvoX e le risorse per l'apprendimento continuo.

> **Obiettivo della pagina**
>
> Questa pagina, come appendice del corso, raccoglie i canali ufficiali della community del sistema di evoluzione intelligente EvoX e della pratica di ricerca AI Native, spiegando i canali per l'apprendimento continuo dopo il corso, per porre domande e partecipare all'esplorazione all'avanguardia.

**Punti chiave dell'insegnamento**

- Prima distinguere i due ingressi ufficiali. L'account WeChat ufficiale è "演化机器智能" (Intelligenza delle macchine evolutive), usato per pubblicare aggiornamenti del corso, articoli tecnici, notifiche di eventi e interpretazioni all'avanguardia, adatto per seguire sistematicamente la direzione dell'evoluzione intelligente. Il gruppo QQ ufficiale ha il numero 297969717, usato per domande in tempo reale, discussioni e scambi tra colleghi, utile per ottenere feedback su problemi specifici. Entrambi puntano a "partecipare continuamente all'esplorazione all'avanguardia dell'evoluzione intelligente", non sostituiscono l'apprendimento in classe, ma formano il ciclo "apprendimento—pratica—scambio—nuovo apprendimento". Dopo l'adesione, prima scorrere gli annunci fissati e i messaggi storici, comprendere le regole e le risorse già disponibili, poi partecipare alle discussioni in base alla propria direzione di ricerca. Quando si fa una domanda, fornire contesto chiaro, domanda specifica e metodi già tentati
- partecipare attivamente alle discussioni altrui aiuta anche a approfondire la comprensione. Controllare periodicamente i contenuti all'avanguardia, trasformare le risorse della community in capacità di ricerca. Gli esercizi di questa pagina ruotano intorno a tre fatti e due atteggiamenti. Il nome dell'account è "演化机器智能"
- il numero del gruppo QQ è 297969717
- lo scopo degli ingressi della community è fornire canali di apprendimento continuo, domande ed esplorazione all'avanguardia dopo il corso
- per ottenere risorse dopo il corso, si dovrebbe seguire l'account ufficiale e unirsi al gruppo QQ tramite gli ingressi ufficiali
- usare la community significa porre domande attivamente, condividere e partecipare alle discussioni, non usarla solo prima degli esami, unirsi a gruppi non ufficiali o restare silenziosi. Il caso di studio può guidare gli studenti a scrivere i due canali ufficiali, e fornire almeno due suggerimenti per l'apprendimento continuo, come seguire gli aggiornamenti dell'account, fare domande e scambiare nel gruppo, seguire le dinamiche all'avanguardia, partecipare a progetti open source o eventi online, applicare quanto appreso nel corso alla ricerca reale e condividere esperienze.

**Verifica della comprensione**

Chiedere agli studenti di spiegare con parole proprie a cosa servono rispettivamente i due ingressi ufficiali, e ripetere il comportamento corretto dopo l'adesione alla community. Se gli studenti ricordano solo i nomi ma non sanno dire l'uso, far rileggere la pagina confrontando i due ingressi.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno dire la relazione tra ingressi ufficiali e ciclo di apprendimento continuo, passare alla pagina successiva.

--- FINE DEL TESTO SORGENTE ---