Prestazioni RAG a Contesto Lungo degli LLM

La Generazione Aumentata dal Recupero (RAG) è il caso d'uso dell'IA generativa più ampiamente adottato dai nostri clienti. RAG migliora l'accuratezza dei LLM recuperando informazioni da fonti esterne come documenti non strutturati o dati strutturati. Con la disponibilità di LLM con lunghezze di contesto maggiori come Anthropic Claude (200k context length), GPT-4-turbo (128k context length) e Google Gemini 1.5 pro (2 million context length), gli sviluppatori di applicazioni LLM sono in grado di fornire più documenti alle loro applicazioni RAG. Portando le lunghezze di contesto più lunghe all'estremo, c'è persino un dibattito sul fatto che i modelli linguistici a contesto lungo finiranno per inglobare i flussi di lavoro RAG. Perché recuperare singoli documenti da un database se si può inserire l'intero corpus nella finestra di contesto?

 

 Questo post del blog esplora l'impatto dell'aumento della lunghezza del contesto sulla qualità delle applicazioni RAG. Abbiamo condotto oltre 2.000 esperimenti su 13 popolari LLM open source e commerciali per scoprire le loro prestazioni su vari set di dati specifici del dominio. Abbiamo scoperto che:

• Recuperare più documenti può effettivamente essere vantaggioso: Recuperare più informazioni per una data query aumenta la probabilità che le informazioni corrette vengano trasmesse al LLM. I moderni LLM con lunghezze di contesto lunghe possono sfruttare questo vantaggio e migliorare così il sistema RAG complessivo.
• Un contesto più lungo non è sempre ottimale per RAG: Le prestazioni della maggior parte dei modelli diminuiscono dopo una certa dimensione del contesto. In particolare, le prestazioni di Llama-3.1-405b iniziano a diminuire dopo 32k token, GPT-4-0125-preview inizia a diminuire dopo 64k token, e solo pochi modelli sono in grado di mantenere prestazioni RAG coerenti su contesti lunghi su tutti i set di dati.
• I modelli falliscono su contesti lunghi in modi molto distinti: Abbiamo condotto analisi approfondite sulle prestazioni su contesti lunghi di Llama-3.1-405b, GPT-4, Claude-3-sonnet, DBRX e Mixtral e abbiamo identificato schemi di fallimento unici come il rifiuto a causa di preoccupazioni sul copyright o la costante riassunzione del contesto. Molti dei comportamenti suggeriscono una mancanza di sufficiente post-addestramento sul contesto lungo.

Contesto

RAG: Un tipico flusso di lavoro RAG coinvolge almeno due passaggi:

• Recupero: data la domanda dell'utente, recuperare le informazioni pertinenti da un corpus o da un database. Il recupero delle informazioni è un'area ricca di progettazione di sistemi. Tuttavia, un approccio semplice e contemporaneo consiste nell'incorporare singoli documenti per produrre una raccolta di vettori che vengono poi archiviati in un database vettoriale. Il sistema recupera quindi documenti pertinenti in base alla somiglianza della domanda dell'utente con il documento. Un parametro chiave di progettazione nel recupero è il numero di documenti e, quindi, il numero totale di token da restituire.
• Generazione: data la domanda dell'utente e le informazioni recuperate, generare la risposta corrispondente (o rifiutare se non ci sono abbastanza informazioni per generare una risposta). Il passaggio di generazione può impiegare una vasta gamma di tecniche. Tuttavia, un approccio semplice e contemporaneo consiste nel sollecitare un LLM attraverso un semplice prompt che introduce le informazioni recuperate e il contesto pertinente per la domanda a cui rispondere.

È stato dimostrato che RAG aumenta la qualità dei sistemi di QA in molti domini e attività (Lewis et.al 2020).

Modelli linguistici a contesto lungo: i moderni LLM supportano lunghezze di contesto sempre maggiori.

Mentre l'originale GPT-3.5 aveva solo una lunghezza di contesto di 4k token, GPT-4-turbo e GPT-4o hanno una lunghezza di contesto di 128k. Allo stesso modo, Claude 2 ha una lunghezza di contesto di 200k token e Gemini 1.5 pro vanta una lunghezza di contesto di 2 milioni di token. La lunghezza massima del contesto dei LLM open source ha seguito una tendenza simile: mentre la prima generazione di modelli Llama aveva solo una lunghezza di contesto di 2k token, modelli più recenti come Mixtral e DBRX hanno una lunghezza di contesto di 32k token. Il recentemente rilasciato Llama 3.1 ha un massimo di 128k token.

