Dentro un Transformer: attention, MLP e residual stream spiegati per chi integra LLM in produzione

Il 27 aprile 2026 ho passato un pomeriggio nella mia sandbox di sperimentazione AI a confrontare come due diverse implementazioni di retrieval producevano risultati drasticamente diversi sullo stesso corpus di documentazione tecnica italiana: stesso Claude Sonnet 4.6, stessi prompt, embedding diversi, recall@10 passato dal 62% all'88%. Per capire perché il cambio di embedding faccia così tanta differenza e perché il prompt engineering non possa compensarlo, serve aver presente cosa succede dentro un Transformer riga per riga. Nessuna magia: quattro componenti ben definiti, ciascuno con un ruolo operativo preciso. Qui il tour interno per chi integra LLM in produzione, con le implicazioni pratiche che nessuna pagina marketing del vendor ti racconta.

Cos'è davvero l'architettura Transformer proposta nel 2017?

Il paper fondazionale è Attention Is All You Need di Vaswani et al. NeurIPS 2017, autori Google Brain, pubblicato il 12 giugno 2017. Al 2025 il paper ha superato le 173.000 citazioni, ottavo paper più citato del XXI secolo. L'architettura proposta elimina completamente ricorrenza e convoluzione e si basa solo su meccanismi di attention.

Schema del modello originale: stack di 6 encoder layer + 6 decoder layer, ogni layer con due sub-layer (self-attention multi-head + feed-forward position-wise). Dimensione del modello $d_{model}=512$, 8 teste di attention, $d_k=d_v=64$. Una residual connection attorno a ciascun sub-layer, seguita da layer normalization: $text{LayerNorm}(x + text{Sublayer}(x))$. Dropout 0,1.

