Effetto Lost in the Middle negli LLM: cos'e e come ridurlo

Quando si lavora con strumenti che usano i LLM, una delle assunzioni più comuni è che il modello utilizzi in modo uniforme tutte le informazioni fornite nel contesto. In realtà, esiste più di una ricerca che ha dimostrato come questa assunzione sia spesso sbagliata: è qui che entra in gioco il fenomeno noto come “Lost in the Middle”.
Cos’è il Lost in the Middle?
Il termine “Lost in the Middle” deriva da un paper di ricerca pubblicato nel 2023 da Liu et al. (Lost in the Middle: How Language Models Use Long Contexts), che ha analizzato le prestazioni di diversi LLM su task che richiedevano il recupero di informazioni all’interno di contesti molto lunghi.
Il risultato è stato sorprendente: i modelli tendono a memorizzare e richiamare con maggiore efficacia le informazioni posizionate all’inizio o alla fine del contesto (il cosiddetto effetto primacy-recency), mentre le informazioni collocate nel mezzo del prompt o del documento vengono sistematicamente sottoutilizzate, se non addirittura ignorate.
In termini pratici, se fornisci a un LLM una lista di 20 documenti e l’informazione rilevante si trova al documento numero 10, la qualità della risposta sarà statisticamente inferiore rispetto a quando quella stessa informazione è posizionata al primo o all’ultimo documento.
Perché avviene questo fenomeno?
Le cause di questo comportamento sono riconducibili principalmente a due fattori:
1. L’architettura Transformer
I modelli basati sull’architettura Transformer utilizzano il meccanismo di self-attention, che teoricamente dovrebbe permettere di prestare la stessa attenzione a ogni posizione del contesto. Tuttavia, nella pratica, diversi studi hanno dimostrato che l’attenzione non è uniforme: i token all’inizio e alla fine della sequenza tendono a ricevere punteggi di attenzione più elevati rispetto a quelli centrali.
Questo comportamento è amplificato quanto più il contesto è lungo, poiché il modello deve distribuire l’attenzione su un numero sempre maggiore di token.
2. Il training e i dati di addestramento
Durante la fase di pre-training, i modelli vengono esposti a testi che presentano strutture tipiche come introduzioni, sviluppi e conclusioni. Questo porta il modello ad apprendere euristiche implicite per cui le informazioni critiche tendono a trovarsi nei punti salienti del testo, cioè all’inizio o alla fine.
Analogamente, anche durante il fine-tuning con istruzioni e feedback umano (RLHF), i valutatori umani tendono a concentrare la loro attenzione sull’inizio e sulla fine delle risposte, rinforzando ulteriormente questo bias.
Quanto è rilevante nella pratica?
Il fenomeno diventa particolarmente critico nei seguenti contesti:
- RAG (Retrieval-Augmented Generation): quando si recuperano più chunk di documenti e si inseriscono nel prompt, l’ordine in cui vengono presentati influisce significativamente sulla qualità della risposta finale.
- Analisi di documenti particolarmente lunghi: se si chiede a un modello di rispondere a domande su un contratto, un paper scientifico o un log di sistema, le informazioni nel mezzo del documento rischiano di essere ignorate.
- Multi-turn conversation: in conversazioni molto lunghe, i turni centrali della chat possono essere sottopesati rispetto al messaggio di sistema iniziale e all’ultima richiesta dell’utente.
- Few-shot prompting: quando si forniscono molti esempi nel prompt, quelli posizionati nel mezzo della lista risultano meno efficaci.
Strategie per mitigare l’effetto
Conoscere il problema permette di adottare alcune strategie pratiche per ridurre il suo impatto:
Riordino dei documenti (Reranking)
Una delle tecniche più efficaci nell’ambito del RAG è il reranking: dopo aver recuperato i documenti rilevanti, invece di presentarli in ordine di similarità o cronologico, è possibile riposizionarli in modo strategico.
Una strategia semplice suggerita dalla ricerca è quella di posizionare i documenti più rilevanti all’inizio e alla fine del contesto, relegando quelli meno importanti al centro:
def riordina_documenti_lost_in_middle(documenti: list, scores: list) -> list:
"""
Riordina i documenti per mitigare il Lost in the Middle:
i più rilevanti vengono messi all'inizio e alla fine.
"""
# Ordina per score decrescente
coppie = sorted(zip(scores, documenti), reverse=True)
documenti_ordinati = [doc for _, doc in coppie]
risultato = []
inizio = True
for doc in documenti_ordinati:
if inizio:
risultato.insert(0, doc) # Aggiungi all'inizio
else:
risultato.append(doc) # Aggiungi alla fine
inizio = not inizio
return risultato
Chunking più granulare
Riducendo la dimensione dei chunk nei sistemi RAG, si diminuisce la probabilità che l’informazione rilevante si trovi “sepolta” nel mezzo di un blocco di testo lungo. Chunk più piccoli e precisi aumentano la probabilità che il contenuto rilevante venga posizionato in modo favorevole.
Prompt con riepilogo progressivo
Per documenti molto lunghi, una tecnica efficace è il Map-Reduce prompting: invece di inserire tutto il documento nel contesto in un’unica soluzione, si elabora il documento in sezioni, si riassume ogni sezione separatamente e poi si combina il tutto in una risposta finale.
def analizza_con_map_reduce(documento_lungo: str, domanda: str, chunk_size: int = 2000) -> str:
"""
Analizza un documento lungo usando la tecnica Map-Reduce
per evitare il Lost in the Middle.
"""
# Fase MAP: analizza ogni chunk separatamente
chunks = [documento_lungo[i:i+chunk_size]
for i in range(0, len(documento_lungo), chunk_size)]
riassunti = []
for i, chunk in enumerate(chunks):
response = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{
"role": "user",
"content": f"Sezione {i+1}:\n{chunk}\n\nEstrai le informazioni rilevanti per: {domanda}"
}],
temperature=0
)
riassunti.append(response.choices[0].message.content)
# Fase REDUCE: combina i riassunti
contesto_ridotto = "\n\n".join(riassunti)
response_finale = client.chat.completions.create(
model="gpt-4o",
messages=[{
"role": "user",
"content": f"Sulla base di queste analisi parziali:\n{contesto_ridotto}\n\nRispondi alla domanda: {domanda}"
}],
temperature=0
)
return response_finale.choices[0].message.content
Modelli con context window più lunga e ottimizzata
Alcuni modelli più recenti, come Claude Sonnet 5, sono stati ottimizzati per gestire meglio i contesti lunghi. Tuttavia, è importante non dare per scontato che il problema sia completamente risolto: anche questi modelli possono mostrare un degrado delle prestazioni con contesti molto estesi.
Il fenomeno nell’era dei contesti milionari
Con modelli come Gemini 1.5 Pro (1 milione di token) o Claude 3.5 (200k token), si potrebbe pensare che il problema fosse diventato irrilevante. In realtà, all’aumentare della context window sono aumentate anche la complessità computazionale dell’attenzione, e il rischio che le informazioni centrali venissero sottopesate non è scomparso, ma si è trasformato.
Ricerche più recenti mostrano che, sebbene i modelli con contesti più lunghi siano generalmente migliori nel recuperare informazioni distribuite, il fenomeno del Lost in the Middle persiste, soprattutto quando il contesto è riempito con informazioni ridondanti o non rilevanti (il cosiddetto distractor noise).
Conclusioni
Il fenomeno del Lost in the Middle è uno dei bias più sottovalutati nell’utilizzo pratico degli LLM, soprattutto in applicazioni RAG o di analisi documentale. Conoscerlo permette di progettare sistemi più robusti, scegliere con cura come strutturare il contesto e adottare strategie di mitigazione che possono fare la differenza tra un sistema che funziona e uno che delude.
Come sempre nel campo dell’AI, la comprensione dei limiti è il primo passo per costruire soluzioni più solide e affidabili.
