Il vantaggio di utilizzare un contesto lungo per RAG è che il sistema può aumentare il passaggio di recupero per includere più documenti recuperati nel contesto del modello di generazione, il che aumenta la probabilità che un documento pertinente per rispondere alla domanda sia disponibile per il modello.

D'altra parte, recenti valutazioni di modelli a contesto lungo hanno evidenziato due limitazioni diffuse:

• Il problema “lost in the middle”: il problema “lost in the middle” si verifica quando i modelli faticano a conservare ed utilizzare efficacemente le informazioni dalle porzioni centrali di testi lunghi. Questo problema può portare a un degrado delle prestazioni all'aumentare della lunghezza del contesto, con i modelli che diventano meno efficaci nell'integrare informazioni sparse in contesti estesi.
• Lunghezza del contesto efficace: il paper RULER ha esplorato le prestazioni dei modelli a contesto lungo su diverse categorie di task, tra cui recupero, tracciamento di variabili, aggregazione e risposta a domande, e ha scoperto che la lunghezza del contesto efficace - la quantità di contesto utilizzabile oltre la quale le prestazioni del modello iniziano a diminuire –  può essere molto più breve della lunghezza massima del contesto dichiarata. 

Tenendo conto di queste osservazioni di ricerca, abbiamo progettato molteplici esperimenti per sondare il valore potenziale dei modelli a contesto lungo, la lunghezza del contesto efficace dei modelli a contesto lungo nei flussi di lavoro RAG e valutare quando e come i modelli a contesto lungo possono fallire.

Metodologia

Per esaminare l'effetto del contesto lungo sul recupero e sulla generazione, sia individualmente che sull'intera pipeline RAG, abbiamo esplorato le seguenti domande di ricerca: 

1. L'effetto del contesto lungo sul recupero: In che modo la quantità di documenti recuperati influisce sulla probabilità che il sistema recuperi un documento pertinente?
2. L'effetto del contesto lungo su RAG: Come cambiano le prestazioni di generazione in funzione di un maggior numero di documenti recuperati?
3. Le modalità di fallimento per il contesto lungo su RAG: Come falliscono i diversi modelli nel contesto lungo?

Abbiamo utilizzato le seguenti impostazioni di recupero per gli esperimenti 1 e 2:

• modello di embedding: (OpenAI) text-embedding-3-large
• dimensione del chunk: 512 token (abbiamo suddiviso i documenti dal corpus in chunk di dimensione 512 token)
• dimensione dello stride: 256 token (la sovrapposizione tra chunk adiacenti è di 256 token)
• vector store: FAISS (con indice IndexFlatL2)

Abbiamo utilizzato le seguenti impostazioni di generazione per l'esperimento 2:

• modelli di generazione: gpt-4o, claude-3-5-sonnet, claude-3-opus, claude-3-haiku, gpt-4o-mini, gpt-4-turbo, claude-3-sonnet, gpt-4, meta-llama-3.1-405b, meta-llama-3-70b, mixtral-8x7b, dbrx, gpt-3.5-turbo
• temperatura: 0.0
• max_output_tokens: 1024

Quando abbiamo benchmarkato le prestazioni alla lunghezza del contesto X, abbiamo utilizzato il seguente metodo per calcolare quanti token utilizzare per il prompt: 

• Data la lunghezza del contesto X, abbiamo prima sottratto 1k token che vengono utilizzati per l'output del modello
• Abbiamo poi lasciato un buffer di 512 token

Il resto è il limite per quanto lungo può essere il prompt (questo è il motivo per cui abbiamo utilizzato una lunghezza di contesto di 125k invece di 128k, poiché volevamo lasciare abbastanza buffer per evitare errori di out-of-context).

Dataset di valutazione

In questo studio, abbiamo benchmarkato tutti gli LLM su 4 dataset RAG curati che sono stati formattati sia per il recupero che per la generazione. Questi includevano Databricks DocsQA e FinanceBench, che rappresentano casi d'uso industriali, e Natural Questions (NQ) e HotPotQA, che rappresentano contesti più accademici. Di seguito i dettagli del dataset:

