Categoria: Capire IA

CAPIRE L’IA · 12 di N

«Come apro una richiesta di assistenza?» e «Apri una richiesta di assistenza per questo problema» sembrano domande vicine. La prima chiede una spiegazione. La seconda chiede una modifica in un sistema esterno.

È qui che il discorso sugli agenti diventa concreto. Un testo corretto non basta più: occorrono identificativi, strumenti, autorizzazioni e prove dell’esito. Il sistema deve collegare ciò che propone a ciò che è realmente accaduto.

Che cosa intendiamo per agente?

Non esiste un unico confine terminologico condiviso. Qui chiamiamo agente basato su LLM un sistema che usa un modello per scegliere passi operativi verso un obiettivo, invoca strumenti e utilizza le osservazioni ottenute per decidere come proseguire.

Il modello è una componente. Intorno ci sono software di orchestrazione, stato, strumenti, credenziali, controlli e criteri di arresto. Dare un nome umano al sistema non aggiunge nessuna di queste capacità.

È utile distinguere un workflow, il cui percorso è in gran parte definito dal codice, da un agente che decide dinamicamente una parte dei passi. Il contributo di Anthropic su come costruire agenti efficaci usa questa distinzione e sottolinea il valore di soluzioni semplici, verificabili e proporzionate al compito.

Un esempio: segnalare una stampante guasta

Immaginiamo un assistente interno e un utente autorizzato: «La stampante PR-204 non stampa. Apri una segnalazione e dammi il numero del ticket». L’identificativo e il caso sono inventati.

Un chatbot senza strumenti può spiegare la procedura o preparare il testo. Un sistema collegato al gestionale può cercare il dispositivo, verificare se esiste già una segnalazione aperta, creare il ticket e leggere l’identificativo restituito.

Se ci sono due dispositivi con nomi simili, deve risolvere l’ambiguità. Se il gestionale non risponde, non può sostituire il risultato con un numero plausibile. L’obiettivo comprende sia l’azione sia una conferma fondata sul suo esito.

La chiamata a uno strumento è un’uscita strutturata

Il modello può produrre una richiesta del tipo: usare lo strumento «crea_ticket» con dispositivo «PR-204», categoria «stampa» e descrizione del problema. È una struttura di dati, spesso codificata in JSON.

Questa richiesta non esegue da sola l’azione. Il software deve controllare nome dello strumento, argomenti, identità dell’utente e permessi; poi può invocare l’API del gestionale. La risposta dello strumento viene riportata al sistema come osservazione.

Si distinguono quindi tre momenti: proposta del modello, esecuzione autorizzata dal software e risultato osservato. Confonderli porta alla frase più pericolosa in questo esempio: «Ticket creato», quando è stato soltanto preparato il comando.

Un ciclo con stato e condizioni di uscita

Il sistema conserva informazioni rilevanti: dispositivo selezionato, dati già raccolti, strumenti chiamati, risultati e passi ancora da completare. Questo stato può vivere nel contesto, in una struttura esterna o in entrambi. Non implica che il modello si riaddestri a ogni passo.

Dopo la ricerca dei ticket esistenti, l’agente può scegliere un ramo. Se trova una segnalazione pertinente, può comunicarne lo stato secondo le regole del servizio. Se non la trova, può proporre la creazione. Se mancano dati necessari, può chiederli.

Un piano iniziale aiuta, ma non è una prova che i passi siano stati eseguiti. Le osservazioni possono costringere a cambiarlo. Servono anche limiti: numero massimo di tentativi, tempo disponibile, budget e condizioni che richiedono il passaggio a un operatore.

Gli errori cambiano natura quando si agisce

Una risposta sbagliata può essere corretta in una conversazione. Un’azione può aver già modificato un archivio, inviato una comunicazione o consumato una risorsa. L’affidabilità deve quindi riguardare l’intera sequenza operativa.

Supponiamo, in un modello puramente didattico, che cinque passi indipendenti abbiano ciascuno probabilità 0,95 di riuscita e che tutti siano necessari. La probabilità di riuscita completa è 0,95⁵ ≈ 0,774. Non è una stima delle prestazioni di un agente reale: i passi possono essere dipendenti e controlli o recuperi cambiano il risultato.

Il conto mostra però perché una buona prestazione locale non basta. Bisogna misurare il completamento del compito, la correttezza delle modifiche e la gestione degli errori, non soltanto la qualità del testo finale.

Un timeout non significa che nulla sia accaduto

Nel nostro esempio il gestionale potrebbe creare il ticket ma perdere la risposta a causa di un’interruzione di rete. Se l’agente ripete subito la creazione, può generare un doppione.

Una soluzione progettuale è usare un identificativo univoco dell’operazione e un’API che supporti l’idempotenza: ripetere la stessa richiesta non deve creare nuove copie dell’effetto. Dove non è disponibile, occorrono controlli specifici dello stato prima di riprovare.

Il risultato finale dovrebbe distinguere «operazione riuscita», «operazione fallita» ed «esito ancora incerto». L’incertezza di esecuzione è una condizione operativa reale, non un difetto da nascondere con una frase rassicurante.

Il controllo umano deve avere un oggetto preciso

Chiedere «Confermi?» a ogni passo può diventare un gesto automatico. È più utile stabilire quali operazioni sono già autorizzate e per quali serve una revisione, mostrando in quel momento il destinatario, i dati e l’effetto previsto.

Nel nostro caso, leggere il dispositivo e verificare ticket aperti può rientrare nell’incarico. Creare la segnalazione può essere già autorizzato dalla richiesta esplicita dell’utente e dalle regole del servizio. Inviare comunicazioni ad altri soggetti o modificare configurazioni richiede una valutazione diversa: non discende automaticamente dall’obiettivo di aprire un ticket.

I controlli devono essere applicati dal software: strumenti disponibili, permessi limitati, validazione degli argomenti e registrazione degli esiti. Una frase nel prompt che invita alla prudenza non sostituisce un vincolo tecnico.

Quando una fonte prova a diventare un comando

L’agente può leggere un documento o un ticket contenente istruzioni ostili, per esempio un testo che gli chiede di ignorare l’obiettivo e inviare informazioni altrove. È il problema della prompt injection: dati provenienti dall’esterno tentano di farsi trattare come istruzioni autorevoli.

Separare i dati dai comandi, limitare strumenti e privilegi e controllare le destinazioni riduce le possibilità di azioni indebite. La questione non riguarda solo la bontà della risposta: riguarda quali effetti il sistema può produrre quando interpreta male ciò che legge.

Come valutare un agente sul serio

Per la stampante fittizia prepariamo casi verificabili: dispositivo valido, identificativo ambiguo, ticket già aperto, permesso insufficiente, timeout dopo creazione e testo ostile in un risultato. Per ciascuno definiamo stato finale atteso e azioni vietate.

Controlliamo se il ticket esiste davvero, se è associato al dispositivo corretto, se ci sono doppioni e se il numero comunicato coincide con quello del gestionale. Osserviamo anche tempo, numero di chiamate, interventi umani e capacità di fermarsi.

Questo rende la valutazione aderente al compito. Una risposta elegante può accompagnare un’azione sbagliata; una risposta breve con un identificativo verificato può rappresentare un risultato migliore.

Tre cose da conservare

1. Un agente è un sistema, non soltanto un modello. Collega scelte, strumenti, stato e osservazioni.
2. Proporre, eseguire e verificare sono momenti distinti. Un comando generato non dimostra un effetto nel mondo.
3. L’autonomia richiede confini concreti. Permessi, controlli, gestione degli errori e intervento umano fanno parte del funzionamento.

La serie è partita da una macchina che impara e arriva a un sistema che agisce. Il filo rimane lo stesso: identificare che cosa cambia, quali calcoli vengono eseguiti e quali prove consentono di fidarsi del risultato. Sono domande utili tanto davanti a una rete piccola quanto davanti a un assistente collegato ai nostri strumenti di lavoro.

← Torna al percorso Capire l’IA

CAPIRE L’IA · 11 di N

Abbiamo un manuale interno e vorremmo che l’assistente rispondesse alle domande dei colleghi. «Diamolo all’IA», diciamo. Ma questa frase può indicare operazioni molto diverse.

Possiamo inserire il testo nella richiesta. Possiamo costruire un sistema che recuperi i passaggi pertinenti quando servono. Oppure possiamo usare esempi per un nuovo addestramento. Sono tre modi di intervenire sul sistema, con effetti diversi su aggiornamento, comportamento e verificabilità.

La distinzione iniziale è decisiva: il RAG usa il contesto. Non è un’alternativa al contesto nello stesso senso in cui lo è una modifica dei parametri. È un modo organizzato di scegliere quali informazioni inserirvi.

Un esempio: la procedura che cambia versione

Immaginiamo un manuale aziendale, interamente fittizio. La versione 1 dice di inviare una richiesta di accesso al referente del servizio. La versione 2 introduce un portale e mantiene un’eccezione per gli utenti esterni.

Alla domanda «Come chiedo l’accesso?», non basta una risposta ben scritta. Occorre sapere quale versione vale e se chi domanda rientra nell’eccezione. Questo esempio ci accompagnerà nei tre casi.

Primo caso: mettere le informazioni nel contesto

Incolliamo il paragrafo aggiornato e chiediamo: «Rispondi usando questo testo; se manca un’informazione, segnalalo». Il modello elabora la domanda insieme al materiale fornito. I suoi parametri rimangono normalmente invariati.

Possiamo includere anche esempi del formato desiderato. Questo adattamento al materiale presente nella richiesta viene spesso descritto come apprendimento nel contesto, ma non implica un aggiornamento tramite gradiente.

Per un documento breve e una domanda occasionale, è una soluzione diretta. Tuttavia il contesto ha una capienza limitata e non garantisce che ogni dettaglio venga utilizzato correttamente. Aggiungere materiale irrilevante può rendere più difficile individuare l’eccezione importante.

Se domani apriamo un’altra conversazione, non possiamo presumere che il documento sia ancora disponibile. La persistenza dipende dal prodotto e dalle sue memorie o archivi esterni, non dal semplice fatto di aver mostrato il testo al modello.

Secondo caso: recuperare i documenti quando servono

RAG significa Retrieval-Augmented Generation: generazione arricchita dal recupero di informazioni. Un riferimento fondativo è il lavoro di Lewis e colleghi del 2020. Nelle applicazioni, il termine comprende oggi pipeline con molte varianti.

Una pipeline tipica prepara un archivio: legge i documenti, li divide in porzioni e conserva metadati come titolo, versione e sezione. Può indicizzarli con metodi lessicali, vettoriali o ibridi. Gli embedding sono una possibilità, non un requisito che esclude la ricerca per parole chiave.

Quando arriva una domanda, il sistema recupera i passaggi candidati, eventualmente li riordina e li inserisce nel contesto del generatore. La risposta può così riportare riferimenti ai documenti effettivamente consultati.

