Che cos'è un large language model (LLM)?

#Che cos'è un large language model

Un large language model (LLM) è un programma che ha imparato, da una quantità molto grande di testo, quali pezzi di testo tendono a seguirne altri. Tu scrivi un prompt e il programma produce la risposta un piccolo pezzo alla volta. Visto dall'alto, il meccanismo è tutto qui. Il resto dell'articolo spiega come un compito così semplice diventa utile e dove si rompe.

La parola "large" si riferisce a due cose: la quantità di testo usata per addestrare il modello e il numero di valori numerici, detti parametri, che l'addestramento regola. La parola "model" significa che il programma assegna probabilità a sequenze di testo. Non cerca le risposte in un database e non ha un elenco di fatti da controllare prima di parlare. Genera testo a partire dagli schemi che ha assorbito durante l'addestramento.

Se hai usato uno strumento di chat con IA, hai usato un LLM. Il prodotto avvolge il modello in un'interfaccia, aggiunge istruzioni che non vedi mai e spesso lo collega a un motore di ricerca o ad altri strumenti. Questo articolo descrive il modello che sta sotto. Quando la risposta del prodotto sembra sbagliata, conviene sapere quale livello ha prodotto l'errore.

#Perché conta nel lavoro di sicurezza

Il lavoro di sicurezza vive di affermazioni. Un pacchetto è sicuro da installare. Una porta è chiusa. Una configurazione disattiva un controllo. Una vulnerabilità colpisce una certa versione. Un LLM scrive ogni affermazione con la stessa voce fluida, vera o falsa che sia. Se non sai come il modello produce il testo, è facile prendere per un finding un paragrafo scritto con sicurezza.

Capire il meccanismo cambia tre abitudini. Smetti di aspettarti che il modello sappia cose che non ha mai visto. Smetti di leggere la fluidità come una prova. E inizi a chiederti dove si può controllare ogni affermazione. Il NIST Generative AI Profile, pubblicato come NIST AI 600-1, elenca la confabulazione tra i rischi dei sistemi di IA generativa. La confabulazione è la produzione di contenuti errati esposti con sicurezza. Il profilo chiede alle organizzazioni di pianificare in funzione di questo rischio, invece di darlo per escluso.

#Come funziona, passo per passo

Il lavoro del modello si divide in poche fasi: il testo diventa token, i token diventano vettori, l'attention mescola il contesto, il modello prevede un token, e addestramento e inferenza rendono utile quella previsione. Le sezioni seguenti le affrontano in ordine.

#Passo 1: il testo diventa token

Il modello non legge direttamente lettere o parole intere. Legge token, cioè pezzi di testo scelti da un componente chiamato tokenizer. Un token può essere una parola intera, parte di una parola, uno spazio, un segno di punteggiatura o una breve sequenza di byte. Le parole comuni di solito diventano un solo token. Le parole rare, gli identificatori nel codice e il testo nelle lingue meno diffuse spesso si dividono in più token.

Il tokenizer impara i suoi pezzi dai dati prima che il modello venga addestrato. Un metodo comune è il byte-pair encoding, di solito abbreviato in BPE. Parte dai singoli caratteri e unisce ripetutamente la coppia di elementi adiacenti più frequente, finché il vocabolario non raggiunge la dimensione scelta. Il risultato è un elenco fisso di pezzi e una regola per dividere in quei pezzi qualsiasi testo nuovo.

Per rendere concreta l'idea, lo script seguente costruisce un piccolo BPE a partire da poche parole. È un giocattolo, non il tokenizer di un modello reale, ma il meccanismo è lo stesso. Salvalo come toy_bpe.py ed eseguilo con Python 3:

from collections import Counter

corpus = "low low low lower lowest newer newer newer wider wider new new"
words = Counter(tuple(w) + ("</w>",) for w in corpus.split())

def pair_counts(vocab):
    pairs = Counter()
    for word, freq in vocab.items():
        for a, b in zip(word, word[1:]):
            pairs[(a, b)] += freq
    return pairs

def merge(vocab, pair):
    out = Counter()
    for word, freq in vocab.items():
        new, i = [], 0
        while i < len(word):
            if i < len(word) - 1 and (word[i], word[i + 1]) == pair:
                new.append(word[i] + word[i + 1]); i += 2
            else:
                new.append(word[i]); i += 1
        out[tuple(new)] += freq
    return out

merges = []
vocab = words
for step in range(6):
    pairs = pair_counts(vocab)
    if not pairs:
        break
    best = max(pairs, key=lambda p: (pairs[p], p))
    merges.append(best)
    vocab = merge(vocab, best)
    print(f"merge {step + 1}: {best[0]!r} + {best[1]!r} -> {best[0] + best[1]!r} (count {pairs[best]})")