Metriche di Valutazione: 

• Metriche di retrieval: abbiamo utilizzato il recall per misurare le prestazioni del retrieval. Il punteggio di recall è definito come il rapporto tra il numero di documenti pertinenti recuperati e il numero totale di documenti pertinenti nel dataset.
• Metriche di generazione: abbiamo utilizzato la metrica di correttezza della risposta per misurare le prestazioni della generazione.  Abbiamo implementato la correttezza della risposta attraverso il nostro sistema LLM-as-a-judge calibrato, alimentato da GPT-4o. I nostri risultati di calibrazione hanno dimostrato che il tasso di accordo giudice-umano è elevato quanto il tasso di accordo umano-umano. 

Perché il contesto lungo per RAG?

Esperimento 1: I benefici del recupero di più documenti

In questo esperimento, abbiamo valutato come il recupero di più risultati influenzi la quantità di informazioni pertinenti inserite nel contesto del modello di generazione. Nello specifico, abbiamo ipotizzato che il retriever restituisca X numero di token e quindi calcolato il punteggio di recall a quel cutoff. Da un'altra prospettiva, le prestazioni di recall sono il limite superiore delle prestazioni del modello di generazione quando al modello è richiesto di utilizzare solo i documenti recuperati per generare risposte. 

Di seguito sono riportati i risultati di recall per il modello di embedding OpenAI text-embedding-3-large su 4 dataset e diverse lunghezze di contesto. Utilizziamo una dimensione di chunk di 512 token e lasciamo un buffer di 1.5k per il prompt e la generazione.

 

Punto di saturazione: come si può osservare nella tabella, il punteggio di recupero del recall per ogni dataset raggiunge la saturazione a una diversa lunghezza di contesto. Per il dataset NQ, si satura presto a una lunghezza di contesto di 8k, mentre i dataset DocsQA, HotpotQA e FinanceBench si saturano rispettivamente a lunghezze di contesto di 96k e 128k. Questi risultati dimostrano che con un semplice approccio di recupero, sono disponibili informazioni pertinenti aggiuntive per il modello di generazione fino a 96k o 128k token. Pertanto, la maggiore dimensione del contesto dei modelli moderni offre la promessa di catturare queste informazioni aggiuntive per aumentare la qualità complessiva del sistema.

L'uso di un contesto più lungo non aumenta uniformemente le prestazioni di RAG

Esperimento 2: Contesto lungo su RAG

In questo esperimento, abbiamo combinato il passaggio di recupero e il passaggio di generazione in una semplice pipeline RAG. Per misurare le prestazioni RAG a una certa lunghezza di contesto, aumentiamo il numero di chunk restituiti dal retriever per riempire il contesto del modello di generazione fino a una lunghezza di contesto data. Quindi chiediamo al modello di rispondere alle domande di un benchmark dato. Di seguito sono riportati i risultati di questi modelli a diverse lunghezze di contesto.

Il set di dati Natural Questions è un set di dati generale per la risposta alle domande, disponibile pubblicamente. Ipotizziamo che la maggior parte dei modelli linguistici sia stata addestrata o messa a punto su attività simili a Natural Question e quindi osserviamo differenze di punteggio relativamente piccole tra diversi modelli a breve lunghezza di contesto. Man mano che la lunghezza del contesto aumenta, alcuni modelli iniziano ad avere prestazioni ridotte.

Rispetto a Natural Questions, il set di dati Databricks DocsQA non è disponibile pubblicamente (sebbene il set di dati sia stato curato da documenti disponibili pubblicamente). Le attività sono più specifiche per il caso d'uso e si concentrano sulla risposta alle domande aziendali basata sulla documentazione Databricks. Ipotizziamo che, poiché è meno probabile che i modelli siano stati addestrati su attività simili, le prestazioni RAG tra diversi modelli varino maggiormente rispetto a quelle di Natural Questions. Inoltre, poiché la lunghezza media del documento per il set di dati è di 3k, molto più breve di quella di FinanceBench, la saturazione delle prestazioni avviene prima rispetto a quella di FinanceBench.

