I problemi della RAG persistono: cinque soluzioni proposte da IBM

È tempo di affrontare la verità sulla Retrieval-Augmented Generation (RAG): è una soluzione che a sua volta necessita di una soluzione. La RAG è stata sviluppata con l'intento di migliorare le prestazioni dei modelli linguistici di grandi dimensioni (LLM) e di ridurre le allucinazioni, permettendo agli LLM di accedere a database di conoscenza esterni che vanno oltre i loro dati di addestramento. Tuttavia, i limiti reali dei sistemi RAG tradizionali sono diventati dolorosamente evidenti.

“Il sistema RAG è ampiamente difettoso”, ha affermato Dinesh Nirmal, Senior Vice President di IBM Software. “Il puro RAG non fornisce realmente i risultati ottimali che ci si aspettava.”

Le sfide che gli utenti devono affrontare con la RAG includono le limitazioni nelle finestre di contesto e nelle operazioni di aggregazione, l'incapacità di comprendere relazioni complesse, nonché output di qualità inferiore legati a un chunking non ottimale. L'implementazione della RAG può anche comportare problemi di sicurezza, come le fughe di dati.

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

SQL RAG

Quando si chiede a un'applicazione LLM basata sulla RAG tradizionale di eseguire operazioni di aggregazione (come il calcolo di una somma) su un set di dati enorme, spesso non è solo difficile, ma letteralmente impossibile. Un fattore che potrebbe compromettere le prestazioni del sistema è la dimensione della finestra di contesto: le finestre di contesto degli LLM non sono generalmente abbastanza scalabili da elaborare, ad esempio, una raccolta di 100.000 fatture. Inoltre, la pipeline RAG tradizionale si basa su database vettoriali, che sono progettati per la ricerca di somiglianza e non per le operazioni di aggregazione.

“Essenzialmente, questo significa che un database vettoriale non è sufficiente per questi casi”, ha spiegato Sudheesh Kairali, IBM Distinguished Engineer. “La finestra di contesto è un problema. L'altro è l'incapacità di gestire operazioni matematiche.”

Ecco l'introduzione di SQL RAG. Quando gli utenti di LLM cercano risposte da grandi set di dati, la combinazione della Retrieval-Augmented Generation con il SQL può fornire risultati precisi, ha spiegato Kairali.

Il SQL include funzioni di aggregazione integrate e i database SQL hanno una capacità maggiore rispetto alle finestre di contesto degli LLM. Se un'azienda inserisce i dati delle sue fatture in un database SQL, può utilizzare un LLM per convertire le query – come ad esempio “Qual è la somma di tutte le fatture dell'ultimo anno?” – in SQL, interrogare il database SQL utilizzando la RAG e ottenere la risposta.

“Se si riesce a costruirlo, molte aggregazioni sono possibili”, ha detto Kairali. Dopo che il database SQL ha eseguito un'aggregazione, “l'LLM deve solo elaborare il linguaggio naturale (NLP).”

GraphRAG

Un'altra debolezza della RAG tradizionale è la determinazione di come le diverse informazioni o entità recuperate siano correlate tra loro. Consideriamo, ad esempio, il caso d'uso di un paziente con una storia clinica complessa. Attraverso il processo di recupero RAG tradizionale, un LLM può fornire informazioni pertinenti. Questi dati potrebbero includere dettagli come il numero di medici che il paziente ha visitato in un anno, ma potrebbe essere difficile specificare quali trattamenti ogni medico abbia prescritto.

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

“Se un paziente è andato in ospedale e la domanda è: mostrami tutte le sue visite precedenti – questo può essere rappresentato non solo a parole, ma come rappresentazione della conoscenza tramite un grafo”, ha spiegato Nirmal. “Si possono esaminare diversi punti e i diversi medici che ha visitato, i diversi farmaci che ha assunto, i trattamenti a cui si è sottoposto – tutto in un'unica rappresentazione grafica.”

