Il fenomeno lost in the middle descrive la tendenza degli LLM a ignorare le informazioni che si trovano al centro di un contesto lungo, privilegiando inizio e fine del prompt. Documentato in uno studio del 2023, il perdersi nel mezzo riguarda tutti i modelli di AI più diffusi e ha conseguenze dirette sulla qualità dei chatbot e dei sistemi RAG. Conoscere questo limite aiuta chi lavora con AI generativa a scrivere e strutturare prompt, e documenti, in modo più efficace per contenuti, marketing digitale e copywriting.

Lost in the middle, cosa significa in ambito AI?

Lost in the middle significa che un LLM tende a ricordare meglio le informazioni all’inizio e alla fine di un prompt lungo, mentre dimentica o ignora quelle posizionate al centro. Per conseguenza, produce risposte meno accurate quando i dati rilevanti si trovano nella parte intermedia del contesto.

Il termine nasce da una ricerca del luglio 2023 di Nelson F. Liu, Kevin Lin e Percy Liang di Stanford con colleghi di Meta AI. Gli autori hanno testato diversi modelli su task di question answering multi-documento con contesti da 10 a 30 documenti. La scoperta: anche i modelli con  finestre di contesto estese mostravano un calo drastico quando l’informazione critica si trovava a metà del contesto.

Il fenomeno riguarda tutti i modelli più recenti. GPT-4, Claude 2, Llama 2 mostrano questo comportamento, e certo con intensità e modi variabili. La dimensione del modello non elimina il problema: anche sistemi oltre 70 miliardi di parametri subiscono degradazione dell’output quando devono recuperare informazioni dalla porzione centrale del contesto. L’aspetto più critico: questa limitazione persiste anche aumentando la capacità della finestra. Un modello da 100.000 token non è migliore nel gestire informazioni al centro rispetto a uno da 8.000 token.

La curva a U: come l’AI elabora contesti lunghi

Il pattern di performance del lost in the middle segue una curva a U: massima accuratezza quando le informazioni rilevanti compaiono all’inizio del prompt, crollo drastico al centro, risalita verso la fine. Nei test di Liu e colleghi, quando il documento rilevante occupava la prima posizione tra 20 documenti forniti al chatbot, l’accuratezza raggiungeva il 90-95%. Spostando lo stesso documento alla posizione 10 (centro), l’accuratezza crollava al 40% – 60%, per poi risalire al 70% – 85% alla posizione 20. Questo comportamento non è casuale: tutti i sistemi testati hanno mostrato la stessa dinamica.

Posizione documento.	Accuratezza media.	Zona del contesto.
1-3	85-95%	Inizio
8-12	40-60%	Centro
18-20	70-85%	Fine

La curva a U si riproduce anche aumentando il numero di documenti. Con 30 documenti invece di 20, la dinamica rimane identica: ottima performance alle estremità, degrado al centro. Questa costanza indica che il fenomeno dipende dalla posizione relativa, non dalla lunghezza assoluta del contesto.

Esempi di LLM perso nel mezzo della via

Esempi concreti del lost in the middle si hanno soprattutto in condizioni di question answering multi-documento, nei quali l’utente pone una domanda e il sistema deve identificare la risposta corretta in un insieme di documenti recuperati.

Per fare un esempio reale: chiedi a GPT-4 il capitale sociale di una società. Il sistema recupera 20 documenti: 19 contengono informazioni generiche, uno riporta il dato esatto. Se il documento con il dato esatto finisce in posizione 1-2, il modello risponde correttamente nel 90% dei casi. In posizione 10-11, l’accuratezza scende al 45%: il modello ignora il documento rilevante e fornisce risposte vaghe basate sui documenti meno pertinenti.

Un altro scenario: generazione contenuti SEO. Carichi 15 articoli in un prompt per riassumere tendenze del settore. Se l’articolo più aggiornato si trova all’ottava posizione, il modello potrebbe ignorarlo e basare il riassunto solo sui primi 3-4 e ultimi 2-3 articoli, producendo output che non riflette le informazioni più importanti.