Il set di dati FinanceBench è un altro benchmark specifico per il caso d'uso che consiste in documenti più lunghi, ovvero i depositi SEC 10k. Per rispondere correttamente alle domande nel benchmark, il modello necessita di una maggiore lunghezza di contesto per catturare le informazioni pertinenti dal corpus. Questo è probabilmente il motivo per cui, rispetto ad altri benchmark, il richiamo per FinanceBench è basso per piccole dimensioni di contesto (Tabella 1). Di conseguenza, le prestazioni della maggior parte dei modelli si saturano a una lunghezza di contesto maggiore rispetto a quella di altri set di dati.

Mediando questi risultati dei task RAG, abbiamo derivato la tabella delle prestazioni RAG a contesto lungo (trovata nella sezione appendice) e abbiamo anche tracciato i dati come grafico a linee nella Figura 1.

La Figura 1 all'inizio del blog mostra la media delle prestazioni su 4 set di dati. Riportiamo i punteggi medi nella Tabella 2 nell'Appendice.

Come si può notare dalla Figura 1:

• Aumentare la dimensione del contesto consente ai modelli di sfruttare documenti recuperati aggiuntivi: Possiamo osservare un aumento delle prestazioni in tutti i modelli da 2k a 4k di lunghezza di contesto, e l'aumento persiste per molti modelli fino a 16~32k di lunghezza di contesto.
• Tuttavia, per la maggior parte dei modelli, esiste un punto di saturazione dopo il quale le prestazioni diminuiscono, ad esempio: 16k per gpt-4-turbo e claude-3-sonnet, 4k per mixtral-instruct e 8k per dbrx-instruct.
• Ciononostante, modelli recenti, come gpt-4o, claude-3.5-sonnet e gpt-4o-mini, hanno migliorato il comportamento a contesto lungo che mostra un deterioramento delle prestazioni minimo o nullo all'aumentare della lunghezza del contesto.

Insieme, uno sviluppatore deve essere consapevole nella selezione del numero di documenti da includere nel contesto. È probabile che la scelta ottimale dipenda sia dal modello di generazione che dal task in questione.

Gli LLM falliscono nel RAG a contesto lungo in modi diversi

Esperimento 3: Analisi dei fallimenti per LLM a contesto lungo

Per valutare le modalità di fallimento dei modelli di generazione a una maggiore lunghezza di contesto, abbiamo analizzato campioni da llama-3.1-405b-instruct, claude-3-sonnet, gpt-4, Mixtral-instruct e DBRX-instruct, che copre sia una selezione di modelli open source e commerciali SOTA.

A causa di vincoli di tempo, abbiamo scelto il set di dati NQ per l'analisi poiché la diminuzione delle prestazioni su NQ nella Figura 3.1 è particolarmente evidente.

Abbiamo estratto le risposte per ciascun modello a diverse lunghezze di contesto, ispezionato manualmente diversi campioni e, in base a queste osservazioni, definito le seguenti ampie categorie di fallimento:

• contenuto_ripetuto: quando la risposta dell'LLM è costituita da parole o caratteri completamente (senza senso) ripetuti.
• contenuto_casuale: quando il modello produce una risposta completamente casuale, irrilevante per il contenuto, o che non ha senso logico o grammaticale.
• fallimento_nel_seguire_istruzioni: quando il modello non comprende l'intento dell'istruzione o non riesce a seguire l'istruzione specificata nella domanda. Ad esempio, quando l'istruzione riguarda la risposta a una domanda basata sul contesto fornito mentre il modello sta cercando di riassumere il contesto.
• risposta_errata: quando il modello tenta di seguire l'istruzione ma la risposta fornita è errata.
• altri: il fallimento non rientra in nessuna delle categorie sopra elencate

Abbiamo sviluppato prompt che descrivono ciascuna categoria e utilizzato GPT-4o per classificare tutti i fallimenti dei modelli in esame nelle categorie sopra menzionate. Notiamo anche che i pattern di fallimento su questo set di dati potrebbero non essere rappresentativi di altri set di dati; è anche possibile che il pattern cambi con diverse impostazioni di generazione e template di prompt.

Analisi dei fallimenti dei modelli commerciali a contesto lungo

I due grafici a barre sottostanti mostrano l'attribuzione dei fallimenti per i due modelli linguistici commerciali gpt-4 e claude-3-sonnet.

