# EvoX Sistema di Evoluzione Intelligente e Pratica di Ricerca Scientifica AI Native — Dispense del Corso

Ore di lezione: 1 · Pagine del materiale: 16

## Navigazione di lettura

- [Lezione 6｜Tema: Evoluzione continua a livello di sistema: Genesis e la sedimentazione nel mondo del software](#lecture-lesson-1)

---

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

## Lezione 6｜Tema: Evoluzione continua a livello di sistema: Genesis e la sedimentazione nel mondo del software

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

### Evoluzione continua a livello di sistema: Genesis e la sedimentazione nel mondo del software

*Pagina 1*

> **Obiettivo della pagina:** Apprendere come Genesis, attraverso la collaborazione multi-Agent e rigorosi meccanismi di verifica, consenta al codice di un progetto di accumularsi ed evolversi continuamente lungo l'intero ciclo di vita.

> **Obiettivo della pagina**
>
> Come un progetto non si limiti a completare una singola codifica, ma permetta al codice di accumularsi ed evolversi continuamente lungo l'intero ciclo di vita. Le linee guida principali sono due: il modello ingegneristico costituito dalla collaborazione multi-Agent e dalla scomposizione ricorsiva dei task, e il meccanismo con cui compilazione, test e accettazione sedimentano le modifiche efficaci nella storia del progetto.

**Punti chiave della lezione**

- 1. Iniziare chiarendo il significato di "evoluzione continua". Il software non è un prodotto definito una volta per tutte dopo la scrittura, ma un'entità continuamente modificata, integrata e rifattorizzata nel tempo. La posizione di Genesis è proprio quella di fornire un modo organizzativo eseguibile per questa evoluzione a lungo termine, e non una tecnica di generazione del codice una tantum. 2. La collaborazione multi-Agent risolve il "chi si divide il lavoro". Di fronte a un progetto reale, la scala dei task spesso supera la capacità di elaborazione singola, quindi servono ruoli differenziati e flussi di collaborazione, affinché le responsabilità di ogni fase siano chiare e tracciabili. 3. La scomposizione ricorsiva dei task risolve il "come iniziare". Suddividere un obiettivo più grande, strato per strato, in piccoli task eseguibili, fino a che ogni sotto-task sia sufficientemente specifico da poter essere completato e verificato in modo indipendente. Questo riduce la difficoltà del singolo passo e permette di valutare separatamente il risultato di ogni passo. 4. La verifica rigorosa risolve il "in base a cosa vale". Compilazione superata, test superati, accettazione superata: sono tre cancelli che si stringono progressivamente. Solo le modifiche che superano questi cancelli hanno il diritto di essere scritte nella storia del progetto
- le modifiche non superate vengono scartate o rimandate in lavorazione. La collaborazione e la scomposizione producono un gran numero di modifiche candidate, la verifica si occupa della selezione, e i risultati selezionati si sedimentano nella storia del progetto, che a sua volta diventa il punto di partenza per il ciclo successivo di evoluzione. Questo è il circuito completo dell'"evoluzione continua a livello di sistema".

**Verifica della comprensione**

Chiedere agli studenti di esprimere con parole proprie la relazione sequenziale tra "scomposizione — verifica — sedimentazione" e di rispondere: se una modifica ha superato la compilazione ma non i test, in quale stato si trova nel meccanismo descritto in questa pagina? L'insegnante verifica così se gli studenti hanno realmente compreso il ruolo dei cancelli di verifica, e non se hanno semplicemente memorizzato i termini.

> **Suggerimento di transizione**
>
> Questa pagina stabilisce il quadro generale; i contenuti successivi entreranno in metodi e casi più specifici. Dopo aver confermato che gli studenti riescono a ripetere questo circuito, si può proseguire in profondità nelle fasi specifiche.

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

### I confini delle capacità dei grandi modelli e la necessità dell'evoluzione a livello di sistema

*Pagina 2*

> **Obiettivo della pagina:** Comprendere i confini attuali delle capacità dei grandi modelli nello sviluppo di sistemi complessi e la necessità di costruire sistemi in grado di evolversi continuamente.

> **Obiettivo della pagina**
>
> Comprendere i confini delle capacità dei grandi modelli nello sviluppo di sistemi complessi, e perché sia necessario integrare componenti intelligenti in un circuito di sistema capace di evolversi continuamente lungo il ciclo di vita.

> **Ordine di esposizione**
>
> I grandi modelli sono potenti componenti intelligenti, ma non sono sistemi in grado di auto-sostenersi. Possiedono già capacità utilizzabili nella comprensione, generazione, ragionamento e chiamata di strumenti, e possono fungere da proponenti di ipotesi e produttori di codice di alta qualità; ma mancano dello stato, degli obiettivi e dei meccanismi di feedback necessari per evolversi continuamente lungo il ciclo di vita.
>
> Comprensione, generazione, ragionamento, chiamata di strumenti: il risultato finale è un'istantanea statica, e al termine della sessione lo stato viene azzerato. Sul lato destro, il grande modello viene integrato come piccolo modulo nel circuito di evoluzione a livello di sistema: proposta, valutazione, selezione, sedimentazione. Il grande modello si occupa della proposta; i modelli surrogati servono a ridurre il costo di valutazione; la fase di selezione gestisce i compromessi multi-obiettivo; la sedimentazione forma una memoria che attraversa le sessioni; l'intelligenza di sciame mantiene la diversità dei candidati e ritorna alla proposta del ciclo successivo.
>
> Confine di stato — la finestra di contesto è limitata, manca una memoria persistente tra sessioni, e i progetti a lungo termine non possono auto-sostenersi; confine di obiettivo — i problemi reali spesso coinvolgono conflitti multi-obiettivo e compromessi di preferenza, e il modello non riesce a fornire autonomamente criteri di scelta difendibili; confine di feedback — mancano meccanismi eseguibili di valutazione, selezione ed eliminazione, e le soluzioni generate non possono essere verificate oggettivamente e conservate iterativamente.
>
> Il miglioramento delle capacità del modello non equivale al miglioramento delle capacità del sistema. La capacità è un'istantanea, l'ambiente è un processo. Solo integrando il grande modello nel circuito evolutivo "generazione—valutazione—selezione—sedimentazione", mantenendo la diversità con l'intelligenza di sciame, comprimendo il costo di valutazione con modelli surrogati, e conservando l'esperienza efficace con selezione e sedimentazione, l'intelligenza può mantenere l'adattamento in un ambiente dinamico. Questo è anche il punto di ancoraggio di EvoX.

**Punti chiave della lezione**

- I grandi modelli possiedono potenti capacità di comprensione e generazione, ma non possono evolvere un sistema in modo indipendente. I sistemi complessi del mondo reale richiedono capacità di evoluzione continua lungo il ciclo di vita; un'istantanea statica non è sufficiente ad affrontare i cambiamenti ambientali. I componenti intelligenti devono essere accompagnati da meccanismi evolutivi per adattarsi a un ambiente dinamico; i meccanismi chiave includono il circuito evolutivo, l'intelligenza di sciame e i modelli surrogati. Confine di stato, confine di obiettivo, confine di feedback.

**Gestione degli esercizi**

Per la domanda sui concetti fondamentali si dovrebbe scegliere "comprendere i confini attuali delle capacità dei grandi modelli nello sviluppo di sistemi complessi e la necessità di costruire sistemi in grado di evolversi continuamente".

Per le restanti domande vero/falso si dovrebbe preferire l'opzione "in grado di spiegare con prove o esempi"; basarsi solo sulle sensazioni, saltare lo studio del materiale, o confrontare cambiando simultaneamente tutti i fattori, non soddisfa i requisiti di questa pagina.

Quando la risposta è corretta, si può riconoscere la capacità di collegarsi ai concetti della pagina e di spiegarne le basi; quando è errata, si suggerisce di tornare alla spiegazione per trovare prove o esempi chiave, rivedendo in particolare i tre tipi di confini e il circuito "proposta—valutazione—selezione—sedimentazione".

Prima si spieghi che il significato centrale è "i grandi modelli possiedono potenti capacità di comprensione e generazione ma non possono evolvere un sistema in modo indipendente", poi si portino esempi per illustrare perché i sistemi complessi richiedono capacità di evoluzione continua lungo il ciclo di vita.

**Verifica della comprensione**

Chiedere agli studenti di spiegare con parole proprie "perché il miglioramento delle capacità del modello non equivale al miglioramento delle capacità del sistema", indicando almeno due dei tre tipi di confini: stato, obiettivo, feedback. Se lo studente riesce a chiarire la relazione tra capacità del singolo e evoluzione a circuito chiuso, si può passare alla pagina successiva; altrimenti, tornare al diagramma comparativo per riorganizzare i due percorsi, sinistro e destro.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno esprimere la relazione centrale "il grande modello è un componente, il circuito evolutivo è il sistema", si può passare ai contenuti successivi sull'evoluzione continua a livello di sistema, Genesis e la sedimentazione nel mondo del software.

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

### L'estensione dei confini evolutivi dai parametri numerici ai sistemi software

*Pagina 3*

> **Obiettivo della pagina:** Padroneggiare come i grandi modelli estendano l'oggetto dell'evoluzione dai tradizionali parametri numerici a programmi, strutture di modelli e stati di sistema.

> **Obiettivo della pagina**
>
> Padroneggiare come i grandi modelli estendano l'oggetto dell'evoluzione dai tradizionali parametri numerici a programmi, strutture di modelli e stati di sistema, e comprendere le condizioni che spingono questa estensione dei confini e i cambiamenti nella valutazione.

> **Ordine di esposizione**
>
> L'oggetto è tipicamente un vettore di parametri numerici a bassa dimensionalità e predefinito, come iperparametri, pesi, variabili continue; lo spazio di ricerca è limitato da strutture e modalità di codifica preimpostate manualmente.
>
> Con l'ampliamento della scala computazionale e delle fondamenta ingegneristiche, la ricerca su oggetti ad alta dimensionalità, discreti e strutturati passa da irrealizzabile a gestibile, e i confini della ricerca si espandono in sincronia con la potenza di calcolo e la catena di strumenti.
>
> Possedere capacità di comprensione del codice, ragionamento contestuale e generazione di candidati permette di costruire, modificare e valutare direttamente oggetti a livello di programma, riducendo la dipendenza dalla progettazione manuale di codifiche e operatori di mutazione.
>
> Se il metodo di generazione dei candidati rimane fissato manualmente, il sistema ripeterà solo schemi prestabiliti; includere il metodo di generazione dei candidati stesso tra gli oggetti dell'evoluzione, come le strategie di mutazione e le impostazioni dei parametri dell'evoluzione differenziale, è proprio la manifestazione dell'estensione dei confini.
>
> Dal basso verso l'alto: parametri numerici → struttura del modello → meccanismo algoritmico → stato del programma e dell'ingegneria del software; salendo aumentano la dimensionalità dello spazio di ricerca e la complessità semantica; a destra il supporto delle capacità dei grandi modelli; in alto i vincoli di verifica eseguibile e costo ingegneristico.
>
> Più alto è il livello, più forti sono i vincoli semantici e più lunga è la catena di valutazione; i candidati devono essere eseguibili e verificabili; la valutazione di fitness passa da una funzione scalare a un giudizio congiunto su risultati di esecuzione e vincoli ingegneristici.
>
> Questo non sostituisce l'ottimizzazione dei parametri, ma la include in un più ampio ciclo di evoluzione di programmi e sistemi, formando uno spettro continuo dalla regolazione locale dei parametri al miglioramento a livello di sistema.

**Punti chiave della lezione**

- L'ampliamento della scala computazionale porta a confini di ricerca più ampi. I grandi modelli possono comprendere il codice e il contesto e costruire candidati complessi. L'oggetto dell'evoluzione si estende dai parametri numerici allo stato dei programmi e dell'ingegneria del software, passando per strutture di modelli e meccanismi algoritmici. Primo: l'ampliamento della potenza di calcolo e delle fondamenta ingegneristiche; secondo: i grandi modelli possiedono capacità di comprensione del codice, ragionamento contestuale e generazione di candidati.

**Copertura delle parole chiave**

- Parametri numerici, struttura del modello, meccanismo algoritmico, stato del programma e dell'ingegneria del software, confini della ricerca, comprensione del codice, ragionamento contestuale, costruzione di candidati, verifica eseguibile, costo ingegneristico, valutazione di fitness, spettro continuo. Gestione degli esercizi e feedback: i grandi modelli estendono l'oggetto dell'evoluzione dai tradizionali parametri numerici a programmi, strutture di modelli e stati di sistema. Se la risposta è fuori strada, suggerire di tornare prima alla frase concettuale e riprovare. I grandi modelli possono comprendere il codice e il contesto di esecuzione, e sulla base di ciò costruire e modificare candidati complessi a livello di programma
- Le opzioni errate spesso limitano i grandi modelli ai parametri numerici codificati manualmente. La direzione corretta degli esercizi 3, 4 e 5 non è memorizzare, basarsi sulle sensazioni o cambiare simultaneamente tutti i fattori, ma saper spiegare le conclusioni pertinenti con prove o esempi. Nel feedback si può sottolineare: solo sapendo collegarsi ai concetti della pagina e spiegarne le basi si può considerare una vera padronanza. Il team prima regola solo iperparametri numerici come il learning rate, la dimensione del batch e il numero di livelli della rete
- Poi fa leggere al grande modello gli script di addestramento e i log di esecuzione, riscrive direttamente l'implementazione dell'ottimizzatore, la pipeline dei dati e il flusso di controllo dell'algoritmo, e sottopone i candidati all'esecuzione runtime con restituzione delle metriche, per il ciclo successivo di evoluzione a livello di programma. Si può chiedere: qual è il significato centrale? Quali sono le due condizioni che spingono l'estensione? Punti chiave della risposta: l'evoluzione tradizionale ha come oggetto vettori di parametri numerici a bassa dimensionalità, e lo spazio di ricerca è limitato da preimpostazioni manuali
- L'ampliamento della potenza di calcolo e delle fondamenta ingegneristiche rende gestibile la ricerca ad alta dimensionalità, discreta e strutturata
- I grandi modelli possono costruire e riscrivere oggetti a livello di programma, quindi l'oggetto dell'evoluzione si estende strato per strato a strutture di modelli, meccanismi algoritmici e stati di programmi o ingegneria del software. Poi chiedere: come partecipano i grandi modelli alla costruzione e valutazione dei candidati a livello di programma? Punti chiave della risposta: leggere script e contesto di esecuzione, riscrivere l'ottimizzatore o il flusso di controllo per generare candidati eseguibili
- L'esecuzione runtime verifica se sono eseguibili, poi li confronta con vincoli ingegneristici come risorse e budget temporali, e le metriche restituite guidano il ciclo successivo di evoluzione.

**Verifica della comprensione**

Far ripetere agli studenti con parole proprie la catena di estensione dei livelli, completando con le capacità dei grandi modelli a destra e i vincoli di verifica e costo in alto. Si può chiedere: "Perché più alto è il livello, più la valutazione di fitness assomiglia a un giudizio congiunto su risultati di esecuzione e vincoli ingegneristici?" Confermare che gli studenti sappiano indicare motivi come eseguibilità, verificabilità e allungamento della catena di valutazione.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno distinguere la relazione tra ottimizzazione dei parametri ed evoluzione a livello di programma o sistema, si può passare alla pagina successiva sulla collaborazione multi-agente e la sedimentazione tramite verifica.

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

### Le sfide complesse del mondo reale: compromessi multi-obiettivo e mantenimento della diversità

*Pagina 4*

> **Obiettivo della pagina:** Comprendere l'importanza dei complessi obiettivi che si vincolano reciprocamente nei problemi del mondo reale e della conservazione di soluzioni candidate diversificate.

**Punti chiave della lezione**

- Sotto obiettivi multipli non esiste un ordine totale naturale. Di fronte a un insieme di candidati, prima chiedersi "sotto quali preferenze si confrontano", poi parlare di meglio o peggio; altrimenti si rischia di scambiare le preferenze personali per conclusioni oggettive.
- Conservare solo il migliore attuale porta la popolazione a convergenza prematura e collasso dei pattern. Si possono usare meccanismi come la distanza di affollamento, i niche e l'archiviazione esterna, per distribuire i candidati in diverse regioni del fronte e coprire più intervalli di compromesso.
- L'algoritmo si occupa di generare opzioni utilizzabili e differenziate, l'esperto di dominio si occupa di completare valutazione e scelta in base a preferenze e vincoli. Non confondere "generare candidati" con "decidere al posto delle persone".

Obiettivo della pagina

Comprendere l'essenza dei vincoli reciproci tra obiettivi nei problemi del mondo reale, e spiegare perché il sistema debba conservare un insieme di soluzioni candidate differenziate, invece di convergere su un'unica "risposta ottimale".

Ordine di esposizione

I problemi reali raramente hanno una soluzione ottimale unica. Più obiettivi si vincolano reciprocamente, e il miglioramento di un indicatore di solito avviene a costo del peggioramento di altri. Pertanto, il sistema dovrebbe conservare un insieme di soluzioni candidate non dominate e differenziate, rendendo visibili le relazioni di compromesso e lasciando il giudizio decisionale alla persona.

I punti grigi rappresentano soluzioni possibili, i punti colorati rappresentano candidati mutualmente non dominati, che insieme costituiscono il fronte. Nel diagramma A pende verso la robustezza, B è equilibrato, C pende verso l'efficienza, D ha resistenza estremamente bassa. Il fronte di Pareto può solo essere approssimato, non eliminato.

3. Sviluppare quattro conoscenze chiave. Primo, il conflitto tra obiettivi è strutturale, non un problema di regolazione dei parametri: tra obiettivi come rapporto portanza-resistenza, resistenza strutturale, costo e producibilità non esiste un ottimo simultaneo. Secondo, sotto obiettivi multipli non esiste un ordine totale: due soluzioni qualsiasi possono essere mutualmente non dominate, e "il migliore" deve essere definito con una direzione di preferenza allegata; di fronte a un insieme di candidati, prima chiedersi "sotto quali preferenze si confrontano", poi parlare di meglio o peggio. Terzo, il feedback sparso è la norma: la valutazione ingegneristica reale dipende da simulazioni o misurazioni costose, il feedback è scarso, rumoroso, il gradiente non è utilizzabile, e la ricerca a salita su punto singolo difficilmente progredisce in modo efficace; gli algoritmi evolutivi, mantenendo una popolazione, esplorano simultaneamente più direzioni con poche valutazioni.

Perseguire solo il migliore attuale porta la popolazione a convergenza prematura e collasso dei pattern, perdendo infine interi intervalli di compromesso inesplorati; si possono usare meccanismi come la distanza di affollamento, i niche e l'archiviazione esterna, per distribuire i candidati in diverse regioni del fronte.

L'algoritmo si occupa di "generare un insieme di opzioni utilizzabili e differenziate", l'esperto di dominio si occupa di "completare valutazione e scelta in base a preferenze e vincoli". L'insieme di soluzioni candidate non decide al posto delle persone, ma mette sul tavolo opzioni comparabili.

Nella progettazione di profili alari supercritici, l'efficienza aerodinamica, le caratteristiche di divergenza della resistenza, la resistenza strutturale e il costo di produzione si vincolano reciprocamente. Il valore di EvoX non sta nel fornire l'unico "profilo alare ottimale", ma nel produrre una famiglia di profili candidati che coprono diversi intervalli di compromesso, tra cui gli ingegneri possano scegliere in base alle specifiche condizioni di volo e ai vincoli di processo.

Punti chiave della lezione

Definire "il migliore" con una direzione di preferenza; mantenere attivamente la diversità; distinguere generazione e scelta. Sotto obiettivi multipli non esiste un ordine totale naturale, e conservare solo il migliore attuale porta al collasso della popolazione; l'algoritmo genera candidati differenziati, l'esperto completa il giudizio finale in base a preferenze e vincoli. I due piccoli diagrammi a destra mostrano già intuitivamente la differenza tra convergenza su punto singolo e distribuzione diversificata: il primo collassa in un grumo, il secondo si estende in un fronte.

Gestione degli esercizi

L'assenza di un ordine totale significa che la direzione di preferenza deve partecipare alla definizione; il feedback sparso rende difficile il progresso della ricerca su punto singolo perché la valutazione è costosa, rumorosa e il gradiente non è utilizzabile; il valore dei candidati dispersi è lasciare agli esperti il diritto di scelta e la conoscenza del dominio; perseguire solo il migliore attuale porta a convergenza prematura e collasso dei pattern; nella progettazione di profili alari supercritici la posizione di EvoX è produrre una famiglia di profili candidati che coprono diversi intervalli di compromesso. Nel feedback, se lo studente sceglie male, lo si può guidare a tornare alle tre parole chiave "direzione di preferenza", "feedback sparso", "la diversità è un bene".

Guida allo studio del caso

Nello scenario dei taxi aerei urbani si possono identificare conflitti tra autonomia e carico utile, tra rumore ed efficienza aerodinamica, tra ridondanza di sicurezza e costo di produzione. Questi obiettivi si vincolano reciprocamente, quindi non esiste un progetto unico simultaneamente ottimale, ma solo un fronte di Pareto di soluzioni mutualmente non dominate. EvoX può trattare autonomia, carico utile, rumore, ridondanza di sicurezza e costo come obiettivi multipli, eseguire una ricerca di popolazione, e produrre soluzioni candidate distribuite in diverse regioni del fronte e mutualmente non dominate; gli esperti di dominio poi, in base allo scenario operativo, ai vincoli normativi e alle condizioni di processo, sottopongono le soluzioni candidate a simulazioni ad alta fedeltà o misurazioni reali, completando valutazione e scelta finale in base alla direzione di preferenza.

Verifica della comprensione

Chiedere agli studenti di portare con parole proprie un esempio quotidiano di obiettivi multipli, come il compromesso tra prestazioni, prezzo, peso e autonomia nell'acquisto di un portatile, e di rispondere "sotto quali preferenze si confrontano". Se lo studente riesce a spiegare che lo stesso insieme di candidati porta a scelte ragionevoli diverse sotto preferenze diverse, significa che ha compreso il nucleo di questa pagina.

Suggerimento di transizione

Dopo aver confermato che gli studenti sanno distinguere "generare candidati" da "decidere al posto delle persone", si può passare alla pagina successiva sul miglioramento dei metodi di calcolo o dei metodi in generale. Questa pagina risponde a "perché servono compromessi multi-obiettivo e candidati diversificati"; i contenuti successivi risponderanno separatamente a "come calcolare più velocemente" e "come migliorare il metodo stesso".

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

### Calcolo tensoriale e architettura unificata a supporto dell'esplorazione parallela

*Pagina 5*

> **Obiettivo della pagina:** Comprendere come EvoX utilizzi il calcolo tensoriale batch per supportare un'esplorazione evolutiva parallela ad alta intensità.

> **Obiettivo della pagina**
>
> Comprendere come EvoX utilizzi il calcolo tensoriale batch per supportare un'esplorazione evolutiva parallela ad alta intensità, e cogliere le due linee portanti che si sostengono a vicenda: il grafo computazionale tensoriale e l'architettura unificata aperta e disaccoppiata.
>
> Ordine di esposizione suggerito:
>
> Quando la popolazione passa da decine a migliaia di individui, il problema centrale del calcolo evolutivo non è più "si riesce a trovare una buona soluzione", ma "si riesce a valutare abbastanza candidati in tempo finito". La diversità dipende dal throughput; mantenere la diversità è essenzialmente una questione di potenza di calcolo.
>
> Il calcolo tensoriale si occupa di "correre veloce", l'architettura unificata si occupa di "poter cambiare".
>
> Il tradizionale ciclo seriale su CPU esegue "valutazione—registrazione—aggiornamento" individuo per individuo, con tre tipi di costo: alto overhead di scheduling, operatori frammentati, utilizzo insufficiente della GPU; l'approccio tensoriale organizza mantenimento della popolazione, valutazione batch e aggiornamento dello stato in operazioni tensoriali batch, facendo calcolare in parallelo i candidati della stessa generazione o anche di più generazioni. Ad esempio, con N soluzioni candidate, la versione seriale è un ciclo individuo per individuo, quella tensoriale organizza la popolazione in un tensore, completando in una volta sola la valutazione batch e l'aggiornamento parallelo dello stato, riducendo l'overhead di scheduling e aumentando l'occupazione della GPU.
>
> Riscrivere solo il ciclo non basta: se algoritmo, problema e logica di scheduling sono accoppiati, cambiare algoritmo o task richiede una riscrittura. L'architettura unificata disaccoppia algoritmo, problema, workflow e scheduling Runtime, e con la gestione eterogenea delle risorse di calcolo gestisce batch di task su CPU/GPU, rendendo lo stesso meccanismo parallelo riutilizzabile in scenari di evoluzione di metodi come MetaDE e AutoPSO.
>
> A sinistra il ciclo seriale tradizionale su CPU, individuo per individuo, con bassa occupazione GPU; a destra il calcolo tensoriale batch su GPU, tensore della popolazione → valutazione batch → aggiornamento parallelo dello stato; in basso la base unificata aperta e disaccoppiata, comprendente algoritmo, problema, workflow e scheduling Runtime.

**Punti chiave della lezione**

- EvoX non si limita a risolvere problemi, ma include tra gli oggetti dell'evoluzione anche il metodo stesso che produce le soluzioni candidate. In MetaDE l'algoritmo esterno evolve configurazione e strategie dell'algoritmo interno; AutoPSO ed EvoGO combinano ulteriormente componenti e usano il feedback storico per apprendere il modo di generare candidati, passando da "cambiare parametri" a "cambiare la struttura dell'algoritmo". Questo tipo di evoluzione a doppio livello interno-esterno richiede naturalmente che un gran numero di task interni venga valutato in batch e aggiornato nello stato. Ciò che cambia è la forma organizzativa del calcolo: l'intero percorso "popolazione—valutazione—aggiornamento" viene trasformato in operazioni tensoriali batch, senza sostituire un singolo operatore né cambiare la modalità di codifica. Se nel profiling delle prestazioni compaiono "troppi piccoli operatori, bassa occupazione GPU, alta percentuale di scheduling CPU", di solito significa che il sistema è ancora in un ciclo seriale individuo per individuo: questo è il segnale d'ingresso per introdurre il grafo computazionale tensoriale. Fare solo tensorializzazione, cambiare algoritmo o task richiede una riscrittura
- Fare solo architettura unificata, senza parallelismo batch, non si diventa comunque veloci.

**Gestione degli esercizi**

Il cambiamento centrale della tensorializzazione è riscrivere mantenimento della popolazione, valutazione batch e aggiornamento dello stato come operazioni tensoriali batch; i costi principali del tradizionale ciclo seriale su CPU sono alto overhead di scheduling, frammentazione degli operatori e utilizzo insufficiente della GPU; l'architettura unificata aperta e disaccoppiata serve a rendere il meccanismo parallelo riutilizzabile per algoritmi e task diversi; con N candidati della stessa generazione, il vantaggio chiave è completare in una volta sola la valutazione batch e l'aggiornamento parallelo dello stato; la base portata da GPU e grandi modelli eleva il calcolo batch da ottimizzazione locale a capacità fondamentale per l'esplorazione evolutiva a livello di sistema. Il feedback sulle risposte dovrebbe guidare gli studenti a tornare alle due parole chiave "parallelismo batch" e "riutilizzo disaccoppiato", evitando di scegliere per errore opzioni fuorvianti come "comprimere la popolazione", "valutazione approssimata", "workflow fisso".

L'esercizio caso richiede di migrare l'evoluzione differenziale da seriale su singola macchina a base parallela batch. Punti chiave della domanda 1: il ciclo seriale individuo per individuo comporta alto overhead di scheduling, frammentazione degli operatori e utilizzo insufficiente della GPU; la tensorializzazione organizza la popolazione in un tensore, fonde valutazione batch e aggiornamento dello stato, mantenendo invariata la semantica di mutazione, crossover e selezione. Punti chiave della domanda 2: l'architettura unificata si scompone e disaccoppia per livelli: algoritmo, problema, workflow e scheduling Runtime;
il livello algoritmo descrive solo la semantica di generazione e aggiornamento dei candidati, il livello problema incapsula l'interfaccia di valutazione batch, il livello workflow orchestra i task interni ed esterni, il livello di scheduling Runtime gestisce lo scheduling eterogeneo e la gestione batch dei task, rendendo la stessa base riutilizzabile in scenari di evoluzione di metodi come MetaDE e AutoPSO.

**Verifica della comprensione**

Si può far spiegare agli studenti con parole proprie "cosa risolve il grafo computazionale tensoriale e cosa risolve l'architettura unificata", portando esempi del perché i due debbano collaborare.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno distinguere "correre veloce" da "poter cambiare", si può passare alla pagina successiva sui casi specifici o i meccanismi ingegneristici dell'evoluzione continua a livello di sistema.

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

### L'evoluzione dell'algoritmo stesso: dalla soluzione alla modifica del metodo

*Pagina 6*

> **Obiettivo della pagina:** Comprendere il principio fondamentale di includere il metodo di generazione dei candidati stesso tra gli oggetti dell'ottimizzazione per realizzare l'auto-evoluzione dell'algoritmo.

**Punti chiave della lezione**

- Il livello interno cerca la risposta, il livello esterno modifica il metodo. Vedere "strategie, parametri, operatori, componenti inseriti nella ricerca" significa evoluzione del metodo; vedere "solo le soluzioni candidate cambiano, le regole di generazione restano sempre invariate" significa algoritmo evolutivo tradizionale.
- Il segnale di preferenza entra prima nella valutazione delle risposte, poi passa per aggregazione cross-task e verifica di stabilità, e solo allora può entrare nella selezione dei metodi. Saltando questo passo, il livello esterno inseguirà un risultato gradevole ma non riproducibile.
- Quanto è grande lo spazio dei metodi? Quanti task interni eseguire per ogni ciclo? Con quale insieme di task indipendenti verificare che il miglioramento esterno generalizzi davvero? Se questi tre conti non sono chiari, la ricerca a doppio livello degenera facilmente in una regolazione casuale dei parametri più costosa.

Obiettivo della pagina

Gli algoritmi evolutivi tradizionali cercano sotto un meccanismo di generazione fisso, e ciò che viene ottimizzato è sempre la soluzione candidata; l'evoluzione dei metodi include tra gli oggetti della ricerca anche il metodo stesso che produce le soluzioni candidate, completando l'evoluzione da "risolvere la risposta" a "migliorare il metodo".

Ordine di esposizione

1. Confrontare prima la differenza tra algoritmo evolutivo tradizionale ed evoluzione dei metodi, chiarendo che "l'oggetto ottimizzato" si è spostato.

2. Introdurre la definizione di evoluzione dei metodi, spiegando che EvoX procede lungo questa linea, includendo tra gli oggetti dell'evoluzione il metodo stesso di generazione dei candidati.

Il livello interno cerca la risposta, il livello esterno modifica il metodo.

4. Individuare a quale livello va collocata l'ottimizzazione delle preferenze, sottolineando che i due tipi di obiettivi non vanno confusi.

5. Portare MetaDE, AutoPSO ed EvoGO come forme tipiche.

6. Concludere su benefici e costi, e gestire esercizi e casi.

Punti chiave della lezione

Regole come selezione, crossover e mutazione — "come si producono le risposte" — sono scritte in anticipo dall'uomo, e la ricerca si muove solo nello spazio delle risposte. Con l'ampliarsi della scala computazionale, il meccanismo di generazione fisso diventa invece il tetto.

L'algoritmo non produce solo risposte migliori, ma attraverso la ricerca esterna migliora continuamente strategie, parametri e componenti che producono le risposte. EvoX è un lavoro su questa linea, ad esempio includendo tra gli oggetti dell'evoluzione la strategia di mutazione e le impostazioni dei parametri dell'evoluzione differenziale.

Il livello interno usa il metodo corrente per risolvere il problema specifico, producendo soluzioni candidate; il livello esterno, in base a feedback come qualità delle soluzioni, segnali di preferenza, stabilità o costo, confronta, seleziona e aggiorna il metodo da usare nel ciclo successivo. Ciò che viene spostato nello spazio di ricerca non è una soluzione, ma il meccanismo di generazione dei candidati stesso, che diventa quindi un oggetto valutabile, selezionabile e aggiornabile.

Il livello superiore è "il metodo che evolve le soluzioni candidate", comprendente strategie/parametri/componenti operatori, ricerca evolutiva esterna e metodo di generazione migliorato; il livello inferiore è "la risoluzione del problema specifico", comprendente metodo corrente, soluzioni candidate e valutazione della qualità delle soluzioni. I due circuiti rappresentano rispettivamente il risultato esterno che ritorna al livello interno, e la qualità delle soluzioni/preferenze/costi che guidano entrambi i livelli. Alla lavagna si possono disegnare prima i due livelli superiore e inferiore, poi con frecce indicare "aggiornare il metodo di generazione" e "segnale di feedback".

Può partecipare al feedback del livello superiore, ma bisogna separare "valutare la risposta attuale" da "migliorare il metodo che genera le risposte". Leggere "questa soluzione è più gradevole" direttamente come "questa strategia è migliore" significa spacciare la preferenza per la risposta come giudizio sul metodo, e il livello esterno verrà trascinato dal rumore di un singolo risultato. Il segnale di preferenza entra prima nella valutazione delle risposte, poi passa per aggregazione cross-task e verifica di stabilità, e solo allora può entrare nella selezione dei metodi.

MetaDE fa evolvere al livello esterno la strategia di mutazione e i parametri dell'evoluzione differenziale, mentre il livello interno risolve normalmente il task; AutoPSO ed EvoGO combinano ulteriormente componenti dello sciame particellare e usano il feedback storico per apprendere il modo di generare candidati, realizzando il passaggio da "cambiare parametri" a "cambiare la struttura dell'algoritmo".

Il beneficio è spingere la progettazione dell'algoritmo da una regolazione manuale una tantum verso un'adattività sostenibile. I costi sono tre: espansione dello spazio di ricerca, perché lo spazio dei metodi è molto più grande di quello delle soluzioni; aumento del costo di valutazione, perché ogni insieme di metodi candidati deve eseguire task interni, di solito dipendendo da valutazione batch parallela su GPU per essere ammortizzato; aumento della complessità di verifica, perché per sapere se il miglioramento esterno generalizza davvero serve un progetto di verifica indipendente.

Indizi per gli esercizi e guida alle risposte

1. Rispetto a un algoritmo evolutivo tradizionale, qual è la differenza più essenziale dell'evoluzione dei metodi rispetto a "l'oggetto ottimizzato"? La direzione corretta è: inserire tra gli oggetti della ricerca anche strategie, parametri e componenti operatori che definiscono "come si producono le risposte". Se lo studente sceglie "popolazione più grande" o "eliminare la valutazione di fitness", suggerire di tornare allo spostamento dell'oggetto dell'ottimizzazione: ciò che viene ottimizzato non è più solo la risposta, ma il meccanismo che la produce.

Qualità delle soluzioni, segnali di preferenza, stabilità o costo: feedback proveniente dalla prestazione dei task interni. Se lo studente sceglie per errore "rumore casuale" o "specificato manualmente dall'ingegnere", guidarlo a chiedersi: in base a cosa il livello esterno giudica che una strategia è migliore di un'altra? Quel "in base a cosa" è il segnale di feedback.

Far partecipare il segnale di preferenza al feedback del livello superiore, ma trattare "valutare la risposta attuale" e "migliorare il metodo di generazione" come due tipi di obiettivi separati. Se lo studente prende la preferenza per la risposta come giudizio diretto sul metodo, ricordargli: la preferenza deve passare per aggregazione cross-task e verifica di stabilità per passare da "preferenza per la risposta" a "criterio sul metodo".

Espansione dello spazio dei metodi, costo di valutazione interna per ogni metodo, e aumento della difficoltà di verifica. Si può riassumere in una tripla pressione: spazio, potenza di calcolo, verifica; l'evoluzione dei metodi alza di un livello l'oggetto della ricerca, e il costo si alza di conseguenza.

5. Quale affermazione su MetaDE e AutoPSO è corretta? La direzione corretta è: MetaDE usa il livello esterno per evolvere la strategia di mutazione e i parametri dell'evoluzione differenziale, mentre il livello interno si occupa ancora della risoluzione dei candidati per il task specifico. AutoPSO ed EvoGO vanno oltre verso la combinazione di componenti e il miglioramento strutturale, con direzione da cambiare parametri a cambiare struttura.

Gestione del caso

Lo scenario è un team che ottimizza il layout di un chip su un cluster GPU; esiste già un solutore a evoluzione differenziale, ma strategia di mutazione e parametri dipendono dall'esperienza manuale, con fluttuazioni di prestazioni evidenti, e si prevede di introdurre un'ottimizzazione a doppio livello tipo MetaDE, guidando la ricerca con le preferenze dell'utente.

L'input del livello interno è il metodo corrente (strategia di mutazione e configurazione dei parametri) e un'istanza concreta del problema di layout; l'output è il layout candidato e la sua qualità. L'input del livello esterno è la statistica aggregata della prestazione dei task interni; l'output è la strategia e la configurazione dei parametri aggiornate. Il segnale di feedback deve essere aggregato su task e ripetizioni diverse, ad esempio media multi-task, quantili o indicatori di stabilità, e non può provenire da una singola esecuzione. Il motivo è che la bontà di una singola soluzione dipende fortemente dall'istanza specifica e dalla casualità; essa misura "se questa risposta è buona", non "se questo metodo è buono"; usare direttamente un singolo risultato per guidare il livello esterno farebbe dominare il livello esterno dalle differenze tra istanze e dal rumore.

Il livello interno può usare una funzione di valutazione ponderata per preferenze per selezionare i layout candidati; il livello esterno deve prima trasformarla in un criterio di confronto stabile cross-task, ad esempio un punteggio ponderato di lunghezza dei fili e congestione con la sua varianza, e poi usarlo per scegliere la configurazione del metodo, evitando di prendere una preferenza per una singola risposta come giudizio sul metodo.

L'espansione dello spazio di ricerca può essere controllata con raggruppamento dei parametri, ricerca gerarchica, prima grossolana poi fine; l'aumento del costo di valutazione può essere ridotto con valutazione batch parallela su GPU, valutazione surrogata su pochi campioni e meccanismi di early stopping; l'aumento della complessità di verifica richiede di conservare un insieme di task di verifica indipendente e ripetere le esecuzioni, per controllare se il miglioramento esterno generalizza davvero.

Verifica della comprensione e transizione

Il livello interno cerca la risposta, il livello esterno modifica il metodo. Vedere "strategie, parametri, operatori, componenti inseriti nella ricerca" significa evoluzione del metodo; vedere "solo le soluzioni candidate cambiano, le regole di generazione restano sempre invariate" significa algoritmo evolutivo tradizionale. Dopo aver confermato che gli studenti sanno spiegare "l'oggetto ottimizzato è cambiato" e "la preferenza non può direttamente spacciarsi per giudizio sul metodo", si può passare alla pagina successiva con esempi, applicazioni o riepilogo.

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

### MetaDE e AutoPSO: l'architettura a doppio livello dell'evoluzione dei metodi

*Pagina 7*

> **Obiettivo della pagina:** Padroneggiare come MetaDE e AutoPSO realizzino l'auto-evoluzione di varianti algoritmiche e parametri attraverso l'ottimizzazione a doppio livello interno-esterno.

> **Obiettivo della pagina**
>
> Comprendere come MetaDE e AutoPSO realizzino l'auto-evoluzione di configurazioni e strutture algoritmiche attraverso un'architettura di ottimizzazione a doppio livello interno-esterno, e padroneggiarne la struttura dei costi e i compromessi ingegneristici.

> **Ordine di esposizione**
>
> L'algoritmo non si limita più a trovare soluzioni, ma deve migliorare "come trova le soluzioni esso stesso".
>
> 2. Mostrare l'astrazione generale dell'architettura a doppio livello, sottolineando che il livello esterno cerca nello spazio degli algoritmi, il livello interno risolve il task obiettivo, e la prestazione interna ritorna come segnale di fitness formando un circuito chiuso.
>
> 3. Spiegare separatamente le due linee di implementazione, MetaDE e AutoPSO, mostrando che la prima gestisce il livello di configurazione e la seconda il livello di struttura/componenti.
>
> 4. Analizzare l'effetto moltiplicativo del costo dell'ottimizzazione a doppio livello, introducendo compromessi ingegneristici come allocazione del budget, valutazione approssimata, early stopping e parallelizzazione.
>
> Passare dalla progettazione manuale di un singolo algoritmo alla progettazione di uno spazio algoritmico evolvibile e di un meccanismo di valutazione.

**Punti chiave della lezione**

- L'evoluzione dei metodi (Meta-Evolution) prende come oggetto di ottimizzazione il "metodo che produce i candidati". Il livello esterno cerca configurazioni algoritmiche, combinazioni di componenti o strategie, non soluzioni del task. Il livello esterno si occupa di cercare nello spazio degli algoritmi (iperparametri, strategie, combinazioni di componenti, ovvero "la definizione dell'algoritmo")
- Il livello interno usa l'algoritmo candidato per risolvere davvero il task obiettivo, ottenendo una prestazione misurabile
- La prestazione interna viene aggregata in fitness e restituita al livello esterno, che elimina le configurazioni scadenti, conserva e muta quelle buone, formando un circuito di miglioramento continuo. Si conserva l'evoluzione differenziale come solutore interno, affidando al livello esterno la ricerca della configurazione di DE — strategia di mutazione, tasso di crossover, fattore di scala — che si adatta in base a problema e fase di ottimizzazione. Risponde a "come va impostata questa configurazione nella fase attuale del task", ed è evoluzione dei metodi a livello di configurazione. Trattare i parametri chiave e i meccanismi di apprendimento di PSO come componenti combinabili — peso d'inerzia, fattori di apprendimento e diverse combinazioni di apprendimento individuale e di gruppo — con il livello esterno che cerca e combina automaticamente varianti PSO adatte a problemi diversi. Trasforma "scegliere l'algoritmo" in "cercare la struttura dell'algoritmo", realizzando il passaggio dall'adattività dei parametri all'auto-generazione dei meccanismi. MetaDE tende all'auto-tuning di configurazione e iperparametri, AutoPSO alla auto-combinazione di struttura e componenti, coprendo insieme l'intervallo evolutivo dall'adattività dei parametri all'auto-generazione dei meccanismi. Il costo chiave dell'ottimizzazione a doppio livello sta nell'effetto moltiplicativo — ogni valutazione esterna di un algoritmo candidato spesso richiede più esecuzioni interne (valutazione ripetuta per casualità, verifica congiunta multi-task, ecc.), e il budget computazionale viene notevolmente amplificato. Il calcolo effettivo è circa "numero di algoritmi candidati esterni × numero di esecuzioni interne per candidato". Allocazione del budget, valutazione approssimata, early stopping, parallelizzazione. Un'esecuzione efficiente dipende da parallelismo tensoriale, scheduling Runtime e componibilità degli algoritmi
- La parallelizzazione può alleviare il tempo wall-clock, ma non riduce il calcolo totale. Il ricercatore non consegna più un algoritmo fisso, ma uno spazio di ricerca e regole di feedback che permettono all'algoritmo di migliorarsi continuamente.

**Verifica della comprensione**

Si può chiedere in sequenza, fornendo i punti chiave delle risposte:

1. Qual è l'oggetto diretto della ricerca del livello esterno?

Configurazioni, strutture e combinazioni di componenti dell'algoritmo stesso. L'essenza dell'evoluzione dei metodi è prendere l'algoritmo stesso come oggetto di ottimizzazione; il livello esterno cerca configurazioni e strutture nello spazio degli algoritmi, non direttamente soluzioni del task. Attenzione a distinguere i due livelli: il livello interno cerca direttamente le soluzioni; il livello esterno cerca "quale algoritmo usare e come configurarlo".

2. In MetaDE, quale insieme di oggetti evolve principalmente il livello esterno?

Strategia di mutazione, tasso di crossover e fattore di scala dell'evoluzione differenziale. MetaDE fa adattare la configurazione di DE a problema e fase; è evoluzione dei metodi a livello di configurazione/iperparametri, non struttura di altri algoritmi.

3. Quale descrizione del分工 tra AutoPSO e MetaDE è più accurata?

AutoPSO si concentra sulla auto-combinazione di parametri e meccanismi di apprendimento, trasformando "scegliere l'algoritmo" in "cercare la struttura dell'algoritmo"; MetaDE si concentra sull'evoluzione a livello di configurazione. I due sono complementari: MetaDE copre configurazione e iperparametri, AutoPSO copre struttura e componenti, insieme costituiscono l'intervallo evolutivo dall'adattività dei parametri all'auto-generazione dei meccanismi, e entrambi devono passare per la valutazione interna.

4. Quale affermazione sulla struttura dei costi dell'ottimizzazione a doppio livello è corretta?

Ogni valutazione esterna di un algoritmo candidato spesso richiede più esecuzioni interne, e il budget viene notevolmente amplificato, richiedendo allocazione del budget, valutazione approssimata o early stopping. Il costo principale dell'architettura a doppio livello è l'effetto moltiplicativo; la parallelizzazione può solo alleviare, non eliminare il costo totale.

5. Dopo l'adozione dell'architettura a doppio livello dell'evoluzione dei metodi, qual è il cambiamento cognitivo del ruolo del ricercatore?

Passare dalla progettazione manuale di un singolo algoritmo alla progettazione di uno spazio in cui l'algoritmo può essere evoluto e di meccanismi di valutazione. Non si consegna più un algoritmo fisso, ma "uno spazio algoritmico evolvibile + regole di valutazione della fitness"; ricerca esterna e risoluzione interna formano così un circuito di miglioramento continuo. Sebbene non si fissi più manualmente un singolo algoritmo, il lavoro centrale diventa progettare spazio di ricerca e meccanismo di valutazione, e la responsabilità è anzi maggiore.

**Gestione degli esercizi**

Il caso "costruire un servizio di evoluzione a doppio livello per task in continuo cambiamento" può essere usato dopo aver spiegato architettura e costi, facendo rispondere prima individualmente e poi discutendo collettivamente.

Si spieghi cosa fanno rispettivamente livello interno ed esterno, e come fluisce il segnale.

Il livello esterno cerca algoritmi candidati nello spazio degli algoritmi — può evolvere strategia di mutazione, tasso di crossover, fattore di scala di DE (percorso MetaDE), oppure combinare automaticamente componenti come peso d'inerzia, fattori di apprendimento e meccanismi di apprendimento di PSO (percorso AutoPSO). Il livello interno esegue e valuta ogni algoritmo candidato sul task obiettivo del giorno, producendo una prestazione comparabile; la prestazione interna viene aggregata in fitness e restituita al livello esterno, che su questa base elimina i candidati scadenti, conserva e muta le configurazioni buone, iterando continuamente, formando il circuito "il livello esterno cerca nello spazio degli algoritmi, il livello interno risolve il task obiettivo, il feedback di prestazione guida il miglioramento".

Di fronte alla pressione di budget "una valutazione esterna richiede più esecuzioni interne", fornire almeno due misure di compromesso e spiegarne costo o rischio.

① Allocazione del budget — fissare quote di calcolo separate per livello esterno e interno e limitare le ripetizioni interne; il costo è l'aumento della varianza di valutazione e la possibile scelta errata; ② valutazione approssimata — stimare la fitness con sottoinsiemi di dati o esecuzioni brevi; il costo è un segnale molto rumoroso e la possibile sottostima dei candidati migliori; ③ early stopping — terminare in anticipo le esecuzioni interne per candidati chiaramente scadenti; il costo è la possibile eliminazione prematura di configurazioni lente a maturare ma buone in seguito; ④ parallelismo tensoriale e scheduling Runtime — esecuzioni interne concorrenti in batch, che alleviano significativamente il tempo wall-clock ma non riducono il calcolo totale, e sono limitate da memoria e overhead di scheduling. La risposta deve chiarire la corrispondenza tra ciascuna misura e il suo costo o rischio, e riflettere la stima moltiplicativa "scala della ricerca esterna × numero di esecuzioni interne per volta".

Linguaggio di feedback:

Corretto. Questa risposta sa collegarsi ai concetti della pagina e spiegarne le basi.

Tornare alla spiegazione di questa pagina, trovare prove o esempi chiave e poi giudicare.

Attenzione a distinguere i "livelli" — il livello interno cerca direttamente le soluzioni, il livello esterno cerca "quale algoritmo usare e come configurarlo"; l'oggetto di MetaDE è la configurazione dell'evoluzione differenziale stessa, non la struttura di altri algoritmi; il costo principale dell'architettura a doppio livello è l'effetto moltiplicativo, e la parallelizzazione può solo alleviare, non eliminare il costo totale; sebbene non si fissi più manualmente un singolo algoritmo, il lavoro centrale del ricercatore diventa progettare spazio di ricerca e meccanismo di valutazione, e la responsabilità è anzi maggiore.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno distinguere con parole proprie "evoluzione a livello di configurazione" ed "evoluzione a livello di struttura/componenti", e sanno esprimere il circuito dei segnali interno-esterno e l'effetto moltiplicativo del budget, si può passare alla pagina successiva con esempi, applicazioni o riepilogo.

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

### Caso pratico multi-obiettivo nella progettazione di profili alari supercritici

*Pagina 8*

> **Obiettivo della pagina:** Apprendere come utilizzare EvoX per gestire vincoli ingegneristici complessi e generare soluzioni di compromesso diversificate nella progettazione di profili alari.

> **Obiettivo della pagina**
>
> Comprendere perché la progettazione di profili alari supercritici sia un problema multi-obiettivo, e padroneggiare come usare EvoX per generare soluzioni di compromesso diversificate sotto rigorosi vincoli ingegneristici.

> **Ordine di esposizione**
>
> La progettazione di profili alari supercritici è una pratica multi-obiettivo di EvoX nell'ingegneria reale. Parametri geometrici come curvatura, spessore e bordo di uscita del profilo sono accoppiati tra loro, e modificare la geometria influenza simultaneamente più indicatori aerodinamici.
>
> Migliorare un indicatore spesso avviene a costo di un altro, quindi non si può trattare come ottimizzazione a obiettivo singolo, ma serve un compromesso multi-obiettivo.
>
> Requisiti come portanza, angolo di attacco e spessore delimitano il dominio di progetto fattibile, e la ricerca deve svolgersi nel rispetto dei vincoli, per garantire che le soluzioni candidate siano ingegneristicamente utilizzabili.
>
> EvoX genera un insieme diversificato di soluzioni candidate che bilanciano i vari indicatori, non l'unica soluzione ottimale; l'insieme di candidate serve agli esperti di dominio per confrontare benefici e costi diversi e fare le scelte.
>
> Questo caso trasforma un problema reale complesso in un processo esplorabile e valutabile, cercando soluzioni di compromesso interpretabili tra vincoli e conflitti di obiettivi.

**Punti chiave della lezione**

- Le variazioni geometriche del profilo alare supercritico influenzano più indicatori aerodinamici, e gli obiettivi spesso confliggono, richiedendo compromessi multi-obiettivo. La progettazione deve soddisfare molteplici vincoli rigorosi come portanza, angolo di attacco e spessore; la ricerca deve svolgersi nel dominio di progetto fattibile. Generare soluzioni candidate diversificate, aiutando gli esperti a valutare benefici e costi diversi e fare scelte. Prima esplorare continuamente nello spazio dei parametri del profilo (curvatura, spessore, bordo di uscita), poi avvicinarsi al fronte di compromesso multi-obiettivo (indicatore A e indicatore B), formando infine un insieme di soluzioni candidate. Profilo alare supercritico, compromesso multi-obiettivo, dominio di progetto fattibile, insieme di soluzioni candidate, EvoX.

> **Indizi per gli esercizi**
>
> - Radice del problema multi-obiettivo, ruolo dei vincoli, output pratico di EvoX, significato dei candidati diversificati, valore del metodo. La comprensione corretta deve centrarsi su: i parametri geometrici influenzano simultaneamente più indicatori causando conflitti tra obiettivi
> - i vincoli delimitano il dominio di progetto fattibile
> - l'output è un insieme diversificato di soluzioni candidate
> - candidati diversi rappresentano benefici e costi diversi
> - il valore del metodo sta nel trasformare un problema reale complesso in un processo esplorabile e valutabile.

**Gestione degli esercizi**

Se lo studente sceglie per errore "ottimizzare solo la portanza" o "cercare l'unica soluzione ottimale", suggerire di tornare all'accoppiamento dei parametri geometrici e ai conflitti tra obiettivi.

Se lo studente sceglie per errore "i vincoli possono essere allentati a piacere" o "non hanno a che fare con l'utilizzabilità ingegneristica", ricordare che i vincoli definiscono il dominio di progetto fattibile e non possono essere allentati arbitrariamente.

Se lo studente sceglie per errore "un singolo profilo alare ottimale" o "geometria casuale", suggerire che l'output dovrebbe essere un insieme diversificato di soluzioni candidate che bilanciano i vari indicatori.

Corretto, questa risposta sa collegarsi ai concetti della pagina e spiegarne le basi.

Tornare alla spiegazione di questa pagina, trovare prove o esempi chiave e poi giudicare.

**Attività in classe**

Poiché le variazioni dei parametri geometrici influenzano simultaneamente più indicatori aerodinamici, e migliorare un indicatore spesso avviene a costo di un altro, serve un compromesso multi-obiettivo; i vincoli delimitano il dominio di progetto fattibile, garantendo che le soluzioni candidate siano ingegneristicamente utilizzabili.

**Verifica della comprensione**

Come EvoX, nella progettazione di profili alari supercritici, generi sotto vincoli rigorosi un insieme diversificato di soluzioni candidate, per l'esperto che ne valuta benefici e costi. L'insegnante integra le parole chiave mancanti in base alla risposta: conflitto tra obiettivi, dominio di progetto fattibile, insieme di soluzioni candidate, compromesso multi-obiettivo.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno distinguere ottimizzazione a obiettivo singolo e compromesso multi-obiettivo, e sanno spiegare l'uso dell'insieme di soluzioni candidate, si può passare alla pagina successiva con esempi, applicazioni o riepilogo.

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

### La sfida del ciclo di vita: esaurimento del contesto e persistenza a livello di progetto

*Pagina 9*

> **Obiettivo della pagina:** Comprendere la contraddizione tra i limiti di contesto dei grandi modelli e i progetti ingegneristici reali che durano mesi o anni.

**Punti chiave della lezione**

- Il contesto singolo è il banco di lavoro, il repository del progetto è la memoria a lungo termine. Non lasciare stato della popolazione, configurazioni fallite e motivazioni delle decisioni solo nella finestra di sessione; prima della chiusura, scriverli in artefatti a livello di progetto, e nella sessione successiva leggerli prima di continuare.
- La persistenza ereditabile richiede che gli artefatti siano versionabili, ricercabili, interpretabili: codice, test, registrazioni sperimentali, log delle decisioni, indicatori di valutazione e conclusioni di accettazione devono poter rispondere a perché è stato scelto così, cosa ha già fallito, quali conflitti restano aperti.
- L'Agent di livello superiore decompone gli obiettivi, quello di livello inferiore implementa e testa. Prima di ogni chiusura di sessione impostare un checkpoint: aggiornare log delle decisioni e indicatori di valutazione; all'avvio della nuova sessione ereditare prima il checkpoint, poi decidere le azioni locali, attraversando più cicli di vita limitati.

> **Obiettivo della pagina**
>
> Comprendere la contraddizione tra i limiti di contesto di un Agent basato su grandi modelli e progetti ingegneristici reali che durano mesi o anni, stabilendo la necessità della persistenza a livello di progetto. Giudizio centrale: la finestra di contesto di una singola sessione C_max è una risorsa limitata, e il ciclo di vita del progetto T_progetto può durare mesi o anni, quindi T_progetto ≫ C_max. La vera difficoltà non è l'insufficienza della singola inferenza, ma il fatto che l'esperienza non può attraversare il ciclo di vita dell'Agent.
>
> Ordine di esposizione
>
> Il contesto di un singolo Agent può contenere solo l'obiettivo corrente, osservazioni locali e ragionamenti recenti; alla chiusura della sessione lo stato viene azzerato, e conclusioni ed esperienze temporanee non sono più disponibili. Senza persistenza, le sessioni successive possono solo riesplorare.
>
> Persistenza a livello di progetto. Esteriorizzare configurazioni fallite, processi di compromesso, soluzioni candidate e conclusioni di accettazione in artefatti persistenti a livello di progetto, compresi codice, test, registrazioni sperimentali, log delle decisioni, indicatori di valutazione e conclusioni di accettazione. Gli Agent successivi non devono ripartire da zero, ma leggono l'esperienza precedente, giudicando quali direzioni sono già state verificate, quali conflitti restano aperti, quali indicatori sono già stati raggiunti.
>
> L'oggetto dell'evoluzione non è più solo un parametro numerico singolo o una soluzione candidata, ma un mondo software persistente, versionabile ed ereditabile. Ogni sessione produce nuovi artefatti che cambiano lo stato di questo mondo; la sessione successiva continua a evolversi sul mondo aggiornato, e così il processo di ottimizzazione diventa evoluzione continua a livello di progetto.
>
> Più Agent dal ciclo di vita limitato possono lavorare insieme: gli esecutori di livello superiore comprendono l'obiettivo e decompongono i task, quelli di livello inferiore completano implementazione e test locali, continuando ricorsivamente la scomposizione se necessario. Prima della chiusura si scrivono gli stati chiave; all'avvio del nuovo Agent si legge prima la memoria del progetto, poi si decidono le azioni locali.
>
> I progetti a lungo termine spesso hanno conflitti tra obiettivi, ad esempio prestazioni, costo e robustezza difficilmente ottimali simultaneamente; anche il feedback può essere sparso, con un esperimento che richiede ore o giorni. Log delle decisioni e indicatori di valutazione persistenti possono trasformare il feedback sparso in esperienza ereditabile, evitando che gli Agent successivi ripetano gli stessi errori.
>
> Punti chiave della lezione
>
> Il contesto singolo è il banco di lavoro, il repository del progetto è la memoria a lungo termine. Non lasciare stato della popolazione, configurazioni fallite e motivazioni delle decisioni solo nella finestra di sessione; prima della chiusura, scriverli in artefatti a livello di progetto, e nella sessione successiva leggerli prima di continuare.
>
> La persistenza non è accumulo di log. La persistenza ereditabile richiede che gli artefatti siano versionabili, ricercabili, interpretabili: codice, test, registrazioni sperimentali, log delle decisioni, indicatori di valutazione e conclusioni di accettazione devono poter rispondere a perché è stato scelto così, cosa ha già fallito, quali conflitti restano aperti.
>
> Prima della fine di ogni sessione aggiornare log delle decisioni e indicatori di valutazione; all'avvio della nuova sessione ereditare prima il checkpoint, poi decidere le azioni locali, attraversando più cicli di vita limitati.
>
> Evoluzione continua a livello di progetto, ovvero trasferire il processo di generazione dei candidati, valutazione dei candidati, registrazione dei compromessi e delle conclusioni di accettazione dal contesto di un singolo Agent ad artefatti persistenti a livello di progetto, facendo iterare il progetto attraverso più cicli di vita dell'Agent.
>
> Indizi per gli esercizi
>
> Si dovrebbe scegliere "la finestra di contesto è limitata, e alla chiusura della sessione stato ed esperienza non sono più affidabili". Nel feedback sottolineare: il confine duro è la lunghezza limitata e l'azzeramento dello stato alla chiusura della sessione, non la scala dei parametri, il grado di parallelismo o la funzione obiettivo.
>
> Si dovrebbe scegliere "codice, test, registrazioni sperimentali, log delle decisioni, indicatori di valutazione e conclusioni di accettazione". Nel feedback spiegare che questi artefatti insieme costituiscono la memoria del progetto.
>
> Si dovrebbe scegliere "dall'estensione da parametri numerici/soluzioni candidate singole a un mondo software persistente, versionabile ed ereditabile". Nel feedback distinguere il cambiamento di paradigma di addestramento dal cambiamento dei confini dell'oggetto dell'evoluzione.
>
> Si dovrebbe scegliere "il livello superiore comprende l'obiettivo e decompone i task, il livello inferiore completa implementazione e test locali, ricorrendo alla scomposizione ricorsiva quando necessario". Nel feedback sottolineare che la continuità cross-ciclo è garantita dalla persistenza a livello di progetto.
>
> Si dovrebbe scegliere "alla chiusura di ogni sessione stato della popolazione, configurazioni fallite e motivazioni delle decisioni vanno persi, e gli Agent successivi riesplorano". Nel feedback spiegare che la mancanza di persistenza non risolve automaticamente i conflitti tra obiettivi né amplia il contesto.
>
> Quando corretto si può riconoscere "sa collegarsi ai concetti della pagina e spiegarne le basi"; quando errato si chiede allo studente di tornare alla spiegazione della pagina, trovare prove o esempi chiave e poi giudicare.
>
> Gestione degli esercizi
>
> Gli obiettivi includono efficienza aerodinamica, resistenza strutturale e costo di produzione, i tre confliggono, il feedback delle simulazioni è sparso, e il team spera in una collaborazione continua di più Agent a ciclo di vita breve. La prima domanda chiede perché non si possa mettere la memoria del progetto solo nel contesto singolo, e di elencare almeno tre tipi di artefatti da rendere persistenti. Punti chiave della risposta: la finestra di contesto singola è limitata e alla chiusura della sessione lo stato viene azzerato, mentre il progetto dura mesi, T_progetto ≫ C_max; affidarsi solo al contesto singolo fa perdere stato della popolazione, risultati delle simulazioni, configurazioni fallite, conflitti tra indicatori e motivazioni delle decisioni; vanno resi persistenti almeno codice e script di addestramento dei modelli surrogati, registrazioni di test e indicatori di valutazione, registrazioni sperimentali e configurazioni fallite, log delle decisioni e motivazioni dei compromessi, soluzioni candidate e conclusioni di accettazione.
>
> All'avvio della sessione si leggono prima log delle decisioni, indicatori di valutazione, registrazioni sperimentali e soluzioni candidate, ripristinando stato della popolazione e conflitti irrisolti; durante la sessione si scrivono nuovi modelli surrogati, risultati di simulazione, valutazioni dei candidati e analisi dei compromessi; prima della chiusura si aggiorna il log delle decisioni, registrando configurazioni fallite del ciclo, conflitti tra indicatori, motivi di scarto e suggerimenti per il passo successivo, con commit versionato; le sessioni successive, leggendo questi artefatti, ereditano configurazioni fallite e motivazioni delle decisioni, evitando riesplorazioni.

**Verifica della comprensione**

Chiedere agli studenti di riassumere con parole proprie "perché la memoria del progetto non può essere conservata solo nel contesto di un singolo Agent", indicando almeno tre tipi di oggetti persistenti a livello di progetto. Suggerimento di transizione: dopo aver confermato che gli studenti sanno esprimere la relazione centrale di questa pagina — T_progetto ≫ C_max, la persistenza a livello di progetto esteriorizza l'esperienza in un mondo software ereditabile — si può passare alla pagina successiva con esempi, applicazioni o riepilogo.

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

### L'architettura Genesis e il paradigma di sedimentazione nel mondo del software

*Pagina 10*

> **Obiettivo della pagina:** Padroneggiare come Genesis permetta al codice del progetto di accumularsi ed evolversi continuamente lungo il ciclo di vita.

> **Obiettivo della pagina**
>
> Aiutare gli studenti a comprendere come Genesis riancori l'intelligenza dal processo di sessione volatile a un mondo software accumulabile, permettendo a codice e risultati ingegneristici del progetto di accumularsi, evolversi ed essere ereditati attraverso singole finestre di contesto e singoli cicli di vita.

> **Ordine di esposizione**
>
> Presentare prima il criterio di giudizio "la sessione è volatile, il repository è la memoria a lungo termine", poi svolgere in sequenza la differenza essenziale del paradigma di sedimentazione, la divisione dei quattro tipi di beni sedimentabili, la premessa dell'interfaccia stabile, il circuito di sedimentazione e la funzione di guardiano dell'accettazione, l'ereditarietà cross-ciclo, e infine chiarire in una frase il confine di divisione tra EvoX e Genesis.

**Punti chiave della lezione**

- 1. Per giudicare se un lavoro ha valore di sedimentazione, basta una domanda: la prossima persona può riprodurlo senza venire a chiedere nulla? Se no, non è ancora diventato un bene. I flussi di lavoro conversazionali evaporano con la fine del contesto, e i risultati restano in "questa sessione"
- il mondo del software, con repository, versioni e artefatti come mezzo, possiede naturalmente accumulabilità. Genesis formalizza proprio questo mezzo come strato di memoria a lungo termine del sistema evolutivo: non ricorda le conversazioni, ma i risultati ingegneristici verificati. Il codice gestisce "cosa può girare", il metodo gestisce "come scegliere", lo stato gestisce "a che punto siamo", l'evidenza gestisce "in base a cosa crederci". Il codice porta capacità eseguibile, è il processo di soluzione direttamente eseguibile e riproducibile
- il metodo porta decisioni algoritmiche e strategiche, ad esempio la scelta di configurazione e la combinazione di componenti nell'evoluzione a doppio livello
- lo stato porta contesto di progetto e memoria di esecuzione, registrando progresso attuale, vincoli e confini noti
- l'evidenza porta registrazioni sperimentali e conclusioni di accettazione, rispondendo al perché i risultati sono credibili. Se manca uno dei quattro, la sedimentazione non è riproducibile o non è ereditabile: solo codice senza evidenza, le conclusioni non sono credibili
- solo metodo senza stato, l'erede non sa da dove continuare. Quindi i quattro tipi di beni devono essere consolidati in blocco, non sparsi. 3. La premessa della sedimentazione è l'interfaccia stabile. Solo quando i confini dei moduli e i contratti sono relativamente stabili, i nuovi prodotti sono beni
- altrimenti ogni modifica coinvolge le implementazioni circostanti, e la sedimentazione si trasforma rapidamente in debito di manutenzione. Questo è in relazione di condizione reciproca con il design della base aperta e disaccoppiata di Genesis: un'interfaccia stabile rende la sedimentazione ereditabile in sicurezza, il disaccoppiamento rende l'ereditarietà non bisognosa di riscrivere la storia. Prima di sedimentare, fissare i contratti, spesso vale più che scrivere diversi documenti. Esplorazione → produzione → accettazione rigorosa → consolidamento in bene → eredità diretta nel ciclo successivo. L'accettazione è il guardiano della sedimentazione — i prodotti non verificati non entrano nello strato dei beni, evitando di consolidare in "esperienza" di progetto rumore, fenomeni accidentali e conclusioni errate. Senza guardiano, il repository diventa sempre più lungo e meno credibile. 5. La chiave dell'ereditarietà cross-ciclo sta nel disaccoppiare i beni dall'istanza di esecuzione concreta, permettendo a nuove sessioni, nuovi Agent e nuovi task di ripristinare la cognizione a livello di progetto leggendo il repository, senza dipendere dalla riproduzione delle conversazioni storiche. Il costo dell'ereditarietà scende da "raccontare di nuovo il progetto" a "checkout e caricamento", e la cognizione del progetto non è più limitata dalla capacità di una finestra di contesto. Genesis si occupa di "cosa sedimentare, in quale forma, e come essere ereditato"
- la collaborazione multi-Agent e la scomposizione ricorsiva dei task si occupano di "come produrre i risultati"
- il meccanismo di accettazione e di eredità storica si occupa di "come un prodotto viene giudicato credibile". Solo la sovrapposizione dei tre costituisce una capacità completa di evoluzione continua a livello di progetto — se manca una qualsiasi parte, il progetto può solo ripetersi sul posto.

**Copertura delle parole chiave**

- Genesis, evoluzione continua a livello di progetto, architettura di sistema EvoX, codice/metodo/stato/evidenza, guardiano dell'accettazione, eredità cross-ciclo. Questa pagina organizza i contenuti con il "Diagramma dell'architettura a tre livelli di Genesis e del circuito di sedimentazione": a sinistra, dall'alto verso il basso, lo strato dei beni (codice·metodo·stato·evidenza), il meccanismo di sedimentazione (versionamento·gateway di accettazione·ricerca ed eredità) e l'EvoX Runtime (parallelismo tensoriale·calcolo eterogeneo·moduli algoritmici)
- a destra un diagramma ad anello mostra il circuito chiuso di esplorazione, produzione, accettazione, consolidamento, riuso e nuova evoluzione, con l'annotazione "i beni si ispessiscono con l'aumentare dei cicli di vita". La pagina include anche tre avvertenze: non prendere la sessione per memoria, i quattro tipi di beni sono tutti necessari, un'interfaccia instabile trasforma la sedimentazione in debito. Durante la spiegazione si può usare il diagramma per guidare gli studenti a ripetere il circuito lungo le frecce, e poi indicare che l'accettazione si trova dopo la produzione e prima del consolidamento.

> **Indizi per gli esercizi**
>
> - La pagina include cinque domande a scelta multipla e un caso. La prima domanda punta al mondo software accumulabile (repository, versioni e artefatti); se lo studente sceglie per errore la finestra di contesto, suggerire di tornare al punto di partenza "alla fine della sessione non resta nulla"
> - la seconda verifica la corrispondenza tra i quattro tipi di beni e le responsabilità, con la risposta corretta che il codice porta capacità eseguibile
> - la terza verifica il confine tra beni e debito di manutenzione, con la risposta corretta "confini dei moduli e contratti relativamente stabili", sottolineando che la chiave non è quanto si produce o quanto sono nuovi gli strumenti
> - la quarta verifica il guardiano nel circuito chiuso, con la risposta corretta l'accettazione rigorosa
> - la quinta verifica l'eredità cross-ciclo, con la risposta corretta "i beni sono disaccoppiati dall'istanza di esecuzione, e una nuova sessione può ripristinare la cognizione del progetto leggendo il repository". Quando la risposta è corretta si riconosce la capacità di collegarsi ai concetti della pagina e spiegarne le basi; quando è errata si chiede di tornare alla spiegazione per trovare prove o esempi chiave e poi giudicare. Dopo l'esplorazione multi-obiettivo di un profilo alare supercritico, il team ha in mano una configurazione a doppio livello MetaDE eseguibile e uno script di addestramento di modelli surrogati, la definizione degli indicatori di valutazione, uno stato intermedio che copre l'intervallo dei parametri del profilo e i vincoli delle condizioni geometriche di esercizio, e le conclusioni di accettazione del ciclo. La prima domanda richiede di organizzare i beni per codice, metodo, stato ed evidenza, e di spiegare la funzione di guardiano dell'accettazione — solo i prodotti che superano l'accettazione rigorosa possono entrare nello strato dei beni, e i quattro tipi devono essere consolidati in blocco, se manca uno non sono riproducibili o ereditabili. La seconda domanda richiede di confrontare "riprodurre le conversazioni storiche" e "leggere il repository": il primo dipende dalla finestra di contesto, il costo cresce linearmente con il progetto, e una volta troncata la conversazione la cognizione è persa
> - il secondo riduce il costo dell'eredità a checkout e caricamento, con risultati versionabili, riproducibili e verificabili, e il costo delle ripetizioni di questo ciclo si sedimenta come punto di partenza per il riuso nel ciclo successivo.

**Attività in classe**

Chiedere agli studenti di ripetere i contenuti di questa pagina con un esempio vicino alla loro esperienza, e di spiegare la relazione tra quell'esempio e il criterio di giudizio "la prossima persona può riprodurlo senza venire a chiedere a te?".

**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, confermando in particolare che lo studente sappia indicare sia "la divisione dei quattro tipi di beni" sia "l'accettazione è il guardiano della sedimentazione".

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno esprimere la relazione centrale di questa pagina — la sedimentazione avviene su contratti stabili, è presidiata dall'accettazione, e infine viene ereditata leggendo il repository — si può passare all'applicazione o al riepilogo della pagina successiva.

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

### Il modello ingegneristico della collaborazione multi-Agent e della scomposizione ricorsiva dei task

*Pagina 11*

> **Obiettivo della pagina:** Comprendere come più Agent dal ciclo di vita limitato collaborino per completare lo sviluppo e la scomposizione dei task di un progetto complesso.

**Punti chiave della lezione**

- Quando si scompone un task, chiedersi prima "cosa deve consegnare questo livello come risultato verificabile", non "a quale Agent affidarlo". Una volta chiariti i deliverable (dataset, interfacce, checkpoint, report di valutazione), i confini di responsabilità e la suddivisione dei livelli emergono da soli.
- Il punto di arresto della scomposizione ricorsiva non è "scomporre al minimo", ma "scomporre fino a un'unità eseguibile, verificabile, chiudibile in un singolo contesto di un Agent". Scomporre troppo superficialmente supera le capacità del livello inferiore; scomporre troppo finemente porta a costi aggiuntivi di coordinamento e passaggio di consegne.
- La sovrapposizione di responsabilità porta più Agent a realizzare la stessa cosa e a produrre risultati in conflitto. Fissare i confini con interfacce e criteri di accettazione chiari, concordando cosa il livello inferiore può decidere da solo e cosa deve essere sottoposto al task padre.

Obiettivo della pagina

Quando la capacità di contesto e di elaborazione di un singolo esecutore non è sufficiente a sostenere l'intero obiettivo di progetto, come degradare un grande problema in un insieme di piccoli problemi consegnabili, e rendere i risultati della collaborazione tra livelli verificabili e recuperabili.

Ordine di esposizione

Iniziare con "un grande problema degradato in un insieme di piccoli problemi consegnabili", poi sviluppare la struttura a tre livelli, spiegare le ragioni e le condizioni di terminazione della scomposizione ricorsiva, e infine arrivare alla relazione di passaggio bidirezionale dell'albero dei task e ai tre suggerimenti ingegneristici. Durante la spiegazione si può usare il diagramma per indicare livello per livello i nodi, aiutando gli studenti a collegare la divisione astratta del lavoro all'albero dei task concreto.

Punti chiave della lezione

1. Struttura a tre livelli e rispettive responsabilità. L'esecutore di livello superiore è orientato all'obiettivo complessivo, risponde a "cosa fare", producendo sotto-task delegabili, vincoli e criteri di accettazione; l'esecutore di livello intermedio accoglie i sotto-task ancora troppo grandi, continuando la scomposizione ricorsiva, convergendo un obiettivo grande e vago in una gerarchia stabile di task; l'esecutore di livello inferiore completa implementazione e test locali entro i confini di responsabilità, producendo risultati verificabili e consegnandoli verso l'alto, formando un circuito locale. Nel diagramma l'Agent superiore si dirama nei moduli A, B, C; il modulo B, ancora troppo pesante, viene ulteriormente scomposto in sotto-task B1, B2; i quattro nodi foglia ricadono infine ciascuno nell'implementazione e test locale degli Agent inferiori.

Il livello superiore, al nodo radice, produce task delegabili e criteri di accettazione, non completa personalmente l'implementazione.

2. Perché è necessaria la scomposizione ricorsiva. La finestra di contesto di un esecutore, gli strumenti disponibili e la dimensione del task gestibile in una singola esecuzione sono tutti limitati. Se un singolo esecutore mantiene a lungo l'intero contesto del progetto, il costo cresce con la scala, ed è facile incorrere in deriva degli obiettivi, inquinamento dello stato e diluizione delle informazioni chiave. La scomposizione ricorsiva distribuisce questa pressione sui vari livelli: ogni esecutore deve comprendere solo l'obiettivo e i vincoli del proprio livello, e gli obiettivi complessi vengono degradati livello per livello in unità di lavoro eseguibili e consegnabili, mentre la coerenza complessiva è garantita dalla gerarchia dei task.

Albero dei task e passaggio bidirezionale. Task padre e task figli formano un albero ricorsivo. Verso il basso fluisce la delega dei task — obiettivi, vincoli di confine e criteri di accettazione; verso l'alto fluisce il recupero dei risultati — prodotti, evidenze di verifica e problemi ancora aperti. Che la collaborazione funzioni davvero dipende da tre cose: chiarezza della gerarchia dei task, esclusività dei confini di responsabilità, e accordo esplicito sui prodotti di passaggio (definizioni di interfaccia, dataset, casi di test, checkpoint). Se manca uno di questi, più esecutori degenerano in lavoro duplicato e risultati in conflitto.

La profondità della scomposizione, la granularità della delega e la strategia di recupero dei risultati possono anch'esse essere continuamente valutate e adattate. Quando feedback come il rifacimento ripetuto di un sotto-task influenzano il modo in cui si scompone la volta successiva, questo processo collaborativo entra in un ciclo di auto-miglioramento.

5. Suggerimenti ingegneristici. La condizione di arresto della scomposizione ricorsiva non è "scomporre al minimo", ma "scomporre fino a un'unità eseguibile, verificabile, chiudibile in un singolo contesto di un esecutore". Scomporre troppo superficialmente supera la capacità del livello inferiore; scomporre troppo finemente porta a grandi costi di coordinamento e passaggio di consegne. Si può prima definire il deliverable, poi decidere chi lo fa; confini poco chiari sono spesso il costo maggiore della collaborazione.

Gestione degli esercizi

Questa pagina include una serie di domande concettuali vero/falso; si consiglia, dopo la risposta, di chiedere allo studente di indicare la base, non solo l'opzione.

La risposta corretta è "comprendere l'obiettivo complessivo e decomp olo in sotto-task delegabili e criteri di accettazione". Se lo studente sceglie male, suggerire di tornare alla posizione del nodo radice — produce task e criteri di accettazione, non codice.

La risposta corretta è "quando il sotto-task è ancora troppo complesso e supera la capacità di elaborazione singola". Sottolineare che la ricorsione non è un'azione incondizionata; la condizione di attivazione è che il sotto-task sia ancora troppo grande per essere completato e verificato in una singola esecuzione.

Cosa succede se c'è solo l'assegnazione dei task? E se c'è solo il recupero dei risultati? Da qui si spiega che la collaborazione deve essere bidirezionale.

La risposta corretta è "distribuire il contesto e la pressione di elaborazione sui vari livelli, riducendo il carico di contesto su un singolo punto e il rischio di deriva degli obiettivi". La parola chiave è "distribuire", non "garantire il successo al primo colpo".

La risposta corretta è "far conservare ai nodi foglia unità di lavoro eseguibili e consegnabili, con interfacce e prodotti di test chiari". Si può ripassare: confini vaghi o eliminazione dei livelli portano a implementazioni duplicate e risultati in conflitto.

Attività in classe

Il caso di studio "Consegna collaborativa di un sistema di controllo qualità per il servizio clienti intelligente" è adatto come attività di gruppo. Far disegnare prima l'albero ricorsivo dei task: il nodo radice si occupa della comprensione dell'obiettivo complessivo e produce tre sotto-task A, B, C con i criteri di accettazione; il modulo B viene ulteriormente scomposto dal livello intermedio in B1, B2, con interfacce chiarite; i nodi foglia sono le quattro unità di lavoro A, B1, B2, C. Poi ogni gruppo elenca i prodotti di passaggio nelle due direzioni, verso il basso e verso l'alto, ad esempio specifiche di interfaccia dati e dataset di conversazioni pulite, dizionario delle feature e specifiche di annotazione, checkpoint del modello e report di validazione, indicatori di valutazione e configurazione di deploy, spiegando perché i nodi foglia soddisfano la condizione di arresto.

Alla domanda di approfondimento in cui B1 scopre un conflitto tra "specifiche di annotazione" e "indicatori di valutazione", si può guidare lo studente a riassumere i principi di gestione: il conflitto sale per la decisione, non si modificano da soli i criteri di accettazione; interfacce e standard mantengono una fonte unica, gestita dal livello superiore; prima della decisione si mantiene comunque un circuito locale verificabile; il risultato della decisione aggiorna a ritroso l'albero dei task e gli input dei sotto-task correlati; si registra tutto il processo, conflitto, base della decisione e criteri finali, per la tracciabilità.

Verifica della comprensione

Cosa fa il livello superiore, a quali condizioni continua la ricorsione, quali informazioni passano nelle due direzioni. Se lo studente sa indicare sia la condizione di arresto sia "prima definire i deliverable, poi la divisione del lavoro", si può considerare la pagina padroneggiata.

Suggerimento di transizione

Dopo aver confermato che gli studenti sanno distinguere "decomp orre il task" da "implementare personalmente", e sanno esprimere il passaggio bidirezionale dell'albero dei task, si può passare alla pagina successiva sulla discussione dei meccanismi di verifica e sedimentazione, collegando il modello di divisione del lavoro di questa pagina alle fasi successive di compilazione, test e accettazione.

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

### Il rigoroso meccanismo di accettazione e di eredità storica

*Pagina 12*

> **Obiettivo della pagina:** Padroneggiare come, attraverso compilazione, test e gateway di accettazione, le modifiche efficaci si sedimentino nella storia del progetto.

> **Ordine di esposizione**
>
> Iniziare con una frase: "Davanti a qualsiasi sistema che 'genera e migliora automaticamente', fare prima tre domande: qual è l'identità predefinita del prodotto di un Agent (candidato?), quali verifiche deve superare per essere adottato (accettazione?), e dopo l'adozione di chi diventa la base (baseline?). Separando queste tre cose, la logica complessiva del meccanismo non si confonde." Poi, con esempi, diagrammi o parole chiave della pagina, spiegare perché è importante.

**Punti chiave della lezione**

- Qual è l'identità predefinita del prodotto di un Agent (candidato?), quali verifiche deve superare per essere adottato (accettazione?), e dopo l'adozione di chi diventa la base (baseline?). Separando queste tre cose, la logica complessiva del meccanismo non si confonde.
- Compilazione → test → verifica comportamentale → accettazione di livello superiore è una discesa a "costo crescente": più economico prima, più costoso dopo. Ricordando "prima si filtrano i costi bassi, poi si esaminano quelli alti", non si spreca la revisione di alto livello su una marea di candidati spazzatura.
- Superare l'accettazione non significa essere davvero migliore. Quando la copertura dei test è insufficiente o manca la verifica comportamentale, il cancello lascia passare modifiche dannose. Adottare due abitudini: completare casi di regressione e definizioni di tolleranza per i comportamenti chiave
- mantenere sempre indicatori osservabili e campionamenti manuali, come ultima linea di difesa quando gli standard sono incompleti.

Meccanismo rigoroso di accettazione e di eredità storica

11

AI999

Genesis e la sedimentazione nel mondo del software

In base a cosa una modifica generata automaticamente da un Agent può essere scritta nel ramo principale del progetto? Il rigoroso meccanismo di accettazione e di eredità storica disaccoppia completamente generazione e adozione — qualsiasi codice inviato da un Agent è solo una modifica candidata (candidate patch), e deve prima superare una serie di cancelli di verifica per avere il diritto di essere riconosciuta come parte della storia del progetto.

Modifica candidata → quattro cancelli di accettazione → diramazione ramo principale / rifiuto. Coda delle modifiche candidate: inviate dall'Agent · non affidabili per default. Candidato A in attesa, candidato B in attesa, candidato C in attesa, candidato D in attesa. ① Cancello di compilazione: sintassi e interfacce compilabili · costo minimo, eliminazione più rapida. ② Cancello di test: unità/integrazione tutti verdi · copre i contratti esistenti. ③ Cancello di verifica comportamentale: coerenza semantica · tolleranza numerica ed equivalenza. ④ Accettazione di livello superiore: prestazioni · speedup · manutenibilità. Rifiuto · area archivio dei fallimenti · conservati come campioni negativi e materiale diagnostico · archiviati isolati, non inquinano il ramo principale · il rifiuto stesso è filtro di rumore · evitare di riesplorare la stessa strada morta. Storia delle versioni del ramo principale (accumulo monotono). Baseline v3 · ereditabile, tracciabile. Baseline v2. Baseline v1. Feedback di eredità storica: le baseline già accettate diventano punto di partenza per gli Agent successivi. Principio della candidatura predefinita: l'output dell'Agent è considerato per default input non affidabile: è rigorosamente isolato da versioni già accettate in termini di permessi, archiviazione e riferimenti; non può leggere o scrivere direttamente il ramo principale, né essere usato da altri moduli come dipendenza stabile.

L'unico scopo di questo principio è impedire la "generazione che equivale a messa in archivio". Solo dopo aver superato tutti i cancelli la modifica candidata ottiene lo stesso status del ramo principale. Filtro progressivo a quattro livelli: costo crescente, fallimento il prima possibile. Compilazione: costruibilità a livello di sintassi e interfacce. Costo minimo, eliminazione più rapida: blocca subito le modifiche evidentemente infondate. Test: unit test e integration test superati, copertura dei contratti esistenti. Verifica comportamentale: coerenza semantica e comportamentale, con tolleranza numerica, equivalenza e confronto di regressione, specificamente per prevenire "test superati ma comportamento alla deriva". Accettazione di livello superiore: decisione finale orientata agli obiettivi del task e ai vincoli ingegneristici, con giudizi su prestazioni, speedup, manutenibilità.

I cancelli sono ordinati per costo crescente, facendo sì che la stragrande maggioranza delle modifiche invalide venga troncata nelle fasi economiche, lasciando la costosa revisione di alto livello a pochi candidati di alta qualità — questa è l'economia del "fallire il prima possibile". Il valore del rifiuto e l'eredità storica: i tentativi non superati non entrano nel ramo principale, ma possono essere conservati come archivio dei fallimenti / campioni negativi, per diagnosi, deduplicazione e prevenzione di riesplorazioni — il rifiuto stesso è un filtro di rumore. Le modifiche che superano l'accettazione diventano la nuova versione baseline, su cui gli esecutori successivi continuano a evolversi, formando una catena evolutiva monotona crescente, non ripartendo da zero ogni ciclo. Come regola di fusione e contratto di qualità della collaborazione multi-Agent e della scomposizione ricorsiva dei task, il gateway di accettazione definisce "chi può scrivere nella storia", determinando se il risultato della collaborazione converge o aumenta l'entropia.

In scenari con forti vincoli di correttezza, come il refactoring di compilatori e l'aggiornamento di software scientifico, questo meccanismo mostra affidabilità molto elevata e porta a notevoli speedup di esecuzione. Confine di fallimento: la completezza degli standard di accettazione stessi diventa il nuovo collo di bottiglia: quando la copertura dei test è insufficiente o manca la verifica comportamentale, il cancello lascia passare modifiche "che passano l'accettazione ma sono effettivamente dannose". Serve quindi una rete di sicurezza con indicatori osservabili e campionamenti manuali, rafforzando continuamente casi di regressione e definizioni di tolleranza.

Nel meccanismo di accettazione rigorosa, qual è lo status predefinito del codice inviato da un Agent?

Un prodotto finito la cui utilizzabilità è decisa dal mittente stesso.

Una versione ufficiale direttamente unibile al ramo principale.

Una modifica candidata in attesa di verifica, rigorosamente isolata dalle versioni già accettate in permessi, archiviazione e riferimenti.

Un sottoprodotto usato solo per la registrazione dei log, che non partecipa a nessun processo.

La candidatura predefinita considera l'output dell'Agent come input non affidabile, rigorosamente isolato dal ramo principale, evitando istituzionalmente la "generazione che equivale a messa in archivio".

Un output non verificato non dovrebbe avere lo stesso status di una versione già accettata.

Corretto. Questa risposta sa collegarsi ai concetti della pagina e spiegarne le basi.

Tornare alla spiegazione di questa pagina, trovare prove o esempi chiave e poi giudicare.

In quale ordine sono disposti i quattro cancelli di accettazione, e qual è l'intento progettuale?

Dal costo più alto al più basso, investendo prima le risorse nella revisione di alto livello più costosa.

In ordine di tempo di invio dei candidati, prima arrivati prima verificati.

In ordine casuale, per aumentare la diversità della verifica.

Compilazione → test → verifica comportamentale → accettazione di livello superiore, facendo troncare la stragrande maggioranza delle modifiche invalide nelle fasi economiche.

I cancelli economici si occupano dell'eliminazione di massa, quelli costosi affrontano solo pochi candidati di alta qualità.

Pensare a quale livello è più costoso e quale è più rapido. L'ordine dei cancelli dovrebbe far incontrare ai revisori costosi il minor numero possibile di candidati spazzatura.

Quale tipo di problema previene principalmente la verifica comportamentale (terzo cancello)?

Che il numero di unit test scritti non sia abbastanza grande.

"Test superati ma comportamento alla deriva", cioè incoerenza semantica o numerica tra vecchia e nuova implementazione.

Errori di sintassi nel codice che impediscono la compilazione.

Che la storia delle versioni del ramo principale occupi troppo spazio di archiviazione.

La verifica comportamentale usa tolleranza numerica, equivalenza e confronto di regressione per confrontare la coerenza semantica, intercettando derive comportamentali non coperte dai test.

Il livello di compilazione gestisce "si può costruire", il livello di test gestisce "il contratto è soddisfatto", la verifica comportamentale si concentra su derive semantiche più nascoste.

Come va inteso il valore di una modifica candidata rifiutata da un cancello?

Va eliminata completamente, per non occupare spazio e disturbare i giudizi successivi.

Va scritta direttamente nel ramo principale, come controesempio.

Può essere conservata come archivio dei fallimenti / campione negativo, per diagnosi, deduplicazione e prevenzione di riesplorazioni.

Va ripresentata ripetutamente senza modifiche, finché non passa automaticamente.

I tentativi falliti vengono isolati dalla linea principale, ma possono ancora essere usati come campioni negativi — il rifiuto stesso è un filtro di rumore.

La differenza chiave sta nel se è permesso inquinare il ramo principale, e se può essere trasformato in informazione diagnostica riutilizzabile.

Quale delle seguenti situazioni è più probabile che faccia passare al gateway di accettazione una modifica "che passa l'accettazione ma è effettivamente dannosa"?

Copertura dei test insufficiente o verifica comportamentale mancante, che rendono incompleti gli standard di accettazione stessi.

L'accettazione di livello superiore valuta simultaneamente prestazioni, speedup e manutenibilità.

Nella coda delle modifiche candidate ci sono contemporaneamente invii di Agent diversi.

L'archivio dei fallimenti è conservato a lungo per diagnosi.

Il cancello può fermare solo i problemi che riesce a rilevare; quando gli standard di accettazione sono incompleti, servono indicatori osservabili e campionamenti manuali come rete di sicurezza.

Il rischio spesso non viene dal mittente, ma dai punti ciechi di copertura degli standard di accettazione stessi.

Accettazione di una patch di riscrittura del kernel di un compilatore

Leggere lo scenario e rispondere alle due domande seguenti.

Un team usa la collaborazione multi-Agent per rifattorizzare il kernel di un compilatore. L'Agent X invia una patch di riscrittura del kernel, sostenendo di poter aumentare di circa 1,4 volte la velocità di esecuzione di un benchmark. Il sistema tratta la patch secondo il "rigoroso meccanismo di accettazione e di eredità storica": la patch entra prima nella coda delle modifiche candidate, poi passa in sequenza per compilazione, test, verifica comportamentale e accettazione di livello superiore; se passa viene riscritta nel ramo principale e diventa punto di partenza per gli Agent della generazione successiva, altrimenti entra nell'area isolata dell'archivio dei fallimenti.

1. Si indichino in ordine quali verifiche la patch deve superare, e si spieghi perché l'accettazione di livello superiore è posta per ultima.

Compilazione → test → verifica comportamentale → accettazione di livello superiore. La compilazione verifica se a livello di sintassi e interfacce si può costruire, con costo minimo ed eliminazione più rapida; i test verificano se unit/integration test sono tutti verdi e coprono i contratti esistenti; la verifica comportamentale confronta la coerenza semantica tra vecchia e nuova implementazione, inclusi tolleranza numerica, equivalenza e confronto di regressione; l'accettazione di livello superiore fa la decisione finale orientata agli obiettivi del task e ai vincoli ingegneristici, giudicando prestazioni, speedup e manutenibilità. L'accettazione di livello superiore è posta per ultima perché è la più costosa e richiede l'intervento umano o di revisione di alto livello; solo dopo che i cancelli precedenti hanno troncato la stragrande maggioranza dei candidati invalidi si può concentrare questa costosa risorsa su pochi candidati di alta qualità, realizzando "costo crescente, fallire il prima possibile".

Su alcuni input le uscite numeriche della nuova implementazione superano la tolleranza concordata rispetto alla vecchia. Come dovrebbe gestirla il sistema? Ha ancora valore? Cosa succederebbe se si rimuovesse la verifica comportamentale?

La patch non deve essere scritta nel ramo principale, va rifiutata e trasferita nell'area isolata dell'archivio dei fallimenti; poiché ha superato compilazione e test, questo mostra proprio che appartiene al tipo pericoloso "test superati ma comportamento alla deriva". Ha comunque valore: può essere conservata come campione negativo, per diagnosticare l'origine delle differenze, evitare che gli Agent successivi ripetano la stessa strada morta, e suggerire al team di aggiungere casi di regressione o rivedere la definizione di tolleranza. Se si rimuovesse la verifica comportamentale, questo tipo di patch entrerebbe direttamente nell'accettazione di livello superiore o addirittura nel ramo principale con i test tutti verdi, introducendo derive comportamentali nella baseline storica; è proprio il confine di fallimento di questo meccanismo — il cancello può fermare solo i problemi che riesce a rilevare, quindi servono indicatori osservabili e campionamenti manuali come rete di sicurezza.

Candidato, accettazione, baseline

Qual è l'identità predefinita del prodotto di un Agent (candidato?), quali verifiche deve superare per essere adottato (accettazione?), e dopo l'adozione di chi diventa la base (baseline?). Separando queste tre cose, la logica complessiva del meccanismo non si confonde.

L'ordine dei cancelli si ricorda come una discesa

Compilazione → test → verifica comportamentale → accettazione di livello superiore è una discesa a "costo crescente": più economico prima, più costoso dopo. Ricordando "prima si filtrano i costi bassi, poi si esaminano quelli alti", non si spreca la revisione di alto livello su una marea di candidati spazzatura.

Il cancello può fermare solo i problemi che riesce a misurare

Superare l'accettazione non significa essere davvero migliore. Quando la copertura dei test è insufficiente o manca la verifica comportamentale, il cancello lascia passare modifiche dannose. Adottare due abitudini: completare casi di regressione e definizioni di tolleranza per i comportamenti chiave; mantenere sempre indicatori osservabili e campionamenti manuali, come ultima linea di difesa quando gli standard sono incompleti.

step-1

Padroneggiare come, attraverso compilazione, test e gateway di accettazione, le modifiche efficaci si sedimentino nella storia del progetto.

lesson_6

lesson_6_slide_11

Dalla bozza di EvoClass

> **Obiettivo della pagina**
>
> Padroneggiare il meccanismo con cui, attraverso compilazione, test e accettazione, le modifiche efficaci si sedimentano nella storia del progetto

**Punti chiave della lezione**

- Il rigoroso meccanismo di accettazione e di eredità storica
- Il codice inviato da un Agent è solo una modifica candidata, e solo dopo aver superato compilazione, test, verifica comportamentale e accettazione di livello superiore può entrare nella versione di progetto accettata. I tentativi falliti possono essere rifiutati, mentre i risultati verificati diventano la base storica per gli esecutori successivi. Nel refactoring di compilatori e nell'aggiornamento di software scientifico, questo meccanismo mostra affidabilità molto elevata e speedup di esecuzione.

**Punti chiave della lezione**

- Il rigoroso meccanismo di accettazione e di eredità storica
- Il codice inviato da un Agent è solo una modifica candidata, e solo dopo aver superato compilazione, test, verifica comportamentale e accettazione di livello superiore può entrare nella versione di progetto accettata. I tentativi falliti possono essere rifiutati, mentre i risultati verificati diventano la base storica per gli esecutori successivi. Nel refactoring di compilatori e nell'aggiornamento di software scientifico, questo meccanismo mostra affidabilità molto elevata e speedup di esecuzione. Il rigoroso meccanismo di accettazione e di eredità storica
- Il codice inviato da un Agent è solo una modifica candidata, e solo dopo aver superato compilazione, test, verifica comportamentale e accettazione di livello superiore può entrare nella versione di progetto accettata. lesson_id_distribution 86818163433546df25555ab4cb1c2d59fc1effedc37a25c4e84b74b7d294e704

**Basi dei materiali**

Dalla bozza di EvoClass

> **Indizi sui materiali**
>
> - Padroneggiare il meccanismo con cui, attraverso compilazione, test e accettazione, le modifiche efficaci si sedimentano nella storia del progetto
> - Il rigoroso meccanismo di accettazione e di eredità storica
> - Il codice inviato da un Agent è solo una modifica candidata, e solo dopo aver superato compilazione, test, verifica comportamentale e accettazione di livello superiore può entrare nella versione di progetto accettata. I tentativi falliti possono essere rifiutati, mentre i risultati verificati diventano la base storica per gli esecutori successivi. Nel refactoring di compilatori e nell'aggiornamento di software scientifico, questo meccanismo mostra affidabilità molto elevata e speedup di esecuzione.
> - Il codice inviato da un Agent è solo una modifica candidata, e solo dopo aver superato compilazione, test, verifica comportamentale e accettazione di livello superiore può entrare nella versione di progetto accettata.

**Attività in classe**

Chiedere di ripetere i contenuti di questa pagina con un esempio vicino all'esperienza degli studenti, e far dire loro la relazione tra questo esempio e "Davanti a qualsiasi sistema che 'genera e migliora automaticamente', fare prima tre domande: qual è l'identità predefinita del prodotto di un Agent (candidato?), quali verifiche deve superare per essere adottato (accettazione?), e dopo l'adozione di chi diventa la base (baseline?). Separando queste tre cose, la logica complessiva del meccanismo non si confonde."

> **Obiettivi corrispondenti**
>
> - Comprendere il modello ingegneristico della collaborazione multi-Agent e della scomposizione ricorsiva dei task
> - Padroneggiare il meccanismo con cui, attraverso compilazione, test e accettazione, le modifiche efficaci si sedimentano nella storia del progetto

**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 esprimere la relazione centrale di questa pagina, si può passare alla pagina successiva con esempi, applicazioni o riepilogo.

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

### Attività in classe: simulare la collaborazione multi-Agent e il gateway di accettazione automatizzato

*Pagina 13*

> **Obiettivo della pagina:** Approfondire la comprensione dello sviluppo collaborativo multi-Agent e dei meccanismi di accettazione automatizzata attraverso una simulazione.

> **Obiettivo della pagina**
>
> Attraverso una simulazione in classe, comprendere la divisione dei task nello sviluppo collaborativo multi-Agent, la convergenza delle modifiche candidate, e come il gateway di accettazione automatizzato intercetti le modifiche non conformi; il punto è far funzionare il circuito ingegneristico "sviluppo collaborativo—accettazione automatica—eredità storica", non far discutere gli Agent fino a trovare la risposta giusta.

> **Ordine di esposizione**
>
> Dividere i gruppi in Agent di pianificazione/scomposizione, Agent di implementazione, Agent di generazione test, Agent di revisione/coordinamento. Lo stesso task può produrre più modifiche candidate, che il gateway di accettazione decide unitariamente.
>
> Scomposizione dei task, implementazione parallela, accettazione automatica, eredità storica. La scomposizione deve trasformare l'obiettivo in sotto-task verificabili indipendentemente, ad esempio "verifica interfacce—correzione algoritmo—test di regressione"; nella fase di implementazione parallela, più Agent di implementazione inviano patch candidate, e l'Agent di test genera casi limite; nella fase di accettazione automatica si eseguono test automatizzati, controlli statici e controlli di contratto, e il gateway decide secondo criteri eseguibili; nella fase di eredità storica, le modifiche approvate si fondono nella baseline storica, quelle rifiutate conservano motivo del fallimento e informazioni di riproduzione, per un nuovo tentativo.
>
> A sinistra la scomposizione ricorsiva dei task, al centro le modifiche candidate multi-Agent, a destra i test automatizzati e il gateway di accettazione. I candidati convergono nel gateway: se passano si fondono nella baseline storica, se rifiutati vengono rispediti con feedback riproducibile, che ritorna ai reparti di implementazione e test.
>
> I criteri devono essere eseguibili, non fermarsi a "sembra corretto". Il focus è intercettare modifiche che non soddisfano i contratti di interfaccia, introducono regressioni, non coprono casi limite o violano vincoli di qualità. Un feedback utilizzabile deve contenere almeno caso di test fallito, log, passi di riproduzione, comportamento atteso e vincoli correlati.
>
> Le modifiche approvate entrano nella baseline, e gli Agent successivi non devono ripartire da zero; quelle rifiutate diventano esempi negativi ricercabili, evitando di ripetere gli errori. In fase di valutazione si deve guardare se le regole di accettazione sono riproducibili, se il feedback è azionabile, e i diversi rischi di falsi positivi e falsi negativi.
>
> Se manca il gateway o gli standard sono vaghi, la collaborazione multi-Agent non è necessariamente più efficiente, ma può diventare caotica per mancanza di decisione unificata; il valore del gate automatico sta nel sostituire l'approvazione soggettiva con evidenze riproducibili.

**Punti chiave della lezione**

- Prima dell'accettazione, scrivere test eseguibili, asserzioni di contratto e casi limite
- Una regola che non è riproducibile non può intercettare in modo stabile. I candidati rifiutati devono essere accompagnati da log di fallimento, comandi di riproduzione, comportamento atteso e vincoli correlati, permettendo all'Agent successivo di localizzare e correggere direttamente. Una granularità di scomposizione troppo fine alza i costi di fusione e accettazione, troppo grossolana fa sovrapporre le modifiche candidate
- privilegiare la scomposizione in sotto-task testabili e accettabili separatamente.

> **Indizi sui materiali**
>
> - Scomposizione ricorsiva dei task, modifiche candidate multi-Agent, test automatizzati e gateway di accettazione. Il diagramma indica anche "convergenza dei candidati", "ritorno del feedback", "approvati entrano nella baseline, rifiutati tornano con feedback riproducibile", adatto per spiegare il circuito indicando il diagramma. Si può far progettare agli studenti, sul caso "il servizio di pagamento va in crash con input negativi o stringhe troppo lunghe", un insieme di regole di gateway di accettazione eseguibili, che coprano almeno interfacce, regressione, casi limite e vincoli di qualità. Direzione di riferimento: il livello di interfaccia richiede che il campo importo rifiuti numeri negativi e stringhe troppo lunghe, restituendo un codice di errore uniforme e facendo asserzioni di contratto
> - il livello di regressione richiede che tutti i casi esistenti di pagamento riuscito, rimborso e riconciliazione passino senza nuove failure
> - il livello dei casi limite include 0, numeri negativi, importo massimo consentito, stringhe troppo lunghe, stringa vuota e caratteri speciali, asserendo assenza di crash ed errori spiegabili
> - i vincoli di qualità includono superamento dei controlli statici, copertura dei percorsi critici non inferiore alla soglia concordata, assenza di avvisi ad alta severità. Tutte le regole devono essere espresse come test o script eseguibili, e riproducibili in integrazione continua.

> **Indizi per gli esercizi**
>
> - Le intercettazioni errate sprecano il lavoro su candidati corretti e riducono l'efficienza della collaborazione, e possono indurre il team ad allentare gli standard
> - le mancate intercettazioni fanno entrare difetti nella baseline storica, e gli Agent successivi lavorano su una baseline errata, amplificando il rischio di regressione. Le modalità di riduzione includono conservare le evidenze di fallimento, ricampionare i risultati delle intercettazioni, sedimentare i nuovi casi di fallimento come set di regressione, e controllare il rischio con una combinazione di casi limite, controlli di contratto e validazione graduale.

**Verifica della comprensione**

Chiedere a uno studente a caso di riassumere con parole proprie i punti chiave della pagina, verificando se sa indicare i tre punti chiave "standard eseguibili", "feedback azionabile", "scomposizione secondo confini verificabili indipendentemente". Se riesce a fare esempi con il caso del servizio di pagamento, si considera padroneggiato; se risponde solo "far discutere gli Agent automaticamente", suggerire di tornare agli standard del gateway di accettazione e al flusso del circuito.

> **Suggerimento di transizione**
>
> Dopo aver confermato che gli studenti sanno esprimere la relazione tra collaborazione multi-Agent, accettazione automatica ed eredità storica, si può passare alla pagina successiva con applicazioni, esempi o riepilogo.

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

### Il modo di lavorare AI Native e l'ingresso agevole

*Pagina 14*

> **Obiettivo della pagina:** Comprendere come avviare rapidamente esperimenti con EvoX negli strumenti AI attraverso un ingresso e una configurazione semplici.

**Punti chiave della lezione**

- Ricordare questa linea di divisione del lavoro: l'ingresso AI Native si occupa di installazione, configurazione di base e verifica dell'ambiente; tu ti occupi di definizione del problema, scelta della direzione e criteri di valutazione. Investire il tempo risparmiato in quest'ultimo è ciò che porta davvero benefici alla ricerca, altrimenti si sposta solo l'attesa dalla configurazione al rifacimento.
- Il valore di un'istruzione in una frase è farti entrare rapidamente nell'esperimento, non saltare la verifica. Dopo l'installazione, verificare attivamente versione, dipendenze e visibilità GPU, trattando lo stato riportato dallo strumento come indizio e non come conclusione, così gli esperimenti successivi avranno un riferimento affidabile.
- Prima di riprodurre su macchine diverse, controllare voce per voce: lista di dipendenze e versioni coerenti, modello GPU e numero di dispositivi disponibili identici, seed casuali e iperparametri chiave fissati. Solo dopo aver superato questi tre controlli si può ampliare la scala dell'esperimento, evitando che il costo di diagnosi successivo superi di molto quello della configurazione iniziale.

Obiettivo della pagina**

Cosa cambia davvero il modo di lavorare AI Native, e dove sono i suoi confini. Dopo lo studio si dovrebbero saper dire tre cose: l'ingresso interattivo passa dalla ricerca manuale di documentazione, installazione di dipendenze, configurazione dell'ambiente e scrittura di scaffold all'avvio di un esperimento con una frase in uno strumento AI; installazione, configurazione di base e verifica dell'ambiente sono a carico dello strumento, che riporta lo stato; definizione del problema, scelta della direzione e criteri di valutazione restano a carico del ricercatore.

Punti chiave della lezione**

1. Il cambio di ingresso è la caratteristica definitoria. Il percorso tradizionale è "consultare la documentazione → installare dipendenze → configurare l'ambiente → scrivere lo scaffold → solo allora iniziare il primo esperimento", e ogni anello può sbagliare, e ogni cambio richiede di ricostruire il contesto. Il percorso AI Native è invece "un'istruzione in una frase → lo strumento prende in carico installazione e configurazione → verifica dell'ambiente superata → ingresso nell'esperimento". Ciò che cambia è il modo in cui la persona inizia a lavorare, non l'oggetto dell'ottimizzazione in sé.

2. La natura dell'attrito si sposta, non scompare. Il vero peso spesso non viene dalla difficoltà della singola operazione, ma dal frequente cambio di contesto: il ricercatore dovrebbe concentrarsi su modellazione del problema, progettazione degli esperimenti e interpretazione dei risultati, e invece viene continuamente interrotto da conflitti di versione, dipendenze mancanti e percorsi d'ambiente. L'ingresso agevole trasferisce l'intera catena ingegneristica, riportando l'attenzione alla ricerca stessa.

Completare installazione e configurazione di base di EvoX in una singola istruzione. Ad esempio digitando "installa EvoX e completa la configurazione di base", lo strumento esegue e restituisce il risultato, e il ricercatore entra subito nell'esperimento. Attenzione: questo è solo il punto di partenza, non di arrivo — il "configurazione completata" riportato dallo strumento è uno stato da verificare, non una conclusione da prendere per buona.

4. Più corto è il percorso, minore è la distanza dall'idea all'esperimento eseguibile; l'idea può essere verificata in giornata, e le ipotesi fallite eliminate rapidamente. Questo è particolarmente evidente per temi come l'evoluzione dei metodi, che richiedono di costruire ripetutamente strutture sperimentali interne ed esterne: il tempo può essere dedicato a progettazione delle strategie, criteri di valutazione e attribuzione dei risultati, invece che a riparare l'ambiente ripetutamente.

L'ingresso agevole riduce i costi di avvio e configurazione, ma non sostituisce il giudizio del ricercatore su valore del problema, direzione della ricerca e indicatori di valutazione. Leggere "risparmiare tempo" come "risparmiare giudizio" è la distorsione più comune di questa pagina. Il tempo risparmiato porta davvero benefici alla ricerca solo se investito nel giudizio; altrimenti si sposta solo l'attesa dalla configurazione al rifacimento.

Indizi sui materiali**

In alto in grigio i quattro passi del percorso tradizionale, con l'annotazione "attrito concentrato"; al centro in blu i quattro passi del percorso AI Native, di cui "istruzione in una frase" è evidenziata, con l'annotazione "attrito trasferito"; in basso il blocco arancione "confini di posizionamento". Durante la spiegazione si può chiedere direttamente: quale segmento è stato rimosso nel diagramma, e quale è rimasto? Guidare gli studenti a scoprire — ciò che viene trasferito è installazione, configurazione di base e verifica dell'ambiente; ciò che resta sono problema, direzione e criteri di valutazione.

Gestione degli esercizi**

Le cinque domande a scelta multipla dovrebbero essere gestite collettivamente dopo la spiegazione, dando per ciascuna una frase di motivazione, per l'autoverifica degli studenti.

Il giudizio corretto è "l'ingresso interattivo predefinito passa dalla ricerca manuale di documentazione, configurazione dell'ambiente e scrittura di scaffold all'avvio diretto di esperimenti con istruzioni semplici in uno strumento AI". Se si scelgono strategie di ricerca, migrazione cloud o sostituzione di architetture di rete, significa confondere "cambiamento di ingresso" e "cambiamento di algoritmo"; tornare a sottolineare: questo punto descrive come la persona inizia a lavorare.

Il giudizio corretto è "lo strumento completa installazione, configurazione di base e verifica dell'ambiente in una singola istruzione e riporta lo stato, e il ricercatore entra nell'esperimento su questa base". Se si pensa che lo strumento garantisca di non dover più controllare versione e visibilità GPU, o che determini automaticamente problemi di ricerca e indicatori di valutazione, significa estendere troppo l'ambito — copre solo il segmento di catena ingegneristica di installazione e configurazione di base.

Il giudizio corretto è "riduce i costi di avvio e configurazione, ma non sostituisce il giudizio del ricercatore su definizione del problema, direzione della ricerca e criteri di valutazione". Leggere "risparmiare tempo" come "risparmiare giudizio", o pensare che valga solo per i principianti, richiede di tornare alla conclusione sui confini.

Il giudizio corretto è "il valore viene dal trasferimento dell'attrito ingegneristico e dall'accorciamento del ciclo iterativo, e la condizione di validità è che il ricercatore possa ancora verificare i risultati della configurazione e la riproducibilità degli esperimenti". Qui si deve sottolineare la distinzione tra "ridurre le operazioni manuali" e "ridurre il giudizio manuale".

La quinta domanda è una proiezione delle conseguenze della mancata verifica; il giudizio corretto è "ambiente non riproducibile, difficile localizzare le differenze tra esperimenti, stabilità dei risultati non garantita". Nel feedback indicare: il problema non è il limite delle capacità dello strumento, ma l'assenza della fase di verifica; una configurazione non verificata pone rischi per la riproduzione e la diagnosi dei guasti successivi.

Attività in classe**

La discussione del caso può svilupparsi su "portare a termine in tre giorni un esperimento di evoluzione dei metodi con EvoX". La prima domanda richiede di chiarire quale costo è stato ridotto e quale responsabilità è rimasta: ridotto il costo dell'attrito ingegneristico, rimangono le decisioni di modellazione su problema e direzione, la determinazione dei criteri di valutazione e la verifica della configurazione. La seconda domanda si concentra sulla riproduzione multi-macchina, guidando gli studenti a indicare almeno due pratiche verificabili: salvare versioni e lista delle dipendenze effettivamente installate e confrontarle voce per voce tra macchine; controllare modello GPU, memoria e numero di dispositivi visibili di ogni macchina, fissando i numeri dei dispositivi se necessario; fissare seed casuali e dimensione del batch, rieseguire prima il task di riferimento con la stessa configurazione per confermare che i risultati rientrino nell'oscillazione attesa, poi ampliare la scala dell'esperimento.

Verifica della comprensione**

"Se l'installazione è tutta affidata allo strumento, cosa devi assolutamente verificare di persona il giorno dopo?" Saper indicare verifica di versione, dipendenze e visibilità GPU significa padroneggiare.

Suggerimento di transizione**

Dopo aver confermato che gli studenti sanno esprimere la linea di divisione "lo strumento si occupa della preparazione ingegneristica, il ricercatore del giudizio di ricerca", si può passare alla pagina successiva con esempi, applicazioni o riepilogo.

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

### Il gusto centrale del ricercatore: divisione del lavoro uomo-macchina e pensiero critico

*Pagina 15*

> **Obiettivo della pagina:** Comprendere il gusto scientifico e il giudizio critico insostituibili del ricercatore nel processo di evoluzione assistita dall'AI.

> **Obiettivo della pagina**
>
> Comprendere il gusto scientifico e il giudizio critico insostituibili del ricercatore nel processo di evoluzione assistita dall'AI. La domanda centrale è: quando l'AI riduce enormemente il costo di "implementare le risposte", dove si sposta il valore della ricerca?

**Punti chiave della lezione**

- AI / EvoX possono completare rapidamente implementazione del codice, esecuzione batch di esperimenti, generazione di candidati, ricerca di parametri e registrazione dei feedback; il costo ingegneristico non è più il collo di bottiglia centrale. Il ricercatore decide quali problemi valgono la pena di essere studiati, quali risultati hanno senso, quali evidenze sono sufficienti a sostenere conclusioni. L'AI espande implementazione e spazio di ricerca
- il ricercatore controlla definizione del problema, conflitti tra obiettivi, confini dei vincoli e criteri di accettazione. Trattare l'output dell'AI come ipotesi da verificare, controllando se l'ipotesi regge, se le evidenze sono sufficienti, se le condizioni al contorno sono considerate, se i risultati negativi sono ignorati, evitando di farsi fuorviare da risposte fluenti ma non verificate. In esplorazione aperta e feedback sparso, la scelta della direzione non può essere esternalizzata all'AI
- il giudizio finale e la responsabilità scientifica restano al ricercatore. A sinistra AI / EvoX, corrispondente a generazione di candidati, esecuzione di esperimenti, spazio di ricerca, registrazione di feedback
- a destra il ricercatore, corrispondente a porre domande, valutare evidenze, soppesare compromessi, riflettere sulla direzione
- al centro "Code is cheap. Taste matters". In basso "circuito di feedback: checkpoint critici" ricorda che non è un flusso unidirezionale, ma un ciclo in cui l'AI produce feedback per la persona, che ridefinisce problemi e standard. Nel task di ottimizzazione multi-obiettivo di EvoX, l'AI genera rapidamente un gran numero di soluzioni candidate e codice sperimentale. Il ricercatore deve giudicare: la funzione obiettivo riflette i bisogni reali? La baseline è equa? Gli indicatori trascurano vincoli chiave? Se si guarda solo il punteggio, si può scegliere una soluzione apparentemente ottimale ma non conforme ai bisogni reali. Qui "Code is cheap. Taste matters" si manifesta così: l'AI si occupa di implementazione rapida e ricerca, il ricercatore esamina definizione del problema e standard delle evidenze, giudicando quali risultati hanno davvero senso.

**Gestione degli esercizi**

Il gusto scientifico e il giudizio critico insostituibili del ricercatore, e la divisione del lavoro in cui l'AI si occupa dell'implementazione e la persona del giudizio. Le opzioni errate tipicamente saltano i concetti, saltano lo studio del materiale, concludono solo per sensazione, o confrontano cambiando simultaneamente tutti i fattori. La risposta al caso in classe deve arrivare a: trattare l'output dell'AI come ipotesi da verificare, controllando funzione obiettivo, baseline e indicatori; e chiarire che scelta della direzione e responsabilità scientifica non possono essere esternalizzate.

**Verifica della comprensione**

Chiedere agli studenti di distinguere con parole proprie "costo di implementazione" e "valore del giudizio", portando un esempio di fase delegabile all'AI e un esempio di fase che deve restare al ricercatore. Se sanno chiarire la relazione tra i due, si può passare alla pagina successiva.

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

### Riepilogo del corso: costruire l'infrastruttura di un mondo software in continua evoluzione

*Pagina 16*

> **Obiettivo della pagina:** Riassumere i contenuti centrali dell'intero corso, chiarendo la visione di costruire un'infrastruttura intelligente aperta, evolutiva e in continua sedimentazione.

**Punti chiave della lezione**

- Soluzioni candidate, metodi che producono candidati (come le configurazioni interne ed esterne di MetaDE) e beni a livello di progetto sono tre livelli diversi. Prima di progettare o rispondere, chiarire una frase: "quale livello sto ottimizzando ora?", per evitare di confondere evoluzione dei metodi ed evoluzione continua a livello di progetto.
- Solo i prodotti che superano l'accettazione rigorosa possono entrare nella libreria di esperienze ed essere ereditati. Una volta che risultati non verificati vengono ereditati da task successivi, l'errore si amplifica lungo la catena di eredità, ed è difficile localizzarne l'origine.
- All'inizio di ogni nuovo task, chiedersi: quali prodotti ed elementi di esperienza già verificati nel ciclo precedente ho riutilizzato direttamente? Se la risposta è vuota, il processo attuale è ancora un task singolo, non un'infrastruttura in continua evoluzione.

Obiettivo della pagina

Elevare "l'evoluzione intelligente" da singola ricerca e singola ottimizzazione a infrastruttura software orientata al mondo reale. Il punto non è introdurre un altro algoritmo, ma far vedere agli studenti come il sistema, attraverso il circuito "task—esplorazione—accettazione—eredità—nuova evoluzione", attraversi singoli task e singoli Agent, mantenendosi aperto, affidabile e in continuo collegamento con problemi reali.

Punti chiave della lezione

1. Aggiornamento dell'oggetto dell'evoluzione. Genesis estende l'oggetto dell'evoluzione dalle soluzioni candidate di un singolo task all'evoluzione continua a livello di progetto, attraverso Agent e cicli di task. Alla fine di un'esecuzione lo stato non viene più azzerato; la fine del task diventa anzi il punto di partenza del ciclo successivo.

2. Paradigma di sedimentazione ingegneristica. Accettazione rigorosa, eredità storica e sedimentazione dell'esperienza sono tutte necessarie: l'accettazione è il cancello, decide cosa ha il diritto di restare; l'eredità è il canale, decide se il sedimentato può essere davvero richiamato nel ciclo successivo; la sedimentazione dell'esperienza fa accumulare stabilità al sistema tra più task. Scrivere documenti e report settimanali non è sedimentazione ingegneristica: solo i beni eseguibili, ereditabili e riutilizzabili lo sono.

3. Posizionamento di EvoX. EvoX si colloca al livello più basso, fornendo base di potenza di calcolo, esecuzione parallela e scheduling evolutivo, sostenendo verso l'alto la costruzione di sistemi aperti, componibili e accumulabili; non è un modulo che sostituisce le decisioni dell'Agent, né un componente di visualizzazione dei risultati.

4. Visione finale. Il mondo del software non è un prodotto chiuso consegnato una volta per tutte, ma un'infrastruttura intelligente che si evolve continuamente, si sedimenta continuamente e si connette continuamente a problemi reali. Le parole chiave sono evoluzione continua, sedimentazione continua, connessione continua.

Indizi sui materiali

Prodotti accettati (risultati di fase che