Nei sistemi RAG il problema è evidente. Un retriever ordina i chunk per similarità semantica, ma se il chunk più rilevante finisce in posizione centrale, il modello generativo potrebbe non utilizzarlo, vanificando l’intero meccanismo di retrieval.

Caso studio: NaturalQuestions

Lo studio di Stanford utilizza NaturalQuestions, dataset con domande reali poste a Google. I ricercatori hanno creato contesti inserendo 10-30 documenti, di cui uno solo conteneva la risposta corretta. Su una domanda come “Chi ha scritto To Kill a Mockingbird?”, GPT-3.5 Turbo risponde correttamente Harper Lee nel 92% dei casi con il documento in prima posizione. Con lo stesso documento in posizione 10, l’accuratezza scende al 52%. Il modello produce allucinazioni AI, inventando autori plausibili ma sbagliati. Allucinazioni che possono sommarsi ai bias che inevitabilmene un LLM produce.

Perché un LLM si perde nel mezzo?

Le cause risiedono nell’architettura transformer e nel modo in cui questi modelli gestiscono l’attenzione su sequenze lunghe, con particolare riguardo ai meccanismi di positional encoding e alle dinamiche di addestramento. Bisogna specificare:

• architettura transformer: si intende la struttura dei moderni modelli di IA che permette loro di analizzare l’intero testo contemporaneamente, collegando parole lontane tra loro per comprenderne il contesto globale
• positional encoding: è il sistema di coordinate numeriche che il modello assegna a ogni parola per ricordarne l’ordine esatto all’interno della frase, dato che l’architettura elabora tutto in parallelo e non riga per riga.

Il meccanismo di self-attention permette a ogni token di prestare attenzione a tutti gli altri, ma questa attenzione non è uniforme: il modello impara a privilegiare certe posizioni. Nei modelli causali come GPT, la maschera causale impedisce ai token di guardare avanti, creando bias verso le posizioni iniziali.

Il positional encoding gioca un ruolo fondamentale. Tecniche come RoPE introducono decadimento basato sulla distanza relativa: più due token sono distanti, meno il modello li mette in relazione. Questo favorisce l’attenzione locale e penalizza le connessioni a lunga distanza. Le informazioni al centro di un contesto molto lungo finiscono isolate, lontane sia dall’inizio che dalla fine.

Durante il training, i modelli vedono sequenze di lunghezza fissa (tipicamente 2048-4096 token) con informazioni distribuite uniformemente. Nel fine-tuning su task di instruction-following, gli 

esempi tendono ad avere prompt brevi con informazione chiave all’inizio o alla fine. Questa distribuzione asimmetrica insegna implicitamente al modello a dare più peso alle estremità del contesto.

Lost in the middle nei sistemi RAG: quando il recupero non basta

Il lost in the middle rappresenta una sfida critica per i sistemi RAG, nei quali il recupero accurato di documenti rilevanti non garantisce che il modello generativo li utilizzi se finiscono nella parte centrale del contesto.

Nei RAG standard, il retriever cerca nel database vettoriale i chunk più simili, li concatena in ordine di similarità e li passa al LLM con la query originale. Il problema è: l’ordine di similarità semantica non corrisponde all’ordine ottimale per l’elaborazione del modello.

Se il retriever recupera 10 chunk con score 0.95, 0.92, 0.90, 0.88, 0.85, 0.82, 0.80, 0.78, 0.75, 0.72 e li inserisce in questo ordine, il chunk con score 0.85 finisce in posizione 5, al centro. Anche se contiene l’informazione fondamentale il modello potrebbe ignorarlo. I punteggi di similarità (o similarity score), bisogna aggiungere sono valori numerici, generalmente compresi tra 0 e 1, che misurano quanto un chunk di testo sia semanticamente vicino alla query dell’utente.