Errori di GPT-4: GPT-4 tende a sbagliare fornendo la risposta errata (ad es. la domanda è “chi ha cantato once upon a dream alla fine di maleficent” dove la risposta corretta è “Lana Del Rey” ma la risposta generata è “Ariana Grande & John Legend”). Inoltre, GPT-4 occasionalmente fornisce risposte irrilevanti o casuali. Ad esempio, quando gli viene chiesto “chi è stato eletto presidente in Messico nel 2000”, la risposta di GPT-4 è “15° più grande in termini nominali e 11° più grande per parità di potere d'acquisto”.

(Esempi di GPT-4 che fornisce la risposta errata)

(Esempi di GPT-4 che risponde con contenuti casuali)

Errori di Claude-3-sonnet: d'altra parte, Claude spesso non riesce a seguire le istruzioni e abbiamo scoperto che la maggior parte degli errori è causata dal fatto che rifiuta di fornire una risposta per motivi di copyright. Di seguito un esempio di modalità di errore da claude-3-sonnet:

(Esempi di claude-3-sonnet che non segue le istruzioni)

Analisi dei fallimenti dei modelli OSS con contesto lungo

I tre grafici a barre sottostanti mostrano l'attribuzione dei fallimenti per i 3 modelli OSS: Llama-3.1-405b-instruct, Mixtral-8x7b-instruct e DBRX-instruct:

Il pattern di fallimento per Llama-3.1-405b-instruct è coerente; il modello fallisce principalmente fornendo la risposta errata. Il modello genera raramente contenuti ripetuti o casuali e le prestazioni di seguimento delle istruzioni sono anche molto buone, con un tasso di fallimento e un'attribuzione complessivi simili a GPT-4. 

(Esempi di Llama-3.1-405b-instruct che fornisce la risposta errata)

chi è stato nominato commissario elettorale dell'India

Om Prakash Rawat

Achal Kumar Jyoti

quando è stata utilizzata per la prima volta la catena per la F1

1978

1973 Canadian Grand Prix

(Esempi per llama-3.1-405b-instruct che forniscono risposte errate)

 

D'altra parte, Mixtral-instruct e DBRX-instruct falliscono con schemi diversi: Mixtral-instruct produce costantemente contenuti ripetuti come “梦梦梦梦梦梦” (cioè “sogno” in cinese) o contenuti casuali irrilevanti per la domanda. Al contrario, DBRX-instruct fallisce costantemente nel seguire le istruzioni riassumendo il contenuto invece di rispondere alla domanda. Il grafico a barre per DBRX mostra anche una maggiore probabilità di rispondere con contenuti ripetuti o casuali. Un esame più attento rivela che questi contenuti casuali o ripetuti cercano ancora di riassumere il contesto ma con frasi ripetute. Di seguito sono riportati esempi da Mixtral-instruct e DBRX-instruct:

(Esempio per Mixtral-instruct che risponde con contenuti ripetuti)

 

(Esempio per Mixtral-instruct che risponde con contenuti casuali)

 

(Esempio per DBRX-instruct che non segue le istruzioni)

 

