I problemi delle RAG persistono: ecco cinque modi per risolverli

È tempo di affrontare la verità sulla retrieval-augmented generation, o RAG: è una soluzione che necessita di una propria soluzione.

La RAG era pensata per migliorare le prestazioni dei modelli linguistici di grandi dimensioni e ridurre le allucinazioni, permettendo ai modelli linguistici di grandi dimensioni (LLM) di andare oltre i dati di addestramento con accesso a knowledge base esterne. Tuttavia, i limiti reali dei sistemi RAG tradizionali sono diventati dolorosamente chiari.

"In larga misura, la RAG è imperfetta", ha affermato Dinesh Nirmal, vicepresidente senior di IBM® Software. "La RAG pura non sta davvero dando i risultati ottimali che ci aspettavamo".

Le sfide della RAG che gli utenti affrontano regolarmente includono limiti sulle finestre di contesto e sulle operazioni di aggregazione, l'incapacità di comprendere relazioni complesse e output di bassa qualità associati a scadenze sub ottimali. In particolare, implementare la RAG può anche presentare problemi di sicurezza, come la fuga di dati.

La buona notizia è che i progressi negli strumenti e nelle strategie di intelligenza artificiale stanno contribuendo a compensare i difetti della RAG tradizionale, generando risposte più precise alle query degli utenti. Diamo un'occhiata più da vicino a come migliorare le prestazioni della RAG.

Chiedere a un'applicazione LLM alimentata dalla tradizionale RAG di eseguire operazioni di aggregazione (come fare una somma) per un enorme set di dati non è difficile, è letteralmente impossibile. Una cosa che ostacola le prestazioni del sistema è la dimensione della finestra di contesto: le finestre di contesto degli LLM generalmente non sono scalabili abbastanza per elaborare, ad esempio, una raccolta di 100.000 fatture. Inoltre, la pipeline RAG tradizionale si basa su database vettoriali, che sono progettati per ricerche di somiglianza, non per operazioni di aggregazione.

"In sostanza, ciò significa che un database vettoriale non è sufficiente per gestire questi casi", ha spiegato Sudheesh Kairali, Ingegnere distinto di IBM. "La finestra di contesto è un problema. L'altro problema è l'incapacità di gestire operazioni matematiche".

Entra in scena la SQL RAG.  

Quando gli utenti LLM cercano risposte da grandi set di dati, combinare la retrieval-augmented generation con un SQL può fornire risultati precisi, ha spiegato Kairali.

SQL include funzioni di aggregazione integrate e i database SQL hanno una capacità maggiore rispetto alle finestre di contesto LLM. Se un'azienda inserisce i propri dati delle fatture in un database SQL, può utilizzare un LLM per convertire le query ("Qual è la somma di tutte le fatture dell'anno scorso?") in SQL, interrogare il database SQL tramite RAG e ottenere la risposta.

"Se si è in grado di costruirlo, si possono realizzare molte aggregazioni", ha affermato Kairali. Dopo che il database SQL esegue un'aggregazione, "a quel punto diventa solo un esercizio di elaborazione del linguaggio naturale (NLP) per l'LLM".

Capire come diversi pezzi di informazione o entità recuperate si connettano tra loro è un altro punto debole della RAG tradizionale. Ad esempio, consideriamo il caso d'uso per un paziente con una storia clinica complessa. Attraverso il tradizionale processo di recupero RAG, un LLM potrebbe fornire informazioni rilevanti. Questi dati potrebbero includere dettagli come il numero di medici consultati dal paziente in un anno, ma potrebbe essere difficile specificare quali trattamenti siano stati prescritti da ciascun medico.

GraphRAG, introdotto nel 2024 da Microsoft Research, affronta questa sfida elaborando e identificando relazioni tramite grafici di conoscenza. GraphRAG organizza le informazioni come una rete di nodi ed edge che rappresentano le entità e le loro relazioni reciproche.

"Se un paziente è andato in ospedale e chiediamo al sistema di mostrare tutte le visite precedenti che ha effettuato, ciò può essere fatto non solo con un testo ma anche come rappresentazione della conoscenza tramite un grafico", ha spiegato Nirmal. "Possiamo esaminare diversi punti e vedere i diversi medici che ha visitato, i diversi medicinali che ha assunto, i trattamenti a cui è stato sottoposto, il tutto in un'unica rappresentazione grafica".

GraphRAG, ha osservato Nirmal, presenta delle limitazioni perché la renderizzazione di un grafo diventa più difficile con l'aumentare del volume di dati. Ad esempio, mappare centinaia di migliaia di nodi è più impegnativo che mapparne solo poche decine. "Tutto ha i suoi limiti", ha affermato Nirmal, "ma il motivo per cui GraphRAG sta decollando è dovuto ai limiti della RAG pura".

Scopri di più su GraphRAG.

Il chunking è critico per le applicazioni della RAG. Nei modelli tradizionali di chunking attraverso l'embedding, i documenti rilevanti vengono suddivisi in punti fissi in pezzi più piccoli, ciascuno rappresentato in un database vettoriale. Tuttavia, questo metodo potrebbe far sì che un'applicazione di LLM fornisca risposte incomplete o imprecise anche quando utilizza un machine learning di ricerca semantica su una knowledge base specifica di un dominio.

"In questo processo, spesso si perde accuratezza perché non si sa dove si stanno suddividendo i dati", ha spiegato Nirmal. "Supponiamo che tu abbia tagliato o diviso il centro di una tabella, così quando la riporti indietro, ne porti via metà. Ora ne hai perso l'accuratezza".

Fortunatamente, strategie di chunking migliori tramite metodi agentici possono migliorare il recupero delle informazioni. Questo chunking agentico include strategie come la creazione di chunk sovrapposti e la modifica dinamica delle dimensioni dei chunk in base al contesto dei documenti recuperati. I framework di orchestrazione LLM possono essere utili a questo scopo. Ad esempio, gli strumenti TextSplitters di LangChain possono suddividere il testo in piccoli blocchi semanticamente significativi. Tali strategie aiutano a evitare la perdita di informazioni rilevanti quando un documento viene decomposto.

Scopri di più sul chunking agentico.

L'agentic AI è utile per il chunking e può anche migliorare la precisione del recupero in altri modi. Considera la RAG agentica: è un framework AI avanzato che può integrare pipeline RAG per interrogare sia dati strutturati in database SQL sia dati non strutturati nei repository di documenti, sfruttando database vettoriali per la ricerca di similarità. 

La RAG agentica arricchisce anche ogni blocco con metadati. Questo processo mette in relazione i dati strutturati (i metadati memorizzati in un database transazionale) con i dati non strutturati per ottimizzare la precisione del recupero.

"Se possiamo davvero prendere il potere di un database vettoriale insieme all'aspetto transazionale o SQL e unirli", ha affermato Nirmal, "possiamo davvero aumentare notevolmente la precisione e le prestazioni".

Scopri cosa serve per superare le tre sfide principali dei dati non strutturati.

La fuga di dati è un problema noto nei sistemi di AI in generale, e gli LLM che utilizzano la RAG non fanno eccezione. Senza le giuste misure in atto, un LLM potrebbe fornire agli utenti di basso livello informazioni a cui non sono autorizzati ad accedere, dalle informazioni personali identificative (PII) ai dati finanziari sensibili.

"Questa è una realtà con la RAG", ha affermato Kairali. "Quando si inizia con una prova di concetto, tutti sono contenti. Ma poi, quando si porta in produzione e ci si assicura che sia di qualità produttiva, si inizia a capire che c'è un problema di protezione dei dati".

Per risolvere il problema è necessario preservare gli elenchi di controllo degli accessi (ACL) e altre policy di governance quando i dati non strutturati vengono inseriti in più database. "Quando arriva la query e i dati vengono recuperati, è importante assicurarsi che gli ACL e le policy di governance vengano rispettati", ha affermato Kairali. "È fondamentalmente un problema di ingegneria".

La risoluzione di questo problema ingegneristico può essere semplificata con le giuste piattaforme di dati, come data lakehouse governati e abilitati all'open source. Ad esempio, watsonx.data di IBM, un data lakehouse ibrido e aperto, garantisce che i controlli di accesso vengano ereditati dai sistemi sorgente dei documenti quando i dati vengono recuperati. Fornisce inoltre annotazioni per le PII per prevenire la condivisione di informazioni sensibili.

Man mano che gli LLM e altre forme di AI generativa diventano sempre più radicati nei workflow quotidiani, il miglioramento della RAG aiuta le aziende a sbloccare maggiore valore dai propri dati aziendali. Gli strumenti e le strategie aziendali adeguati "consentono prestazioni e accuratezza più elevate, rendendo i dati gestibili e preziosi", ha affermato Nirmal. "Questo è ciò che ogni cliente cerca".