Nel nostro manuale, il recupero dovrebbe trovare sia la regola del portale sia l’eccezione per gli utenti esterni. Se la divisione in porzioni separa le due informazioni e ne viene recuperata una sola, il modello può ricevere una base incompleta.

La selezione della versione non dovrebbe dipendere soltanto dalla somiglianza semantica. La versione superata può contenere parole quasi identiche alla domanda. Date, stato di validità e permessi di accesso devono contribuire al recupero.

Tre punti in cui il RAG può fallire

Archivio: manca il documento corretto, oppure è stato estratto male. Recupero: il documento esiste ma il passaggio pertinente non arriva al modello. Generazione: il passaggio arriva, ma viene interpretato o citato in modo scorretto.

Questi errori richiedono interventi differenti. Cambiare il prompt non ripara un archivio privo della versione aggiornata. Migliorare la ricerca non basta se il generatore ignora sistematicamente le eccezioni.

Un test utile per diagnosticare il problema consiste nel fornire manualmente il passaggio corretto e osservare la risposta. Se il risultato migliora, il recupero merita attenzione; se resta sbagliato, occorre indagare anche istruzioni, interpretazione e modello. Non è una prova definitiva, ma separa due ipotesi.

Terzo caso: modificare il modello con il fine-tuning

Il fine-tuning è un ulteriore addestramento a partire da un modello esistente. Gli esempi contribuiscono a una funzione di perdita; i gradienti aggiornano parametri addestrabili. Cambia quindi una parte persistente del sistema.

Nel fine-tuning completo si possono aggiornare tutti i parametri. Tecniche efficienti come LoRA mantengono fissi i pesi di base e addestrano matrici aggiuntive più piccole. Il comportamento effettivo cambia comunque: non stiamo soltanto aggiungendo pagine alla richiesta.

Per esempio, possiamo addestrare su richieste di assistenza e classificazioni corrette per migliorare l’uso di una tassonomia interna, oppure su risposte nel formato strutturato atteso. Servono esempi coerenti e una valutazione su casi separati da quelli usati per l’addestramento.

Il fine-tuning può anche incorporare conoscenze, ma non è un database con operazioni affidabili di inserimento, correzione e cancellazione di singoli fatti. Se cambia il manuale, non basta assumere che una nuova sessione di addestramento cancelli ogni traccia della vecchia regola.

Confrontiamoli senza confonderli

Intervento	Che cosa cambia	Esempio
Contesto fornito direttamente	Le informazioni della richiesta corrente	Incollare il paragrafo della versione 2
RAG	I passaggi recuperati e inseriti nel contesto	Cercare regola ed eccezione nel manuale vigente
Fine-tuning	I parametri addestrabili del modello o degli adattatori	Imparare a classificare richieste con esempi corretti

Un sistema può combinarli: un modello adattato al formato aziendale riceve istruzioni nella richiesta e consulta documenti con RAG. Non occorre scegliere una sola casella per sempre.

Come decidere da dove partire?

Nel nostro esempio, se la domanda riguarda una singola pagina già disponibile, inserirla nel contesto consente un primo esperimento semplice. Se le domande riguardano molti documenti che cambiano, il recupero organizzato diventa una possibilità da valutare. Se il problema persistente riguarda il comportamento su molti esempi simili, il fine-tuning può essere pertinente.

Prima di aumentare la complessità, conviene individuare il difetto concreto. Il sistema non trova la regola? La trova ma non la rispetta? Produce il formato sbagliato? La stessa etichetta «non funziona» nasconde problemi diversi.

Per informazioni puntuali e dinamiche, come lo stato attuale di una richiesta, può essere più appropriata una query a un sistema gestionale rispetto alla ricerca in documenti. Il dato operativo vive altrove e deve essere interrogato nel momento opportuno.

La verifica va progettata insieme alla soluzione

Costruiamo un insieme di domande con risposta attesa e fonti: casi ordinari, eccezioni, documenti superati, richieste ambigue e domande cui l’archivio non permette di rispondere. Misuriamo separatamente se il passaggio necessario viene recuperato e se la risposta lo usa correttamente.

Per il fine-tuning teniamo separati addestramento e valutazione, controllando anche duplicati e somiglianze eccessive tra i casi. Per il RAG rispettiamo i permessi già nella selezione dei documenti: il generatore non dovrebbe ricevere materiale cui l’utente non ha accesso.

I testi recuperati sono inoltre dati, non nuove istruzioni autorevoli. Una frase contenuta in un documento non deve poter cambiare liberamente obiettivo o autorizzazioni del sistema. La questione diventa ancora più concreta quando l’assistente può agire attraverso strumenti.

Tre cose da conservare

1. Il contesto fornisce materiale da elaborare. Di norma non aggiorna i parametri.
2. Il RAG seleziona materiale da portare nel contesto. Recupero corretto e risposta corretta vanno verificati separatamente.
3. Il fine-tuning modifica parametri addestrabili. Può affiancare il RAG, ma non equivale a caricare un archivio consultabile.

Ora il sistema sa ricevere informazioni e cercarle. L’ultimo passaggio della serie riguarda un cambiamento ulteriore: che cosa accade quando, oltre a rispondere, può compiere azioni?

← Torna al percorso Capire l’IA

CAPIRE L’IA · 10 di N

Chiediamo a un assistente il titolo di un saggio poco noto. La risposta arriva completa: autore, editore, anno, perfino una citazione. Tutto ha la forma giusta. Poi cerchiamo il volume e non lo troviamo.

Un errore del genere colpisce perché non si presenta come un vuoto. Si presenta come una risposta. Il problema delle allucinazioni nasce proprio dalla possibilità di produrre testo plausibile senza un adeguato fondamento fattuale.

Il termine è una metafora tecnica: non attribuisce alla macchina un’esperienza percettiva. Né «inventare» implica necessariamente l’intenzione di ingannare.

Due domande diverse: suona bene? È vero?

Nell’articolo precedente abbiamo visto che un LLM autoregressivo costruisce una sequenza a partire da probabilità condizionate. Una risposta può rispettare la grammatica, il tono e le convenzioni di una bibliografia anche se combina dettagli che non appartengono a nessun libro reale.

Il fatto che il modello abbia appreso molte informazioni vere non trasforma ogni completamento in una verifica. I parametri non costituiscono un catalogo nel quale ogni affermazione sia accompagnata da una fonte consultabile.

Per ragionare con precisione distinguiamo almeno tre proprietà: plausibilità, cioè quanto il testo appare coerente; correttezza fattuale, cioè quanto corrisponde ai fatti; fedeltà alla fonte, cioè quanto rispetta il materiale che dovrebbe riassumere.

Una sintesi può essere fedele a un documento sbagliato. Un’affermazione vera può essere assente dal documento fornito e quindi risultare indebita in un compito che richiede di usare soltanto quella fonte. «È nel testo» ed «è vero nel mondo» richiedono verifiche differenti.

Un errore piccolo, nascosto in una risposta quasi giusta

Costruiamo un esempio interamente immaginario. Il documento dice: «Il laboratorio Alba è stato fondato nel 2018. Nel 2022 ha aperto una sede a Padova». Chiediamo un riassunto e riceviamo: «Il laboratorio Alba, fondato a Padova nel 2018, ha ampliato le attività nel 2022».

I nomi e gli anni provengono dalla fonte, ma le relazioni sono state cambiate. Il documento non dice che il laboratorio sia stato fondato a Padova. E «ha ampliato le attività» è una generalizzazione che sostituisce l’informazione precisa sull’apertura della sede.

Il punto fragile non è sempre un nome inventato. Può essere un nesso: chi ha fatto che cosa, dove, quando e con quale certezza. Per questo una lettura che controlla soltanto la presenza delle parole chiave non basta.

Perché succede?

Non c’è una sola causa. Un fatto può essere raro nei dati di addestramento, contraddittorio, cambiato nel tempo o semplicemente non disponibile. La domanda può contenere una premessa falsa. Il contesto può essere incompleto oppure interpretato male.

Supponiamo di chiedere «Quale premio ricevette nel 2019 l’autore di questo libro?» senza fornire prove dell’esistenza del premio. La struttura della domanda invita a completare una relazione già data per vera. Un sistema poco capace di contestare le premesse può riempire il vuoto con una continuazione plausibile.

Esiste poi la propagazione dell’errore. Una volta introdotto un dettaglio sbagliato, i token successivi vengono generati anche a partire da quel dettaglio. Il testo può diventare sempre più coerente con la propria premessa falsa.

Ridurre tutto a «il modello non sa nulla» sarebbe altrettanto impreciso. Può possedere rappresentazioni utili e rispondere correttamente a molte domande, pur fallendo nel riconoscere quando la base informativa è insufficiente.

La sicurezza del tono non misura l’affidabilità

«Certamente» è una parola generata. Una percentuale dichiarata dall’assistente può essere anch’essa testo prodotto, senza una procedura di calibrazione che la renda significativa.

Anche le probabilità dei token hanno un altro oggetto: descrivono continuazioni linguistiche. Non sono automaticamente la probabilità che l’intera affermazione sia vera. Una formula molto comune può essere altamente prevedibile e accompagnare un contenuto errato.

Un sistema è ben calibrato rispetto a un compito se, tra le risposte cui assegna una certa affidabilità, la frequenza di correttezza osservata corrisponde approssimativamente a quella stima. Per verificarlo servono molti casi con esito controllabile; non basta una singola risposta sicura.

Temperatura bassa: meno variabilità, non una garanzia

Se la continuazione sbagliata ha il punteggio massimo, una selezione deterministica può sceglierla ogni volta. Abbassare la temperatura può rendere il comportamento meno variabile, ma non aggiunge una fonte mancante.

Neppure ripetere la domanda e ottenere la stessa risposta costituisce una verifica indipendente: lo stesso sistema può riprodurre lo stesso errore. Il consenso tra risposte diventa utile solo se ne comprendiamo le dipendenze e i limiti.

Verificare affermazioni, non soltanto paragrafi

Torniamo al laboratorio immaginario. Possiamo separare la sintesi in affermazioni: esiste il laboratorio Alba; è stato fondato nel 2018; è stato fondato a Padova; ha aperto una sede nel 2022. A ogni affermazione associamo il passaggio che la sostiene, la contraddice o non permette di deciderla.

Questa scomposizione evita che molti dettagli corretti nascondano una singola invenzione. Il lavoro FActScore propone una valutazione della precisione fattuale basata su affermazioni atomiche e fonti. È un riferimento utile per capire perché il giudizio globale «sembra corretto» sia troppo grossolano.

In un esempio didattico, se 8 affermazioni su 10 sono supportate, la quota supportata è 80%. Non è una probabilità universale di affidabilità del modello. Inoltre, due errori possono avere conseguenze molto diverse: sbagliare una virgola e sbagliare una scadenza non pesano allo stesso modo.