GraphRAG, come ha notato Nirmal, ha i suoi limiti, poiché la rappresentazione di un grafo diventa più difficile con l'aumentare del volume dei dati. La mappatura di centinaia di migliaia di nodi è una sfida maggiore rispetto, ad esempio, alla mappatura di solo poche decine di nodi. “Tutto ha limitazioni”, ha detto Nirmal, “ma la ragione per cui GraphRag sta davvero decollando è a causa delle limitazioni del RAG puro stesso.”

Scopri di più su GraphRAG.

Agentic Chunking

Il chunking è cruciale per le applicazioni RAG. Nel chunking tradizionale tramite modelli di embedding, i documenti pertinenti vengono suddivisi in parti più piccole in punti fissi, ciascuna rappresentata in un database vettoriale. Tuttavia, questo metodo può portare un'applicazione LLM a fornire risposte incomplete o imprecise, anche quando utilizza un algoritmo di ricerca semantica basato sul machine learning su un database di conoscenza specifico del dominio.

“Spesso la precisione si perde in questo processo perché non si sa dove suddividere i dati in sezioni”, ha spiegato Nirmal. “Diciamo che si divide un tavolo a metà, in modo che quando si riporta il tavolo, si riporta solo metà del tavolo. Ora si è persa la precisione.”

Fortunatamente, migliori strategie di chunking attraverso i metodi basati su agenti possono migliorare il recupero delle informazioni. Questo chunking basato su agenti include strategie come la creazione di chunk sovrapposti e la modifica dinamica della dimensione dei chunk in base al contesto dei documenti recuperati. I framework di orchestrazione per LLM possono essere utili a questo scopo. Ad esempio, gli strumenti TextSplitters di LangChain possono suddividere il testo in sezioni piccole e semanticamente significative. Tali strategie aiutano a evitare la perdita di informazioni rilevanti quando un documento viene scomposto.

Scopri di più su Agentic Chunking.

Agentic RAG

L'IA agentica è utile nel chunking e può migliorare l'accuratezza del recupero anche in altri modi. Consideriamo la RAG agentica: è un framework avanzato di intelligenza artificiale che può integrare pipeline RAG per interrogare sia i dati strutturati nei database SQL sia i dati non strutturati nei repository di documenti, e utilizzare database vettoriali per la ricerca di somiglianza.

La RAG agentica arricchisce inoltre ogni chunk con metadati. Questo processo correla i dati strutturati (i metadati che sono memorizzati in un database transazionale) con i dati non strutturati per ottimizzare l'accuratezza del recupero.

“Se possiamo combinare la potenza di un database vettoriale con l'aspetto transazionale o SQL, e fondere questi due aspetti”, ha detto Nirmal, “possiamo aumentare significativamente la precisione e le prestazioni.”

Scopri cosa devi fare per superare le tre sfide centrali dei dati non strutturati.

Managed Data Lakehouses

Le fughe di dati sono un problema noto nei sistemi di intelligenza artificiale in generale, e gli LLM che utilizzano la RAG non fanno eccezione. Senza le misure appropriate, un LLM potrebbe fornire a utenti di basso livello informazioni a cui non dovrebbero avere accesso, dai dati personali identificabili (PII) a dati finanziari sensibili.

“Questa è la realtà della RAG”, afferma Kairali. “Quando si inizia con il proof-of-concept, tutti sono soddisfatti. Ma poi, quando si vuole portare il prodotto in produzione e assicurarsi che sia pronto per la produzione, ci si rende conto che c'è un problema di privacy dei dati.”

Per affrontare queste preoccupazioni cruciali sulla sicurezza dei dati, le Managed Data Lakehouses emergono come una soluzione strategica. Offrono un approccio unificato alla gestione dei dati, combinando la flessibilità di un data lake con le funzionalità di gestione e strutturazione di un data warehouse. Questo ambiente controllato è fondamentale per implementare rigide politiche di accesso ai dati, la crittografia e la governance, garantendo che le informazioni sensibili siano protette e accessibili solo agli utenti autorizzati. La loro architettura intrinsecamente sicura aiuta a prevenire le fughe di dati e a mantenere la conformità normativa, trasformando un potenziale punto debole in una risorsa affidabile per l'integrazione sicura di dati in sistemi RAG complessi.