def tokenize(word):
    toks = list(word) + ["</w>"]
    for a, b in merges:
        i = 0
        while i < len(toks) - 1:
            if toks[i] == a and toks[i + 1] == b:
                toks[i:i + 2] = [a + b]
            else:
                i += 1
    return toks

for w in ["lowest", "newest", "widen"]:
    print(w, "->", tokenize(w))

L'output seguente viene dall'esecuzione di questo script su Windows 11 con Python 3.12.10. Il tuo dovrebbe coincidere riga per riga, perché lo script non usa casualità:

merge 1: 'r' + '</w>' -> 'r</w>' (count 6)
merge 2: 'e' + 'r</w>' -> 'er</w>' (count 6)
merge 3: 'w' + '</w>' -> 'w</w>' (count 5)
merge 4: 'n' + 'e' -> 'ne' (count 5)
merge 5: 'l' + 'o' -> 'lo' (count 5)
merge 6: 'w' + 'er</w>' -> 'wer</w>' (count 4)
lowest -> ['lo', 'w', 'e', 's', 't', '</w>']
newest -> ['ne', 'w', 'e', 's', 't', '</w>']
widen -> ['w', 'i', 'd', 'e', 'n', '</w>']

Leggi prima le fusioni. La coppia più frequente nel piccolo corpus è un marcatore di fine parola accanto a r, quindi quella fusione viene per prima. Le fusioni successive costruiscono pezzi come er</w> e lo, che riflettono grafie ripetute nel corpus. Poi guarda le divisioni. "lowest" si spezza in lo, w, e, s, t e il marcatore finale, perché il vocabolario giocattolo non ha mai imparato un pezzo per est o owe. "widen" si riduce quasi ai singoli caratteri. Il vocabolario del tokenizer copre quello che ha visto durante il proprio addestramento, e tutto il resto costa più pezzi.

Molti tokenizer reali lavorano sui byte e si addestrano su molto più testo, quindi i loro pezzi sono più lunghi e più numerosi. Il principio resta valido. Il testo frequente nei dati di addestramento costa poco, quello insolito costa più token. Questo ha effetti pratici. I modelli limitano input e output in base al numero di token, e i servizi di solito fanno pagare le richieste a token, quindi la stessa frase può costare cifre diverse in lingue diverse o nel codice.

#Passo 2: i token diventano vettori

Ogni token ha un identificatore intero. Il modello associa quell'identificatore a un vettore, un elenco di numeri spesso lungo centinaia o migliaia di valori. Questi vettori si imparano durante l'addestramento. I token che compaiono in contesti simili finiscono con vettori simili, così il modello può trattare "car" e "automobile" come parole collegate senza che nessuno abbia scritto una regola apposta.

Da qui in poi il modello lavora con numeri, non con caratteri. Non esamina le lettere dentro un token come faresti tu. È una spiegazione comune del perché i modelli a volte contano male le lettere di una parola o sbagliano un semplice gioco di ortografia. Le lettere non sono mai state presentate al modello come elementi separati.

#Passo 3: attention e transformer

La maggior parte degli LLM attuali si basa sull'architettura transformer, descritta in "Attention Is All You Need" di Vaswani e colleghi, pubblicato nel 2017 (arXiv:1706.03762). I modelli linguistici precedenti spesso leggevano il testo un token dopo l'altro, portandosi dietro un riassunto progressivo. Il transformer permette a ogni posizione di guardare direttamente le altre grazie a un meccanismo chiamato attention.

Per ogni token del contesto, l'attention calcola quanto peso dare a ciascun token precedente quando costruisce la rappresentazione di quello corrente. Impila molti livelli di attention e piccole reti feed-forward, e il modello si costruisce un quadro ricco del contesto. Può collegare un pronome al nome a cui si riferisce, abbinare una chiamata di funzione a una definizione qualche riga più in alto o capire a quale parte di una domanda deve rispondere.

Per usare bene questi modelli non ti serve la matematica. Il fatto utile è che la lettura di un token dipende dai token che lo circondano, in tutto il contesto. Cambia una parola in un prompt e con essa può cambiare la rappresentazione di molte altre parole. Per questo piccole modifiche al testo a volte producono grandi cambiamenti nella risposta.

#Passo 4: prevedere il token successivo

