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

Immagine di copertina

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.

Risorse utili

Conosci meglio chi ha scritto questo articolo

Serena Sensini

Ciao! Mi chiamo Serena Sensini e sono la creatrice di @ TheRedCode.it. Ho aperto questo blog nel 2021 per raccontare il mio lavoro e il mondo dell’informatica a parole semplici, in piccole pillole e alla portata di tutte le persone.

Sono un’ingegnera informatica specializzata in ambito AI & NLP. Di giorno lavoro come CTO @ Welyk e come Innovation & Emerging Technologies Leader @ Dedalus, mentre di notte scrivo e sono autrice di 5 libri -per ora-. 🖊️

Foto di Serena Sensini

Partners

Community, aziende e persone che supportano attivamente il blog

Vuoi diventare partner?

Collaboriamo con community, aziende e strumenti del mondo tech che vogliono raggiungere la nostra community di dev ed engineer italiani. Scrivici per proporre una collaborazione.

Vuoi diventare tech content creator? 🖊️

Se ti va di raccontare la tua esperienza nel mondo tech, questo è il posto giusto.

Cerchiamo voci autentiche, esempi pratici e punti di vista utili per chi legge.

Scrivici a collaborazioni[at]theredcode.it con una proposta: idea, taglio del contenuto e una breve presentazione. Non vediamo l'ora di leggere la tua esperienza!

Invia la tua idea