(Esempio per DBRX-instruct che risponde con "contenuti casuali/ripetuti", che non segue comunque l'istruzione e inizia a riassumere il contesto.)

Mancanza di contesto lungo post-addestramento: Abbiamo trovato particolarmente interessanti i pattern di claude-3-sonnet e DBRX-instruct, poiché questi specifici fallimenti diventano particolarmente evidenti dopo una certa lunghezza del contesto: il fallimento di copyright di Claude-3-sonnet aumenta dal 3,7% a 16k al 21% a 32k al 49,5% a 64k di lunghezza del contesto; il fallimento di DBRX nel seguire le istruzioni aumenta dal 5,2% a 8k di lunghezza del contesto al 17,6% a 16k al 50,4% a 32k. Ipotizziamo che tali fallimenti siano causati dalla mancanza di dati di addestramento per il seguire le istruzioni a lunghezze di contesto maggiori. Osservazioni simili si possono trovare anche nel paper LongAlign (Bai et.al 2024) dove gli esperimenti mostrano che più dati di istruzioni lunghe migliorano le prestazioni nei compiti lunghi, e la diversità dei dati di istruzioni lunghe è benefica per le capacità di seguire le istruzioni del modello.

Insieme, questi pattern di fallimento offrono un set aggiuntivo di diagnostica per identificare fallimenti comuni a lunghe dimensioni di contesto che, ad esempio, possono indicare la necessità di ridurre la dimensione del contesto in un'applicazione RAG basata su diversi modelli e impostazioni. Inoltre, speriamo che queste diagnostiche possano alimentare futuri metodi di ricerca per migliorare le prestazioni del contesto lungo.

Conclusioni

C'è stato un intenso dibattito nella comunità di ricerca LLM riguardo la relazione tra modelli linguistici a contesto lungo e RAG (vedi ad esempio Can Long-Context Language Models Subsume Retrieval, RAG, SQL, and More?, Summary of a Haystack: A Challenge to Long-Context LLMs and RAG Systems, Cohere: RAG Is Here to Stay: Four Reasons Why Large Context Windows Can't Replace It, LlamaIndex: Towards Long Context RAG, Vellum: RAG vs Long Context?)  I nostri risultati sopra mostrano che i modelli a contesto lungo e RAG sono sinergici: il contesto lungo consente ai sistemi RAG di includere efficacemente più documenti pertinenti. Tuttavia, ci sono ancora limiti alle capacità di molti modelli a contesto lungo: molti modelli mostrano prestazioni ridotte a contesto lungo, come evidenziato dal fatto che non seguono le istruzioni o producono output ripetitivi. Pertanto, l'allettante affermazione che il contesto lungo sia posizionato per sostituire RAG richiede ancora un investimento più approfondito nella qualità del contesto lungo in tutto lo spettro dei modelli disponibili.

Inoltre, per gli sviluppatori incaricati di navigare in questo spettro, devono utilizzare buoni strumenti di valutazione per migliorare la loro visibilità su come il loro modello di generazione e le impostazioni di recupero influenzano la qualità dei risultati finali. Seguendo questa esigenza, abbiamo reso disponibili sforzi di ricerca (Calibrating the Mosaic Evaluation Gauntlet) e prodotti (Mosaic AI Agent Framework and Agent Evaluation) per aiutare gli sviluppatori a valutare questi complessi sistemi.

Limitazioni e Lavoro Futuro

Semplice impostazione RAG

I nostri esperimenti relativi a RAG hanno utilizzato una dimensione di chunk di 512, una dimensione di stride di 256 con il modello di embedding OpenAI text-embedding-03-large. Durante la generazione delle risposte, abbiamo utilizzato un semplice template di prompt (dettagli nell'appendice) e abbiamo concatenato i chunk recuperati insieme con delimitatori. Lo scopo di questo è rappresentare l'impostazione RAG più diretta. È possibile impostare pipeline RAG più complesse, come l'inclusione di un re-ranker, il recupero di risultati ibridi tra più retriever, o persino il pre-processing del corpus di recupero utilizzando LLM per pre-generare un set di entità/concetti simili al paper GraphRAG. Queste impostazioni complesse sono al di fuori dell'ambito di questo blog, ma potrebbero richiedere future esplorazioni.

Dataset

Abbiamo scelto i nostri dataset per essere rappresentativi di ampi casi d'uso, ma è possibile che un particolare caso d'uso possa avere caratteristiche molto diverse. Inoltre, i nostri dataset potrebbero avere le proprie peculiarità e limitazioni: ad esempio, Databricks DocsQA presuppone che ogni domanda necessiti solo di un documento come ground truth, mentre questo potrebbe non essere il caso di altri dataset.

Retriever

I punti di saturazione per i 4 dataset indicano che il nostro attuale setting di recupero non può saturare il punteggio di recall fino a oltre 64k o addirittura 128k di contesto recuperato. Questi risultati significano che c'è ancora potenziale per migliorare le prestazioni di recupero spingendo la fonte dei documenti di verità in cima ai documenti recuperati.

Appendice

Tabella delle prestazioni RAG a contesto lungo

Combinando questi task RAG, otteniamo la seguente tabella che mostra le prestazioni medie dei modelli sui 4 dataset elencati sopra. La tabella è costituita dagli stessi dati della Figura 1.

 

Prompt templates

Utilizziamo i seguenti prompt template per l'esperimento 2:

Databricks DocsQA:

 

FinanceBench:

 

NQ e HotpotQA:

 

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale