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

Durata: 1 · Pagine della presentazione: 16

## Navigazione di lettura

- [Lezione 1 | Tema: Le origini dell'evoluzione intelligente e il contesto di nascita di EvoX](#lecture-lesson-1)

---

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

## Lezione 1 | Tema: Le origini dell'evoluzione intelligente e il contesto di nascita di EvoX

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

### Le origini dell'evoluzione intelligente e il contesto di nascita di EvoX

*Pagina 1*

> **Obiettivo della pagina:** Esplorare il percorso evolutivo dell'intelligenza umana, la visione di Turing sulla "macchina bambina" e come EvoX costruisca un ciclo evolutivo chiuso tra le capacità del modello e le capacità del sistema.

**Punti chiave della lezione**

- Comprendere la profondità storica e la velocità dell'evoluzione dell'intelligenza
- Distinguere i limiti della generazione singola dei grandi modelli e la necessità dell'evoluzione sistemica

Obiettivo della pagina

Il primo aspetto riguarda la profondità storica e la velocità dell'evoluzione intelligente, il secondo la necessità di passare dalla generazione singola dei grandi modelli all'evoluzione sistemica. Dopo lo studio, si dovrebbe essere in grado di spiegare perché EvoX non si limiti a invocare un modello, ma costruisca un ciclo evolutivo chiuso tra le capacità del modello e le capacità del sistema.

Ordine di esposizione

L'evoluzione non procede a velocità costante; i salti chiave sono spesso guidati da strumenti, linguaggio, collaborazione e meccanismi di feedback.

Invece di creare in un colpo solo una mente adulta, è meglio progettare una macchina che possa imparare, essere educata e crescere gradualmente. Questo getta le basi per la successiva prospettiva "evolutiva".

Forte nella compressione della conoscenza e nell'output immediato, debole negli obiettivi persistenti, nella memoria a lungo termine, nell'interazione con l'ambiente, nell'autocorrezione e nella collaborazione multi-turno.

Trattare il modello come un anello dell'evoluzione, costruendo un ciclo chiuso dalle capacità del modello alle capacità del sistema attraverso compiti, feedback, valutazione, selezione e iterazione.

Punti chiave della lezione

L'evoluzione intelligente ha profondità storica, ma l'evoluzione tecnologica è estremamente rapida; insieme costituiscono il contesto.

Il punto chiave della visione di Turing non è che "la macchina è come un bambino", ma che "la macchina può crescere attraverso l'esperienza".

La generazione singola è come un'istantanea, l'evoluzione sistemica è come un processo; un'istantanea può stupire, ma solo un processo può accumulare.

EvoX non vuole sostituire il modello, ma dare al modello direzione, memoria e pressione selettiva all'interno del ciclo.

Verifica della comprensione

Si può chiedere agli studenti di distinguere in una frase "generazione singola del modello" e "evoluzione sistemica", e di fare un esempio di quale anello in più abbia quest'ultima.

Suggerimento di transizione

Se al modello fosse permesso rispondere una sola volta, cosa gli mancherebbe? Da qui si passa naturalmente alla sezione successiva sullo sviluppo delle capacità sistemiche e del ciclo evolutivo chiuso.

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

### La tendenza all'accelerazione dell'evoluzione intelligente e la compressione dei cicli

*Pagina 2*

> **Obiettivo della pagina:** Lo studente deve comprendere che la velocità dell'evoluzione dell'intelligenza umana segue una curva in rapida ascesa, e che il ciclo evolutivo si è compresso dalle generazioni genetiche fino alla singola iterazione di software e IA.

> **Obiettivo della pagina**
>
> Comprendere la tendenza all'accelerazione dell'evoluzione intelligente e la compressione dei cicli. Ciò che questa pagina vuole stabilire non è un evento specifico, ma una scala temporale: l'evoluzione non procede a velocità costante, ma è un processo di accelerazione guidato dal cambio di substrato; la sua velocità segue una curva non lineare che nella prima fase resta rasoterra e nella seconda sale bruscamente, e il ciclo evolutivo si comprime dalle generazioni genetiche fino alla singola iterazione di software, potenza di calcolo e intelligenza artificiale.

> **Ordine di esposizione**
>
> Prima si osserva la forma della curva, poi si spiegano le due catene e la loro corrispondenza, quindi si illustra il meccanismo di accelerazione, e infine si indica l'anello compresso — selezione e verifica — introducendo la necessità del ciclo evolutivo chiuso.

**Punti chiave della lezione**

- 1. La curva non è una linea retta in lenta salita, ma una salita non lineare ripida. L'asse verticale misura la durata di un singolo ciclo evolutivo, che varia per ordini di grandezza, quindi non si può estrapolare linearmente la velocità futura senza sottostimare sistematicamente l'impennata della fase finale. Accumulo genetico → linguaggio e cultura → software, potenza di calcolo e intelligenza artificiale. Ogni migrazione ha cambiato le condizioni di base: dove può esistere l'informazione, quanto velocemente può essere copiata, quanto dura un tentativo. Generazioni → anni → mesi → singola iterazione. Un ciclo completo di "tentativo — conservazione o eliminazione" si è accorciato da scale generazionali a scale annuali, mensili, fino a una singola generazione, una singola compilazione, un ciclo di addestramento e valutazione. Su quale livello si sposta il substrato, a quel livello si comprime il ciclo. Per ripassare, usare una delle due catene per ricordare l'altra è più efficace che memorizzarle separatamente. 5. Il meccanismo dell'accelerazione sta nel fatto che il costo unitario e la durata unitaria del circuito "prova ed errore — copia — selezione" vengono costantemente ridotti: copiare le soluzioni candidate costa sempre meno, il tempo per verificare un ciclo si accorcia sempre di più, e il numero di tentativi completabili per unità di tempo aumenta molte volte. 6. Più corto è il ciclo, più economica è la generazione di candidati
- ma ciò che determina davvero il successo o il fallimento è sempre "quale candidato è realmente efficace". Quando la generazione viene enormemente accelerata, ciò che viene relativamente compresso è proprio la selezione e la verifica, che da presupposto implicito diventa un collo di bottiglia esplicito. La linea tratteggiata grigia nella figura indica il ritardo relativo del "costo di selezione e verifica". 7. La generazione singola non può autodimostrare la propria correttezza, né rimanere efficace quando ambiente e modello cambiano continuamente. L'interfaccia a cui punta è il ciclo evolutivo chiuso composto da generazione, feedback ambientale, valutazione selettiva ed eredità. L'intelligenza è un prodotto progettato in anticipo o un processo che si forma continuamente nell'ambiente? Questa pagina si limita a stabilire questa scala temporale; lo sviluppo della questione è rinviato ai contenuti successivi.

**Copertura delle parole chiave**

- Evoluzione intelligente
- Migrazione del substrato
- Compressione dei cicli
- Accelerazione non lineare
- Collo di bottiglia di selezione e verifica
- Ciclo evolutivo chiuso.

> **Spunti per i materiali**
>
> - Grafico a linee o a gradini con asse orizzontale le ere temporali e asse verticale la durata del singolo ciclo evolutivo (scala logaritmica); i quattro gradini corrispondono ad accumulo genetico, linguaggio e cultura, software e potenza di calcolo, singola iterazione del grande modello
> - La linea tratteggiata grigia indica il ritardo relativo del costo di selezione e verifica. Durante l'esposizione si può usare un gesto lungo la scala discendente per sottolineare "il ciclo si contrae verso il basso, l'accelerazione sale verso l'alto".

> **Spunti per gli esercizi**
>
> - La causa fondamentale dell'accelerazione è il cambio del substrato evolutivo, dai geni al linguaggio e alla cultura, poi a software, potenza di calcolo e intelligenza artificiale
> - Non è che gli individui siano più diligenti, che il volume totale dei dati aumenti o che l'hardware costi meno. L'ordine corretto della catena di compressione dei cicli è "generazioni → anni → mesi → singola iterazione". La comprensione corretta è che la curva sale bruscamente in modo non lineare e non si può estrapolare linearmente per dedurre la velocità evolutiva futura. Dopo la compressione dei cicli, ciò che richiede maggiormente una ridistribuzione dell'attenzione è la fase di selezione e verifica, cioè "determinare quale candidato è realmente efficace". La generazione singola manca della verifica ripetuta e della selezione valutativa dell'ambiente, e non può formare un ciclo chiuso ereditabile.

**Gestione degli esercizi**

Prima si lascia che gli studenti giudichino autonomamente, poi si chiede loro di spiegare le motivazioni. Se sbagliano, si guidano verso le due prove chiave: "cambio di substrato" e "generazione economica, giudizio compresso". Per l'analisi del caso si può suggerire: il cambiamento percepito dai ricercatori deriva dalla migrazione del substrato; la conoscenza non risiede più principalmente negli articoli e nella memoria delle persone, ma nei repository di codice, nelle risorse di calcolo e nei pesi dei modelli; alla migrazione del substrato segue la compressione dei cicli, e un ciclo completo si accorcia da scala semestrale a scala oraria. Il collo di bottiglia si sposta su selezione e verifica; la generazione singola non può sostituire il ciclo chiuso dell'evoluzione continua, perché le conclusioni devono essere verificate ripetutamente nell'ambiente e sedimentarsi come basi selettive ereditabili.

**Verifica della comprensione**

Far dire agli studenti in una frase il nucleo di questa pagina. Una formulazione valida deve contenere "il cambio di substrato guida l'accelerazione" e "la generazione diventa sempre più economica, il giudizio diventa il collo di bottiglia"; se sanno dire solo "il modello diventa sempre più forte", bisogna tornare alla curva e alle due catene.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno distinguere la catena della migrazione del substrato dalla catena della compressione dei cicli, e comprendono il collo di bottiglia di selezione e verifica, si passa alla pagina successiva sullo sviluppo del ciclo evolutivo chiuso.

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

### Le potenti capacità attuali dei grandi modelli e i limiti della generazione singola

*Pagina 3*

> **Obiettivo della pagina:** Lo studente deve riconoscere che, sebbene i grandi modelli attuali possiedano potenti capacità di comprensione e generazione, la generazione singola non può autodimostrare la propria correttezza ed è difficile che si adatti continuamente ai cambiamenti.

> **Obiettivo della pagina**
>
> Distinguere i limiti della generazione singola dei grandi modelli e la necessità dell'evoluzione sistemica. Il punto centrale è far separare agli studenti la "capacità di generare contenuti" dalla "capacità sistemica di far verificare e iterare i contenuti": il modello è potente, ma senza esecuzione, verifica, valutazione, feedback ed eredità, l'output resta un suggerimento una tantum.
>
> Prima si riconoscono la forte comprensione, la forte generazione e il forte ragionamento dei grandi modelli, poi si indicano i tre limiti della generazione singola, quindi si usa la soluzione di riduzione della latenza per spiegare perché non si possa mettere direttamente in produzione, infine si riassume il ciclo evolutivo chiuso, ricollegandosi alla visione della "macchina bambina" di Turing.

**Punti chiave della lezione**

- Il modello può formare rapidamente spiegazioni, piani e contenuti candidati; è un efficiente "generatore di possibilità". Non può autodimostrare la correttezza, perché manca di esecuzione, verifica e valutazione indipendente
- Non può autoaggiornarsi, perché quando ambiente, vincoli o obiettivi cambiano non li rivaluta automaticamente
- Non può autoaccumulare, perché un output singolo non produce esperienza ereditabile. 3. Pertanto, il collo di bottiglia spesso non è se il modello "sa" qualcosa, ma se la capacità intelligente è inserita in un processo esplorabile, eseguibile, verificabile e iterabile. Generazione → esecuzione e verifica → valutazione → selezione/mutazione → rigenerazione. Solo spiegando input, output e segnali di giudizio di ogni passo gli studenti possono capire come le capacità si accumulino nel ciclo. 5. Nel diagramma comparativo, il lato sinistro rappresenta la generazione singola che "termina qui", il lato destro rappresenta il ciclo evolutivo chiuso che "itera continuamente, con valutazione sistemica ed eredità", utile per evidenziare la differenza tra risposta una tantum ed evoluzione continua. Un team vuole ridurre la latenza del servizio di inferenza online; il modello fornisce in una volta suggerimenti di pruning, quantizzazione e distillazione, ma solo inserendoli nell'hardware target, nei vincoli di precisione e nelle fluttuazioni di carico per test reali, e iterando in base al feedback, si possono ottenere soluzioni candidate verificabili ed evolvibili.

**Copertura delle parole chiave**

- Limiti dei grandi modelli, generazione singola, autodimostrazione della correttezza, feedback continuo, ciclo evolutivo chiuso, selezione/mutazione, valutazione sistemica ed eredità.

**Gestione degli esercizi**

La generazione singola è un output una tantum e aperto; non può autodimostrare la correttezza perché manca di esecuzione, verifica, segnali di feedback e valutazione indipendente; una soluzione una tantum si ferma alle ipotesi del momento della generazione; di fronte a un problema reale il primo passo è trasformarlo in un processo esplorabile, eseguibile e verificabile; la struttura del ciclo chiuso è generazione, esecuzione e verifica, valutazione, selezione/mutazione, rigenerazione. Per il caso "soluzione di riduzione della latenza" si possono dividere gli studenti in gruppi per scrivere i passi del ciclo chiuso e input/output di ciascuno, verificando se include un ambiente di verifica eseguibile, metriche di valutazione quantificabili e un meccanismo di rigenerazione basato sul feedback. Se gli studenti attribuiscono il problema alla mancanza di potenza di calcolo o a un prompt insufficientemente dettagliato, ricordare che il collo di bottiglia è nelle capacità sistemiche; se scrivono solo "iterazione" senza segnali di valutazione, suggerire di aggiungere indicatori per giudicare il bene e il male.

Chiedere agli studenti di ripetere i "tre non può" con un esempio familiare, e poi di dire in quali situazioni è necessario introdurre il ciclo evolutivo chiuso. Chiedere a uno studente a caso di riassumere con parole proprie i punti chiave della pagina; l'insegnante integra le parole chiave mancanti in base alla risposta.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno esprimere la differenza tra generazione singola e ciclo evolutivo chiuso, si passa alla pagina successiva per discutere l'origine storica o le applicazioni concrete del pensiero evolutivo.

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

### La convergenza dei percorsi intelligenti e le origini del calcolo evolutivo

*Pagina 4*

> **Obiettivo della pagina:** Lo studente deve comprendere il punto di convergenza dei diversi percorsi di sviluppo dei sistemi intelligenti e la posizione del calcolo evolutivo come fonte tecnologica principale.

> **Obiettivo della pagina**
>
> Comprendere perché i molteplici percorsi di sviluppo dei sistemi intelligenti convergono a livello sistemico, e perché il calcolo evolutivo è considerato la fonte tecnologica più diretta in questo punto di convergenza; allo stesso tempo, stabilire una prospettiva meta-livello di "algoritmi che ottimizzano algoritmi" e imparare a valutare un percorso in base al costo di migrazione.

> **Ordine di esposizione**
>
> Quando potenza di calcolo e capacità del modello non sono più scarse, il problema centrale passa da un problema di campionamento — "generare una buona risposta una volta" — a un problema di ricerca — "come cercare, ricevere feedback e filtrare continuamente". Si può evidenziare che una generazione singola non può autodimostrare la correttezza ed è difficile che resti efficace dopo cambiamenti di ambiente o modello.
>
> Comprensione, espressione, azione-feedback, selezione dei risultati e altre dimensioni non possono formare un ciclo chiuso in modo indipendente; la comprensione si calibra con il feedback, l'azione converge attraverso la selezione dei risultati, l'espressione si verifica nell'ambiente. Pertanto si ricongiungono a livello sistemico, formando la catena di osservazione "porre il problema → generare candidati → feedback ambientale → valutazione e selezione → conservazione e rigenerazione".
>
> Popolazione, mutazione, selezione e iterazione corrispondono naturalmente al ciclo chiuso "generazione — valutazione — conservazione — rigenerazione", quindi è il meccanismo che fa funzionare il ciclo, non l'ennesima capacità espressiva.
>
> Mutazione, crossover e selezione modificano le soluzioni candidate, ma raramente modificano "il metodo che produce le soluzioni candidate"; il meta-livello resta a lungo nella fase di progettazione manuale, e l'algoritmo è bravo a cercare risposte ma non a cercare se stesso. Si può usare l'evoluzione differenziale per illustrare: la scelta e la taratura di strategia di mutazione, vettore base, fattore di mutazione e probabilità di crossover avvengono al di fuori della ricerca, non sono riutilizzabili e difficili da sedimentare.
>
> Far entrare il metodo di risoluzione stesso nel processo di ricerca, cioè "algoritmi che ottimizzano algoritmi"; l'algoritmo passa da strumento a oggetto da cercare e migliorare. EvoX è il veicolo che sistematizza questa prospettiva; i dettagli architetturali sono rinviati alle pagine successive.

**Punti chiave della lezione**

- Per valutare un percorso intelligente, non basta guardare la capacità espressiva singola, ma soprattutto se può formare un ciclo chiuso sostenibile e auto-migliorabile, e se dopo una deriva del problema può continuare a cercare a costi contenuti. Non è se può generare, ma se può cercare, ricevere feedback e filtrare continuamente. Ciò che viene modificato sono solo le soluzioni candidate, o anche "il metodo che produce le soluzioni candidate"? Solo il secondo caso entra in "algoritmi che ottimizzano algoritmi". I meccanismi adattivi e di autotaratura spesso riducono il costo di migrazione, ma comportano costi computazionali aggiuntivi e minore interpretabilità; è un compromesso da chiarire in anticipo.

> **Spunti per i materiali**
>
> - Il diagramma della pagina mostra molteplici percorsi intelligenti che convergono verso il problema sistemico, collegandosi poi a "calcolo evolutivo: la fonte tecnologica più diretta"
> - Allo stesso tempo, una linea tratteggiata arancione evidenzia il circuito meta-livello, sottolineando che gli algoritmi evolutivi tradizionali ne sono privi. Durante l'esposizione si può usare il diagramma per spiegare la differenza di livello tra "algoritmo attuale" e "metodo per generare e selezionare soluzioni candidate".

**Gestione degli esercizi**

La risposta alla domanda 1 cade su "passare da un problema di campionamento a un problema di ricerca", sottolineando che il collo di bottiglia è la ricerca continua, il feedback e il filtraggio, non i dati, la potenza di calcolo o la scala delle annotazioni.

La risposta alla domanda 2 è che nessuna dimensione può formare un ciclo chiuso indipendente e serve un accoppiamento a livello sistemico; non vanno scelte denominazione, costo o ordine storico.

La risposta alla domanda 3 è che i meccanismi del calcolo evolutivo corrispondono uno a uno alla struttura del ciclo chiuso sistemico; non velocità, assenza di parametri o ambito applicativo.

La risposta alla domanda 4 è che modifica le soluzioni candidate ma raramente il metodo che le produce, e il meta-livello si basa sulla progettazione manuale; il punto cieco è che il metodo stesso non viene cercato.

La risposta alla domanda 5 è che la selezione e la taratura avvengono al di fuori della ricerca e difficilmente si sedimentano, il che mostra che l'algoritmo stesso non entra nel processo di ricerca; il punto non è la densità di scansione dei parametri o la piena automazione.

Nel caso di scheduling di officina, i parametri dell'evoluzione differenziale diventano inefficaci per l'aggiunta di vincoli di cambio formato e finestre temporali su due turni, riflettendo l'assenza del meta-livello. Se si fa entrare il metodo nella ricerca, si possono usare meccanismi adattivi o di autotaratura per ricostruire automaticamente strategie e parametri, riducendo il costo di migrazione e la ripetizione degli esperimenti; il prezzo è un costo computazionale aggiuntivo e una minore interpretabilità. Il compromesso è: scambiare calcolo e interpretabilità con un costo di migrazione inferiore quando il problema deriva.

**Verifica della comprensione**

Chiedere agli studenti di distinguere con parole proprie "cercare risposte" e "cercare il metodo che produce le risposte", e di spiegare perché questa pagina colloca il calcolo evolutivo come la fonte tecnologica più diretta nel punto di convergenza.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno esporre la linea principale "convergenza di più percorsi — calcolo evolutivo corrispondente al ciclo chiuso — algoritmi tradizionali privi di meta-livello — algoritmi che ottimizzano algoritmi", si passa ai contenuti successivi sull'architettura di EvoX.

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

### La visione di Turing della "macchina bambina"

*Pagina 5*

> **Obiettivo della pagina:** Lo studente deve comprendere la visione della "macchina bambina" proposta da Turing nel 1950 e l'idea che le capacità si acquisiscano nell'ambiente attraverso educazione e premi/punizioni.

> **Obiettivo della pagina**
>
> Comprendere la visione della "macchina bambina" proposta da Turing nel 1950 — la macchina parte da uno stato incompleto simile a un bambino e acquisisce gradualmente capacità nell'ambiente attraverso educazione, sperimentazione e premi/punizioni, intendendo così l'intelligenza come "processo in continua formazione" e non come "prodotto progettato in anticipo".

> **Ordine di esposizione**
>
> Prima si indica in una frase il percorso alternativo proposto da Turing, poi si usa il confronto sinistra-destra per illustrare le due fonti delle capacità; quindi si sviluppano i tre giudizi chiave; poi si arriva al significato ingegneristico odierno, aggiungendo il ciclo chiuso esterno; infine si chiariscono i fraintendimenti comuni e si consolidano con gli esercizi.

**Punti chiave della lezione**

- Nel 1950, discutendo se "le macchine possono pensare", Turing propose un percorso alternativo di grande rilevanza ingegneristica: invece di creare in un colpo solo una mente matura come quella di un adulto, costruire prima una "macchina bambina". All'uscita dalla fabbrica non è completa, ma viene "allevata" nell'ambiente, passando per educazione, sperimentazione e premi/punizioni, e solo così le capacità crescono gradualmente. La svolta chiave di questa pagina è: l'intelligenza non è un risultato scritto in modo rigido, ma un processo plasmato dall'ambiente. Il lato sinistro, "prodotto progettato in anticipo", segue il percorso analisi dei requisiti → progettazione dei moduli → fissazione dei parametri → deployment (unidirezionale); le capacità sono definite al momento della consegna e non si modificano più durante l'esecuzione
- il lato destro, "processo che si forma nell'ambiente", segue il ciclo educazione → sperimentazione → premi/punizioni, e le capacità si generano gradualmente. I premi conservano i comportamenti efficaci, le punizioni eliminano le strategie inefficaci. Durante l'esposizione si può chiedere agli studenti di descrivere prima le differenze tra i due lati, poi di sintetizzarle in "capacità scritte in anticipo" e "capacità generate gradualmente nel feedback ambientale". Le capacità non sono progettate in anticipo e scritte una volta per tutte
- l'intelligenza è un processo in continua formazione, e valutare un sistema significa vedere se può migliorare nell'interazione continua
- il feedback ambientale è il meccanismo centrale di generazione delle capacità, e le strategie comportamentali vengono ripetutamente filtrate nel ciclo "educazione → sperimentazione → premi/punizioni". I grandi modelli sono bravi a generare e possono produrre in una volta molte risposte possibili, ma il risultato di una generazione singola non può autodimostrare la correttezza, né è facile che resti efficace dopo cambiamenti dell'ambiente. Chi verifica, chi elimina, chi conserva? Serve un ciclo chiuso esterno: il modello genera possibilità → l'ambiente fornisce feedback → il sistema valuta, seleziona ed eredita. Questa è l'interfaccia tra questa pagina e il successivo ciclo evolutivo chiuso. Non considerare la "macchina bambina" come una specifica struttura di rete o il nome di un particolare algoritmo di addestramento; essa fornisce una tesi metodologica sull'origine delle capacità.

**Copertura delle parole chiave**

- Macchina bambina, educazione, sperimentazione, premi/punizioni, processo e non prodotto finito, feedback ambientale, ciclo chiuso esterno, valutazione—selezione—eredità.

> **Spunti per i materiali**
>
> - Il concetto centrale è "la visione della macchina bambina di Turing", il termine chiave è "macchina bambina"; si può accompagnare con un diagramma comparativo per spiegare la differenza tra "capacità scritte in anticipo" e "capacità generate gradualmente nel feedback ambientale". Le cinque domande a scelta della pagina verificano rispettivamente "la tesi centrale", "il ruolo del feedback ambientale", "il cambiamento metodologico della prospettiva di processo", "l'assenza di un ciclo chiuso esterno", "la spiegazione dell'origine delle capacità". In caso di risposta corretta, sottolineare le motivazioni
> - in caso di errore, riportare gli studenti alla frase originale — non si richiede che sia completa fin dall'inizio, ma che le capacità crescano gradualmente nell'interazione con l'ambiente, distinguendo "definita all'uscita dalla fabbrica" e "formata gradualmente"
> - il problema non è nella lunghezza del prompt, nel numero di parametri o nella potenza di calcolo, ma nell'assenza di un ciclo chiuso che permetta ai risultati di essere verificati, filtrati e conservati. Per la domanda del caso "da dove vengono le capacità del robot di magazzino" si suggerisce di far prima cerchiare agli studenti le differenze tra il piano A e il piano B, poi di rispondere corrispondendo ai tre anelli educazione, sperimentazione e premi/punizioni
> - la seconda domanda deve arrivare a "la generazione singola non può autodimostrare la correttezza ed è difficile che resti efficace a lungo", spiegando come il ciclo chiuso conservi le strategie efficaci ed elimini quelle inefficaci.

**Attività in classe**

Chiedere agli studenti di ripetere "educazione → sperimentazione → premi/punizioni" con un esempio vicino alla propria esperienza, e di spiegare il rapporto con "processo e non prodotto finito".

**Verifica della comprensione**

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

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno esporre la catena "generazione singola → feedback ambientale → valutazione sistemica, selezione ed eredità", si passa alla pagina successiva sull'applicazione o sul riepilogo.

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

### Nuove fonti di generazione di candidati con l'ampliamento della scala di calcolo

*Pagina 6*

> **Obiettivo della pagina:** Lo studente deve comprendere come, una volta aperta la scala di calcolo, i grandi modelli aiutino il sistema a produrre soluzioni candidate strutturate più ricche.

**Punti chiave della lezione**

- Ricordare le tre nuove fonti di generazione di candidati: esplorazione parallela su GPU, costruzione strutturata con grandi modelli, partecipazione del modello a codifica e mutazione. Esse risolvono rispettivamente i problemi di ricerca parallela, generazione di strutture complesse e automazione delle regole di mutazione.
- Prima di iniziare l'evoluzione, porsi tre domande: cosa può essere cambiato? cosa può essere osservato? quale criterio decide la conservazione? Se queste tre domande non hanno risposta, l'evoluzione perde direzione.
- Nella valutazione seguire il principio della stratificazione: le valutazioni a basso costo vanno parallelizzate il più possibile; le valutazioni ad alto costo vanno approssimate con modelli surrogati. Così si bilanciano costo computazionale e precisione di valutazione, ampliando lo spazio dei candidati esplorabili.

Obiettivo della pagina

Il sistema non si chiede più solo "se può generare una risposta", ma si spinge a chiedere "quali cambiamenti possono essere generati, osservati, conservati ed ereditati". Il nucleo di questa pagina è comprendere le tre nuove fonti — esplorazione parallela su GPU, costruzione strutturata con grandi modelli, partecipazione del modello a codifica e mutazione — all'interno della definizione dei confini prima dell'evoluzione, della valutazione stratificata, della conservazione dei risultati e del ciclo chiuso di EvoX.

Ordine di esposizione

Prima si usano le "tre nuove fonti" per spiegare da dove vengono i candidati, poi si illustrano i tre tipi di confini da chiarire prima che i candidati entrino nell'evoluzione, quindi si spiega come stratificare la valutazione, infine si collegano struttura evolvibile, conservazione dei risultati e ciclo chiuso di EvoX. Così gli studenti vedono prima l'espansione dello spazio dei candidati, poi capiscono perché l'evoluzione ha bisogno di direzione, criteri e memoria.

Punti chiave della lezione

1. Le tre nuove fonti di generazione di candidati

Molte possibilità vengono esplorate simultaneamente; la generazione di candidati passa dal tentativo ed errore seriale alla ricerca parallela nello spazio. Ad esempio, si campionano migliaia di punti nello spazio dei parametri e si valutano in parallelo. Risolve principalmente il problema della "ricerca parallela".

Il grande modello è in grado di comprendere linguaggio naturale e codice, costruendo soluzioni candidate strutturalmente complesse, non solo risposte testuali. Può generare programmi completi, casi di test o configurazioni di sistema. Risolve principalmente il problema della "generazione di strutture complesse".

La codifica e le modalità di mutazione artificiali iniziano a essere generate con la partecipazione del modello. La fonte dei candidati si espande da regole scritte dall'uomo a regole e strutture generate dal modello, ad esempio facendo proporre al modello nuovi operatori di mutazione o strategie di codifica. Risolve principalmente il problema dell'"automazione delle regole di mutazione".

Queste tre fonti non si sostituiscono a vicenda, ma ampliano insieme le fonti dei candidati. L'espansione della potenza di calcolo non solo aumenta la velocità di generazione, ma cambia la natura stessa della generazione di candidati.

2. Definizione dei confini prima dell'evoluzione

Prima che i candidati entrino nell'evoluzione, bisogna rispondere a tre domande:

Ciò che è evolvibile è la struttura del codice, gli iperparametri o l'intera architettura?

Come si definiscono e si raccolgono metriche come accuratezza, latenza, consumo di risorse?

Di solito servono funzioni di valutazione multi-obiettivo o soglie.

Se queste tre domande non hanno risposta, l'evoluzione perde direzione. Pertanto la definizione dei confini deve precedere l'avvio dell'evoluzione.

3. Strategia di valutazione stratificata

La valutazione deve essere stratificata:

Le valutazioni parallelizzabili vanno parallelizzate il più possibile.

Le valutazioni costose vanno ridotte con modelli surrogati.

Ad esempio, metriche di prestazione semplici possono essere calcolate in parallelo su GPU; le valutazioni costose che richiedono interazione con l'ambiente reale vengono approssimate con modelli surrogati. Così, con potenza di calcolo limitata, si bilanciano costo computazionale e precisione di valutazione, ampliando lo spazio dei candidati esplorabili.

4. Identificazione delle strutture evolvibili e conservazione dei risultati

Bisogna identificare quali strutture nei metodi esistenti possono essere ulteriormente evolute, invece di regolare solo parametri numerici. Ad esempio, rendere oggetto di mutazione le modalità di connessione tra moduli in una rete neurale e la struttura del flusso di controllo del codice. Allo stesso tempo, bisogna conservare codice, test e prove di verifica, affinché il lavoro successivo non debba ricominciare da zero, evitando ripetizioni.

5. Collegamento al ciclo chiuso di EvoX

Il modello propone candidati, gli strumenti eseguono cambiamenti, l'ambiente restituisce feedback, il meccanismo evolutivo completa la selezione, il Runtime organizza il calcolo, il sistema persistente eredita i risultati verificati. Così i componenti intelligenti dispersi si accumulano continuamente, formando un sistema in continua evoluzione.

Spunti per i materiali

Il diagramma di flusso di questa pagina può aiutare gli studenti a collegare in una catena "tre nuove fonti → generazione di candidati → valutazione → selezione → persistenza". Durante l'esposizione si può usare la frase riassuntiva "nucleo: quali cambiamenti possono essere generati, osservati, conservati ed ereditati", per poi passare al "cambiamento chiave": da "se può generare" a "cosa generare, come osservarlo, come conservarlo, come ereditarlo".

Spunti per gli esercizi

Gli esercizi di questa pagina verificano principalmente se gli studenti sanno distinguere le tre nuove fonti e spiegarne il ruolo con prove o esempi. Nella gestione non ci si deve fermare alla memorizzazione dei termini, ma far dire agli studenti scenari concreti.

Una risposta ragionevole deve collegarsi a "molti candidati cercati simultaneamente, campionamento e valutazione paralleli", non a confrontare risultati cambiando tutti i fattori insieme.

Una risposta ragionevole deve esemplificare che il grande modello può generare programmi, casi di test o configurazioni di sistema, non solo risposte testuali.

Una risposta ragionevole deve spiegare che il modello può proporre nuovi operatori di mutazione o strategie di codifica, espandendo la fonte dei candidati da regole artificiali a regole generate dal modello.

In caso di risposta corretta, chiedere allo studente di aggiungere un esempio per dimostrare la comprensione; in caso di errore, guidarlo a tornare alla spiegazione della pagina, trovare la prova o l'esempio chiave prima di giudicare, evitando conclusioni basate solo sull'intuizione.

Gestione del caso

Il caso richiede di applicare i concetti della pagina a un "compito di ottimizzazione collegato a EvoX".

Quali oggetti possono essere cambiati, ad esempio tipo di layer di rete, modalità di connessione, iperparametri o solo parametri numerici; quali risultati possono essere osservati, ad esempio accuratezza sul validation set, latenza di inferenza, numero di parametri; quale criterio decide la conservazione, ad esempio soglie multi-obiettivo o punteggio ponderato.

Conservare nel sistema persistente codice, test e prove di verifica verificati; il ciclo successivo può partire da strutture già validate, evitando ripetizioni; il modello può proporre nuovi candidati basandosi su strutture di successo storiche, e la valutazione parallela su GPU può riutilizzare risultati esistenti, accelerando il ciclo evolutivo chiuso.

Verifica della comprensione

Saper elencare le tre nuove fonti; saper rispondere alle tre domande di confine prima dell'evoluzione; saper spiegare il principio di stratificazione della valutazione; saper indicare il ruolo del sistema persistente nell'eredità dei risultati. Se gli studenti ricordano solo i termini, si può chiedere un esempio concreto, ad esempio "nella ricerca di architetture neurali, quali oggetti possono essere cambiati? quali metriche possono essere osservate? quali risultati vale la pena conservare?"

Suggerimento di transizione

Dopo aver confermato che gli studenti sanno esporre il rapporto tra "tre nuove fonti, tre tipi di confini, valutazione stratificata, eredità dei risultati nel ciclo chiuso di EvoX", si passa alla pagina successiva con esempi, applicazioni o riepilogo.

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

### L'espansione dell'oggetto evolutivo dai parametri numerici ai sistemi software

*Pagina 7*

> **Obiettivo della pagina:** Lo studente deve comprendere che l'oggetto evolutivo ha superato i parametri numerici, estendendosi a programmi, strutture di modello, meccanismi algoritmici e stati di ingegneria del software.

> **Obiettivo della pagina**
>
> Comprendere che l'oggetto evolutivo si è esteso dai semplici parametri numerici a programmi, strutture di modello, meccanismi algoritmici e persino stati di ingegneria del software; allo stesso tempo, cogliere lo spostamento del baricentro tra "generazione" e "valutazione" e i conseguenti compromessi ingegneristici.

> **Ordine di esposizione**
>
> Prima si torna alla pratica tipica del primo calcolo evolutivo — gli oggetti evoluti erano quasi tutti parametri numerici, come learning rate, batch size, intensità della regolarizzazione, modalità di inizializzazione dei pesi. In questo caso lo spazio di ricerca è un insieme di numeri e la valutazione è un addestramento più una verifica. Poi si indica che, con l'aumento della scala di calcolo e la maturazione delle capacità dei grandi modelli, gli oggetti evolvibili si sono chiaramente espansi, formando una catena di espansione chiara: parametri numerici → programmi e strutture di modello → stati di ingegneria del software e candidati a livello di sistema. Più il livello è a destra, maggiore è l'espressività e più tipi di cambiamento può coprire, rendendo possibile anche l'evoluzione a livello di sistema. Infine si arriva alla realtà ingegneristica del "carico di valutazione che cresce in parallelo", ricordando agli studenti: più candidati non significa evoluzione migliore; la chiave è se i dispositivi di esecuzione e valutazione si aggiornano in modo sincrono.

**Punti chiave della lezione**

- Primo livello, parametri numerici. Il candidato è un insieme di numeri, economico da generare e veloce da valutare, di solito un addestramento più una verifica bastano per il punteggio. Ma può rispondere solo a "quanto bene è tarato", non può aggiungere un meccanismo che mancava fin dall'inizio. Secondo livello, programmi e strutture di modello. Il candidato è una struttura di rete, una combinazione di operatori, un flusso di lavoro di prompt o una patch di codice; il cambiamento modifica "cosa il sistema può fare", non solo "quanto è preciso". La valutazione diventa esecuzione in sandbox e test di regressione. Terzo livello, stati di ingegneria del software e candidati a livello di sistema. Il candidato è configurazione, versione delle dipendenze, contratto di interfaccia, strategia di deployment e di esecuzione, che determinano direttamente se il sistema può funzionare stabilmente e essere riprodotto. La valutazione diventa confronto con benchmark e verifica di riproducibilità. La generazione determina quanto è grande lo spazio dei candidati, la valutazione determina quali possono restare. Quando i candidati passano da numeri a programmi, "generare candidati" non è più il collo di bottiglia — il grande modello può produrre in massa strutture, meccanismi e patch
- chi riesce a far funzionare davvero i candidati, chi riesce a giudicare a costi accettabili se vale la pena conservarli. Isolamento in sandbox, test di regressione, confronto con metriche di benchmark, vincoli di costo e rischio, registrazione della riproducibilità sono proprio i dispositivi ingegneristici per controllare costo, rischio e riproducibilità, e permettono di conservare o eliminare stabilmente i cambiamenti. Equiparare direttamente "più candidati" a "evoluzione più efficace". L'aumento del numero di candidati amplia solo il raggio di ricerca
- solo quando i meccanismi di esecuzione e valutazione sono in grado di filtrare i cambiamenti inefficaci, più candidati si traducono in un sistema migliore. In altre parole, maggiore espressività significa maggiore carico di valutazione; benefici e costi vanno considerati insieme.

**Gestione degli esercizi**

La domanda 1 chiede "il cambiamento più centrale nell'espansione dell'oggetto evolutivo"; la risposta corretta è "da soli parametri numerici a programmi, strutture di modello, meccanismi algoritmici e stati di ingegneria del software". Si può suggerire agli studenti di cogliere "il salto di livello dell'oggetto evoluto stesso", mentre l'addestramento distribuito e i cambiamenti di paradigma di apprendimento sono mezzi di implementazione.

La domanda 2 chiede "perché più candidati non equivale a evoluzione più efficace"; la risposta corretta è "perché solo quando i meccanismi di esecuzione e valutazione riescono a filtrare i cambiamenti inefficaci, più candidati si traducono in un sistema migliore". Punto di feedback: il numero di candidati amplia il raggio di ricerca; la capacità di conservare cambiamenti efficaci dipende dall'aggiornamento sincrono di sandbox, test di regressione, benchmark e altri dispositivi di valutazione.

La domanda 3 chiede "perché servono sandbox, test di regressione e benchmark"; la risposta corretta è "per giudicare a costi controllabili se un candidato è efficace, se comporta rischi e se i risultati sono riproducibili". Si può aggiungere: il candidato è un programma direttamente eseguibile, quindi va prima isolato, poi verificato con regressione, poi confrontato con la baseline.

La domanda 4 chiede "lo spostamento del baricentro tra generazione e valutazione"; la risposta corretta è "con il rafforzamento delle capacità dei grandi modelli, la questione chiave passa da come generare candidati a come eseguire, valutare e conservare i cambiamenti efficaci". Ricordare agli studenti: il miglioramento della capacità di generazione resta un presupposto, ma la chiave del successo dell'evoluzione si sposta verso i meccanismi di esecuzione e valutazione.

La domanda 5 chiede "dopo aver esteso l'oggetto evolutivo dagli iperparametri al flusso di lavoro di prompt, cosa va integrato in modo sincrono"; la risposta corretta è "dispositivi di esecuzione e valutazione come sandbox, test di regressione e benchmark, con un buon compromesso tra costo, rischio e riproducibilità". Si può chiedere: cosa succede continuando ad accumulare candidati? Il carico di valutazione aumenta; comprimere i candidati a uno solo significa rinunciare al senso della ricerca; la chiave è aggiornare il meccanismo di valutazione.

Si può organizzare la discussione con lo scenario "un servizio di raccomandazione che si estende da iperparametri a patch di codice". La prima domanda, "perché i candidati vengono prodotti più velocemente ma il tasso di adozione diminuisce", si guida spiegando lo spostamento del baricentro: la generazione non è più l'anello più stretto, il collo di bottiglia si sposta su esecuzione e valutazione; i candidati sono programmi e non numeri, quindi vanno prima eseguiti in un ambiente controllato, poi verificati con regressione e confrontati con benchmark, per giudicare efficacia, sicurezza e riproducibilità. La seconda domanda, "quali dispositivi ingegneristici integrare e quale tipo di rischio ciascuno vincola", può essere riassunta così: l'esecuzione isolata in sandbox vincola il rischio di "contaminare il sistema esistente, le dipendenze o l'ambiente di produzione"; i test di regressione vincolano il rischio che "le modifiche rompano funzionalità esistenti"; il confronto con metriche di benchmark vincola il rischio di errore di valutazione "sembra migliore ma in realtà non porta miglioramenti";

il budget di costo e il controllo dei timeout vincolano il rischio di costo "la valutazione stessa diventa fuori controllo"; la registrazione di seed e risultati vincola il rischio che "i risultati non siano riproducibili". Nel complesso si tratta di un compromesso tra espressività, costo di valutazione, riproducibilità e sicurezza, non della semplice ricerca del numero di candidati.

**Verifica della comprensione**

Chiedere agli studenti di ripetere con parole proprie la catena di espansione e di spiegare perché "quando il livello dell'oggetto sale, i dispositivi di valutazione devono aggiornarsi in modo sincrono". Se sanno anche dire che "la generazione determina lo spazio dei candidati, la valutazione decide chi resta", hanno raggiunto il requisito centrale della pagina.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno esporre le forme candidate e le modalità di valutazione dei tre livelli di oggetto evolutivo, e sanno usare lo schema "generazione — valutazione — conservazione/eliminazione" per spiegare perché più candidati non equivale automaticamente a evoluzione migliore, si passa alla pagina successiva con esempi, applicazioni o riepilogo.

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

### La complessità del mondo reale e i compromessi multi-obiettivo

*Pagina 8*

> **Obiettivo della pagina:** Lo studente deve comprendere che nel mondo reale i molteplici obiettivi si vincolano a vicenda, e il sistema non dovrebbe fornire troppo presto un'unica soluzione ottimale, ma conservare soluzioni candidate differenziate.

**Punti chiave della lezione**

- Scrivere per primi i confini che devono essere rispettati, ad esempio il limite massimo di latenza end-to-end e il budget di costo unitario. Qualsiasi candidato che violi i confini, anche se una metrica è brillante, non va conservato; solo i candidati all'interno della regione ammissibile hanno diritto a partecipare al confronto multi-obiettivo.
- Nel confrontare due candidati, fare prima un giudizio a coppie: esiste un candidato che non è peggiore su tutti gli obiettivi e migliore su almeno uno? Se sì, la parte completamente dominata può essere eliminata; se no, i due non si dominano a vicenda e vanno entrambi conservati. L'insieme di candidati così ottenuto non perde le informazioni sui compromessi.
- Conservare un gruppo di candidati con differenze evidenti serve a mantenere margini di scelta quando cambiano gli scenari o le priorità. Convergere troppo presto su una singola risposta sembra pulito nel breve termine, ma una volta che l'ambiente o le esigenze cambiano, spesso si paga un prezzo maggiore per riesplorare.

> **Obiettivo della pagina**
>
> Comprendere che nel mondo reale l'ottimizzazione multi-obiettivo raramente ha un'unica soluzione ottimale; cogliere il significato di vincoli rigidi, regione ammissibile, soluzioni non dominate e fronte di Pareto; comprendere perché EvoX debba conservare un gruppo di candidati differenziati e porre il giudizio del ricercatore al di sopra dell'implementazione del codice.
>
> Ordine di esposizione e punti chiave:
>
> Lo stesso sistema spesso persegue contemporaneamente prestazioni, latenza, consumo energetico e costo, e questi obiettivi si vincolano a vicenda. Aumentare la precisione spesso aumenta il calcolo e il consumo energetico, spingendo su latenza e costo; ridurre la latenza spesso sacrifica la precisione. Non esistono miglioramenti gratuiti, quindi i problemi di ottimizzazione reali raramente hanno una sola risposta.
>
> L'asse orizzontale rappresenta latenza, costo, consumo energetico; l'asse verticale rappresenta precisione, prestazioni. I punti sulla curva tratteggiata sono soluzioni non dominate e costituiscono il fronte di Pareto; i punti grigi sotto la curva sono soluzioni dominate, eliminabili. Sul fronte vanno conservate sia le soluzioni a bassa latenza e bassa precisione, sia quelle equilibrate, sia quelle ad alta precisione e alto costo, per permettere al decisore di scegliere in base allo scenario. Convergere troppo presto su una singola risposta fa perdere le informazioni sui compromessi; una volta che l'ambiente o le priorità cambiano, si paga un prezzo maggiore per riesplorare.
>
> Gli obiettivi possono essere bilanciati, i vincoli sono confini inviolabili. Il limite massimo di latenza end-to-end, il budget di costo per inferenza, i limiti di memoria e consumo energetico devono essere chiariti in anticipo. I candidati che violano i confini, anche se una metrica è brillante, non vanno fatti entrare nel confronto; solo i candidati nella regione ammissibile hanno diritto a partecipare al confronto multi-obiettivo.
>
> Se un candidato non è peggiore di un altro su tutti gli obiettivi ed è migliore su almeno uno, allora l'altro è una soluzione dominata ed è eliminabile; se i due non si dominano, vanno entrambi conservati. Tutti i candidati che non si dominano a vicenda, collegati insieme, formano il fronte di Pareto, che conserva integralmente la relazione di scambio "quanto dell'uno si sacrifica per migliorare l'altro".
>
> Quali oggetti possono essere cambiati? Quale feedback dimostra che il cambiamento è efficace? Quali vincoli non possono essere violati? Il confronto è equo? I risultati sono sufficienti a sostenere una conclusione? Cosa conservare e cosa abbandonare nel prossimo ciclo? Queste domande determinano direttamente spazio di ricerca, segnali di valutazione, regione ammissibile e regole di eliminazione.
>
> La capacità di generazione può accelerare la realizzazione delle risposte, ma se la domanda merita di essere posta, se le prove sono credibili e se i risultati sono sufficientemente buoni resta una decisione del ricercatore. Il codice è economico, il gusto e il giudizio sono scarsi; ciò che EvoX vuole costruire è un'infrastruttura capace di entrare nell'ambiente reale, ricevere feedback reali, e produrre, verificare e conservare miglioramenti nella lunga durata.

**Copertura delle parole chiave**

- Compromesso multi-obiettivo, vincoli rigidi, regione ammissibile, soluzioni non dominate, soluzioni dominate, fronte di Pareto, candidati differenziati, convergenza prematura, confronto equo, capacità di giudizio.

**Gestione degli esercizi**

La risposta corretta alla domanda 1 è "molteplici obiettivi si vincolano a vicenda, migliorare uno spesso comporta sacrificarne un altro". Punto di feedback: prestazioni, latenza, consumo energetico e costo si tirano reciprocamente; questa è la radice del compromesso multi-obiettivo.

La risposta corretta alla domanda 2 è "si perdono le informazioni sui compromessi tra candidati, e il decisore non può confrontare benefici e costi". In caso di errore, suggerire di interpretare la convergenza prematura come "perdita di informazioni" e non come "velocità di calcolo".

La risposta corretta alla domanda 3 è "non è peggiore degli altri candidati su tutti gli obiettivi ed è migliore su almeno uno, quindi non può essere completamente dominato". Punto di feedback: non dominato non significa migliore in una singola metrica, ma non dominabile su tutto.

La risposta corretta alla domanda 4 è "chiarire prima quali vincoli non possono essere violati e assumerli come confini che le soluzioni candidate devono rispettare". Punto di feedback: i vincoli rigidi sono confini, non merce di scambio; chi viola il limite di latenza o di costo non deve entrare nell'insieme dei candidati.

La risposta corretta alla domanda 5 è "giudicare quali problemi meritano di essere affrontati, quali prove meritano fiducia, quali risultati sono sufficientemente buoni". Punto di feedback: la generazione può essere automatizzata, ma la scelta dei problemi, il giudizio sulle prove e il criterio di sufficienza devono essere presidiati dal ricercatore.

Gestione del caso di studio:

Per la messa in produzione di un modello di raccomandazione, i requisiti rigidi sono una latenza end-to-end non superiore a 80 millisecondi e un costo per inferenza entro il budget; i candidati includono un grande modello ad alta precisione, un modello piccolo a bassa latenza e un modello distillato intermedio.

Non si può consegnare solo quello con la precisione più alta, perché potrebbe violare i vincoli rigidi; anche se rispetta i vincoli, una soluzione singola nasconde la relazione di scambio tra precisione, costo e latenza. Si dovrebbe restituire un insieme di candidati non dominati sul fronte di Pareto.

Si può chiedere quali oggetti possono essere cambiati, quale feedback è efficace, quali vincoli non possono essere violati, l'equità del confronto, la sufficienza delle conclusioni, cosa conservare e cosa abbandonare nel prossimo ciclo. Il processo è: eliminare prima chi viola i vincoli rigidi, poi eliminare le soluzioni dominate, conservare candidati non dominati e ben differenziati, per far fronte a cambiamenti di priorità.

Chiedere agli studenti di spiegare con un esempio di vita o di ingegneria che "migliorare una cosa spesso richiede sacrificarne un'altra", e poi di giudicare quali sono vincoli rigidi e quali obiettivi bilanciabili. Chiedere a uno studente a caso di spiegare con parole proprie il fronte di Pareto; l'insegnante integra le parole chiave mancanti. Se gli studenti sanno distinguere obiettivi e vincoli, soluzioni non dominate e dominate, e sanno indicare la ragione per conservare candidati differenziati, si può passare alla pagina successiva; altrimenti tornare al diagramma e alla definizione dei criteri.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno rispondere a "perché nel mondo reale è difficile avere un'unica soluzione ottimale" e "perché EvoX conserva un gruppo di candidati differenziati", si passa alla pagina successiva con esempi, applicazioni o riepilogo.

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

### L'auto-miglioramento dei metodi di risoluzione e l'evoluzione degli algoritmi

*Pagina 9*

> **Obiettivo della pagina:** Lo studente deve comprendere che gli algoritmi evolutivi tradizionali modificano raramente il metodo che produce le soluzioni candidate, mentre l'evoluzione sistematizzata può far entrare l'algoritmo di risoluzione stesso nel processo di ricerca.

> **Obiettivo della pagina**
>
> Comprendere il paradigma predefinito degli algoritmi evolutivi tradizionali — "metodo fisso, soluzioni candidate in evoluzione" — e saper spiegare come l'evoluzione degli algoritmi renda il metodo di risoluzione stesso un oggetto cercabile, valutabile e sostituibile.

> **Ordine di esposizione**
>
> Prima si evidenzia l'impostazione predefinita — ciò che viene evoluto sono le soluzioni candidate, mentre il metodo che le genera resta invariato; poi si usa il diagramma comparativo per illustrare "il livello delle soluzioni si muove, il livello del metodo no"; quindi si spiega il secondo circuito di feedback aggiunto dall'evoluzione degli algoritmi; infine si arriva alla svolta chiave: da "usare un algoritmo fisso per trovare soluzioni migliori" a "far migliorare l'algoritmo stesso durante la risoluzione".

**Punti chiave della lezione**

- 1. Nel paradigma predefinito, modalità di crossover, strategia di mutazione e iperparametri vengono di solito scelti una volta per tutte prima dell'esecuzione, e poi non cambiano più per tutta la ricerca. Essi determinano direttamente come vengono generate le soluzioni candidate e influenzano significativamente i risultati, ma il livello del metodo non riceve feedback. Soluzioni candidate → valutazione → selezione → eredità. Il problema è che il livello del metodo non si muove, quindi dopo un cambiamento del compito il meccanismo di generazione può diventare gradualmente inadatto al nuovo compito. 3. La taratura manuale è decisa dall'uomo, e dopo la modifica il metodo viene nuovamente bloccato; la velocità e l'ampiezza del miglioramento sono limitate dall'esperienza umana. Ampliare la popolazione o aumentare le iterazioni prolunga solo la ricerca all'interno dello stesso metodo, senza toccare il livello del metodo. Trattare modalità di crossover, strategia di mutazione, iperparametri e altri elementi del metodo come oggetti candidabili, valutabili e sostituibili, sottoposti insieme alle soluzioni candidate alla verifica delle prestazioni di risoluzione. Elementi del metodo → generazione di soluzioni candidate → valutazione delle prestazioni di risoluzione → conservazione o sostituzione → aggiornamento del metodo
- allo stesso tempo, all'interno delle soluzioni candidate continua a funzionare il ciclo "generazione → valutazione → selezione → eredità". Il primo cambia "come cercare", il secondo cambia "cosa si è trovato". 6. Per giudicare se un sistema sta davvero facendo evoluzione di algoritmi, la chiave è se gli elementi del metodo sono stati inclusi nella ricerca e se la loro permanenza è decisa dalle prestazioni di risoluzione, non scritta una volta per tutte dall'uomo.

> **Spunti per i materiali**
>
> - Il diagramma comparativo ha due livelli — in alto il livello del metodo, in basso il livello delle soluzioni. Nel diagramma di sinistra il livello del metodo è bloccato e si muove solo il livello delle soluzioni
> - nel diagramma di destra compare una freccia arancione che va dalla "valutazione delle prestazioni di risoluzione" al livello del metodo: è il circuito di miglioramento aggiunto dall'evoluzione degli algoritmi.

**Gestione degli esercizi**

La domanda 1 verifica il paradigma predefinito. La direzione corretta è "il metodo di ricerca resta fisso, solo le soluzioni candidate cambiano nell'iterazione". Se gli studenti sbagliano, suggerire di tornare alla struttura a due livelli e verificare se hanno considerato anche il livello del metodo come oggetto evoluto.

La domanda 2 verifica gli elementi del meccanismo di generazione. La risposta corretta è strategia di mutazione, modalità di crossover e iperparametri. Nel feedback si può chiedere: "come vengono create le nuove soluzioni?" per escludere fattori di disturbo come hardware, numerazione, suddivisione dei dataset.

La taratura manuale è fatta dall'uomo; gli elementi del metodo non vengono valutati e sostituiti automaticamente in base alle prestazioni di risoluzione. Se sbagliano, ricordare agli studenti di concentrarsi su "chi modifica e in base a cosa".

Da "usare un algoritmo fisso per trovare soluzioni migliori" a "far migliorare l'algoritmo stesso durante la risoluzione". Si può suggerire di notare i due estremi della svolta: da un lato l'algoritmo fisso, dall'altro l'algoritmo che viene migliorato.

La domanda 5 verifica come si manifesta l'ingresso del metodo nella ricerca. La risposta corretta è trattare modalità di crossover, strategia di mutazione ecc. come oggetti cercabili, candidabili, valutabili e sostituibili in base alle prestazioni di risoluzione. Va chiarito: ampliare solo la popolazione, aumentare le iterazioni o cambiare la funzione di valutazione modifica sempre lo stesso metodo fisso.

Il team adotta il paradigma predefinito; il metodo viene bloccato prima dell'esecuzione, e dopo cambiamenti nella struttura degli ordini, nel numero di macchine e nelle regole di consegna, il metodo bloccato non riceve feedback e le soluzioni candidate diventano sempre meno adatte al nuovo compito. La differenza di meccanismo è: la taratura manuale è giudicata dall'uomo e poi nuovamente bloccata; l'evoluzione degli algoritmi mette gli elementi del metodo nella ricerca, e le prestazioni di risoluzione decidono automaticamente cosa resta.

Gli elementi includibili nella ricerca comprendono modalità di crossover, strategia di mutazione, iperparametri, e si possono considerare anche pressione selettiva, condizioni di attivazione della ricerca locale, ecc.; i segnali di valutazione possono usare risultati ponderati come ritardi di consegna, numero di cambi linea, utilizzo delle macchine in compiti reali di scheduling, confrontando il più possibile sugli stessi lotti di istanze; conservare le combinazioni di metodi con buone prestazioni ed eliminare quelle scarse, mantenendo una piccola perturbazione casuale per preservare la diversità; il flusso del ciclo chiuso è elementi del metodo → generazione di soluzioni candidate → valutazione delle prestazioni di risoluzione → conservazione o sostituzione → aggiornamento del metodo, poi ritorno alla generazione, mentre all'interno delle soluzioni candidate continua l'iterazione ordinaria.

**Verifica della comprensione**

Chiedere agli studenti di ripetere con parole proprie la differenza tra "il livello delle soluzioni si muove, il livello del metodo no" e "anche il livello del metodo entra nella ricerca"; poi far scrivere a memoria il ciclo chiuso in cinque passi; se manca "valutazione" o "sostituzione", significa che il metodo non si sta ancora auto-migliorando davvero.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno distinguere "taratura dei parametri" e "evoluzione degli algoritmi", e sanno indicare il criterio per cui gli elementi del metodo entrano nella ricerca e la permanenza è decisa dalle prestazioni di risoluzione, si passa alla pagina successiva con esempi, applicazioni o riepilogo.

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

### MetaDE: architettura annidata di algoritmi che ottimizzano algoritmi

*Pagina 10*

> **Obiettivo della pagina:** Lo studente deve comprendere come MetaDE realizzi, tramite due livelli interni ed esterni di evoluzione differenziale, l'uso di un algoritmo evolutivo per migliorare un algoritmo evolutivo.

> **Obiettivo della pagina**
>
> Comprendere come MetaDE realizzi con l'evoluzione differenziale annidata "algoritmi che ottimizzano algoritmi": il livello esterno evolve la configurazione dell'algoritmo, il livello interno risolve il compito reale.

> **Ordine di esposizione**
>
> 1. Prima si riprende il ciclo chiuso "generazione — valutazione — selezione — eredità" della lezione precedente, indicando che questa pagina lo spinge un livello più in profondità: non solo far risolvere problemi all'algoritmo, ma far migliorare l'algoritmo dall'algoritmo.
>
> Il DE interno (livello del compito) mantiene la popolazione di soluzioni candidate, esegue mutazione, crossover e selezione, e restituisce le prestazioni sul compito; gli individui del DE esterno (livello meta) non sono soluzioni del compito, ma un'intera configurazione di "strategia di mutazione + parametri", come modalità di mutazione, fattore di scala, probabilità di crossover.
>
> Il livello esterno produce configurazioni → le invia al livello interno → il livello interno esegue e restituisce feedback di prestazione → il livello esterno conserva e ricombina le configurazioni migliori, poi si passa al ciclo successivo. Si può riassumere in "configurazione esterna → risoluzione interna → prestazioni sul compito → aggiornamento esterno".
>
> La strategia e i parametri dell'algoritmo interno non sono più impostati una volta per tutte dall'uomo e poi fissati, ma vengono continuamente riscritti dalla ricerca esterna; l'algoritmo acquisisce così un canale di auto-miglioramento.
>
> Ogni valutazione esterna richiede di eseguire completamente il livello interno; la valutazione annidata amplifica i costi; il parallelismo su GPU permette di valutare più configurazioni contemporaneamente, comprimendo il tempo wall-clock di una singola iterazione esterna, ed è il presupposto per la praticabilità dell'architettura. In caso di risorse insufficienti, si dovrebbe prima ridurre la scala del livello esterno o abbassare la precisione di valutazione del livello interno, invece di ampliare ciecamente la ricerca.

**Punti chiave della lezione**

- Il livello esterno modifica l'algoritmo, il livello interno risolve il compito. Vedendo "strategia di mutazione, configurazione dei parametri, schema algoritmico" pensare al livello esterno
- l'oggetto modificato è l'algoritmo o la soluzione? MetaDE non equivale a taratura manuale o a una ricerca a griglia una tantum. La taratura manuale è un tentativo ed errore una tantum fuori dal ciclo
- MetaDE porta la configurazione nel ciclo evolutivo; la configurazione viene continuamente generata, valutata e ricombinata; l'oggetto della ricerca è la combinazione "strategia + parametri". Quante configurazioni deve valutare il livello esterno a ogni ciclo? Quanto costa una singola valutazione interna? Quante risorse di accelerazione sono disponibili? Se il tempo wall-clock non può essere compresso a un intervallo accettabile tramite parallelismo, prima ridurre la scala esterna o la precisione di valutazione interna, poi considerare di ampliare la ricerca.

**Gestione degli esercizi**

Le 5 domande a scelta di questa pagina servono a verificare la divisione dei compiti tra i due livelli e la consapevolezza dei costi. La domanda 1 sceglie "iterare soluzioni candidate su un compito di ottimizzazione concreto e restituire le prestazioni sul compito", sottolineando che il livello interno è il livello del compito. La domanda 2 sceglie "un insieme di strategia di mutazione e configurazione di parametri del DE interno", sottolineando che l'individuo esterno è una configurazione, non una soluzione del compito. La domanda 3 sceglie "il feedback di prestazione ottenuto dal livello interno dopo l'esecuzione sul compito", corrispondente al canale ascendente del ciclo chiuso. La domanda 4 sceglie "la valutazione annidata moltiplica i costi computazionali, il parallelismo può comprimere il costo temporale della ricerca meta-livello", notando che il parallelismo riduce il tempo wall-clock, non il calcolo totale. La domanda 5 sceglie "MetaDE porta la configurazione dell'algoritmo nel ciclo evolutivo, la configurazione viene continuamente generata, valutata e ricombinata", distinguendola dalla taratura manuale.

Gestione del caso:

Lo spazio di ricerca esterno è l'"insieme delle configurazioni dell'algoritmo", inclusi strategia di mutazione, fattore di scala, probabilità di crossover e altri parametri; il processo di risoluzione interno mantiene soluzioni candidate su un compito fisso di ottimizzazione di percorso, esegue l'evoluzione e restituisce la qualità del percorso. Il valore di mettere la strategia di mutazione nell'evoluzione esterna sta nel fatto che l'oggetto della ricerca si estende dai valori numerici alla combinazione "strategia + parametri", potendo cambiare automaticamente strategia in base alla struttura del compito o alla fase di ricerca, riducendo la subottimalità e i tentativi ed errori ripetuti causati dal fissare manualmente una singola strategia.

Valutazione parallela in batch di più configurazioni, per comprimere il tempo wall-clock dell'iterazione esterna; valutazione a stadi, con una prima selezione grezza usando popolazioni o iterazioni ridotte, poi una valutazione completa delle configurazioni migliori; limitazione dell'ambito di ricerca, limitando popolazione e numero di iterazioni esterne e memorizzando nella cache le configurazioni già valutate. Il compromesso è: più grossolana è la valutazione interna, maggiore è il rumore del feedback e più probabile scegliere configurazioni fortunate; maggiore è il parallelismo, maggiori sono i costi di memoria e scheduling; il parallelismo non riduce il calcolo totale, comprime solo il tempo wall-clock, quindi bisogna bilanciare precisione di valutazione, ampiezza della ricerca e budget hardware.

**Verifica della comprensione**

Si può chiedere a uno studente a caso di riassumere in una frase "chi modifica l'algoritmo, chi risolve il compito", e di classificare un elemento come esterno o interno, ad esempio "fattore di scala" è esterno, "qualità del percorso" è interno. Se lo studente sa motivare, si passa alla pagina successiva con applicazioni o riepilogo.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno esporre il ciclo chiuso "configurazione esterna → risoluzione interna → feedback di prestazione → aggiornamento esterno", si passa alla pagina successiva con esempi, applicazioni o riepilogo.

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

### L'architettura del sistema a ciclo evolutivo chiuso di EvoX

*Pagina 11*

> **Obiettivo della pagina:** Lo studente deve comprendere come EvoX costruisca un'infrastruttura completa a ciclo evolutivo chiuso tra le capacità del modello e le capacità del sistema.

**Punti chiave della lezione**

- Il modello genera possibilità → l'ambiente fornisce feedback → il sistema valuta e seleziona → eredità. Di fronte a una domanda su EvoX, prima si giudica quale ruolo ha questo passo nel ciclo chiuso: produrre possibilità, fornire verifica, fare la scelta, o conservare i risultati.
- Se un'opzione descrive EvoX come "un modello più grande" o "una chiamata singola più veloce", si può praticamente determinare che è un distrattore. EvoX descrive il meccanismo di funzionamento tra i componenti: come generazione, feedback, valutazione, selezione ed eredità si collegano e circolano.
- Feedback distorto, criteri di valutazione deviati rispetto all'obiettivo, meccanismo di eredità che conserva le cose sbagliate: se uno dei tre ha problemi, la deviazione viene ereditata e amplificata ripetutamente nel ciclo. Per il ripasso, autoverifica con tre domande: il feedback è reale? la valutazione è allineata all'obiettivo? l'eredità conserva le cose giuste?

【Obiettivo della pagina】

I grandi modelli sanno già scrivere codice, proporre ipotesi e fornire soluzioni; perché serve ancora un intero sistema? Lo studente deve comprendere come EvoX costruisca un'infrastruttura completa a ciclo evolutivo chiuso tra le capacità del modello e le capacità del sistema, padroneggiando i quattro anelli del ciclo chiuso con il loro ordine, il significato architetturale, il meccanismo di accumulo continuo, le origini di pensiero e i rischi.

【Ordine di esposizione】

Una generazione singola non può autodimostrare la correttezza ed è difficile che resti efficace quando ambiente e modello cambiano continuamente. La posizione di EvoX è fare da ponte tra le capacità del modello e le capacità del sistema, organizzando i risultati delle generazioni successive in capacità verificabili, selezionabili e conservabili. Poi si spiegano i quattro anelli del ciclo chiuso: il modello genera possibilità → l'ambiente fornisce feedback → il sistema valuta e seleziona → eredità. Quindi si illustra il significato architetturale: EvoX non è un algoritmo puntuale, né una singola chiamata, ma un meccanismo sistemico riutilizzabile. Poi si parla dell'accumulo continuo e della corrispondenza con la "macchina bambina" di Turing del 1950, infine si ricorda che il ciclo chiuso può anche amplificare le deviazioni.

【Punti chiave della lezione】

Il modello è bravo a fornire in una singola chiamata una "possibilità" — un'ipotesi, un pezzo di codice, una soluzione. Ma la possibilità non è una conclusione: se il risultato regge lo deve dire l'ambiente reale; dopo che l'ambiente ha dato il risultato, chi giudica quale sia migliore, cosa conservare, cosa eliminare, e chi porta la parte conservata nel ciclo successivo? Questi anelli il modello stesso non li assume. EvoX si rivolge proprio a questo vuoto "dopo la generazione", trasformando i risultati generati in capacità sistemiche accumulabili.

2. I quattro anelli del ciclo chiuso:

Il modello fornisce soluzioni candidate, ipotesi o codice; offre possibilità, non conclusioni.

Esperimenti, simulazioni o esecuzioni reali restituiscono risultati osservabili, sottoponendo i candidati alla verifica della realtà.

Il sistema confronta i candidati secondo obiettivi e vincoli, giudica il bene e il male, decide quali possono restare.

La strategia, i parametri o i componenti selezionati entrano nel ciclo successivo, diventando il nuovo punto di partenza.

Il modello genera possibilità → l'ambiente fornisce feedback → il sistema valuta e seleziona → eredità → ritorno al modello che genera nuove possibilità. Finché il ciclo chiuso funziona, ogni ciclo non deve ricominciare da zero. La chiave dell'ordine è: il feedback deve avvenire prima della valutazione, la valutazione prima dell'eredità. Altrimenti la valutazione manca di basi e anche l'eredità.

Organizzare generazione, feedback di esecuzione, valutazione, selezione ed eredità in un'architettura sistemica riutilizzabile è la differenza fondamentale tra EvoX e un algoritmo puntuale o una singola chiamata. Un algoritmo puntuale si occupa di "come calcolare questo passo"; una singola chiamata si occupa di "se questa risposta è corretta"; EvoX si occupa di "se questo meccanismo può funzionare ciclo dopo ciclo, migliorando sempre". Descrive quindi interfacce tra componenti, criteri di valutazione e regole di eredità, non solo i parametri di un modello o la risposta di una singola domanda.

Nel ciclo chiuso, le strategie che superano la valutazione vengono ereditate, quelle che non la superano vengono eliminate o corrette. Generatore, simulatore, valutatore e altri componenti intelligenti distribuiti in anelli diversi condividono così lo stesso "registro di sopravvivenza": le loro capacità si sommano in molti cicli evolutivi, invece di essere azzerate ogni volta. È questo il punto chiave con cui il ciclo chiuso aggrega componenti dispersi in capacità che si accumulano continuamente.

La "macchina bambina" di Turing del 1950. Già nel 1950 Turing propose la visione della "macchina bambina": la macchina è come un bambino che, attraverso educazione, sperimentazione e premi/punizioni, acquisisce gradualmente capacità nell'interazione con l'ambiente. EvoX può essere visto come un'estensione sistematizzata di questa visione nella pratica di ricerca AI Native — l'educazione corrisponde alla generazione e alla guida, la sperimentazione al feedback ambientale, i premi/punizioni alla valutazione selettiva, la crescita all'eredità e all'accumulo.

Il ciclo chiuso amplifica anche le deviazioni. L'efficacia del ciclo chiuso non equivale automaticamente a "migliore". Dipende dalla coerenza di tre anelli: se il feedback ambientale è reale, se i criteri di valutazione sono allineati all'obiettivo, se il meccanismo di eredità conserva le cose giuste. Se il feedback è distorto o la definizione dell'obiettivo è deviata, l'errore non scompare da solo, ma viene amplificato ciclo dopo ciclo. Progettare un ciclo chiuso significa essenzialmente progettare le regole di valutazione ed eredità. Per il ripasso, autoverifica con tre domande: il feedback è reale? la valutazione è allineata all'obiettivo? l'eredità conserva le cose giuste?

【Copertura delle parole chiave】

Sistema a ciclo evolutivo chiuso, livello di ponte EvoX, il modello genera possibilità, l'ambiente fornisce feedback, il sistema valuta e seleziona, eredità, capacità sistemiche accumulabili, macchina bambina, distorsione del feedback, criteri di valutazione, meccanismo di eredità, amplificazione delle deviazioni, ricerca AI Native.

【Spunti per gli esercizi】

Questa pagina è corredata da 5 domande a scelta e 1 caso, per verificare la comprensione dell'ordine del ciclo chiuso, del significato architetturale, della visione di Turing e dei rischi.

【Gestione degli esercizi】

Qual è la ragione fondamentale per cui EvoX è necessario?

I grandi modelli sono forti nella generazione singola, ma mancano di un veicolo a ciclo chiuso che trasformi i risultati generati in capacità sistemiche accumulabili.

Come i risultati vengono verificati, valutati ed ereditati nell'ambiente. EvoX fornisce proprio questo veicolo a ciclo chiuso. Se gli studenti scelgono erroneamente opzioni come "capacità di generazione insufficiente", ricordare che la domanda chiede "perché serve un sistema", non "dove il modello calcola male".

Qual è l'ordine corretto dei quattro anelli del ciclo evolutivo chiuso di EvoX?

Il modello genera possibilità → l'ambiente fornisce feedback → il sistema valuta e seleziona → eredità.

Prima si generano possibilità, poi l'ambiente fornisce feedback, quindi il sistema valuta e seleziona, infine la parte efficace viene ereditata nel ciclo successivo, chiudendo il cerchio. Il feedback deve avvenire prima della valutazione, la valutazione prima dell'eredità.

La frase "EvoX è un'architettura di sistema", qual è la spiegazione più accurata?

EvoX è una progettazione d'insieme che organizza generazione, feedback di esecuzione, valutazione, selezione ed eredità in un meccanismo riutilizzabile.

Il significato dell'architettura sta nelle interfacce tra componenti, nei criteri di valutazione e nelle regole di eredità, e nella capacità di questi meccanismi di funzionare stabilmente ciclo dopo ciclo. Distinguere "algoritmo puntuale/chiamata singola" e "architettura di sistema": il primo risolve un passo o una volta, la seconda se il meccanismo può funzionare continuamente.

La visione della "macchina bambina" proposta da Turing nel 1950, qual è il suo nucleo?

La macchina acquisisce gradualmente capacità attraverso educazione, sperimentazione e premi/punizioni, nell'interazione con l'ambiente.

L'educazione dà la direzione, la sperimentazione fornisce la verifica, i premi/punizioni formano la pressione selettiva. Non è un'infusione di conoscenza una tantum, ma far acquisire alla macchina capacità gradualmente nell'ambiente, come un bambino.

Se il feedback ambientale è distorto e i criteri di valutazione deviano dall'obiettivo reale, quale conseguenza è più probabile nel ciclo evolutivo chiuso?

Gli errori vengono ereditati ripetutamente e amplificati ciclo dopo ciclo.

Il ciclo chiuso amplifica fedelmente i segnali che riceve, compresi quelli errati. La coerenza tra qualità del feedback, criteri di valutazione e meccanismo di eredità è il presupposto dell'efficacia del ciclo chiuso. La caratteristica del ciclo chiuso è l'"uso ciclico": il risultato del ciclo precedente entra in quello successivo, quindi la deviazione non si autocorregge, ma può essere ereditata ripetutamente e ingrandirsi.

【Gestione del caso】

Un ciclo di evoluzione nella ricerca AI Native. Un gruppo di ricerca cerca formule praticabili per un nuovo catalizzatore: il grande modello genera 20 formule candidate basandosi sulla letteratura; queste vengono inviate a un ambiente di simulazione e a una piccola piattaforma sperimentale, misurando attività e stabilità e registrando le cause dei fallimenti; il sistema ordina secondo "attività × stabilità ÷ costo" e vincoli di sicurezza, conserva le prime 5 e organizza le cause dei fallimenti in una base di esperienza; nel ciclo successivo, il modello genera una nuova serie di candidati basandosi sulle 5 formule conservate e su tutte le cause dei fallimenti. Il team scopre che, senza registrare le cause dei fallimenti, la qualità dei candidati si blocca dopo il terzo ciclo; includendo le cause dei fallimenti come base per la generazione successiva, la praticabilità dei candidati migliora nettamente.

Quale passo si assume la responsabilità di "far sottoporre le possibilità alla verifica della realtà"? Se si elimina questo passo, in quale forma degenera il ciclo chiuso?

L'ambiente di simulazione e la piccola piattaforma sperimentale restituiscono misure reali di attività e stabilità, e registrano una per una le cause dei fallimenti. Senza questo passo, il sistema può valutare i candidati solo in base al giudizio del modello stesso, e il ciclo chiuso degenera in un giro a vuoto "generazione — autovalutazione — generazione": la qualità dei candidati non è più vincolata dalla realtà, i fallimenti non possono essere spiegati, e le conclusioni del ciclo precedente non possono essere verificate.

Dopo aver incluso le cause dei fallimenti come base per la generazione successiva, la praticabilità dei candidati migliora nettamente. Spiegare questo fenomeno collegandolo ai due anelli "valutazione selettiva del sistema" ed "eredità", e indicare il presupposto progettuale che rivela.

L'anello "valutazione selettiva del sistema" non conserva solo i candidati di successo meglio classificati, ma salva anche in modo strutturato le cause dei fallimenti nella base di esperienza; l'anello "eredità" porta con sé non solo "quali soluzioni sono efficaci", ma anche "quali percorsi si sono dimostrati inefficaci". Queste informazioni entrano nella generazione successiva, indicando di fatto le regioni dello spazio di ricerca da evitare, e i candidati diventano naturalmente più praticabili. Il presupposto progettuale che rivela è: il meccanismo di eredità deve essere coerente con i criteri di valutazione — tutte le informazioni efficaci identificate nella valutazione, di successo o di fallimento, devono poter essere ereditate; altrimenti metà della capacità di accumulo del ciclo chiuso va sprecata.

【Verifica della comprensione】

Perché EvoX ha bisogno del ciclo chiuso? Quali sono i quattro anelli del ciclo chiuso? Qual è la differenza tra architettura e chiamata singola? Quali rischi può comportare il ciclo chiuso? L'insegnante integra le parole chiave mancanti in base alle risposte, come "capacità sistemiche accumulabili", "il feedback deve avvenire prima della valutazione", "coerenza tra meccanismo di eredità e criteri di valutazione", ecc.

【Suggerimento di transizione】

Dopo aver confermato che gli studenti sanno esporre l'ordine del ciclo chiuso e le responsabilità di ciascun anello, si passa alla pagina successiva con esempi, applicazioni o riepilogo. Se gli studenti intendono ancora EvoX come "un modello più grande" o "una chiamata singola più veloce", bisogna tornare alla parte sul significato architetturale di questa pagina per chiarire.

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

### I confini fondamentali e le questioni chiave per collegare un compito a EvoX

*Pagina 12*

> **Obiettivo della pagina:** Lo studente deve comprendere che, per collegare un problema reale a EvoX, è necessario chiarire gli oggetti modificabili, i risultati osservabili e i criteri di valutazione.

> **Obiettivo della pagina**
>
> Presentare "il collegamento di un compito reale a EvoX" come un processo che prima contrattualizza e poi tara i parametri. Lo studente deve saper esporre tre confini: quali oggetti possono essere cambiati (spazio di ricerca), quali risultati possono essere osservati (canale di feedback), quali cambiamenti devono essere conservati (criteri di valutazione), e comprendere che i confini precedono la scelta della ricerca e degli operatori.

**Punti chiave della lezione**

- Modificabile? Osservabile? Conservabile? I confini determinano la direzione dell'evoluzione, gli operatori determinano solo quanto velocemente si procede nella direzione
- se i confini sono sbagliati, più intensa è la ricerca, più ci si allontana. Dichiarare esplicitamente variabili decisionali e struttura (genotipo) e la loro mappatura al prodotto reale (fenotipo), indicando anche ambiente, dati, interfacce, hardware e vincoli di conformità in sola lettura. Confini troppo ampi introducono molti candidati inefficaci, troppo stretti non lasciano margine evolutivo. Ogni candidato deve produrre segnali catturabili dal programma, chiarendo canale di osservazione, latenza, livello di rumore e riproducibilità. Le dimensioni non osservabili non possono essere usate come base di ottimizzazione, ma solo per spiegazioni a posteriori
- inserire nell'idoneità ciò che non si può osservare fa derivare l'evoluzione verso il rumore. Definire la funzione di idoneità o il vettore degli obiettivi, i vincoli e il giudizio di ammissibilità, indicando se comprimere in un unico valore o conservare secondo il Pareto multi-obiettivo, e specificando penalità, riparazione o arresto anticipato per candidati falliti, in crash o in timeout. Una volta determinati, i criteri di valutazione determinano la direzione di convergenza dell'evoluzione. Grado di parallelismo e latenza singola determinano direttamente il ritmo del circuito evolutivo e il numero di generazioni sopportabili. La valutazione seriale allunga il circuito e riduce bruscamente le generazioni sopportabili
- la valutazione in batch o asincrona può accelerare significativamente l'iterazione. Bisogna anche definire il budget totale di valutazione, i criteri di convergenza e le condizioni di arresto, per evitare consumo illimitato di calcolo e per evitare di terminare troppo presto soluzioni non ancora formate. Attenzione al disallineamento tra metriche surrogate e obiettivi reali, alla fuga di obiettivi, ai candidati che sfruttano il valutatore per gonfiare il punteggio. La contromisura è mantenere un set di validazione indipendente o una revisione manuale, e rendere la valutazione il più possibile senza stato e riproducibile, per facilitare la riproduzione dei fallimenti e l'attribuzione dei risultati. Incapsulare il compito in un'interfaccia unificata: input un candidato, output metriche e vincoli, garantendo una valutazione il più possibile senza stato e riproducibile. Se il contratto è stabile, il ciclo evolutivo chiuso è stabile.

> **Spunti per i materiali**
>
> - Il diagramma della pagina presenta il flusso di dati "compito e ambiente reale — oggetti modificabili — valutatore e canale di osservazione — ciclo evolutivo chiuso di EvoX", e usa il confronto dei tempi tra valutazione seriale e in batch o asincrona per illustrare la differenza di ritmo. Si può usare il diagramma per sottolineare: prima disegnare i tre confini, poi regolare operatori e parametri.

**Gestione degli esercizi**

Scegliere "variabili decisionali e struttura (genotipo) modificabili e la loro mappatura al prodotto reale (fenotipo)". Suggerimento: il budget di calcolo appartiene ai confini di valutazione, frequenza di campionamento e rumore ai confini di osservazione, l'operatore di mutazione è un dettaglio implementativo.

Scegliere "ogni candidato deve produrre segnali catturabili dal programma, chiarendo canale di osservazione, latenza e rumore; le dimensioni non osservabili possono servire solo per spiegazioni a posteriori". Suggerimento: la base di ottimizzazione deve venire da segnali catturabili.

Scegliere "il modo di valutazione decide cosa verrà conservato; se si amplia prima lo spazio di ricerca, l'evoluzione si sovradattarà a metriche facili da osservare e da gonfiare". Suggerimento: cosa conservare precede cosa cercare.

Scegliere "grado di parallelismo e latenza della singola valutazione determinano direttamente il ritmo del circuito evolutivo e le generazioni sopportabili". Suggerimento: la serialità allunga il circuito, il batch o l'asincrono accelerano l'iterazione.

Scegliere "il candidato sfrutta le falle del valutatore per ottenere un punteggio molto alto, ma in realtà non risolve davvero il problema del compito". Suggerimento: le decisioni chiave di messa in produzione devono basarsi su risultati di validazione indipendenti.

La scelta degli operatori, l'ordine di esecuzione e gli iperparametri di ciascun operatore costituiscono il genotipo; l'output della pipeline reale è il fenotipo. Risultati osservabili: accuratezza end-to-end, latenza end-to-end, tasso di fallimento, chiarendo latenza, rumore e riproducibilità. Criteri di conservazione: accuratezza e latenza possono essere conservate secondo il Pareto multi-obiettivo; il limite di latenza è vincolo rigido, chi non lo rispetta è giudicato non ammissibile; per candidati falliti, in crash o in timeout si prevede penalità o riparazione prima della valutazione. Vincoli di sola lettura: definizione della struttura dei dati di input, requisiti di conformità, interfacce a monte, hardware e ambiente di esecuzione. Contratto di collegamento: input il candidato, output metriche e vincoli, valutazione il più possibile senza stato e riproducibile, invio in batch containerizzato, recupero asincrono.

Definire il budget totale di valutazione, i criteri di convergenza e le condizioni di arresto.

**Verifica della comprensione**

Chiedere a uno studente a caso di riassumere con parole proprie "le tre domande prima della taratura dei parametri", e di fare un esempio di cosa succede se si usa il punteggio del training set come unico criterio di conservazione. Se lo studente ripete solo la taratura degli operatori, tornare a "i confini determinano la direzione" e rispiegare.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno esporre i tre confini — oggetti modificabili, risultati osservabili, criteri di valutazione — e il loro rapporto con il ciclo evolutivo chiuso, si passa alla pagina successiva con esempi, applicazioni o riepilogo.

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

### Avvio rapido: configurazione dell'ambiente e uso di EvoX

*Pagina 13*

> **Obiettivo della pagina:** Lo studente deve padroneggiare i metodi di base per installare e configurare rapidamente EvoX negli strumenti di IA.

> **Obiettivo della pagina**
>
> Questa pagina vuole risolvere il percorso più breve "da zero al primo ambiente EvoX funzionante": completare installazione e configurazione di base con il minor numero possibile di comandi, poi verificare con import ed esempio minimo, confermando che EvoX possa essere invocato da un compito. Il concetto centrale è "installato non significa funzionante"; solo ottenendo output reali in tutti e quattro i passi si può dire di aver completato l'avvio.

> **Ordine di esposizione**
>
> Prima si spiega che la configurazione dell'ambiente non è semplicemente eseguire un comando di installazione, ma un ciclo chiuso "isolamento — installazione — configurazione — verifica"; poi si sviluppano in sequenza i quattro passi, infine si aggiungono i limiti dell'assistenza IA e i requisiti di riproducibilità.

**Punti chiave della lezione**

- Prima di installare qualsiasi pacchetto, creare un ambiente Python indipendente con venv o conda. I pacchetti nell'ambiente globale sono condivisi da più progetti, e dopo conflitti di versione il costo di diagnosi è molto alto
- un ambiente indipendente equivale a riservare a EvoX un banco di lavoro separato; se si rompe, si può ricostruire l'intero ambiente. La pratica comune è python -m venv.venv, poi attivare l'ambiente
- Su Windows corrisponde allo script di attivazione nella directory Scripts. Dopo l'attivazione, eseguire prima pip install -U pip, per evitare errori del vecchio gestore di pacchetti nella risoluzione delle dipendenze. Di solito si esegue pip install evox, ma si può usare anche conda o il codice sorgente. Nome del pacchetto, versione e fonte di download devono sempre fare riferimento alla pubblicazione ufficiale; non scambiare nomi simili per EvoX. L'assenza di errori rossi durante l'installazione indica solo che "è installato", non che "funziona", quindi non fermarsi a questo passo. Al primo avvio non serve regolare tutti i parametri; basta confermare quattro punti di partenza: se la versione di Python soddisfa i requisiti ufficiali, se le versioni delle dipendenze sono compatibili, se per questo esperimento si usa CPU o GPU, se il seed casuale è fissato. I primi due determinano se il programma può funzionare, gli altri due se i risultati sono riproducibili. La verifica più affidabile non è cercare errori rossi nel terminale, ma far eseguire davvero EvoX una volta. Prima import evox e stampare il numero di versione, confermando che il pacchetto è caricato nell'ambiente corrente
- poi eseguire l'esempio minimo o completare un ciclo di iterazione evolutiva, confermando che può essere invocato normalmente da un compito. Indicatori di accettazione: output riuscito del numero di versione, esempio minimo senza errori, completamento di un ciclo di iterazione evolutiva. Si può comunicare all'IA sistema operativo, versione di Python e hardware, facendole generare comandi di installazione, configurazione e diagnosi, per risparmiare tempo nella consultazione della documentazione
- ma nomi dei pacchetti, combinazioni di versioni e operazioni a livello di sistema devono essere verificati con la documentazione ufficiale e la matrice delle versioni prima dell'esecuzione, specialmente i comandi che modificano la configurazione di sistema o disinstallano dipendenze. Registrare comandi di installazione, file delle dipendenze e numeri di versione permette di riprodurre lo stesso ambiente su un'altra macchina, evitando "funziona sulla mia macchina, ma fallisce su un'altra".

> **Spunti per i materiali**
>
> - La pagina usa un diagramma di flusso in quattro passi per mostrare "ambiente isolato — installazione di EvoX — configurazione di base — verifica dell'avvio", con una lista di controllo per l'accettazione
> - si può accompagnare con una finestra di esempio del terminale per spiegare comandi e identificatori dell'ambiente.

**Gestione degli esercizi**

La risposta alla domanda 1 è "isolare le dipendenze, evitando contaminazioni reciproche con altri progetti nell'ambiente globale". Nel feedback sottolineare che il valore centrale dell'ambiente isolato è la non interferenza delle dipendenze, non la connettività o la velocità di esecuzione.

La risposta alla domanda 2 è "importare con successo evox, stampare il numero di versione ed eseguire un esempio minimo". Va chiarito che l'installazione senza errori è solo uno stato intermedio.

La risposta alla domanda 3 è "comunicare prima all'IA sistema operativo, versione di Python e hardware della macchina, poi verificare con documentazione ufficiale e matrice delle versioni prima di eseguire". Ricordare che l'IA fornisce comandi candidati; prima di eseguire, verificare l'ambito di impatto.

La risposta alla domanda 4 è "garantire la riproducibilità dei risultati sperimentali, in modo che restino confrontabili su un'altra macchina o versione". Seed e versione influenzano la riproducibilità, non velocità, memoria o garanzie di convergenza.

La risposta alla domanda 5 è "conflitti di dipendenze o incompatibilità di versioni vengono rimandati e si manifestano solo quando si esegue davvero il compito". La mancanza di verifica rimanda il problema a un momento più scomodo.

Indicare i passi minimi praticabili secondo i quattro passi, spiegando il segnale di accettazione di ciascuno, ad esempio: dopo l'attivazione compare l'identificatore dell'ambiente nella riga di comando e python -V punta alla versione target, l'installazione termina senza conflitti di dipendenze, si chiarisce CPU o GPU e si fissa il seed, l'import riesce e l'esempio minimo funziona. Domanda 2: organizzare sistema operativo, versione di Python, hardware ed errore completo da fornire all'IA, chiedendo comandi di diagnosi in ordine di invasività minima, con spiegazione di effetti e effetti collaterali; prima dell'esecuzione verificare nome ufficiale del pacchetto, intervallo di compatibilità delle versioni e fonte di installazione; conservare l'elenco delle dipendenze e i numeri di versione chiave per ricostruire l'ambiente.

**Verifica della comprensione**

Chiedere agli studenti di ripetere con parole proprie "installato non significa funzionante", e di indicare i segnali di accettazione dei quattro passi.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno distinguere installazione completata e verifica superata, si passa alla pagina successiva con esempi, applicazioni o riepilogo.

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

### Le competenze centrali del ricercatore e il giudizio estetico

*Pagina 14*

> **Obiettivo della pagina:** Lo studente deve riconoscere che, nel sistema EvoX, porre le domande chiave e mantenere un'estetica scientifica è più importante che scrivere codice.

> **Obiettivo della pagina**
>
> Far riconoscere agli studenti che, nel sistema di evoluzione intelligente EvoX, la competenza centrale del ricercatore si sposta dallo "scrivere a mano ogni riga di codice" al "porre domande chiave, definire prove credibili ed esprimere un giudizio estetico". Quando generazione e tentativi ed errori diventano economici, ciò che è veramente scarso è la capacità di giudizio, non la velocità di digitazione.

> **Ordine di esposizione**
>
> Prima si usa "Code is cheap. Taste matters." per chiarire la posizione di questa pagina, poi si spiega perché, con l'espansione della generazione di candidati, il collo di bottiglia si sposta sulla capacità di selezione, quindi si sviluppano le quattro azioni con cui operano i criteri estetici, poi si chiarisce che l'estetica scientifica non è preferenza soggettiva, infine si verificano la comprensione con domande a scelta e casi di studio.

> **Spunti per i materiali**
>
> - Il poster concettuale di questa pagina può servire da struttura per la lavagna. Al centro "il codice è economico, il gusto conta"; intorno quattro nodi: "porre domande chiave, definire prove credibili, giudicare la direzione evolutiva, stabilire criteri estetici". Durante l'esposizione si può indicare prima l'idea centrale, poi chiedere agli studenti cosa risolve ciascun nodo.

**Punti chiave della lezione**

- Il modello può generare rapidamente soluzioni candidate, il costo dei tentativi ed errori diminuisce, e il limite massimo dei risultati non è più determinato dalla velocità di digitazione, ma dal giudizio del ricercatore su direzione e valore. L'offerta di candidati si espande rapidamente; nello stesso giorno si possono produrre centinaia o migliaia di soluzioni "che sembrano tutte buone"
- quali domande meritano risposta? quali prove meritano fiducia? quali risultati sono sufficienti a sostenere una conclusione? Porre domande, giudicare se una direzione merita investimento
- definire prove credibili, chiarire prima "quale tipo di risultato conta come prova", e su questa base scegliere i candidati
- stabilire criteri estetici, usare una misura stabile per selezionare problemi, obiettivi, prove e direzioni evolutive
- giudicare la direzione evolutiva, scegliere tra molti passi successivi praticabili quello che porta il sistema verso un valore più alto. Non equivale a preferenza soggettiva personale, non è "quale stile mi piace di più", ma un criterio di selezione riutilizzabile, spiegabile e verificabile dai colleghi. Determina quali problemi vengono posti, quali metriche vengono credute, quali direzioni vengono conservate. Non considerare l'estetica come qualcosa di misterioso o come abbellimento a posteriori. Essa agisce nella parte più iniziale delle decisioni: quando si decide in quale problema investire, a quale gruppo di metriche credere, quale percorso evolutivo conservare, l'estetica sta già plasmando i risultati. Più la generazione è economica, più il gusto è importante. Prima di agire, chiedersi: la domanda che pongo merita risposta? le prove su cui mi baso sono credibili? i miei criteri di valutazione sanno filtrare il rumore e conservare le soluzioni veramente preziose?

**Copertura delle parole chiave**

- Migrazione delle competenze centrali, porre domande chiave, definire prove credibili, stabilire criteri estetici, giudicare la direzione evolutiva, capacità di selezione, scarsità della capacità di giudizio, estetica scientifica, criteri di selezione riutilizzabili, Code is cheap. Taste matters..

**Gestione degli esercizi**

La risposta corretta alla domanda 1 è "quando il costo di generazione dei candidati e dei tentativi ed errori diminuisce, porre domande chiave e il giudizio estetico diventano le vere risorse scarse". Punto di feedback: ampliata la capacità di generazione, il collo di bottiglia si sposta su capacità di alto livello come porre domande, definire prove e giudicare. Se gli studenti scelgono male, farli riflettere su cosa diventa veramente scarso quando la generazione diventa economica.

La risposta corretta alla domanda 2 è "quando il costo di generazione e tentativi ed errori diminuisce, la capacità di giudizio (il gusto) diventa la chiave del valore dei risultati". Punto di feedback: lo slogan sottolinea lo spostamento della scarsità; resa economica la generazione, è preziosa la capacità di giudizio che sa filtrare il rumore e indicare la direzione.

La risposta corretta alla domanda 3 è "giudicare quali problemi meritano investimento, quali metriche sono veramente importanti, quali risultati sono sufficienti a sostenere conclusioni". Punto di feedback: più candidati ci sono, più la scelta è cruciale; non si può conservare tutto, né rinunciare a definire obiettivi e criteri di valutazione.

La risposta corretta alla domanda 4 è "l'estetica scientifica è un insieme di giudizi di alto livello, riutilizzabili e spiegabili, per selezionare problemi, obiettivi e prove". Punto di feedback: distinguere preferenza personale e criterio di selezione riutilizzabile; solo il secondo è l'estetica scientifica di cui parla questa pagina.

La risposta corretta alla domanda 5 è "chiarire prima quale tipo di risultato conta come prova, e su questa base scegliere le soluzioni candidate". Punto di feedback: le prove credibili devono essere criteri definiti in anticipo, non una proprietà implicita dei risultati generati.

La scelta quando i candidati esplodono. Lo scenario: un team usa il sistema per generare e testare migliaia di soluzioni candidate in poche ore, le metriche iniziali "sembrano tutte buone", e poi il team deve decidere se continuare ad ampliare la scala o fermarsi a ridefinire problema e metriche di valutazione.

Ciò che è più scarso in questo momento è la capacità di giudizio del ricercatore, cioè il "gusto". La ragione è che il costo di generazione dei candidati e dei tentativi ed errori è già fortemente diminuito; continuare ad ampliare semplicemente la scala ha rendimenti marginali decrescenti, e più soluzioni ci sono, più è difficile distinguerle; ciò che determina davvero il successo è giudicare quali problemi meritano risposta, quali metriche sono veramente importanti, quali risultati sono sufficienti a sostenere conclusioni.

Chiarire le domande chiave a cui questa fase deve rispondere, sostituendo "generare di più" con "rispondere con più precisione"; definire criteri di prova credibili, elencando quali metriche e a quale livello contano come prova; stabilire criteri estetici e di valutazione stabili, usandoli per selezionare obiettivi e direzioni evolutive; fare scelte motivate tra i candidati, eliminando le soluzioni "che sembrano buone ma non sostengono conclusioni", concentrando le risorse sui pochi percorsi di maggior valore.

**Verifica della comprensione**

Chiedere agli studenti di spiegare con parole proprie la logica di "più la generazione è economica, più il gusto è importante", indicando almeno due azioni di giudizio concrete. Si può chiedere: se potessi conservare un solo criterio di valutazione, quale conserveresti? Perché?

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno distinguere "capacità di generazione" e "capacità di giudizio", e sanno esporre le quattro azioni — porre domande, definire prove, stabilire criteri, giudicare la direzione — si passa alla pagina successiva con applicazioni, esempi o riepilogo.

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

### Confronto tra il tradizionale dialogo singolo e il sistema evolutivo continuo di EvoX

*Pagina 15*

> **Obiettivo della pagina:** Lo studente deve chiarire, attraverso il confronto, le differenze centrali tra il tradizionale dialogo con grandi modelli e il sistema evolutivo continuo di EvoX nell'affrontare ambienti complessi.

> **Obiettivo della pagina**
>
> Questa pagina vuole far chiarire agli studenti, attraverso il confronto, le differenze centrali tra il tradizionale dialogo singolo con grandi modelli e il sistema evolutivo continuo di EvoX nell'affrontare ambienti complessi. Si ricollega alla visione della "macchina bambina" di Turing: le capacità vengono dall'esperienza, non da una formazione in un colpo solo. Durante l'esposizione si devono cogliere due punti di giudizio: quanto è lunga la catena e se dopo il punto finale c'è un ritorno; la verifica avviene fuori o dentro il sistema.

> **Ordine di esposizione**
>
> Prima si torna alla visione di Turing del 1950, poi si sviluppano i due percorsi. Il tradizionale dialogo singolo è un circuito aperto: prompt → generazione → output, e l'output termina tutto. Non ha un canale che riporti automaticamente i risultati dell'esecuzione al sistema; la verifica avviene per lo più fuori dal sistema, dipendendo dal giudizio manuale, dalla selezione, dalla riproduzione e da nuove domande del ricercatore; i miglioramenti restano dispersi nel giudizio umano e in annotazioni temporanee, difficili da sedimentare come capacità sistemiche; è sostanzialmente disaccoppiato dall'ambiente fisico reale e resta fisso dopo una generazione. Quindi, quando il compito può essere generato in una volta e il costo di verifica è basso, è più diretto ed efficiente.
>
> Generazione di candidati → verifica nell'ambiente → accumulo di feedback → nuova evoluzione, in un cerchio continuo. I risultati della verifica diventano feedback e guidano la generazione, selezione e conservazione dei candidati del ciclo successivo; ambiente del compito, valutatore o interfaccia di esecuzione reale entrano nei confini del sistema; i candidati non solo vengono generati, ma anche effettivamente eseguiti e verificati; i miglioramenti si sedimentano attraverso feedback e meccanismi di conservazione, e le capacità si accumulano con i cicli; l'accoppiamento con l'ambiente è profondo, e i cambiamenti ambientali entrano direttamente nel ciclo successivo. Quando il compito è complesso, l'ambiente è reale e servono verifica continua e accumulo di miglioramenti, bisogna adottare il ciclo chiuso.

**Punti chiave della lezione**

- I quattro anelli del ciclo chiuso hanno responsabilità diverse. La generazione di candidati propone possibilità
- la verifica nell'ambiente fa eseguire realmente i candidati in condizioni reali
- l'accumulo di feedback registra i risultati della verifica
- la nuova evoluzione genera e conserva i candidati della generazione successiva in base al feedback accumulato. I quattro si collegano in cerchio; un fallimento non scompare con la fine dell'output, ma diventa il punto di partenza del ciclo successivo. Allo stesso tempo va sottolineato che il ciclo chiuso non elimina il ruolo umano, ma ne cambia la posizione: l'uomo passa dal giudizio, dalla riproduzione e dalle domande ciclo per ciclo alla progettazione dei criteri di valutazione, alla definizione delle regole di selezione e conservazione, alla revisione dei vincoli di confine. È questo il modo più concreto in cui la "macchina bambina" di Turing si realizza oggi — non formata in un colpo solo, ma cresciuta nell'esperienza. Un fraintendimento comune è equiparare "alta qualità della generazione" e "sistema affidabile": il modello può fornire soluzioni apparentemente ragionevoli, ma ciò non significa che siano valide nell'ambiente reale
- solo i candidati che hanno superato esecuzione e verifica reali possono essere conservati e trasformati in capacità accumulabili in modo sostenibile.

**Gestione degli esercizi**

Questa pagina ha 5 domande a scelta e 1 caso. Si consiglia di usarle dopo aver spiegato la tabella comparativa e i quattro anelli del ciclo chiuso. La domanda 1 sceglie "prompt → generazione → output, dopo l'output il processo termina". Punto di feedback: la catena del dialogo singolo ha solo tre segmenti, l'output è il punto finale, manca un canale che riporti automaticamente i risultati al sistema; se gli studenti scelgono erroneamente i quattro segmenti del ciclo chiuso, ricordare che la domanda chiede del tradizionale dialogo singolo. La domanda 2 sceglie "fuori dal sistema, dipendendo dal giudizio, dalla selezione e dalla riproduzione manuale del ricercatore". Punto di feedback: la posizione della verifica è il punto chiave del giudizio; la verifica nel dialogo singolo di solito non avviene automaticamente dentro il sistema. La domanda 3 sceglie "generazione di candidati → verifica nell'ambiente → accumulo di feedback → nuova evoluzione".

Prima i candidati, poi l'ingresso nell'ambiente per la verifica reale, e solo dopo l'accumulo dei risultati della verifica si passa al ciclo evolutivo successivo; il feedback deve tornare alla generazione per chiudere il cerchio. La domanda 4 sceglie "le soluzioni candidate non solo vengono generate, ma anche eseguite e verificate realmente, e i risultati diventano input del ciclo successivo". Punto di feedback: l'ingresso dell'ambiente nei confini significa che la verifica è inclusa nel sistema, non sostituisce la generazione, né salta l'accumulo di feedback. La domanda 5 sceglie "quando il compito è complesso, l'ambiente è reale e servono verifica continua e accumulo di miglioramenti, si dovrebbe adottare il ciclo chiuso in stile EvoX". Punto di feedback: la scelta si basa sulla complessità del compito e sul costo di verifica, non sulla velocità di generazione o sulla lunghezza dell'output. Se gli studenti esitano, guidarli a cercare prove nelle tre righe "meccanismo di verifica", "accumulo di miglioramenti", "giudizio di selezione" della tabella comparativa.

Sistema di presa robotica in un magazzino non strutturato. La risposta alla domanda 1 può essere organizzata così: nel percorso del dialogo singolo, la verifica avviene fuori dal sistema, con l'ingegnere che osserva manualmente i risultati della presa, riproduce gli scenari di fallimento e formula nuove domande; i miglioramenti restano nel giudizio dell'ingegnere e nella documentazione, difficili da sedimentare automaticamente come capacità sistemiche. Nel percorso EvoX, valutatore, interfaccia di esecuzione reale o ambiente del compito entrano nei confini del sistema; le soluzioni candidate di presa vengono eseguite e verificate realmente, e i risultati della verifica ritornano per partecipare alla generazione, selezione e conservazione dei candidati del ciclo successivo; i miglioramenti si sedimentano con i cicli nel meccanismo di conservazione. Il ruolo umano non scompare, ma si sposta dalla verifica e riproduzione ciclo per ciclo alla progettazione dei criteri di valutazione (ad esempio come determinare il successo di una presa), alla definizione delle regole di selezione e conservazione, alla revisione di sicurezza e vincoli di confine.

Se il compito può essere generato in una volta e il costo di verifica è basso, ad esempio una presa ripetitiva su postazione fissa e oggetto fisso, il dialogo singolo è più diretto e meno costoso; ma l'ambiente di questo caso è non strutturato, con oggetti di forme e pesi diversi, disposizione casuale, illuminazione variabile, scaffali mobili; se una soluzione regge deve essere confermato attraverso interazione ripetuta con l'ambiente reale, e anche i modi di fallimento cambiano continuamente. Quindi bisogna adottare il ciclo chiuso in stile EvoX, facendo verificare i candidati nell'ambiente reale, accumulando i risultati della verifica come feedback, e usando il feedback per guidare generazione e conservazione del ciclo successivo, facendo crescere continuamente le capacità del sistema. La formula è: una volta basta, verifica economica → dialogo singolo; complesso e reale, serve verifica continua e accumulo → ciclo chiuso evolutivo.

**Verifica della comprensione**

Differenza di catena tra i tre segmenti del circuito aperto e i quattro del ciclo chiuso; la verifica avviene fuori o dentro il sistema; la scelta dipende da complessità del compito e costo di verifica. L'insegnante integra le parole chiave mancanti e le basi del giudizio in base alle risposte.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno esporre le relazioni centrali di questa pagina, si passa alla pagina successiva con esempi, applicazioni o riepilogo. Si può chiedere agli studenti di ripetere prima le due catene, poi di giudicare un sistema dato come circuito aperto o chiuso, spiegando dove avviene la verifica e se i miglioramenti possono sedimentarsi.

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

### La visione di un'infrastruttura di evoluzione intelligente per il mondo reale

*Pagina 16*

> **Obiettivo della pagina:** Lo studente deve comprendere che l'obiettivo finale di EvoX è costruire un'infrastruttura che produca, verifichi e conservi continuamente miglioramenti in un mondo reale complesso e in cambiamento.

> **Obiettivo della pagina**
>
> Chiudere il corso sulla posizione finale di EvoX — non un modello o un ottimizzatore, ma un'infrastruttura di evoluzione intelligente rivolta al mondo reale. Lo studente deve saper spiegare: EvoX deve poter collegare compiti reali, ricevere feedback reali, e produrre, verificare e conservare continuamente miglioramenti nella lunga durata, formando infine un ciclo evolutivo chiuso sostenibile.

**Punti chiave della lezione**

- "Cosa vuole diventare EvoX alla fine?" La risposta è un "campo evolutivo" capace di funzionare a lungo. Con il diagramma: al centro l'infrastruttura di evoluzione intelligente EvoX, quattro anelli formano il ciclo chiuso — generazione di candidati → verifica degli effetti → conservazione dei miglioramenti → nuova evoluzione
- all'esterno si possono collegare compiti del mondo reale, piattaforme sperimentali, sistemi produttivi; alla base il supporto di potenza di calcolo, modelli, valutatori. La freccia circolare torna al punto di partenza, sottolineando che l'accumulo di capacità viene dal ciclo chiuso, non da una consegna lineare. Fare del ciclo chiuso un sistema che possa funzionare sempre. EvoX sostiene la ricerca e la pratica AI Native, organizzando collegamento del compito → generazione di candidati → feedback di valutazione → ciclo evolutivo chiuso in una catena stabile
- non persegue un output bello una volta, ma diventa uno strato di base su cui altri sistemi possono fare affidamento. Feedback reale, evoluzione di lungo periodo, conservazione dei miglioramenti. Il feedback reale richiede che l'oggetto evolutivo entri nell'ambiente reale; metriche offline, effetti dimostrativi e output singoli non possono sostituirlo
- l'evoluzione di lungo periodo richiede di produrre continuamente nuovi candidati, verificare gli effetti reali, conservare i miglioramenti efficaci, rendendo le capacità accumulabili, riutilizzabili e ulteriormente evolvibili
- la conservazione dei miglioramenti richiede che le parti verificate come efficaci restino, invece di ricominciare da zero ogni ciclo. Gli obiettivi si tirano reciprocamente, l'ambiente deriva, i risultati portano incertezza. Pertanto questo sistema non promette una soluzione ottimale una tantum, ma si avvicina continuamente alla risposta utilizzabile nel presente attraverso cicli chiusi successivi. Riconoscere l'incertezza è proprio il presupposto della lunga durata. Questa pagina risponde solo a una domanda di giudizio — se il sistema ha organizzato "feedback reale + evoluzione di lungo periodo + conservazione dei miglioramenti" in un ciclo chiuso sostenibile
- la visione regge solo se le tre condizioni valgono insieme.

**Gestione degli esercizi**

La domanda 1 sceglie "un'infrastruttura di evoluzione intelligente rivolta al mondo reale"; il feedback deve sottolineare che l'infrastruttura può collegare compiti reali, ricevere feedback reali e produrre, verificare e conservare continuamente miglioramenti nella lunga durata; se scelgono erroneamente modello generativo, singolo ottimizzatore o strumento per gonfiare punteggi, guidarli a tornare alla posizione di questa pagina. La domanda 2 sceglie "feedback reale, evoluzione di lungo periodo, conservazione dei miglioramenti", sottolineando che scala, velocità ed effetti dimostrativi non sono condizioni di validità. La domanda 3 sceglie "perché l'oggetto evolutivo deve entrare nell'ambiente reale e ricevere feedback reali", spiegando che le metriche offline non possono sostituire la verifica nell'ambiente reale; il punto non è costo o diffusione.

La domanda 4 sceglie "produrre nuovi candidati, verificare gli effetti reali e conservare i miglioramenti efficaci nella durata", sottolineando che produzione — verifica — conservazione — nuova evoluzione formano un ciclo; il punto non è il numero di candidati o il risultato in un colpo solo. La domanda 5 sceglie "riconoscere compromessi multi-obiettivo, incertezza e deriva dell'ambiente, senza promettere una soluzione ottimale una tantum", spiegando che l'ambiente deriva, gli obiettivi confliggono e il sistema deve evolvere continuamente.

Intorno allo scenario "collegare EvoX a una linea di produzione reale", far prima interrogare gli studenti su ciascuno dei tre criteri: l'oggetto evolutivo entra nella linea reale e riceve feedback reali, invece di essere valutato solo su un set di test offline? Il sistema produce continuamente nuovi candidati nella durata, verifica gli effetti reali e conserva i miglioramenti verificati come efficaci? Le capacità sono accumulabili, riutilizzabili e ulteriormente evolvibili, invece di ricominciare da zero ogni ciclo? Se la risposta è no, resta uno strumento di generazione singola o di consegna una tantum. Nel progettare ulteriormente il ciclo chiuso, si possono usare come basi di verifica i risultati del controllo qualità online, le conclusioni della revisione manuale e le prestazioni reali dopo l'esecuzione della pianificazione; rendere esplicito il compromesso multi-obiettivo, conservando più strategie candidate verificate;

usare finestre scorrevoli per far decadere gradualmente il peso dei dati più vecchi, identificando la deriva dell'ambiente e attivando un nuovo ciclo evolutivo; conservare ogni ciclo solo i miglioramenti verificati come efficaci, facendo sommarsi le nuove capacità a quelle vecchie.

**Verifica della comprensione**

C'è feedback reale? C'è evoluzione di lungo periodo? C'è conservazione dei miglioramenti? Solo se si risponde "sì" a tutte e tre il sistema regge; se una risposta è "no", resta nella generazione singola o nella consegna una tantum. Allo stesso tempo ricordare agli studenti che il ciclo chiuso non è una linea retta, ma un cerchio che torna continuamente al punto di partenza; diffidare delle affermazioni "tutto in un colpo, valido per sempre".

> **Suggerimento di transizione**
>
> Questa è la pagina conclusiva del corso; dopo aver confermato che gli studenti sanno distinguere l'infrastruttura evolutiva dagli strumenti di generazione singola, si può richiamare la linea principale del modulo: la tendenza all'accelerazione dell'evoluzione intelligente e i limiti dei grandi modelli, e l'idea centrale di costruire il ciclo evolutivo chiuso con EvoX.