In cima ai livelli, il modello produce un punteggio per ogni token del suo vocabolario, poi converte i punteggi in probabilità. Il token successivo viene scelto da quella distribuzione e aggiunto al testo, e il processo si ripete con il testo più lungo come input. Una risposta di 300 token è fatta di 300 previsioni separate, ciascuna condizionata da tutto quello che la precede, compresi i token che il modello stesso ha appena prodotto.

Prendi la frase "The capital of France is". Quasi tutta la probabilità va a un token che continua con "Paris". Il modello non ha consultato una mappa. Ha imparato che questa continuazione è molto comune nel testo che ha visto. Lo stesso meccanismo gestisce le richieste più difficili: un commento nel codice seguito dalla firma di una funzione, un messaggio di errore seguito da una causa probabile, una domanda seguita da una spiegazione plausibile. Ognuna è una continuazione, e il successo del modello dipende da quanto gli schemi imparati si adattano al testo nuovo.

#Passo 5: addestramento

L'addestramento regola i parametri in modo che le previsioni del modello corrispondano al testo dei dati di addestramento. In forma semplificata, il modello legge un pezzo di testo, nasconde il token successivo, lo prevede, misura quanto la previsione si è allontanata dal token reale e sposta leggermente i parametri nella direzione che avrebbe aiutato. Ripeti questo su una quantità enorme di testo, con molta potenza di calcolo, e i parametri arrivano a codificare gran parte della struttura statistica del linguaggio.

Di solito l'addestramento avviene per fasi. La prima, spesso chiamata pre-training, è il processo sul token successivo descritto sopra. Le fasi successive di solito usano esempi di istruzioni e buone risposte, e a volte il giudizio di persone che mettono le risposte in classifica. Queste fasi determinano come si comporta il modello quando qualcuno gli fa una domanda: diventa più disposto a rispondere in forma utile e meno portato a continuare la conversazione come se fosse una pagina web. I dati di addestramento fissano la gamma di argomenti a cui il modello può attingere, e la loro data limite stabilisce fin dove arriva ciò che ha imparato dal testo.

L'addestramento è costoso e lo fa chi sviluppa il modello, non chi scrive in una finestra di chat. Le normali sessioni di chat non cambiano i parametri del modello.

#Passo 6: inferenza

L'inferenza è l'esecuzione di un modello addestrato per produrre un output. Ogni risposta che vedi è inferenza. Durante l'inferenza i parametri restano fissi. Da una richiesta all'altra cambia solo l'input, che comprende le istruzioni di sistema, la conversazione fin lì, gli eventuali file allegati e i risultati degli strumenti reinseriti nel contesto.

Questo spiega una sorpresa comune. Il giorno dopo può sembrare che un modello abbia dimenticato una conversazione. Niente di quello che hai scritto ha aggiornato i suoi parametri, quindi il modello riparte dallo stesso stato di prima. I prodotti con una funzione di memoria salvano appunti fuori dal modello e li inseriscono nel contesto delle richieste successive. Il modello legge gli appunti come testo. Non li ricorda come farebbe una persona.

#Finestra di contesto

La finestra di contesto è il numero massimo di token che il modello può considerare in una richiesta. Deve contenere le istruzioni, la conversazione, i documenti allegati e la risposta in corso di generazione. Il testo fuori dalla finestra non è visibile al modello in quel momento, per quanto importante fosse prima. Nelle conversazioni lunghe i primi messaggi possono uscire dalla finestra, oppure perdere influenza rispetto a quelli recenti.

Le dimensioni della finestra variano da un modello all'altro e cambiano nel tempo. Controlla la documentazione attuale del modello che usi, invece di fidarti di un numero letto in un articolo, compreso questo. Una finestra più grande inoltre non garantisce che venga usata meglio. I contesti lunghi possono seppellire il dettaglio che conta, quindi un prompt mirato con il documento giusto spesso batte una lunga pila di testo.

#Temperatura e campionamento

Il campionamento è il passaggio che sceglie un token dalla distribuzione di probabilità. La temperatura è un'impostazione che controlla quanto è netta quella distribuzione prima della scelta. A bassa temperatura dominano i token più probabili, quindi le risposte sono più ripetitive e più stabili da un'esecuzione all'altra. Ad alta temperatura la probabilità si distribuisce su più token, quindi le risposte variano di più e divagano più spesso. Molte interfacce di chat non espongono affatto questa impostazione.

La temperatura non decide se una risposta è corretta. Un valore basso può ripetere un'affermazione errata con la stessa sicurezza di uno alto. Anche un valore pari a zero non garantisce output identici in ogni deployment, perché il calcolo sottostante può variare tra versioni di hardware e software. Se ti serve un output ripetibile per un test, registra la versione del modello, le impostazioni e l'input, e tratta l'output come un campione e non come una verità fissa.