I LLM moderni (GPT-4, Claude Opus, Gemini) sono evoluzioni di questa architettura: decoder-only (abbandonato l'encoder), dimensioni enormemente più grandi (GPT-4 stimato a 1.800 miliardi di parametri distribuiti su decine di transformer block), numerose varianti architetturali (Multi-Query Attention, Grouped-Query Attention, Sliding Window, Mixture of Experts). Ma la struttura base resta quella di Vaswani: attention + MLP + residual stream, ripetuti ricorsivamente.

Componente 1: embedding lookup (la porta d'ingresso del modello)

Il prompt testuale viene spezzato in token dal tokenizer (BPE, SentencePiece, Tiktoken). Ciascun token è un intero che indicizza una riga della matrice di embedding, una matrice di dimensione $|V| times d_{model}$ dove $|V|$ è la dimensione del vocabolario (tipicamente 50.000-200.000) e $d_{model}$ è la dimensione del modello (4.096 su Llama 3, molto di più su modelli frontier). Il risultato è una sequenza di vettori.

Qui si aggiunge il positional encoding: una funzione (originariamente sinusoidale, poi RoPE su Llama/Mistral) che inietta informazione sulla posizione del token nella sequenza. Senza positional encoding il modello vedrebbe la sequenza come un bag-of-words senza ordine.

Implicazione operativa: due prompt con gli stessi token ma ordine diverso producono risultati diversi perché il positional encoding è diverso. Questo è il motivo per cui nei miei articoli precedenti ho sottolineato che l'ordine degli esempi few-shot conta: gli esempi "tipici" all'inizio e gli "edge case" alla fine non sono un vezzo, sono una leva sull'attention distribuzione.

Componente 2: multi-head self-attention (i token che si parlano)

Il blocco di attention è il cuore concettuale del Transformer. Prende la sequenza di vettori e la trasforma in una nuova sequenza dove ciascun vettore "attende" (presta attenzione) agli altri in base a una metrica di rilevanza appresa.

Matematicamente, per ogni testa di attention $h$ si calcolano tre matrici $Q_h$, $K_h$, $V_h$ (query, key, value) proiettando la sequenza input. L'output della testa è $text{softmax}(Q_h K_h^T / sqrt{d_k}) V_h$. Le teste operano in parallelo e i loro output sono concatenati e proiettati di nuovo a dimensione $d_{model}$.

Intuizione operativa: quando il modello processa il token "it" in "The animal didn't cross the street because it was tired", l'attention assegna un peso alto a "animal" perché il modello ha imparato che "it" in quel contesto riferisce "animal". Non è magia: è l'output di un calcolo matriciale sulle proiezioni apprese in pretraining.

Implicazione per chi integra: l'attention è quadratica nella lunghezza della sequenza. Un prompt di 100k token richiede 10^10 operazioni di attention. Per questo la latenza cresce non-linearmente con la lunghezza del contesto, e per questo i vendor hanno introdotto varianti (flash attention, sliding window, grouped-query) che tagliano i costi mantenendo la qualità.

Se vuoi vedere come progetto pipeline LLM con attenzione al costo computazionale del context window, nel mio hub dedicato allo sviluppo AI trovi articoli tecnici con metodologia applicata e perimetro dichiarato.

Componente 3: MLP (dove stanno i fatti)

Dopo l'attention, c'è il blocco feed-forward, un MLP (multi-layer perceptron) a due layer con una non-linearità nel mezzo (originalmente ReLU, ora SwiGLU o GeGLU). Dimensione interna tipicamente 4x $d_{model}$, quindi l'MLP è la componente con più parametri del blocco.

La ricerca di mechanistic interpretability di Anthropic ha evidenziato che l'MLP è la componente dove si concentra la memoria fattuale del modello. Fatti appresi durante pretraining ("Parigi è la capitale della Francia") sono distribuiti sparsamente tra i neuroni dell'MLP. Il paper Scaling Monosemanticity di maggio 2024, che applica sparse autoencoder al residual stream a metà di Claude 3 Sonnet, ha identificato migliaia di feature interpretabili corrispondenti a concetti semantici.

Implicazione operativa: il prompt non cambia la memoria fattuale dell'MLP (i pesi sono congelati). Non puoi "aggiornare" un LLM dicendogli "da oggi la capitale della Francia è Lione". Puoi solo sovrascrivere la sua risposta con informazione fornita nel context (RAG), ma il modello continua a "sapere" la risposta originale sotto.

Componente 4: residual stream (il nastro che trasporta i vettori)

Il residual stream è il concetto che ha rivoluzionato il modo in cui i ricercatori di interpretability analizzano il Transformer. Non è un componente aggiuntivo ma la connessione $x + text{Sublayer}(x)$ che passa da layer a layer. Ogni sub-layer legge il residual stream, calcola una modifica, e riaggiunge la modifica. Alla fine il residual stream contiene l'informazione accumulata attraverso tutti i layer.

Anthropic descrive il residual stream come "il nastro su cui il modello scrive e legge". Le attention head scrivono sul residual stream informazione appresa sulla relazione fra token; i layer MLP scrivono informazione fattuale. All'ultimo layer, il residual stream viene proiettato sul vocabolario tramite un'unembedding matrix e softmaxato per ottenere la distribuzione di probabilità del prossimo token.

Implicazione operativa: il residual stream è la variabile da monitorare per fare interpretability. Anthropic (team di 17 persone al 2024) pubblica su transformer-circuits.pub paper che descrivono feature estratte dal residual stream di Claude. Per una PMI, conoscere questo framework è il prerequisito per capire cosa stia facendo davvero il modello quando risponde in modo anomalo.

Implicazioni operative per chi integra LLM: quattro osservazioni non ovvie

Prima osservazione. L'ordine dei token conta per via del positional encoding. I prompt non sono insiemi di parole, sono sequenze. Rimuovere una virgola, aggiungere uno spazio extra, cambiare l'ordine di due esempi few-shot può modificare significativamente l'output.

Seconda osservazione. La lunghezza del contesto costa quadraticamente per via dell'attention. Il trade-off "metto tutto nel prompt" fallisce oltre una soglia: non solo per costi monetari ma per latenza. Il retrieval mirato batte il contesto lungo in quasi tutti i casi di produzione.

Terza osservazione. Il modello non distingue nativamente system prompt da user input a livello architetturale; la distinzione è implementata nel template di tokenizzazione. Prompt injection sfrutta esattamente questa non-distinzione: un'istruzione nascosta in un documento fornito come user input viene processata dall'attention con lo stesso meccanismo del system prompt.

Quarta osservazione. I fatti nell'MLP sono fissi. RAG, fine-tuning, prompting sono tutti modi di bypassare o sovrascrivere la memoria fattuale a runtime, non di aggiornarla. Ogni qualvolta il vendor rilascia un nuovo modello, l'MLP è diverso: i fatti possono cambiare silenziosamente fra versioni.

Come questo impatta le decisioni di progetto AI in PMI italiane

Quattro scenari ricorrenti in cui la conoscenza architetturale cambia la risposta.

Scenario 1: scelta del contesto RAG. Un cliente chiede "quanti documenti inserisco nel contesto del RAG?". Risposta ingenua: più possibili. Risposta informata: il minimo necessario per coprire la domanda, perché l'attention è quadratica e il "lost in the middle" fa perdere precisione sui documenti centrali. Il pattern corretto è retrieval mirato con reranking, non dumping di contenuto.

Scenario 2: prompt engineering disciplinato. Conoscere che il positional encoding assegna peso diverso ai token in base alla posizione ti fa scrivere prompt con istruzioni critiche alla fine (dove l'attention si concentra di più sui token finali), esempi variati (per evitare over-weighting di un sottotipo), delimitatori espliciti (che aiutano l'attention a segmentare blocchi logici).

Scenario 3: audit di comportamento anomalo. Il cliente segnala che il modello risponde male a un pattern di domande. Senza conoscere l'architettura, la diagnosi è impossibile; con l'architettura, le domande giuste sono: il prompt sta saturando il context? C'è un'interazione di positional bias? Gli embedding di termini specifici del dominio sono distorti?

Scenario 4: scelta fra vendor e modello self-hosted. Il vendor cambia tokenizer tra versioni (Claude 4.7 ha cambiato tokenizer rispetto a 4.6, come descritto nell'articolo claude-opus-4-7-tokenizer-nuovo-costi-api-aumento-35-percento). Questo significa che l'embedding lookup cambia, i fatti nell'MLP possono essere riallocati, e il comportamento complessivo è diverso. Chi non conosce l'architettura non sa nemmeno quale parametro varia quando il vendor fa un minor release.

Edge case: cosa osservo quando confronto modelli in sandbox

Tre pattern che emergono ripetutamente quando confronto Claude, GPT, Gemini sullo stesso task.

Pattern A: sensibilità al fraseggio. Due formulazioni semanticamente identiche ("come migliorare la performance" vs "come ottimizzare le prestazioni") producono risposte significativamente diverse. È l'attention che pesa in modo diverso le proiezioni dei token sinonimi.

Pattern B: bias di recency. Le istruzioni alla fine del prompt pesano di più di quelle all'inizio, a parità di importanza logica. È un artefatto della distribuzione di attention sui token finali, spesso più concentrata.

Pattern C: errore catastrofico su long-context. Oltre una certa lunghezza di prompt, il modello perde l'istruzione iniziale e si concentra sugli ultimi N token. È il "lost in the middle" visto nei paper 2023-2024, ancora parzialmente presente nei modelli 2026 nonostante le ottimizzazioni.

Framework operativo: cosa diagnosticare in ciascun componente

Una mappa mentale che uso nei code review di pipeline LLM.

Se il problema è nell'embedding lookup, i sintomi sono: parole di dominio specifiche trattate come sinonimi di termini non correlati, peggioramento di qualità su lingue non-inglesi, costi token non proporzionali alla lunghezza apparente del testo. Soluzioni: embedding specializzati (vedi il draft embeddings dominio-specifici in pipeline), tokenizer awareness nelle stime di budget.

Se il problema è nell'attention, i sintomi sono: risposte che ignorano parti del prompt, bias di recency, degradazione sul long context. Soluzioni: prompt compressi con retrieval mirato, riformulazione con istruzioni critiche in posizione di peso.

Se il problema è nell'MLP, i sintomi sono: allucinazioni fattuali (il modello "sa" fatti sbagliati), regressioni fra versioni del modello su fatti specifici, confabulazioni contestualmente plausibili. Soluzioni: RAG per fatti, validation layer esterno, nessuna fiducia cieca nella memoria del modello.

Se il problema è nell'unembedding/softmax, i sintomi sono: instabilità dell'output (lo stesso prompt produce risposte diverse anche con temperature 0), dominanza di token specifici. Soluzioni: constrained decoding, structured output API, temperature tuning deliberato.

Perché questa comprensione architetturale fa la differenza in produzione

Un ingegnere che integra LLM senza capire la struttura interna tratta il modello come una scatola nera: si affida al vendor marketing, prova varianti di prompt a caso, quando qualcosa non funziona ripete "proviamo un modello più potente". Un ingegnere che conosce l'architettura ha leve concrete: posizionamento dei token cruciali in zone di alta attention, gestione del context budget, consapevolezza di cosa cambi (e cosa non cambi) con RAG e fine-tuning, diagnostica delle regressioni fra versioni di modello.

Capire l'architettura del Transformer non è esercizio accademico; è la base per costruire sistemi AI che reggono il carico di produzione e che si possono auditare quando qualcosa va male. Se hai un progetto LLM in cui le scelte architetturali pesano (retrieval, context budget, prompt engineering sistematico) e vuoi verificare se l'architettura proposta dal fornitore regge al confronto con quello che davvero succede dentro il modello, il modulo di preventivo gratuito ti risponde in due minuti se il caso rientra nel mio ambito. Il Transformer ha nove anni; chi lo usa senza averne mai aperto il cofano sta guidando un motore di cui non conosce nemmeno i cilindri, e quando il motore si ferma l'unica risposta sensata che sa dare è "proviamo un modello più grande", che è il modo più costoso e meno efficace di risolvere un problema architetturale. L'architettura si studia una volta, le sue implicazioni durano cinque anni di integrazioni AI ben progettate, e il ROI del tempo investito è sproporzionato rispetto a qualunque corso di prompt engineering offerto dal mercato italiano. I consulenti che parlano di LLM senza aver letto Vaswani 2017 e la serie di circuits Anthropic sono venditori di hype; i pochi che li hanno letti portano valore per dieci anni, perché la struttura è stabile anche quando i modelli specifici cambiano ogni sei mesi e quando le buzzword commerciali vanno e vengono su LinkedIn senza lasciare traccia nell'ingegneria reale dei sistemi in produzione.