Forse vi hanno già parlato della metafora del pappagallo stocastico. O del motore di previsione. Sono metafore valide, ma rimangono astratte. Ecco come funziona davvero, con sufficiente precisione per prendere decisioni utili, senza una sola equazione.
Il token: l’unità di base
Un LLM non legge le parole. Legge i token. Un token è un frammento di testo: a volte una parola intera, a volte una parte di parola, a volte solo uno spazio o un segno di punteggiatura. In inglese, un token corrisponde in media a 3/4 di una parola. In francese, un po’ meno, poiché le parole sono in media più lunghe.
Perché è importante? Perché la lunghezza dei testi che inviate a un modello viene misurata in token, non in parole. E i costi delle API vengono fatturati per token. 1.000 token corrispondono all’incirca a 750 parole in inglese o a 650 in francese.
Quando si invia «Buongiorno, potete analizzare questo contratto?», il modello non riceve una frase. Riceve una sequenza di token: [«Bu», «on», «,», «pu», «te», «-tu», «anal», «izzare», «questo», «contra», «t», «?»] (approssimativamente, la suddivisione esatta dipende dal tokenizer del modello).
Il contesto: la memoria a breve termine
Un LLM non dispone di una memoria permanente. Ciò che «sa» della vostra conversazione è ciò che si trova nella finestra di contesto, ovvero la sequenza di token che riceve ad ogni richiamo.
La finestra di contesto ha una dimensione massima. GPT-4 Turbo può elaborare fino a 128.000 token. Claude 3.5 Sonnet, 200.000. È una quantità notevole. Ciò non significa che il modello utilizzi tutto con la stessa efficacia. Alcune ricerche dimostrano che i modelli tendono a ricordare meglio ciò che si trova all’inizio e alla fine della finestra rispetto a ciò che si trova nel mezzo. Non è una regola assoluta, ma è un bias documentato.
La temperatura: il compromesso tra creatività e affidabilità
Quando il modello prevede il token successivo, non sempre sceglie quello più probabile. Esiste un parametro chiamato ‘temperatura’ che regola il grado di casualità nella scelta.
Temperatura bassa (vicina allo 0): il modello sceglie quasi sempre il token più probabile. Risultato deterministico, ripetibile e affidabile per compiti basati sui fatti.
Temperatura alta (vicina a 1 o superiore): il modello amplia le sue opzioni, esplorando token meno probabili. Il risultato è più creativo e variegato, ma anche più incline a prendere direzioni inaspettate.
Per un caso d’uso concreto (estrazione di informazioni, verifica del formato, classificazione): temperatura bassa. Per la scrittura creativa: temperatura più alta. La maggior parte degli utenti non modifica questa impostazione; le interfacce predefinite utilizzano una temperatura intermedia.
Perché è incredibile, dal punto di vista meccanico
Ora conoscete tutti gli elementi: la previsione del token, il contesto, la temperatura. Metteteli insieme e l’allucinazione diventa inevitabile.
Il modello prevede il token successivo più probabile. Quando si tratta di un argomento su cui è stato addestrato in misura limitata (un evento recente, una persona poco conosciuta, una normativa specifica), non dispone di segnali chiari. Tuttavia, formula comunque una previsione, poiché non può astenersi dal farlo. E il token che prevede può essere plausibile formalmente (è una cifra plausibile per una data, è un nome plausibile per una persona) ma falso dal punto di vista fattuale.
Il modello non sa di non sapere. Non ha alcuna metacognizione riguardo alle proprie lacune. Genera con la stessa naturalezza sia la verità che l’invenzione.
I modelli addestrati con RLHF (Reinforcement Learning from Human Feedback) possono essere più inclini a produrre risposte fluide e sicure, anche su argomenti incerti, poiché gli annotatori umani tendono a preferire le risposte sicure a quelle esitanti.
Questo punto è fondamentale. La messa a punto tramite feedback umano (RLHF), che rende i modelli più piacevoli da usare, può aggravare il fenomeno delle allucinazioni in termini di sicurezza apparente. Gli annotatori umani premiano le risposte che sembrano sicure. Il modello impara a sembrare sicuro, anche quando non lo è.
Il RAG: un valido supporto, non una soluzione
RAG sta per Retrieval-Augmented Generation. L’idea è questa: invece di inserire tutto nel contesto o di chiedere al modello di «memorizzare» tutto durante l’addestramento, si recuperano al volo i documenti pertinenti e li si inseriscono nel contesto prima di porre la domanda.
Esempio: si dispone di un database di 10.000 contratti. Per ogni domanda, si individuano i 5 contratti semanticamente più vicini alla domanda, li si inserisce nel contesto e il modello risponde basandosi su questi documenti.
Il RAG riduce le ‘allucinazioni’ nell’ambito di applicazione. Se la risposta si trova nei documenti, il modello la troverà. Se non c’è, potrebbe comunque ‘allucinare’. E se i documenti stessi contengono errori, il modello li riporterà.
Cosa potete dedurne per i vostri casi d’uso
Questi meccanismi hanno implicazioni dirette:
Compiti adatti a un LLM: conversione di formati, sintesi, classificazione in categorie ben definite, generazione di codice basato su modelli comuni, prima bozza di testo.
Attività a rischio senza precauzioni: estrazione di informazioni fattuali precise (date, cifre, nomi propri), verifiche di natura giuridica o medica, ovvero tutto ciò che dipende da conoscenze recenti non presenti nei dati di addestramento.
Compiti non adatti senza un’architettura specifica: tutto ciò che richiede una memoria a lungo termine, tutto ciò che richiede un ragionamento formale garantito, tutto ciò che non tollera errori non rilevati.
La regola generale è questa: più alto è il costo di un errore nel vostro contesto, maggiore è la necessità di un meccanismo di convalida, manuale o automatizzata, dei risultati del modello. Questo meccanismo ha un costo. Tale costo rientra nel costo totale del vostro progetto di IA.