#Perché i modelli sembrano sicuri e sbagliano comunque

Una risposta sbagliata e sicura di sé deriva da come è stato costruito il modello, non da un raro malfunzionamento.

Il modello punta alla continuazione plausibile. Una frase falsa che si adatta allo schema del testo può ottenere lo stesso punteggio di una vera. Anche i dati di addestramento contengono errori, e il modello li assorbe con la stessa facilità dei fatti corretti. Durante l'inferenza non ha accesso diretto al mondo, a meno che non glielo dia uno strumento. Senza una fase di retrieval o uno strumento, risponde a partire dagli schemi nei suoi parametri.

La fluidità fa parte del problema. La scrittura sicura e ben organizzata è comune nel testo di addestramento, quindi il modello impara a produrla a prescindere dall'accuratezza. Il tono di una risposta non dice niente sulla verità del suo contenuto.

Le lacune peggiorano le cose. Quando manca un dettaglio, il modello colma il vuoto con qualcosa che si adatta allo schema. I dettagli specifici come numeri di versione, nomi di funzione, identificatori CVE, chiavi di configurazione e URL sono i più facili da ricostruire male, perché hanno un aspetto regolare ma devono corrispondere a un fatto preciso. Il NIST lo chiama confabulazione, e lo stesso schema compare in quasi tutti i sistemi generativi.

#Errori comuni

1. Trattare una risposta come un risultato di ricerca. Il modello può parafrasare fonti reali, inventarne altre o mescolarne due. Chiedi la fonte, poi aprila.
2. Dare per scontato che il modello abbia eseguito il comando o lo scan che descrive. A meno che uno strumento non gli abbia fornito un output reale, sta descrivendo come apparirebbe di solito un'esecuzione del genere.
3. Incollare segreti, credenziali o dati dei clienti in un prompt senza controllare come il servizio conserva e usa gli input. Leggi l'informativa prima di incollare qualcosa di sensibile.
4. Prendere una sola risposta come parola definitiva su un numero di versione, un'impostazione predefinita, una questione legale o una clausola di licenza.
5. Dare per scontato che un contesto più lungo aiuti sempre. Il testo in più può diluire la parte che conta.
6. Credere che una citazione sia reale perché ha il formato giusto. Autori, titoli e link possono essere generati per sembrare plausibili.

#Cosa significa per il lavoro di sicurezza

Verifica le affermazioni sulle fonti primarie. Per una domanda di sicurezza, di solito significa il bollettino di sicurezza del vendor, la RFC o lo standard pertinente, la documentazione ufficiale della versione esatta che usi, il record CVE, la pubblicazione del NIST o il codice nel tuo repository. Usa il modello per capire cosa controllare e come testarlo, non come autorità finale su ciò che è vero.

Tieni una breve traccia per ogni affermazione su cui fai affidamento: l'affermazione, la fonte, la data del controllo e la versione a cui si applica. Questa abitudine intercetta sia gli errori del modello sia i tuoi. Tratta ogni comando generato come una bozza da leggere prima di eseguirlo. Eseguilo solo in un laboratorio di tua proprietà, e non puntare mai passaggi di scansione o sfruttamento generati dal modello contro un sistema che non hai il permesso scritto di testare.

#Per andare oltre

Leggi la prima sezione e la figura dell'architettura del paper sul transformer. Non ti serve ogni equazione per vedere la forma dell'idea. Poi esegui il tokenizer giocattolo sulle tue parole e guarda dove le divide. Il paper di Sennrich e colleghi ha introdotto le unità sub-parola costruite con il byte-pair encoding, e il capitolo del corso di Hugging Face illustra l'algoritmo con il codice. Dopodiché leggi la sezione sulla confabulazione del profilo NIST per vedere come il rischio viene inquadrato per le organizzazioni.

Il prossimo articolo, Che cos'è un'API LLM, spiega come chiamare un modello dal tuo codice. È così che NotHoly espone i suoi modelli agli sviluppatori, e la stessa abitudine di verifica vale per ogni risposta che ricevi tramite un'API. Per il contesto sul tipo di affermazione da cui dipende il lavoro di sicurezza, vedi Che cos'è una vulnerabilità.

#Fonti

• Vaswani et al., "Attention Is All You Need": https://arxiv.org/abs/1706.03762
• NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative AI Profile: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
• Sennrich, Haddow and Birch, "Neural Machine Translation of Rare Words with Subword Units": https://arxiv.org/abs/1508.07909
• Byte-Pair Encoding tokenization, Hugging Face LLM Course: https://huggingface.co/learn/llm-course/chapter6/5