Questa situazione arriva a creare un paradosso: aumentare i chunk recuperati può peggiorare le prestazioni. Con 5 chunk, la posizione centrale è 3 e il degrado è limitato. Con 15 chunk, le posizioni 7-8-9 cadono in piena zona lost, con accuratezza al 30-40%. Una guida per mitigare questo problema prevede tecniche di context reordering: bisogna quindi riordinare i chunk piazzando i più rilevanti all’inizio e alla fine, relegando quelli meno rilevanti al centro.

Come evitare il fenomeno lost in the middle: strategie operative

Evitare completamente il lost in the middle è impossibile con gli attuali modelli, ma esistono strategie pratiche per ridurne significativamente l’impatto e ottimizzare la qualità dell’output.

Strategia strutturale: posiziona sempre le informazioni critiche all’inizio o alla fine del prompt. Quando scrivi un prompt lungo, inizia con le istruzioni chiave. Se includi documenti di riferimento, metti i più rilevanti in apertura o in chiusura, mai al centro.

Per il prompt engineering, adotta struttura a sandwich: istruzioni essenziali all’inizio, materiale di supporto al centro, richiamo delle istruzioni chiave alla fine. Esempio: Inizio: “Scrivi articolo SEO 1500 parole su keyword X, target Y” → Centro: documenti di riferimento, competitor research, esempi → Fine: “Ricorda: 1500 parole, keyword X, tone autorevole ma colloquiale”.

Chunking intelligente: invece di caricare tutto in un unico prompt, spezza il task in sotto-task con contesti più brevi. Se devi analizzare 15 documenti, processane 5 alla volta con prompts separati, poi aggrega i risultati. Questo riduce la lunghezza di ogni contesto, evitando il problema del middle.

Per sistemi RAG, implementa context optimization:

• limita i chunk recuperati a 5-7 invece di 10-15, privilegiando qualità su quantità
• usa reranker per ordinare i chunk strategicamente, alternando alta e bassa rilevanza
• considera di applicare la context compression che sintetizza i chunk centrali in riassunti più brevi.

Monitora e testa sistematicamente come i tuoi prompt performano con l’informazione rilevante in posizioni diverse. Usa dataset di test dove sposti deliberatamente il contenuto rilevante e misuri l’accuratezza. Solo così quantifichi l’impatto del lost in the middle sui tuoi use case e calibri le strategie di AI spiegabile per comprendere quando e perché il modello ignora certe parti del contesto.

Context rot: quando il contesto diventa rumore

Un fenomeno correlato è il context rot, che si verifica quando l’aggiunta di informazioni addizionali degrada la qualità dell’output invece che migliorarla. Il context rot è amplificato dal lost in the middle: più informazioni carichi, più è probabile che quelle importanti finiscano in posizione sfavorevole. Passare da 5 a 15 chunk può abbassare l’accuratezza del 20-30%. La soluzione: solo contesto di alta qualità, filtrato e ordinato. Meglio 3 chunk estremamente rilevanti ben posizionati che 10 vagamente pertinenti distribuiti male.

FAQ

Tutti gli LLM soffrono di lost in the middle?

Sì, tutti i modelli transformer testati mostrano questo comportamento in misura variabile. GPT-4, Claude, Llama 2, PaLM 2 presentano il fenomeno, anche se con intensità diverse. I modelli più grandi hanno degradazione leggermente inferiore, ma la curva a U persiste.

Aumentare la finestra di contesto risolve il problema?

No. Modelli con finestre di 100.000 token mostrano lo stesso pattern di degrado al centro di quelli con 8.000 token. La posizione relativa conta più della dimensione assoluta. Estendere il contesto senza affrontare il bias posizionale non migliora le prestazioni sulle informazioni centrali.

Come posso testare se il mio sistema RAG soffre di lost in the middle?

Crea un dataset di test con query e documenti rilevanti noti. Esegui il RAG posizionando il documento rilevante in diverse posizioni (inizio, centro, fine) e misura l’accuratezza. Se l’accuratezza al centro è significativamente inferiore, il sistema è affetto dal problema e richiede ottimizzazioni di ordinamento dei chunk.