La Retrieval Augmented Generation (RAG) verrà uccisa dagli LLM a contesto lungo?
La ricerca dell’innovazione e della supremazia nell’IA non mostra segni di rallentamento. Di recente, Google ha presentato Gemini 1.5, appena due mesi dopo il debutto di Gemini, il suo più recente modello linguistico di grandi dimensioni (LLM) capace di gestire contesti che si estendono fino all’impressionante cifra di 10 milioni di token. Allo stesso tempo, OpenAI è salita alla ribalta con Sora, un solido modello text-to-video apprezzato per i suoi affascinanti effetti visivi. Il confronto tra queste due tecnologie all’avanguardia ha acceso discussioni sul futuro dell’IA, in particolare sul ruolo e sul potenziale declino della Retrieval Augmented Generation (RAG).
In questo blog, esploreremo le complessità delle capacità di Gemini relative ai contesti lunghi, i suoi limiti e il suo impatto sull’evoluzione delle tecniche di Retrieval Augmented Generation. Soprattutto, discuteremo se la RAG sia sull’orlo del declino e come ottimizzare i sistemi RAG.
Comprendere la capacità di Gemini di gestire contesti lunghi
Sebbene il fascino degli effetti visivi di Sora attiri maggiore attenzione, io sono più interessato a Gemini e al relativo rapporto tecnico, che supera le 50 pagine ed esplora i test sulle capacità di Gemini relative ai contesti lunghi e multimodali. Secondo questo rapporto, Gemini 1.5 Pro supporta contesti ultra-lunghi fino a 10 milioni di token e l’elaborazione di dati multimodali, consentendo a Gemini di interagire senza problemi con dati diversi, da un intero libro e immense raccolte di documenti fino a vaste librerie di codice e un film di un’ora.
Gemini 1.5 Pro supporta contesti ultra-lunghi fino a 10M token. Fonte dell’immagine: https://blog.google/technology/ai/google-gemini-next-generation-model-february-2024/
Stabilità e accuratezza del recupero
Questo rapporto introduce un metodo di valutazione "ago in un pagliaio" per testare e confrontare la capacità di recupero di Gemini 1.5 Pro e GPT-4. In questo test, Google inserisce segmenti di testo (gli "aghi") in posizioni diverse di un documento lungo (il "pagliaio"), e Gemini e GPT devono trovare e nominare i documenti pertinenti per recuperarli.
I risultati dei test mostrano che Gemini 1.5 Pro raggiunge il 100% di recall fino a 530.000 token e mantiene oltre il 99,7% di recall fino a 1M token. Anche con un documento estremamente lungo di 10M token, il modello conserva un impressionante tasso di recall del 99,2%. Mentre GPT-4 gestisce in modo eccellente meno di 128.000 token, Gemini è più competente nella gestione di contesti più estesi. Questi risultati sottolineano l’eccellente recupero delle informazioni, la stabilità e l’accuratezza di Gemini in contesti eccezionalmente lunghi fino a 10M token.
Fonte dell’immagine: https://storage.googleapis.com/deepmind-media/gemini/gemini_v1_5_report.pdf
Risposta alle domande
Oltre a testare la capacità di recupero di Gemini, Google valuta la sua capacità di rispondere alle domande fornire contesto. In questo test, Google utilizza il libro Les Misérables (710.000 token) come contesto e chiede a Gemini 1.5 Pro, Gemini 1.0 Pro e Claude 2.1 di Anthropic di rispondere a domande sul libro.
Poiché Gemini 1.0 Pro e Claude 2.1 supportano una lunghezza del contesto inferiore a 710.000 token, devono sfruttare la tecnica della retrieval augmented generation (RAG) per accedere ai passaggi più rilevanti Top-K (fino a 4.000 token) del libro come loro contesto. Gemini ha una finestra di contesto più ampia, quindi fa riferimento all’intero libro come suo contesto. Questo test confronta anche le prestazioni dei tre modelli nella configurazione 0-shot senza nulla fornito come contesto.
I risultati dei test mostrano che Gemini 1.5 Pro supera altri LLM basati su RAG nel rispondere alle domande, dimostrando la sua superiorità nella comprensione e nell’elaborazione di enormi raccolte di testi. Questo test rivela inoltre che la tecnica della retrieval augmented generation spesso fatica a risolvere espressioni referenziali e ragionamenti tra fonti di dati con dipendenze a lunga distanza.
Fonte immagine: https://storage.googleapis.com/deepmind-media/gemini/gemini_v1_5_report.pdf
Gli LLM con contesto lungo uccideranno RAG?
Il framework di retrieval augmented generation, che incorpora un database vettoriale, un LLM e prompt-as-code, è una tecnologia all’avanguardia che integra senza soluzione di continuità fonti di conoscenza esterne per arricchire la base di conoscenza di un LLM con documenti e risposte precisi e pertinenti. È una soluzione comprovata che affronta efficacemente sfide fondamentali degli LLM come le allucinazioni e la mancanza di conoscenza specifica di dominio.
Assistendo alle notevoli prestazioni di Gemini nella gestione di contesti lunghi, alcune voci prevedono rapidamente la fine di RAG. Ad esempio, in una recensione di Gemini 1.5 Pro su Twitter, il Dr. Yao Fu ha dichiarato audacemente: "Il contesto da 10M uccide RAG."
Questa affermazione è vera? Dal mio punto di vista, la risposta è “NO.” Lo sviluppo della tecnologia RAG è appena iniziato e continuerà a evolversi. Sebbene Gemini eccella nella gestione di contesti estesi, si scontra con sfide persistenti riassunte nelle 4V: Velocity, Value, Volume e Variety.
Le sfide delle 4V degli LLM
Velocity: Gemini incontra ostacoli nel raggiungere tempi di risposta inferiori al secondo per contesti estesi, come evidenziato da un ritardo di 30 secondi nel rispondere a 360.000 contesti. Nonostante l’ottimismo sui progressi computazionali degli LLM, risposte rapide a livello sub-secondo durante il recupero di contesti lunghi rimangono una sfida per i grandi modelli basati su transformer.
Value: La proposta di valore degli LLM è indebolita dai considerevoli costi di inferenza associati alla generazione di risposte di alta qualità in contesti lunghi. Ad esempio, il recupero di 1 milione di token di dataset a una tariffa di 1.50 per una singola richiesta. Questo fattore di costo rende tali spese elevate impraticabili per l’utilizzo quotidiano, ponendo una barriera significativa all’adozione diffusa.
Volume: Nonostante la sua capacità di gestire un’ampia finestra di contesto fino a dieci milioni di token, la capacità di volume di Gemini impallidisce rispetto alla vastità dei dati non strutturati. Ad esempio, nessun LLM, incluso Gemini, può ospitare adeguatamente la scala colossale dei dati presenti nell’indice di ricerca di Google. Inoltre, i dati aziendali privati dovranno rimanere entro i confini dei loro proprietari, che potrebbero scegliere di usare RAG, addestrare i propri modelli o usare un LLM privato.
Varietà: I casi d’uso reali coinvolgono non solo dati non strutturati come testi lunghi, immagini e video, ma anche una vasta gamma di dati strutturati che potrebbero non essere facilmente acquisiti da un LLM a fini di addestramento, come dati di serie temporali, dati a grafo e modifiche al codice. Strutture dati e algoritmi di recupero ottimizzati sono essenziali per elaborare in modo efficiente dati così diversificati.Tutte queste sfide evidenziano l’importanza di un approccio equilibrato nello sviluppo di applicazioni di AI, rendendo RAG sempre più cruciale nel panorama in evoluzione dell’intelligenza artificiale.
Strategie per ottimizzare l’efficacia di RAG
Sebbene la retrieval augmented generation si sia dimostrata utile nel ridurre le allucinazioni degli LLM, presenta comunque dei limiti. In questa sezione esploreremo strategie per ottimizzare l’efficacia della retrieval augmented generation, al fine di trovare un equilibrio tra accuratezza e prestazioni e rendere i sistemi RAG più adattabili a una gamma più ampia di applicazioni.
Migliorare la comprensione del contesto lungo
Le tecniche convenzionali di retrieval augmented generation si basano spesso sul chunking per vettorializzare dati non strutturati, principalmente a causa delle limitazioni dimensionali degli embedding models e delle loro finestre di contesto. Tuttavia, questo approccio di chunking presenta due svantaggi notevoli.
- In primo luogo, suddivide la sequenza di input in chunk isolati, interrompendo la continuità del contesto e influenzando negativamente la qualità degli embedding.
- In secondo luogo, c’è il rischio di separare informazioni consecutive in chunk distinti, con la possibile conseguenza di un recupero incompleto di informazioni essenziali.
In risposta a queste sfide, le strategie emergenti di embedding basate sugli LLM hanno guadagnato terreno come soluzioni efficienti. Offrono una migliore capacità di embedding e supportano finestre di contesto ampliate. Ad esempio, SRF-Embedding-Mistral e GritLM7B, due tra gli embedding language models con le migliori prestazioni nella Huggingface MTEB LeaderBoard, supportano contesti lunghi 32k token, mostrando un sostanziale miglioramento nelle capacità di embedding. Questo miglioramento nell’embedding di dati non strutturati eleva anche la comprensione dei contesti lunghi da parte di RAG.
Un altro approccio efficace per affrontare le sfide sopra menzionate è la strategia BGE Landmark Embedding, recentemente rilasciata. Questo approccio adotta un’architettura senza chunking, in cui gli embedding per le unità di input a grana fine, ad esempio le frasi, possono essere generati sulla base di un contesto lungo coerente. Sfrutta inoltre una funzione sensibile alla posizione per facilitare il recupero completo di informazioni utili comprendenti più frasi consecutive all’interno del contesto lungo. Pertanto, il landmark embedding è utile per migliorare la capacità dei sistemi RAG di comprendere ed elaborare contesti lunghi.
L’architettura per il landmark embedding. I token Landmark (LMK) vengono aggiunti alla fine di ogni frase. Una finestra scorrevole viene utilizzata per gestire i testi di input più lunghi della finestra di contesto dell’LLM. Fonte dell’immagine: https://arxiv.org/pdf/2402.11573.pdf
Questo diagramma confronta i metodi Sentence Embedding e Landmark Embedding nell’aiutare le app RAG a rispondere alle domande. Il primo funziona con il contesto suddiviso in chunk, che tende a selezionare la frase saliente. Il secondo mantiene un contesto coerente, che gli consente di selezionare la frase corretta. Le frasi evidenziate in blu e viola sono risposte recuperate rispettivamente dai due metodi di embedding. Il sistema RAG che ha sfruttato il Sentence embedding ha fornito la risposta sbagliata, mentre il RAG basato su Landmark embedding ha dato la risposta corretta. Questa immagine è adattata da: https://arxiv.org/abs/2402.11573
Utilizzare la ricerca ibrida per migliorare la qualità della ricerca
La qualità delle risposte della generazione aumentata dal recupero dipende dalla sua capacità di recuperare informazioni pertinenti di alta qualità. La pulizia dei dati, l’estrazione di informazioni strutturate e la ricerca ibrida sono tutti modi efficaci per migliorare la qualità del recupero. Ricerche recenti suggeriscono che i modelli a vettori sparsi come Splade superano i modelli a vettori densi nel recupero di conoscenze fuori dominio, nella percezione delle parole chiave, nella ricerca semantica e in molti altri ambiti.
Il modello di embedding BGE_M3, recentemente reso open-source, può generare vettori di token sparsi, densi e simili a Colbert all’interno dello stesso modello. Questa innovazione migliora significativamente la qualità del recupero del database vettoriale conducendo recuperi ibridi su diversi tipi di vettori. In particolare, questo approccio è in linea con il concetto di ricerca ibrida ampiamente accettato tra i fornitori di database vettoriali come Zilliz. Ad esempio, la prossima versione di Milvus 2.4 promette una ricerca ibrida più completa di vettori densi e sparsi.
Utilizzare tecnologie avanzate per migliorare le prestazioni di RAG
In questo diagramma, Wenqi Glantz ha elencato 12 punti critici nello sviluppo di una pipeline RAG e ha proposto 12 soluzioni corrispondenti per affrontare queste sfide. Fonte dell’immagine:https://towardsdatascience.com/12-rag-pain-points-and-proposed-solutions-43709939a28c
Massimizzare le capacità di RAG implica affrontare numerose sfide algoritmiche e sfruttare capacità e tecnologie ingegneristiche sofisticate. Come evidenziato da Wenqi Glantz nel suo blog, sviluppare una pipeline RAG presenta almeno 12 complesse sfide ingegneristiche. Affrontare queste sfide richiede una profonda comprensione degli algoritmi di ML e l’utilizzo di tecniche complesse come la riscrittura delle query, i dati di addestramento per il riconoscimento dell’intento,, e il rilevamento delle entità.
Anche modelli avanzati come Gemini 1.5 affrontano ostacoli sostanziali. Richiedono 32 chiamate per raggiungere un tasso di accuratezza del 90,0% nei test benchmark MMLU di Google. Ciò sottolinea la natura della massimizzazione delle prestazioni nei sistemi RAG.
I database vettoriali, una delle tecnologie AI all’avanguardia, sono un componente fondamentale nella pipeline RAG. Optare per un database vettoriale più maturo e avanzato, come Milvus, estende le capacità della tua pipeline RAG dalla generazione di risposte ad attività come la classificazione, l’estrazione di dati strutturati e la gestione di documenti PDF complessi. Tali miglioramenti poliedrici dei database vettoriali contribuiscono all’adattabilità dei sistemi RAG in uno spettro più ampio di casi d’uso applicativi.
Conclusione: RAG rimane un cardine per il successo duraturo delle applicazioni AI.
I modelli linguistici di grandi dimensioni stanno rimodellando il mondo, ma non possono cambiare i principi fondamentali del nostro mondo. La separazione tra calcolo, memoria e archiviazione esterna dei dati esiste fin dalla nascita dell’architettura di von Neumann nel 1945. Tuttavia, anche con la memoria di una singola macchina che oggi raggiunge il livello dei terabyte, SATA e i dischi flash svolgono ancora ruoli cruciali in diversi casi d’uso applicativi. Ciò dimostra la resilienza dei paradigmi consolidati di fronte all’evoluzione tecnologica.
Il framework RAG è ancora un cardine per il successo duraturo delle applicazioni AI. La sua fornitura di memoria a lungo termine per i modelli linguistici di grandi dimensioni si rivela indispensabile per gli sviluppatori che cercano un equilibrio ottimale tra qualità delle query ed efficienza dei costi. Nell’implementazione dell’AI generativa da parte delle grandi imprese, RAG è uno strumento critico per il controllo dei costi senza compromettere la qualità delle risposte.
Proprio come gli sviluppi della memoria di grandi dimensioni non possono scalzare i dischi rigidi, il ruolo di RAG, insieme alle sue tecnologie di supporto come il database vettoriale, rimane integrale e adattivo. È destinato a durare e coesistere nel nuovo panorama dei dati in continua evoluzione delle applicazioni AI e del recupero delle informazioni.
Continua a leggere
Why Context Engineering Is Becoming the Full Stack of AI Agents
Discover how context engineering unifies prompts, RAG, and tools to build smarter, production-ready AI agents powered by Milvus.
Why Not All VectorDBs Are Agent-Ready
Explore why choosing the right vector database is critical for scaling AI agents, and why traditional solutions fall short in production.
What is the K-Nearest Neighbors (KNN) Algorithm in Machine Learning?
KNN is a supervised machine learning technique and algorithm for classification and regression. This post is the ultimate guide to KNN.