Che cosa aiuta davvero?

Per un riassunto, chiedere di restare nella fonte, riportare i passaggi pertinenti e segnalare le informazioni assenti rende il compito più controllabile. Per un fatto aggiornato, serve una fonte aggiornata. Per un calcolo, uno strumento deterministico può fornire una verifica del risultato, purché l’espressione inviata sia quella giusta.

Una citazione va controllata su tre livelli: la fonte esiste? Contiene il passaggio indicato? Quel passaggio sostiene davvero l’affermazione? Un collegamento autentico può essere irrilevante o usato fuori contesto.

Anche il recupero di documenti, che vedremo nella tappa successiva, lascia possibili errori: può trovare il testo sbagliato, omettere un’eccezione o fornire una versione superata. Migliorare l’accesso alle informazioni riduce alcune cause del problema; non sostituisce la valutazione.

Saper fermarsi è parte della qualità

Un assistente utile dovrebbe poter dire che una fonte non basta, chiedere un elemento mancante o distinguere un’ipotesi da un fatto. Se valutiamo soltanto quante domande ricevono una risposta, rischiamo di premiare chi risponde anche senza basi.

Conviene osservare insieme correttezza, copertura e astensioni appropriate. Un sistema che non risponde mai evita molte falsità ma non aiuta; uno che risponde sempre può nascondere l’incertezza. Il punto è scegliere un comportamento adatto al compito e alle conseguenze degli errori.

Tre cose da conservare

1. Plausibilità e verità sono proprietà differenti. La forma convincente non verifica il contenuto.
2. Gli errori possono riguardare le relazioni tra dettagli corretti. Controllare le singole affermazioni aiuta a individuarli.
3. Fonti, strumenti e astensione rendono il sistema più controllabile. Nessuno di questi elementi garantisce da solo l’assenza di errori.

La domanda utile diventa allora: come mettiamo a disposizione dell’IA le informazioni che le servono, e come distinguiamo la consultazione di un documento da un cambiamento del modello?

← Torna al percorso Capire l’IA

CAPIRE L’IA · 9 di N

Scriviamo una domanda e compare una risposta: una definizione, un programma, una spiegazione matematica. L’interfaccia ci mostra un testo che cresce. Che cosa sta accadendo, esattamente, tra una parola e la successiva?

Nelle tappe precedenti abbiamo incontrato token ed embedding e il meccanismo dell’attenzione. Ora possiamo unirli: un modello linguistico autoregressivo costruisce una continuazione calcolando, ripetutamente, una distribuzione sul prossimo token.

La frase è semplice, ma va aperta con cura. «Prevedere il prossimo token» descrive un obiettivo e un modo di generare; non significa che il calcolo interno sia una banale ricerca della parola più frequente.

Prima della prima parola

Il modello riceve un contesto: può includere istruzioni, messaggi precedenti, la domanda e materiali aggiuntivi. La conversazione viene rappresentata in un formato che distingue i ruoli e poi trasformata in token. Le rappresentazioni attraversano i blocchi della rete.

Alla posizione finale, il risultato viene trasformato in un elenco di punteggi, uno per ogni token del vocabolario. Questi punteggi si chiamano logit. Non sono ancora probabilità e possono essere positivi o negativi.

Una forma semplificata del passaggio finale è z = hW + b: h è il vettore elaborato dalla rete, W una matrice appresa e b un eventuale termine di bias. Ritroviamo moltiplicazioni e somme già viste negli articoli sulle reti neurali.

Un esempio con tre soli candidati

Riprendiamo «La chiave accanto ai libri era…». Per fare i conti, immaginiamo un vocabolario ridotto a tre continuazioni, ciascuna trattata come un token: «arrugginita», «piccola» e «nuova». Un tokenizer reale potrebbe suddividerle e un vero vocabolario comprenderebbe molte altre possibilità.

Supponiamo che i logit siano (2, 1, 0). Sono valori inventati per illustrare il meccanismo, non misure di un modello reale. Applicando la softmax otteniamo:

p_i = e^zᵢ / Σ_j e^zⱼ

Il denominatore è e² + e¹ + e⁰ ≈ 11,107. Le probabilità risultano circa 0,665, 0,245 e 0,090. Sommano a 1 perché abbiamo normalizzato sui tre candidati del nostro esempio.

Questa softmax somiglia a quella dell’attenzione, ma svolge un ruolo diverso. Nell’attenzione normalizzava collegamenti tra posizioni; qui normalizza punteggi sui possibili token in uscita.

Una distribuzione non è ancora una scelta

Con la selezione greedy si sceglie il candidato con probabilità massima: nel nostro esempio «arrugginita». Con il campionamento si estrae un candidato secondo la distribuzione: anche «piccola» o «nuova» possono essere selezionati.

La temperatura T modifica la distribuzione applicando la softmax ai logit divisi per T. Per T positivo e inferiore a 1 la distribuzione diventa più concentrata; per T maggiore di 1 diventa più uniforme. Il caso T = 0 viene spesso usato dalle interfacce per indicare una scelta deterministica, ma non si inserisce zero al denominatore della formula.

Nell’esempio, con T = 0,5 otteniamo circa (0,867; 0,117; 0,016); con T = 2 circa (0,506; 0,307; 0,186). Cambia la variabilità della scelta. Non abbiamo aggiunto nuove prove sulla chiave né reso automaticamente più vera una frase.

Altre strategie limitano i candidati: top-k conserva i k più probabili; top-p conserva un insieme dei più probabili sufficiente a raggiungere una massa cumulativa prefissata. Sono scelte di decodifica, distinte dai parametri appresi. La documentazione di Hugging Face presenta le principali strategie.

Il token scelto cambia il passo successivo

Dopo aver selezionato «arrugginita», la sequenza disponibile diventa «La chiave accanto ai libri era arrugginita». Il modello calcola una nuova distribuzione condizionata anche da questa aggiunta. Potrebbe seguire un punto, una virgola o un altro frammento di frase.

Non esiste una lista immutabile di parole future già pronta da svelare. Ogni scelta modifica il contesto delle successive. Implementazioni efficienti possono riutilizzare calcoli precedenti, per esempio attraverso una cache di key e value; il significato probabilistico del processo resta lo stesso.

Per una sequenza di token y₁, …, yₘ, la probabilità condizionata al contesto c si scompone così:

P(y₁, …, yₘ | c) = Π_t=1…m P(y_t | c, y₁, …, y_t−1)

È la regola della catena delle probabilità. Non assume che i token siano indipendenti: ciascun fattore dipende dai precedenti. Se tre scelte hanno probabilità condizionate 0,6, 0,5 e 0,8, quella specifica sequenza ha probabilità 0,24 nel modello semplificato.

Scegliere sempre il token localmente più probabile non garantisce di trovare la sequenza globalmente più probabile. E nemmeno la sequenza più probabile è necessariamente la risposta più utile o corretta.

Perché risponde a una domanda invece di limitarsi a continuarla?

L’addestramento iniziale può fornire capacità linguistiche generali, ma un assistente deve anche imparare a seguire istruzioni, rispettare formati e gestire richieste. Fasi successive usano esempi di comportamento desiderato e, in alcuni casi, preferenze o ricompense.

Un riferimento storico è il lavoro su InstructGPT e il feedback umano: mostra un percorso che combina esempi supervisionati e ottimizzazione sulla base di preferenze. Non è la ricetta obbligatoria di ogni assistente. Serve a distinguere la capacità di continuare testo dal comportamento di un sistema conversazionale.

Durante la conversazione ordinaria, i parametri rimangono normalmente fissi. La risposta cambia perché cambia il contesto e può cambiare la procedura di selezione. Un’eventuale memoria del prodotto, conservata fuori dal modello, è un ulteriore meccanismo.

Predire token può sostenere calcoli complessi?

Per completare correttamente un programma può essere utile rappresentare variabili, vincoli e dipendenze. Per spiegare un problema può essere utile costruire risultati intermedi. Un obiettivo espresso sui token può quindi favorire l’apprendimento di strutture interne più ricche di una semplice frequenza locale.

Il fatto che l’uscita sia generata in sequenza non decide da solo se una particolare prestazione meriti il nome di ragionamento. Occorre guardare il comportamento: correttezza, robustezza a variazioni, generalizzazione e possibilità di verificare i passaggi. Una spiegazione fluida non dimostra di per sé che quei passaggi descrivano fedelmente tutti i calcoli interni.

Quando finisce la risposta?

La generazione può terminare con un token speciale di fine, una sequenza di arresto o il raggiungimento di un limite. La quantità di testo visualizzata dipende anche dall’applicazione. Se il sistema usa strumenti, una parte dell’uscita può diventare una richiesta strutturata anziché una frase destinata all’utente.

La distinzione centrale resta questa: il modello assegna probabilità a continuazioni, mentre il sistema organizza contesto, selezione, strumenti e presentazione. Per comprendere un assistente bisogna osservare entrambi.

Tre cose da conservare

1. La rete produce punteggi, poi una distribuzione. La procedura di decodifica sceglie il token successivo.
2. Ogni scelta entra nel contesto delle successive. La risposta si costruisce attraverso dipendenze condizionate.
3. Probabilità linguistica e correttezza sono cose diverse. Una continuazione favorita dal modello può contenere un errore.

Quest’ultimo punto apre la prossima tappa: perché un testo costruito così può essere convincente anche quando racconta qualcosa di falso?

← Torna al percorso Capire l’IA

CAPIRE L’IA · 8 di N

«La chiave accanto ai libri era…»

Se proseguiamo con «arrugginita», colleghiamo l’aggettivo alla chiave, anche se tra i due compaiono altre parole. I libri sono più vicini al verbo, ma non sono il soggetto. Leggere una frase richiede di tenere insieme relazioni che la semplice vicinanza non basta a descrivere.

Come può una rete neurale rappresentare queste relazioni? Uno dei meccanismi più importanti si chiama attenzione. È alla base dei Transformer, la famiglia di architetture su cui sono costruiti molti modelli linguistici.

Il nome suggerisce un’esperienza umana. Qui indica invece un calcolo: confrontare rappresentazioni numeriche e combinare informazioni con coefficienti diversi. Per capirlo, seguiremo un esempio abbastanza piccolo da poterlo verificare a mano.

Una rappresentazione cambia con il contesto

Il modello riceve una sequenza di token: unità che possono corrispondere a parole, parti di parola o segni di punteggiatura. Per rendere leggibili gli esempi, tratteremo ogni parola come un token. Un tokenizer reale potrebbe suddividerla diversamente.

A ogni token viene associato un vettore, cioè una lista di numeri. Ma una rappresentazione iniziale, da sola, non descrive ancora il ruolo di quella parola nella frase. «Chiave» può comparire accanto a una porta, in una spiegazione musicale oppure nell’espressione «la chiave del problema».

L’attenzione permette alla rappresentazione di una posizione di incorporare informazioni provenienti da altre posizioni. Il risultato è un vettore che dipende anche dal contesto disponibile. Nei blocchi successivi, il processo si ripete su rappresentazioni già trasformate.

Nella nostra frase, trasferire informazioni da «chiave» alla posizione «era» potrebbe essere utile per prevedere il seguito. È un’intuizione linguistica che motiva l’esempio: non stiamo misurando il comportamento di un modello reale né affermando che una particolare testa impari necessariamente questo collegamento.

Query, key e value: tre ruoli numerici

Da ciascun vettore di ingresso x si calcolano tre vettori, mediante tre matrici di parametri:

q = xW_Q   ·   k = xW_K   ·   v = xW_V

La query viene confrontata con le key delle posizioni consentite. Questi confronti producono punteggi. I value contengono invece le informazioni che verranno combinate usando coefficienti derivati dai punteggi.

Possiamo ricordare i tre ruoli così: query e key determinano quanto pesa un collegamento; il value determina che cosa viene trasferito attraverso quel collegamento. Non sono domande e risposte scritte in italiano: sono vettori.

Si parla di self-attention quando query, key e value derivano dalla stessa sequenza di rappresentazioni. Ogni posizione può così interagire con altre posizioni della sequenza, rispettando gli eventuali vincoli di accesso.

Facciamo il conto: da tre punteggi a tre coefficienti

Consideriamo una sola query, associata a «era», e limitiamo artificialmente il confronto a tre posizioni: «chiave», «libri» ed «era». Le altre parole sono escluse solo per tenere corto il calcolo. Scegliamo vettori di due componenti:

q = (√2, 0)
k_chiave = (2, 0)
k_libri = (0, 0)
k_era = (1, 0)

Questi numeri sono inventati a scopo didattico. Non derivano da un addestramento e non attribuiamo alle singole componenti un significato grammaticale.

Per ciascuna key calcoliamo il prodotto scalare con q: moltiplichiamo le componenti corrispondenti e sommiamo. Dividiamo poi per √d_k, dove d_k è il numero di componenti di query e key. Qui d_k = 2, quindi otteniamo:

s_chiave = 2   ·   s_libri = 0   ·   s_era = 1

La divisione per √d_k serve a controllare la scala dei punteggi al crescere della dimensione dei vettori. Applichiamo quindi la softmax: eleviamo e a ciascun punteggio e dividiamo per la somma dei risultati.

α_j = e^sⱼ / Σ_r e^sᵣ

Il denominatore vale e² + e⁰ + e¹ ≈ 11,107. I coefficienti risultano circa 0,665 per «chiave», 0,090 per «libri» e 0,245 per «era». Sono positivi e sommano a 1, salvo arrotondamenti.

Un punteggio zero non implica un coefficiente zero: e⁰ vale 1. Inoltre, i coefficienti dipendono da tutti i candidati nel denominatore. Aggiungere una posizione può modificare la distribuzione anche se gli altri punteggi restano uguali. Per la formulazione tecnica si può consultare il capitolo sulle funzioni di punteggio dell’attenzione di Dive into Deep Learning.

Il risultato è una combinazione di informazioni

Finora abbiamo stabilito quanto pesano i collegamenti. Ora scegliamo i value dell’esempio:

v_chiave = (1, 0)
v_libri = (0, 1)
v_era = (0,5; 0,5)

Il punto e virgola nell’ultimo vettore separa le componenti, entrambe pari a un mezzo. L’uscita della testa, per la query considerata, è la somma dei value moltiplicati per i rispettivi coefficienti:

z ≈ 0,665 · (1, 0) + 0,090 · (0, 1) + 0,245 · (0,5; 0,5)
z ≈ (0,788; 0,212)

Il risultato non è la parola «chiave» e non è ancora la previsione «arrugginita». È un nuovo vettore, ottenuto mescolando informazioni. Altri calcoli della rete lo elaboreranno prima di produrre una distribuzione sui possibili token successivi.

Questa distinzione evita un equivoco: il coefficiente 0,665 non significa che il modello sia sicuro al 66,5% del soggetto della frase. Descrive il contributo di un value a questa specifica combinazione.

La formula compatta, letta un pezzo alla volta

Raccogliendo tutte le query, key e value nelle matrici Q, K e V, il calcolo si scrive:

Attention(Q, K, V) = softmax(QK^T / √d_k + M)V

QK^T raccoglie i confronti fra le posizioni. La divisione ne regola la scala. M applica un’eventuale maschera. La softmax, calcolata separatamente su ogni riga, produce i coefficienti. La moltiplicazione finale per V combina i value.

La formula è una versione in blocco dei conti appena svolti: ogni riga corrisponde a una query. Non occorre memorizzarla per seguire l’idea; basta riconoscere i passaggi confrontare, normalizzare, combinare.

Per prevedere il prossimo token, non si può leggere il futuro

Durante l’addestramento di un modello autoregressivo, la sequenza completa è disponibile. Ma se chiediamo al modello di prevedere la parola dopo «era», permettergli di leggere quella parola significherebbe mostrargli la soluzione.

La maschera causale impedisce questa scorciatoia: ogni posizione può leggere se stessa e le precedenti, ma non le successive. In M si usa 0 per i collegamenti consentiti e, idealmente, −∞ per quelli vietati; dopo la softmax questi ultimi hanno coefficiente zero.

In addestramento si possono calcolare in parallelo le previsioni di molte posizioni, mantenendo questa restrizione. Durante la generazione, invece, il modello produce un token, lo aggiunge al contesto e calcola il successivo. Il parallelismo dell’addestramento non elimina la dipendenza sequenziale della generazione autoregressiva.

Che cosa aggiunge un Transformer?

Il Transformer fu presentato nel 2017 da Vaswani e colleghi in Attention Is All You Need. L’architettura originale comprendeva un encoder e un decoder, pensati per compiti come la traduzione. Molti modelli generativi di testo usano invece un’architettura di tipo decoder-only.

L’attenzione ne è un ingrediente centrale. Un blocco include anche una rete feed-forward, che trasforma separatamente la rappresentazione di ciascuna posizione, normalizzazioni e connessioni residue, che sommano l’ingresso di un sottoblocco al suo risultato.

L’attenzione multi-head esegue più calcoli di attenzione con proiezioni diverse. Le uscite delle teste vengono concatenate e proiettate nuovamente. Questo offre più modi di combinare il contesto, senza assegnare necessariamente a ogni testa una funzione linguistica fissa o facilmente interpretabile.

Serve inoltre informazione sulla posizione: il puro confronto tra vettori non codifica da solo l’ordine della sequenza. Le architetture la introducono con codifiche o altri meccanismi posizionali. Una descrizione dei componenti è nel capitolo sull’architettura Transformer di Dive into Deep Learning.

La maschera dipende dal compito. Un encoder può usare anche il contesto successivo; un decoder autoregressivo deve escluderlo. Nella cross-attention, infine, le query provengono da una sequenza e key e value da un’altra, per esempio dal testo sorgente durante la traduzione.

Che cosa viene imparato, e che cosa viene ricalcolato?

Nell’articolo Come si addestra una rete neurale? abbiamo seguito errore, gradiente e aggiornamento dei pesi. Lo stesso principio vale qui: la funzione di perdita permette di calcolare gradienti e aggiornare anche W_Q, W_K e W_V.

I coefficienti di attenzione, invece, sono calcolati sul testo in ingresso. Cambiano al cambiare della sequenza, della posizione, della testa e dello strato. Durante il normale utilizzo, questo avviene con parametri fissi: adattare una rappresentazione al contesto non equivale a riaddestrare il modello.

La parola «pesi» può indicare entrambe le cose nel linguaggio informale. Conviene distinguerle: parametri appresi da una parte, coefficienti di attenzione calcolati dall’altra.

Collegare il contesto non garantisce la comprensione

Una mappa di attenzione può mostrare quali posizioni contribuiscono a una combinazione interna. Da sola, però, non dimostra perché l’intero modello abbia prodotto una risposta. Entrano in gioco value, proiezioni, altri strati e percorsi residui. Il lavoro Attention is not Explanation discute proprio i limiti dell’uso dei coefficienti come spiegazione del comportamento.

Anche il contesto ha un costo. Nell’attenzione densa standard, una sequenza di n token comporta un numero di confronti tra posizioni proporzionale a n². Raddoppiare la lunghezza quadruplica questi confronti, a parità delle altre dimensioni. Esistono implementazioni e varianti che ne migliorano l’efficienza; la formula descritta qui serve a capire il meccanismo di base.

L’attenzione consente di costruire rappresentazioni sensibili alle relazioni tra token. La correttezza di una risposta rimane un’altra questione: dipende da ciò che il modello ha appreso, dal contesto e dal compito.

Tre cose da conservare

1. L’attenzione combina vettori in base al contesto. Query e key determinano i coefficienti; i value forniscono le informazioni da combinare.
2. Un Transformer organizza più trasformazioni. Attenzione, reti feed-forward, posizioni, normalizzazioni e percorsi residui lavorano insieme.
3. Contestualizzare non significa riaddestrare. I coefficienti cambiano con l’ingresso, mentre i parametri restano normalmente fissi durante l’utilizzo.

Nella frase iniziale, «chiave» e «arrugginita» sono separate nello spazio ma legate nella struttura. L’attenzione offre alla rete un modo numerico per mettere in relazione posizioni distanti. È questo passaggio — da una lista di token a rappresentazioni che incorporano il contesto — che rende il meccanismo così utile per il linguaggio.

Torna alla pagina della serie Capire l’IA

CAPIRE L’IA · 7 di N

Una rete neurale moltiplica numeri, somma risultati e applica funzioni. Ma quando scriviamo «Il gatto dorme», non le stiamo consegnando una matrice: le stiamo consegnando del testo. Come si passa dall’uno all’altra?

Il passaggio comprende due idee diverse: dividere il testo in unità identificabili e associare a queste unità rappresentazioni numeriche che la rete possa elaborare. Le prime sono i token. Le seconde sono gli embedding.

Seguiamo una frase fino ai suoi vettori. Useremo numeri inventati e molto piccoli, così da poter controllare ogni passaggio senza nasconderlo dietro una libreria software.

Il testo è già digitale. Che cosa manca?

Un computer conserva già il testo mediante una codifica: per esempio UTF-8 rappresenta i caratteri attraverso sequenze di byte. Quella codifica permette di memorizzare e ricostruire ciò che scriviamo, ma non è una rappresentazione appresa per un compito linguistico.

Possiamo pensare alla differenza tra il codice di catalogo di un libro e una descrizione del suo contenuto. Il codice permette di individuarlo. La descrizione offre informazioni utilizzabili per confrontarlo con altri libri. Anche questa analogia ha un limite: un embedding non è una scheda compilata da qualcuno, ma un vettore i cui valori vengono normalmente appresi.

Un token non coincide necessariamente con una parola

Un tokenizer trasforma il testo in una sequenza di unità. A seconda del sistema, queste possono corrispondere a parole, frammenti, punteggiatura o sequenze di byte. I metodi a sottoparole consentono di comporre molte parole usando un vocabolario di frammenti riutilizzabili. La segmentazione non coincide necessariamente con sillabe o morfemi.

Spazi, maiuscole e accenti possono cambiare la sequenza ottenuta. Non esiste quindi un conteggio universale dei token di una frase: dipende dal tokenizer. Modello e tokenizer devono essere compatibili, come spiega la guida di Hugging Face alla tokenizzazione.

Per il nostro esempio inventiamo questa suddivisione:

Il gatto dorme. → [Il] [·gatto] [·dorm] [e] [.]

Il punto mediano «·» indica uno spazio incluso nel token: è soltanto un segno esplicativo, non un carattere aggiunto alla frase. «Dorme» occupa due token. La frase contiene tre parole e, nel nostro sistema didattico, cinque token.

Non stiamo mostrando l’output di un tokenizer commerciale. Abbiamo costruito una regola semplice e dichiarata: serve a separare il concetto generale dai dettagli di una particolare implementazione.

Gli ID sono indirizzi, non significati

Il vocabolario associa a ogni token un numero intero, il suo ID. Nel nostro piccolo vocabolario assegniamo 1 a «Il», 2 a «·gatto», 3 a «·dorm», 4 a «e» e 5 al punto. La frase diventa la sequenza:

[1, 2, 3, 4, 5]

Questo è già un elenco di numeri, ma usarli come quantità sarebbe fuorviante. L’ID 4 non contiene il doppio del significato dell’ID 2. E due ID consecutivi non identificano necessariamente token simili.

Potremmo rinumerare il vocabolario senza cambiare il funzionamento del modello, purché riordinassimo coerentemente tutte le strutture che dipendono da quegli indici. Il numero serve a trovare una voce, come il numero di uno scaffale.

L’embedding: dalla voce di vocabolario a un vettore

Introduciamo una matrice E con una riga per ogni token del vocabolario. Ogni riga contiene d numeri. Nel nostro esempio ci sono otto voci e tre componenti per vettore: E ha dimensione 8 × 3.

Aggiungiamo al vocabolario «·cane», «·tavolo» e un token di riempimento, «<pad>», al quale riserviamo l’ID 0. Il riempimento può servire a costruire gruppi di sequenze della stessa lunghezza; qui non compare nella frase.

L’operazione essenziale è una selezione:

embedding del token con ID i = E[i]

Per «·gatto», che ha ID 2, leggiamo la riga 2: (0,8; 0,6; 0). Il punto e virgola separa le componenti, mentre la virgola è il separatore decimale.

Applicando la stessa operazione ai cinque ID otteniamo cinque vettori, ciascuno con tre componenti. La frase diventa quindi una matrice 5 × 3: una riga per posizione, una colonna per componente. In un modello reale le dimensioni sono maggiori, ma il principio è lo stesso.

Il vocabolario e la lunghezza della frase svolgono ruoli distinti. La tabella E ha una riga per ogni token possibile; la matrice della frase ha una riga per ogni token effettivamente presente. Un token ripetuto seleziona più volte la stessa riga di E.

Un piccolo ponte con l’algebra

La selezione di una riga si può descrivere anche con un vettore one-hot: tutti zeri, tranne un 1 nella posizione dell’ID. Per l’ID 2, contando da zero:

u = (0, 0, 1, 0, 0, 0, 0, 0)
uE = (0,8; 0,6; 0)

La moltiplicazione annulla tutte le righe tranne quella scelta. È una descrizione matematica utile; in pratica si può recuperare direttamente la riga senza costruire il lungo vettore di zeri.

La distinzione è anche geometrica. Due vettori one-hot relativi a token diversi sono sempre perpendicolari: codificano l’identità, senza graduare la somiglianza. Gli embedding possono invece assumere direzioni e distanze diverse.

Che cosa significa che due embedding sono vicini?

Riprendiamo due righe della tabella:

gatto = (0,8; 0,6; 0)
cane = (0,7; 0,7; 0)

Una misura comune è la similarità coseno, che confronta la direzione di due vettori non nulli:

cos(a, b) = (a · b) / (‖a‖ ‖b‖)

Il prodotto scalare al numeratore vale 0,8 × 0,7 + 0,6 × 0,7 = 0,98. Le lunghezze dei vettori sono 1 e √0,98. Otteniamo quindi 0,98 / √0,98 ≈ 0,990: le direzioni sono molto vicine.

Per «tavolo», il cui vettore abbiamo scelto come (0; 0,1; 0,9), la similarità con «gatto» è invece circa 0,066. Abbiamo costruito noi questa geometria: il risultato verifica i conti, non dimostra una proprietà di un modello addestrato.

In rappresentazioni apprese, relazioni geometriche possono riflettere regolarità linguistiche utili al compito. Ma «vicino» non significa automaticamente «sinonimo». Anche parole opposte possono comparire in contesti simili. E il coseno non è una probabilità: 0,990 non significa «99% di probabilità di avere lo stesso significato».

Nemmeno le coordinate sono necessariamente proprietà leggibili come «animalità» o «dimensione». L’informazione può essere distribuita tra molte componenti. Disegnare vettori in due dimensioni aiuta a capire la geometria; proiettare embedding reali su un piano, invece, può perdere e deformare relazioni.

Da dove arrivano i numeri della tabella?

Nel nostro esempio li abbiamo scelti a mano. In un modello linguistico addestrato da zero, la tabella viene tipicamente inizializzata con valori casuali e aggiornata insieme agli altri parametri. Si possono anche riutilizzare rappresentazioni già addestrate.

Il meccanismo è quello incontrato nell’articolo Come si addestra una rete neurale?: la rete produce una previsione, la perdita misura l’errore e la retropropagazione calcola i gradienti. L’ottimizzatore usa questi gradienti per aggiornare anche i valori della matrice degli embedding, quando sono addestrabili.

Non occorre assegnare manualmente una definizione a ogni parola. L’obiettivo di addestramento premia rappresentazioni che contribuiscono a svolgere il compito. Questo non garantisce che la geometria ottenuta corrisponda perfettamente alle nostre categorie linguistiche.

Durante il normale utilizzo, la tabella resta fissa. Selezionare una riga per una nuova frase è un calcolo, non un nuovo apprendimento.

Una stessa parola può avere più significati

«Ho perso la chiave di casa.»
«Questa è la chiave del problema.»

Se «chiave» corrisponde allo stesso token, il suo embedding iniziale è lo stesso nei due casi. La sola tabella non decide quale uso sia pertinente. Inoltre, la semplice selezione delle righe non incorpora di per sé l’ordine: per rappresentarlo occorrono meccanismi posizionali.

Nei Transformer, i blocchi successivi combinano le informazioni disponibili nel contesto e trasformano i vettori. Distinguiamo dunque embedding iniziale del token e rappresentazione contestuale di una sua occorrenza. Quest’ultima può cambiare tra le due frasi, anche con parametri fissi.

È il punto da cui parte l’articolo 08, «L’attenzione e i Transformer: collegare le parole nel contesto»: come può la rappresentazione di una posizione incorporare informazioni provenienti dalle altre?

Dal vettore al testo, e tre conseguenze pratiche

Un modello generativo compie anche il percorso verso l’uscita: dalla rappresentazione finale calcola punteggi per i token del vocabolario, li trasforma in una distribuzione e una procedura di generazione seleziona il token successivo. Il tokenizer riconverte poi la sequenza di ID in testo. Non si tratta semplicemente di scegliere l’embedding più vicino.

Da quanto abbiamo visto seguono tre conseguenze. Il limite di contesto espresso in token non corrisponde a un numero fisso di parole. Lingue, nomi rari e stringhe insolite possono avere segmentazioni molto diverse. Infine, un embedding dell’intera frase o di un documento richiede un metodo per produrre una rappresentazione complessiva: non coincide automaticamente con una delle righe della tabella dei token.

Tre cose da conservare

1. Il token è un’unità di elaborazione. Può essere una parola, un frammento o un’altra unità prevista dal tokenizer.
2. L’ID identifica; l’embedding rappresenta. Il primo seleziona una riga, il secondo offre un vettore che la rete può trasformare.
3. Il contesto richiede altri calcoli. L’embedding iniziale è il punto di partenza per costruire rappresentazioni sensibili alla frase.

Le parole diventano elaborabili attraverso una sequenza concreta di operazioni: segmentazione, identificazione e selezione di vettori. È da queste rappresentazioni numeriche che la rete comincia a costruire relazioni utili sul linguaggio.

← Torna al percorso Capire l’IA

CAPIRE L’IA · 6 di N

Errore, gradiente e aggiornamento dei pesi: seguiamo un piccolo addestramento, un passo alla volta.

Nell’articolo precedente abbiamo costruito una rete neurale: due ingressi, tre unità nascoste, un’uscita e tredici parametri. Inserendo i numeri 2 e 1, la rete restituiva 1,5.

Adesso le forniamo un esempio accompagnato dal risultato atteso: per quell’ingresso vorremmo ottenere 2. La previsione è troppo bassa. Che cosa dobbiamo cambiare?

Non basta dire “aumenta i pesi”. Alcuni collegamenti hanno pesi negativi, alcune unità possono produrre zero, e lo stesso parametro può influenzare molti esempi in modi diversi. Serve un procedimento che misuri l’errore e calcoli come una piccola modifica di ciascun parametro lo influenzerebbe.

Qui entra il gradiente. Il suo ruolo diventa più chiaro se, prima di parlare di milioni di pesi, ne osserviamo uno solo.

Il ciclo: prevedere, misurare, derivare, aggiornare

Consideriamo un addestramento supervisionato. Disponiamo di ingressi e risultati attesi. La rete esegue il calcolo in avanti, produce una previsione e una funzione di perdita ne misura lo scostamento dal riferimento. Calcoliamo poi le derivate della perdita rispetto ai parametri e usiamo un ottimizzatore per aggiornarli.

Il processo si ripete sugli esempi disponibili. All’inizio i pesi di una nuova rete vengono in genere inizializzati con valori casuali secondo criteri appropriati; si può anche partire da un modello già addestrato. Nel nostro esperimento partiamo invece dai coefficienti scelti nell’articolo precedente, così possiamo seguire tutti i passaggi.

L’apprendimento avviene quando cambiano i parametri. Calcolare una previsione, da solo, non modifica la rete.

Dall’errore a una quantità da minimizzare

Indichiamo la previsione con ŷ, “y cappello”, e il risultato atteso con y. Lo scarto con segno è:

Elevare al quadrato evita che scarti positivi e negativi si annullino quando vengono mediati, e dà più peso agli scarti grandi. È una scelta adatta al nostro esempio numerico, non l’unica possibile: per altri compiti si usano altre perdite.

Lo scarto −0,5 e la perdita 0,25 non sono la stessa cosa. Il primo descrive quanto e in quale verso abbiamo sbagliato la previsione; la seconda quantifica ciò che l’addestramento cerca di ridurre.

Fermiamo dodici parametri e muoviamone uno

Per l’ingresso (2, 1), lo strato nascosto della nostra rete produce h₁ = 1, h₂ = 2 e h₃ = 0. L’uscita è:

Teniamo fissi tutti i parametri tranne v₁, che per semplicità chiamiamo v. Poiché h₁ = 1, l’uscita si semplifica:

Abbiamo ottenuto una parabola. Sull’asse orizzontale c’è un peso della rete, non un dato in ingresso; sull’asse verticale c’è la perdita. Il punto più basso si trova in v = 2,5. In questo caso lo vediamo subito, ma useremo comunque un procedimento iterativo per capire che cosa accade quando la soluzione non è evidente.

La derivata è una pendenza locale

La derivata della perdita rispetto a v è:

Quel −1 ci dice che, nelle immediate vicinanze del punto attuale, aumentare v tende a diminuire la perdita. Non indica quanto siamo lontani dalla soluzione e non autorizza un salto arbitrariamente grande.

La lettura più precisa è: per una piccola variazione Δv, ΔL ≈ (dL/dv)Δv. È un’approssimazione locale. La funzione può cambiare pendenza mentre ci spostiamo, quindi dopo il passo dobbiamo ricalcolare.

Per visualizzarlo, immaginiamo una pallina su un pendio. La pendenza suggerisce una direzione di discesa; non fornisce una mappa completa del terreno. La metafora va usata con cautela: nell’algoritmo siamo noi a stabilire quanto muovere i parametri.

La regola di aggiornamento

La discesa del gradiente usa una regola semplice:

Scegliamo η = 0,1. Otteniamo:

La perdita è scesa da 0,25 a 0,16. Ora la derivata vale −0,8: un secondo aggiornamento porta il peso a 2,18. La previsione sale a 1,68 e la perdita scende a 0,1024. Ogni passo usa la pendenza nel punto raggiunto, non quella iniziale.

Il segno meno nella regola è importante: ci muoviamo nel verso opposto alla crescita locale della perdita. La diminuzione effettiva, però, dipende anche dall’ampiezza del passo.

Un passo troppo grande può peggiorare tutto

Ripartiamo sempre da v = 2 e confrontiamo tre valori di η. Con 0,1 ci avviciniamo gradualmente a 2,5. Con 0,8 oltrepassiamo il minimo e oscilliamo, ma con scarti sempre più piccoli. Con 1,1 le oscillazioni crescono: la perdita aumenta.

Nel terzo caso il primo aggiornamento porta v a 3,1. La perdita diventa (3,1 − 2,5)² = 0,36: è maggiore dello 0,25 iniziale. La direzione locale era corretta, ma il passo era troppo lungo.

Questa soglia dipende dalla forma e dalla scala della perdita. Non è una regola universale per le reti neurali. Anche moltiplicare la perdita per una costante modifica la scala del gradiente e quindi l’effetto dello stesso learning rate.

Da una derivata al gradiente

Nella rete completa i parametri sono molti. Li raccogliamo in un vettore θ, theta, che comprende pesi e bias. Il gradiente è il vettore delle derivate parziali della perdita rispetto a questi parametri:

Ogni derivata parziale misura la sensibilità locale della perdita a un parametro, tenendo fissi gli altri. Nell’aggiornamento standard i gradienti sono calcolati nello stesso stato della rete e poi usati per modificare insieme i parametri.

La nostra parabola è quindi soltanto un taglio a una dimensione del problema. Con una rete completa la superficie può essere molto più complessa: non bisogna immaginarla necessariamente come una valle regolare con un unico fondo.

Come si calcolano tutte quelle derivate?

Per il peso finale del nostro esempio possiamo scrivere:

È la regola della catena: il peso cambia la previsione e la previsione cambia la perdita. Moltiplichiamo gli effetti locali lungo quel percorso. Quando una quantità contribuisce attraverso più percorsi, si sommano i contributi.

La retropropagazione, o backpropagation, organizza questi calcoli partendo dalla perdita e risalendo il grafo delle operazioni. Riutilizza risultati intermedi, evitando di rifare separatamente gli stessi conti per ogni parametro. La distinzione fra propagazione in avanti e retropropagazione è illustrata in Dive into Deep Learning.

Possiamo vedere il principio anche dentro lo strato nascosto. Alla partenza, h₁ = ReLU(z₁), z₁ = 1 e il peso che collega h₁ all’uscita è 2. Dunque ∂L/∂h₁ = −1 × 2 = −2. Poiché ReLU ha derivata 1 in z₁ = 1, anche ∂L/∂z₁ = −2. Se w₁₁ moltiplica l’ingresso x₁ = 2, otteniamo ∂L/∂w₁₁ = −2 × 2 = −4.

Questo gradiente è calcolato nei valori iniziali della rete. Non lo abbiamo applicato nell’esperimento a un solo peso. Mostra però come l’informazione raggiunga un collegamento precedente, senza attribuirgli una “colpa” in senso umano.

Nella terza unità nascosta, z₃ = −1: la derivata di ReLU è zero e quel percorso non contribuisce al gradiente dei suoi pesi per questo esempio. Altri ingressi possono attivare l’unità. In zero ReLU non è derivabile; le implementazioni adottano una convenzione, comunemente una derivata impostata a zero.

Retropropagazione e ottimizzatore fanno lavori diversi

La retropropagazione calcola le derivate. L’ottimizzatore usa quelle derivate per aggiornare i parametri. La discesa del gradiente mostrata qui è una regola possibile; altri ottimizzatori usano anche informazioni accumulate nei passi precedenti.

Tenere separate queste due operazioni aiuta a capire perché possiamo cambiare il metodo di aggiornamento senza cambiare il significato delle derivate. Un gradiente descrive una sensibilità locale; l’ottimizzatore decide come sfruttarla.

Un esempio non basta: batch ed epoche

Abbiamo ripetuto i conti sullo stesso ingresso per rendere visibile il meccanismo. Un addestramento utile deve confrontarsi con molti esempi, che possono suggerire correzioni diverse. Spesso si lavora su piccoli gruppi, chiamati mini-batch, e si calcola la perdita media del gruppo.

Con il batch successivo, la direzione può cambiare. Per questo la perdita osservata durante un addestramento può oscillare e non diminuire a ogni aggiornamento.

Un’epoca è, nel caso ordinario di un dataset finito, un passaggio completo sui dati di addestramento. Se abbiamo 1.000 esempi divisi in batch da 100 e aggiorniamo dopo ogni batch, un’epoca contiene 10 aggiornamenti. Non significa un solo aggiornamento.

Quando smettere di correggere?

La perdita di training ci dice come stiamo ottimizzando gli esempi usati. Non dimostra che la rete stia diventando più utile sui casi nuovi. Come abbiamo visto nell’articolo sulla generalizzazione, una rete può continuare a migliorare sul training mentre peggiora sulla validazione.

Durante lo sviluppo controlliamo quindi anche dati separati e possiamo scegliere un punto di arresto sulla base della validazione. Il test finale serve a valutare la soluzione già scelta, senza guidare ulteriori correzioni.

Nella nostra parabola il minimo si può individuare esattamente. In una grande rete non abbiamo la stessa garanzia di trovare il miglior risultato possibile, né una perdita bassa rende automaticamente corretto il compito che abbiamo formulato. L’ottimizzazione risponde all’obiettivo numerico scelto.

La rete era partita da 1,5. Modificando un peso siamo arrivati a 1,6, poi a 1,68. Sono cambiamenti piccoli, ma ora sappiamo da dove provengono: una misura dell’errore, una derivata e una regola di aggiornamento. Ripetuti su molti parametri ed esempi, questi passaggi sono alla base dell’addestramento di gran parte delle reti neurali contemporanee.

← Torna al percorso Capire l’IA

CAPIRE L’IA · 2 di N

Una rappresentazione appresa: parametri, addestramento e utilizzo.

Immaginiamo di addestrare un piccolo sistema a stimare il prezzo delle case. Gli mostriamo superfici e prezzi, gli facciamo correggere le sue previsioni e, a un certo punto, interrompiamo l’addestramento.

Ora chiudiamo il file con gli esempi. Il sistema continua a stimare il prezzo di una casa che non aveva mai visto.

Che cosa gli è rimasto?

Questa domanda ci porta dentro una parola che ricorre ovunque quando si parla di intelligenza artificiale: modello. Nel primo articolo abbiamo osservato come si può imparare dagli esempi. Ora apriamo idealmente la scatola per capire che cosa contiene il risultato di quell’apprendimento.

Una rappresentazione che serve a fare qualcosa

Una mappa della metropolitana rappresenta una città selezionando ciò che serve al viaggiatore: stazioni, linee, coincidenze. Tralascia alberi, facciate, dislivelli; spesso deforma anche le distanze. La sua utilità dipende da ciò che vogliamo farne.

Anche un modello seleziona e rappresenta relazioni utili a un compito. Nel machine learning, queste relazioni vengono ricavate dai dati attraverso l’addestramento. Da qui l’idea centrale: un modello è una rappresentazione appresa, che permette di trasformare nuovi ingressi in risultati.

“Rappresentazione” non significa necessariamente un’immagine o una descrizione comprensibile. Può essere una funzione matematica, un insieme di regole decisionali o una rete di calcoli governata da numeri. Qui ci concentriamo sui modelli con parametri appresi, alla base di gran parte dell’IA contemporanea.

Apriamo un modello con appena due parametri

Riprendiamo per un momento le case. Supponiamo di aver scelto una relazione semplicissima:

prezzo stimato = a × superficie + b

La forma della relazione è stata scelta da chi costruisce il sistema. L’addestramento deve trovare valori utili per a e b. Questi numeri sono i parametri del modello.

In un esempio puramente didattico, il risultato potrebbe essere a = 2.000 €/m² e b = 30.000 €. Il primo numero indica quanto cresce la stima per ogni metro quadrato aggiuntivo; il secondo è il termine costante della formula. Non va interpretato automaticamente come il valore reale di una casa di zero metri quadrati.

Per stimare il prezzo di una casa di 70 m², bastano la formula e quei due numeri. Non occorre consultare di nuovo tutte le righe del file iniziale. Gli esempi hanno contribuito a determinare i parametri; i parametri ora governano il calcolo.

Questo modello resta molto povero: ignora quartiere, stato dell’immobile e numerose altre caratteristiche. Una rappresentazione può funzionare correttamente come calcolo ed essere insufficiente come descrizione del problema.

Addestrare significa cambiare ciò che resterà

Durante l’addestramento, il sistema produce stime sugli esempi disponibili, misura quanto si discostano dai risultati attesi e modifica i parametri secondo una procedura di ottimizzazione. Il criterio che quantifica l’errore viene chiamato funzione di perdita.

Nel nostro esempio, cambiare a significa modificare quanto pesa la superficie; cambiare b sposta tutte le stime della stessa quantità. Il sistema cerca una combinazione che riduca l’errore complessivo. Non è garantito che l’errore diventi nullo, né sarebbe sufficiente azzerarlo sugli esempi già visti per dimostrare che il modello funziona bene.

La prova decisiva arriva su dati tenuti fuori dall’addestramento. Un modello utile deve cogliere relazioni che valgano anche per casi nuovi: questa capacità si chiama generalizzazione. Adattarsi troppo alle particolarità degli esempi di partenza può invece peggiorare le prestazioni sui nuovi casi.

Utilizzare significa calcolare con ciò che si è appreso

Quando il modello già addestrato riceve un nuovo ingresso e produce un risultato, siamo nella fase di inferenza. Il nome può suonare astratto, ma nel nostro esempio significa semplicemente inserire 70 nella formula e ottenere 170.000.

La distinzione da conservare è questa: l’addestramento modifica i parametri; l’inferenza ordinaria li utilizza mantenendoli fissi.

Un modello può essere aggiornato o ulteriormente addestrato in seguito. Ma il fatto che produca una risposta non implica, da solo, che stia imparando da quella richiesta.

Dai due numeri di una retta ai parametri di un LLM

Una rete neurale contiene moltissimi parametri distribuiti fra operazioni collegate. Nei modelli linguistici, o LLM, queste operazioni trasformano il testo in rappresentazioni numeriche e calcolano, passo dopo passo, una distribuzione di probabilità sui possibili token successivi. Un token è un’unità di testo, che può corrispondere a una parola o a una sua parte.

I parametri vengono appresi attraverso grandi quantità di esempi e ulteriori fasi di addestramento. Nel loro insieme permettono di rappresentare regolarità linguistiche, associazioni e relazioni che sostengono le capacità del modello.

Qui però l’analogia con la retta ha un limite: in una grande rete neurale, di solito non possiamo indicare un singolo parametro e dire “questo contiene la grammatica” oppure “qui si trova la capitale della Francia”. L’informazione è distribuita; un parametro partecipa a molti calcoli e una capacità dipende dall’interazione di molti parametri.

Parlare di miliardi di parametri descrive quindi una dimensione del sistema. Non equivale a contare miliardi di fatti conosciuti e non basta, da solo, a stabilire quanto sarà affidabile.

Se ricorda la conversazione, sta cambiando?

Scriviamo a un assistente: “Da ora rispondi con frasi brevi”. Alla domanda successiva, l’assistente si adegua. È facile pensare che abbia appena modificato il proprio modello.

Normalmente accade qualcosa di diverso: l’istruzione è presente nel contesto fornito al modello insieme alla nuova domanda. Sono cambiati i dati in ingresso, mentre i parametri sono rimasti gli stessi. Anche imparare a svolgere un compito da alcuni esempi contenuti nella richiesta può avvenire senza aggiornare i parametri.

Anche una funzione di memoria dell’applicazione può conservare informazioni all’esterno del modello e ripresentarle nelle richieste successive. Per capire che cosa sta succedendo conviene separare sempre il modello dal servizio che lo utilizza.

Il modello è una parte dell’assistente

Un assistente può combinare un modello con istruzioni, cronologia, documenti, un motore di ricerca o una calcolatrice. Se risponde sulla base di un documento appena caricato, quel contenuto può essere stato fornito al momento dell’uso. Non è necessario che sia entrato nei suoi parametri.

Allo stesso modo, il fatto che un modello abbia incontrato un testo durante l’addestramento non significa che possa recuperarlo integralmente come farebbe un archivio. Può averne appreso alcune regolarità o informazioni; può anche aver memorizzato passaggi. Non offre però, per questo, le garanzie di conservazione e recupero di una banca dati.

La domanda “da dove arriva questa risposta?” può quindi avere risposte diverse: dai parametri appresi, dal contesto fornito in quel momento, da uno strumento esterno, o da una combinazione di questi elementi. Distinguerli aiuta a capire sia le capacità sia gli errori di un sistema.

Chiudiamo di nuovo il file con gli esempi. Nel nostro piccolo modello restano una formula e due numeri. In un grande modello linguistico resta una struttura di calcolo molto più complessa, con un’enorme quantità di valori appresi. Cambia la scala; resta la domanda che ci ha guidati: quale rappresentazione è stata costruita, e per quali compiti possiamo fidarci di usarla?

← Torna al percorso Capire l’IA

CAPIRE L’IA · 3 di N

Apprendimento supervisionato, non supervisionato e per rinforzo: tre modi diversi di dare una direzione all’apprendimento.

Immaginiamo un centro di assistenza informatica, che in maniera più consona si definisce SPOC o HD di I Livello. Ogni giorno arrivano richieste: una password da recuperare, un’applicazione che si blocca, una connessione che non funziona. Vorremmo usare l’intelligenza artificiale per gestirle meglio.

Abbiamo almeno tre possibilità. Possiamo mostrarle migliaia di richieste già assegnate al reparto corretto. Possiamo darle un archivio e chiederle di individuare richieste simili. Oppure possiamo farle sperimentare, in una simulazione, diverse strategie per gestire la coda, valutandone gli effetti.

In tutti e tre i casi diciamo che il sistema “impara”. Ma gli stiamo dando tre tipi diversi di informazione su cui basare l’apprendimento.

Nei primi due articoli abbiamo visto che un modello può apprendere modificando i propri parametri. Ora la domanda diventa: da dove arriva il segnale che orienta quelle modifiche?

1. Supervisionato: imparare con il risultato atteso

Apriamo l’archivio del centro di assistenza. Ogni richiesta è accompagnata dal reparto a cui avrebbe dovuto essere assegnata:

Richiesta	Etichetta attesa
«Ho dimenticato la password»	Gestione accessi
«Il programma si chiude quando salvo»	Supporto applicativo
«Non riesco a collegarmi alla rete»	Reti

Queste coppie costituiscono esempi di apprendimento supervisionato: un ingresso e un risultato atteso. Il modello produce una previsione, la confrontiamo con il riferimento e usiamo una misura dell’errore per guidare l’addestramento.

“Supervisionato” non significa che una persona debba stare accanto al computer a correggere ogni tentativo. Il riferimento può essere già registrato nei dati. L’etichetta può essere una categoria, come il reparto, oppure un numero, come il prezzo delle case incontrate nei primi articoli. Nel primo caso parliamo di classificazione; nel secondo di regressione.

Per la distinzione fra dati etichettati e non etichettati: IBM, Supervised vs. Unsupervised Learning.

Il risultato utile arriva quando il sistema riceve una richiesta nuova: «Non ricordo le credenziali». Questa frase potrebbe non essere mai comparsa nell’archivio, ma il modello dovrebbe riconoscere una relazione con i problemi di accesso. Copiare gli esempi non basta: deve generalizzare.

C’è però una domanda preliminare: le assegnazioni storiche erano corrette? Se nell’archivio un certo tipo di problema veniva sistematicamente mandato al reparto sbagliato, addestrare il modello a riprodurre quelle assegnazioni può rendere più efficiente lo stesso errore.

L’etichetta è il riferimento dell’addestramento. La sua presenza non la trasforma automaticamente in verità.

2. Non supervisionato: cercare una struttura senza categorie già assegnate

Ora togliamo la colonna dei reparti. Restano migliaia di richieste. Possiamo cercare gruppi di testi simili, senza fornire per ogni richiesta la categoria a cui dovrebbe appartenere.

Questo è un esempio di apprendimento non supervisionato. Uno dei suoi compiti tipici è il clustering, cioè il raggruppamento. Esistono anche altri obiettivi, come costruire rappresentazioni più compatte dei dati: “non supervisionato” non è sinonimo di “dividere in gruppi”.

Nel nostro archivio potrebbero emergere richieste relative alle credenziali, ai collegamenti di rete e ai malfunzionamenti dopo un aggiornamento. I nomi dei gruppi, però, sono un’interpretazione che possiamo attribuire dopo averne esaminato il contenuto. L’algoritmo non deve necessariamente produrre categorie già dotate di un significato operativo.

Che cosa vuol dire “simili”? Due richieste possono condividere le stesse parole, riguardare lo stesso prodotto o descrivere lo stesso guasto con parole diverse. La rappresentazione usata e il criterio di somiglianza influenzano i raggruppamenti.

Immaginiamo che tutte le richieste di un ufficio inizino con una lunga firma standard. Se quella parte pesa troppo, potremmo ottenere gruppi distinti per ufficio anche quando cercavamo tipi di guasto. Il risultato può essere coerente con il criterio di calcolo e poco utile per il nostro scopo.

“Non supervisionato” significa che mancano le etichette del compito, non che manchino scelte umane. Qualcuno seleziona i dati, decide come rappresentarli, sceglie il metodo e valuta se le strutture trovate servono davvero.

3. Per rinforzo: imparare dalle conseguenze delle azioni

Facciamo un altro passo. Non vogliamo soltanto classificare o esplorare le richieste: vogliamo decidere quale gestire adesso, con quali risorse, mentre continuano ad arrivarne altre.

Costruiamo una simulazione del centro di assistenza. Un agente osserva la situazione disponibile, sceglie un’azione e riceve dall’ambiente nuove osservazioni e una ricompensa, cioè un segnale numerico. L’apprendimento per rinforzo cerca una strategia, detta politica, che produca un buon ritorno cumulativo nel tempo.

Una politica indica come scegliere le azioni nelle situazioni incontrate. Non serve che qualcuno fornisca la mossa corretta per ogni situazione: l’agente apprende usando le conseguenze delle azioni. Una ricompensa non implica piacere o soddisfazione: è una quantità usata dall’algoritmo.

Per i concetti di agente, ambiente e ricompensa: Google Cloud, What is reinforcement learning?.

Nel nostro esperimento potremmo assegnare punti per problemi risolti e sottrarne per attese eccessive o richieste riaperte. Sono scelte didattiche, non una ricetta per un sistema reale.

La difficoltà è che un’azione modifica anche ciò che sarà possibile fare dopo. Occupare l’unico specialista disponibile con una richiesta semplice può rallentare un guasto importante che arriva poco più tardi. Una decisione conveniente nell’immediato può peggiorare il risultato complessivo.

Inoltre, il riscontro può arrivare in ritardo. Se una richiesta torna aperta il giorno dopo, quale decisione precedente ha contribuito al problema? Attribuire gli esiti alle azioni è una parte essenziale della difficoltà.

L’agente deve anche bilanciare esplorazione e sfruttamento: provare alternative per raccogliere informazioni oppure scegliere ciò che, secondo l’esperienza disponibile, sembra funzionare meglio. In un servizio reale, i tentativi hanno costi; ecco perché abbiamo collocato l’esempio in una simulazione. Esistono anche metodi che apprendono da esperienze già registrate, senza sperimentare direttamente durante l’addestramento.

La ricompensa può essere il problema

Supponiamo di premiare soltanto il numero di richieste chiuse. Quale comportamento potrebbe risultare vantaggioso?

Gestire prima tutti i casi facili, lasciando invecchiare quelli complessi. Oppure, se il sistema lo consente e la misura non verifica l’esito, chiudere richieste che non sono state davvero risolte. Il contatore migliora; il servizio peggiora.

Questo è un esempio ipotetico di un problema concreto: ottimizzare la misura scelta può allontanare dal risultato desiderato. La ricerca parla di specification gaming quando un sistema sfrutta una specifica imperfetta per ottenere un buon punteggio senza soddisfare l’intento del compito. DeepMind ne raccoglie e discute diversi esempi.

Aggiungere una penalità per le riaperture può migliorare il criterio, ma non esaurisce la progettazione. Bisogna chiedersi quali conseguenze la misura ignori e quali azioni debbano essere escluse mediante vincoli espliciti.

Tre segnali diversi, uno stesso ambiente

Metodo	Segnale disponibile	Nel nostro esempio
Supervisionato	Risultato atteso per gli esempi	Prevedere il reparto di una nuova richiesta
Non supervisionato	Regolarità nei dati, secondo un criterio scelto	Individuare gruppi di richieste simili
Per rinforzo	Ricompense legate ad azioni e conseguenze	Apprendere una strategia di gestione della coda

La differenza non sta nel fatto che uno usi esempi e gli altri no: anche un agente accumula esperienza, e anche un metodo non supervisionato analizza dati. Conta come è formulato il problema e quale informazione guida l’apprendimento.

Non sono tre gradini di una scala, dal meno al più intelligente. Rispondono a esigenze diverse e possono essere combinati. Un sistema potrebbe usare un classificatore per riconoscere le richieste e una politica per decidere come gestirle.

E un modello linguistico, dove si colloca?

Qui la tripartizione richiede un’aggiunta: l’apprendimento auto-supervisionato. Il segnale di riferimento viene ricavato dai dati stessi. Per esempio, possiamo usare l’inizio di un testo per prevederne il token successivo: il testo originale contiene già il riferimento con cui confrontare la previsione.

Non è necessario che una persona etichetti ogni passaggio. Il testo consente di costruire automaticamente coppie di contesto e token atteso. Durante l’addestramento si può così aumentare la probabilità assegnata al token effettivamente presente. Il riferimento osservato non è però l’unica continuazione linguisticamente possibile.

L’auto-supervisione è spesso ricondotta in senso ampio all’apprendimento non supervisionato, ma distinguerla aiuta: il sistema ha un bersaglio di previsione, costruito a partire dai dati. Yann LeCun e Ishan Misra illustrano questa idea nel blog di Meta AI.

Un modello linguistico può poi attraversare ulteriori fasi, con esempi di risposte desiderate o segnali di valutazione. Non tutte le procedure basate su preferenze sono apprendimento per rinforzo: la presenza di un giudizio umano, da sola, non identifica l’algoritmo. Per capire come è stato addestrato un sistema occorre guardare alle singole fasi.

Una piccola prova prima di proseguire

Un’azienda vuole usare un archivio di documenti. In quale situazione riconosci ciascun metodo?

1. Mostra documenti già associati a un ufficio e vuole assegnare quelli nuovi.
2. Cerca famiglie di documenti simili, senza fornire le categorie.
3. Fa sperimentare a un agente sequenze di azioni e valuta il risultato con un punteggio.
4. Nasconde una parte di ciascun testo e usa la parte originale come riferimento da prevedere.

Prova a rispondere cercando il segnale disponibile, prima di dare un nome al metodo.

Confronta il tuo ragionamento

1. Supervisionato: il riferimento è l’ufficio assegnato. 2. Non supervisionato: si cercano strutture senza categorie date. 3. Per rinforzo: azioni e conseguenze sono valutate mediante ricompense. 4. Auto-supervisionato: il bersaglio viene ricavato dal testo stesso.

Quando sentiamo dire che un’IA “impara da sola”, possiamo ora porre una domanda più precisa: da quali segnali sta imparando? Le etichette, la struttura dei dati, il testo da completare e le ricompense orientano capacità diverse. Guardare a quei segnali aiuta a capire non soltanto che cosa un sistema può imparare, ma anche quali errori rischiamo di insegnargli.

← Torna al percorso Capire l’IA

CAPIRE L’IA · 1 di N

Cinque case, due parametri e un errore: un piccolo esperimento per capire che cosa significa imparare dai dati.

Ti mostro quattro case. Di ciascuna conosci soltanto due cose: la superficie e il prezzo. Poi ti chiedo di stimare il prezzo di una quinta. Non puoi visitarla, non sai in quale città si trovi e non hai un agente immobiliare a cui telefonare.

Hai soltanto quattro esempi. Sono sufficienti per cominciare a fare una previsione?

Fermati un momento, prima di proseguire. Quale cifra hai in mente? E soprattutto: come ci sei arrivato?

La regola che nessuno ti ha consegnato

Forse hai pensato a 160.000 euro. Ogni volta che la superficie aumenta di 20 metri quadrati, il prezzo sale di 40.000 euro. La casa da 70 metri quadrati si trova a metà tra quella da 60 e quella da 80: hai assegnato anche al prezzo un valore intermedio.

Hai trovato una regolarità negli esempi e l’hai usata per un caso che non avevi visto. È un buon punto di partenza per capire una parte importante del machine learning: l’apprendimento supervisionato, nel quale forniamo a un sistema esempi accompagnati dal risultato che vorremmo prevedere.

Non significa che una macchina ragioni come hai appena ragionato tu. Significa che possiamo costruire un procedimento capace di cercare una regola a partire dai dati.

Mettiamo due manopole alla previsione

Scegliamo una famiglia di regole molto semplice: il prezzo cresce lungo una retta. Per descriverla bastano due numeri, che possiamo immaginare come due manopole: una controlla quanto aumenta il prezzo per ogni metro quadrato; l’altra sposta tutte le previsioni verso l’alto o verso il basso.

Proviamo con a = 2 e b = 0. Per 60 metri quadrati otteniamo 120.000 euro. Nel nostro elenco, però, il prezzo è 140.000. Anche le altre tre previsioni sono troppo basse di 20.000 euro. Portando b a 20, la regola riproduce tutti e quattro gli esempi.

Questo è il nostro primo modello: una regola di calcolo con parametri scelti usando i dati. Per costruirlo abbiamo deciso noi di usare una retta. I dati aiutano a scegliere i parametri; non scelgono da soli tutte le regole del gioco.

Dove avviene, esattamente, l’apprendimento?

Nel nostro esempio abbiamo trovato i parametri quasi a colpo d’occhio. Un algoritmo può cercarli in modo sistematico: produce previsioni, misura gli scarti rispetto ai prezzi noti e modifica i parametri per ridurre una misura complessiva dell’errore.

La parola “imparare”, qui, indica qualcosa di concreto: cambiare i parametri in modo da migliorare le prestazioni secondo un criterio scelto. Un criterio comune è la media dei quadrati degli scarti. Elevare gli scarti al quadrato impedisce che errori positivi e negativi si cancellino e dà più peso agli errori grandi.

Per una retta esistono anche metodi che calcolano direttamente i parametri migliori, senza procedere per correzioni successive. Il ciclo illustrato serve a capire il principio degli aggiornamenti iterativi, fondamentale nell’addestramento di molti modelli più complessi.

Una volta terminato l’addestramento, possiamo usare i parametri trovati per una nuova previsione. Questa fase si chiama inferenza. Fare una previsione non comporta, di per sé, imparare di nuovo: i parametri possono restare esattamente gli stessi.

Il momento della verità arriva con la quinta casa

Finora il modello ha visto quattro esempi costruiti apposta per allinearsi perfettamente. Un risultato impeccabile su quei quattro punti dice ancora poco sulla sua utilità. Proviamo allora con una casa tenuta da parte, che non abbiamo usato per scegliere i parametri.

Per 70 metri quadrati la regola prevede 160.000 euro. Immaginiamo che il prezzo osservato sia 168.000: abbiamo sbagliato di 8.000 euro. È tanto o poco? Dipende dallo scopo e dal termine di confronto. Un modello va valutato rispetto all’uso previsto e a un’alternativa ragionevole, anche molto semplice.

Una sola casa non basta per valutarlo. Servono molti casi nuovi e pertinenti. Il punto, però, è già visibile: la prova decisiva riguarda esempi che non hanno guidato l’apprendimento. Questa capacità di funzionare su casi nuovi si chiama generalizzazione.

Adesso cambiamo quartiere

Ecco il problema che la nostra retta non può risolvere. Arriva un’altra casa da 70 metri quadrati, ma in un quartiere molto più costoso. Il modello ripete 160.000 euro: per lui le due case sono identiche, perché gli abbiamo mostrato soltanto la superficie.

Non gli manca una calcolatrice migliore. Gli manca un’informazione. Potremmo aggiungere quartiere, stato dell’immobile, piano e altre caratteristiche. Dovremmo anche raccogliere esempi sufficientemente rappresentativi delle case su cui useremo il modello.

Aggiungere dati e variabili, però, non garantisce automaticamente il successo. Informazioni poco affidabili o un mercato cambiato possono rendere deboli le previsioni. La precisione del calcolo non elimina i limiti di ciò che abbiamo misurato.

E c’è un’altra distinzione da conservare: una relazione utile a prevedere non è, da sola, una spiegazione causale. La nostra retta descrive un andamento nei dati; non dimostra che aggiungere venti metri quadrati a una qualsiasi casa ne aumenterebbe il valore di esattamente 40.000 euro.

Da una retta a un modello che scrive

Un modello linguistico è enormemente più complesso di questa retta. Cambiano l’architettura, i dati, gli obiettivi di addestramento e il numero dei parametri. Non basta estendere l’esempio immobiliare per spiegare come funziona una conversazione.

Ma un’idea ci accompagna: durante l’addestramento vengono modificati parametri sulla base dei dati e di un criterio; durante l’uso, quei parametri contribuiscono a produrre una risposta a un nuovo ingresso. Su questo nucleo costruiremo i prossimi passi.

Quando qualcuno ti dirà che un sistema “ha imparato”, puoi cominciare con tre domande: da quali esempi? Per riuscire in quale compito? E su quali casi nuovi è stato verificato?

← Torna al percorso Capire l’IA