Considerazioni pratiche nella progettazione dell’applicazione RAG

Pratici consigli nella progettazione dell'applicazione RAG

Questa è la seconda parte dell’analisi RAG:

parte 1: Svantaggi di RAG
parte 2: Considerazioni pratiche nella progettazione delle applicazioni RAG

L’architettura RAG (Retrieval Augmented Generation) è stata dimostrata efficiente nel superare il limite di lunghezza di input LLM e il problema del taglio della conoscenza. Nello stack tecnico LLM di oggi, RAG è tra le fondamenta per ancorare l’applicazione alla conoscenza locale, mitigare le allucinazioni e rendere le applicazioni LLM verificabili. Ci sono molti esempi di come costruire un’applicazione RAG. E ci sono anche vari tipi di database vettoriali.

Molte persone hanno notato che, nonostante il fatto che le applicazioni RAG siano facili da mostrare, sono difficili da mettere in produzione. In questo articolo, vediamo alcuni dettagli pratici dello sviluppo delle applicazioni RAG.

Agenda

· Il bilanciamento perfetto LLM· Aspettative di prestazioni RAG· Conservazione delle informazioni· Punti di forza e debolezze di RAG· Verso un’applicazione RAG migliore ∘ Tratta il tuo LLM ∘ Mantenere il modello di embedding sulla stessa pagina ∘ La strategia di chunking conta ∘ Ridurre la perdita di informazioni ∘ LLM Empatia· Parole di chiusura· Riferimenti

Il bilanciamento perfetto LLM

Assumendo di avere un LLM generativo con una lunghezza di input illimitata, la lunghezza della stringa di input non ha alcuna influenza sull’accuratezza del LLM generativo. Oltre a ciò, si comporta esattamente come tutti gli altri LLM popolari. Chiamiamo questo modello LLM perfetto. Lo consideriamo perfetto non perché ha ottime prestazioni, ma perché ha la desiderata lunghezza di input illimitata, che è attualmente impossibile. La lunghezza di input illimitata è davvero una caratteristica attraente da avere. In effetti, alcuni progetti ambiziosi stanno già lavorando su LLM con un input incredibilmente lungo. Uno di essi sta cercando la possibilità di un LLM con 1 milione di token di input! Tuttavia, temo che anche il limite di 1 milione di token potrebbe non essere sufficiente nell’applicazione perché corrisponde solo a 4-5 MB. È comunque inferiore a un gran numero di documenti nel mondo reale.

Ora la domanda è: se avessi un LLM perfetto del genere, considereresti comunque l’architettura RAG? Il LLM perfetto con lunghezza di input illimitata riduce la necessità di costruire un RAG complicato. Tuttavia, probabilmente sì, devi comunque considerare l’architettura RAG. L’architettura RAG aiuta non solo a superare il limite di lunghezza di input del LLM, ma anche a ridurre i costi di invocazione del LLM e a migliorare la velocità di elaborazione. I LLM generativi devono elaborare i contenuti in sequenza. Più lungo è l’input, più lento diventa.

Quando progettiamo un’applicazione RAG, dobbiamo utilizzare il LLM presumibilmente perfetto come punto di riferimento per scrutinare l’applicazione RAG, così da poter avere una chiara visione dei pro e dei contro di RAG e trovare modi per migliorare le nostre applicazioni RAG.

Aspettative sulle prestazioni di RAG

Con il modello di base, l’input dell’applicazione AI generativa viene direttamente inserito nel LLM in un’unica volta. In questo modo, il LLM ha l’opportunità di elaborare tutte le informazioni nel testo in input. L’accuratezza del risultato finale dipende solo dalle prestazioni del generativo LLM.

Per un’applicazione RAG standard, ci sono altri due componenti che influenzano le prestazioni finali: il metodo di ricerca semantica e l’implementazione di RAG. L’architettura RAG utilizza un modello di incorporamento per generare vettori sia della conoscenza del vero sapere che della query. Successivamente, utilizza la funzione di similarità tra vettori per recuperare i contenuti più rilevanti. La capacità del modello di incorporamento di estrarre il significato dal testo è molto critica. Oltre al modello di incorporamento, ci sono numerosi dettagli di implementazione nello sviluppo di RAG, che influiscono anche pesantemente sul risultato finale. Pertanto, l’accuratezza dell’output di RAG sarebbe uguale al prodotto dell’accuratezza del generativo LLM, dell’accuratezza della ricerca semantica e del tasso di conservazione delle informazioni di RAG. Spiegherò in seguito il concetto di tasso di conservazione delle informazioni di RAG.

Poiché tutti e tre i fattori sono inferiori al 100%, l’accuratezza prevista di un’applicazione RAG è inferiore a quella di un’applicazione basata sullo stesso modello LLM ma perfetto. Se RAG non è progettato correttamente, le sue prestazioni calano in modo significativo. Questo è il primo concetto da tenere presente quando iniziamo a pensare alla progettazione della nostra applicazione RAG. Altrimenti, le prestazioni inaspettate ci sorprenderanno.

Dato che le prestazioni finali sono guidate da questi tre fattori, il design dell’applicazione RAG deve anche essere incentrato su tutti e tre i componenti per ottenere un risultato soddisfacente.

Conservazione delle informazioni

È facile comprendere che sia il modello LLM che la ricerca semantica non possono raggiungere un’accuratezza del 100%. Permettimi di spiegare cos’è il tasso di conservazione delle informazioni di RAG.

Il corpus di testo che alimentiamo nell’applicazione può contenere informazioni molto ricche. Diamo un’occhiata a cosa c’è nel corpus e a come le informazioni vengono fornite al LLM:

Il grafico rappresenta le relazioni tra entità nel corpus di testo. Le entità sono distribuite in tutto il corpus e anche le relazioni di riferimento sono ovunque. Dopo il processo di chunking, le entità vengono contenute in ciascun silos e le relazioni tra i chunk vengono interrotte. Nella fase di recupero, solo i chunk top-k hanno l’opportunità di essere inviati al LLM. Ciò significa che solo una porzione delle entità e delle relazioni può essere trasmessa al LLM. Il LLM avrà difficoltà se richiede una conoscenza delle relazioni estesa per rispondere alla query.

Oltre alle relazioni tra entità, l’operazione di chunking avrà un impatto su una varietà di altri tipi di informazioni nell’input:

1. Informazioni contestuali:

Nella maggior parte dei casi, il testo ha diversi livelli di informazioni contestuali. Ad esempio, il libro “The Elements of Statistical Learning” ha 18 capitoli, ognuno dei quali si concentra su un singolo argomento. Ha sottotemi e sottotemi di secondo livello in ciascun capitolo, ecc. Le persone sono abituate a comprendere il testo in contesto. La strategia di chunking fa sì che il contenuto sia disconnesso dal suo contesto.

2. Informazioni posizionali:

I testi hanno diversi pesi a seconda della loro posizione nel documento. I testi all’inizio e alla fine di un documento sono più importanti di quelli nel mezzo. Sono più importanti quando si trovano all’inizio o alla fine di un capitolo rispetto a quando si trovano nel mezzo di un capitolo.

3. informazioni sequenziali:

Il testo naturale utilizza frequentemente connessioni linguistiche esplicite e implicite per collegare argomenti. Ad esempio, una storia può iniziare con “nell’inizio”, continuare con “poi”, “quindi”, “dopo di che”, fino a terminare con “infine”, “eventualmente”, ecc. Con la strategia di chunking, questo tipo di connessione non è più completa. Non solo mancano i pezzi del puzzle, ma l’ordine sequenziale viene mescolato.

4. informazioni descrittive:

Questo si riferisce alle informazioni che descrivono un singolo soggetto. Con il chunking, le informazioni descrittive potrebbero non essere garantite di essere raggruppate insieme. Immagina di essere a metà di una telefonata e improvvisamente la linea cade. Dipende da quanto è importante la chiamata e quando è successo, l’impatto va da banale a molto frustrante.

Punti di forza e di debolezza di RAG

Se chiamiamo RAG che utilizza solo il chunking e la ricerca di similarità vettoriale “RAG vanilla”, possiamo vedere che possono gestire solo alcuni tipi di query perché perdono parte delle informazioni di input di cui abbiamo parlato in precedenza:1. Buono per rispondere a domande descrittive a portata ristretta. Ad esempio, quale soggetto possiede determinate caratteristiche?

2. Non buono nel ragionamento delle relazioni, ossia nel trovare un percorso dall’entità A all’entità B o nell’identificare gruppi di entità.

3. Non buono nella sintesi a lunga distanza. Ad esempio, “Elenca tutte le lotte di Harry Potter” o “Quante lotte ha Harry Potter?”.

Le applicazioni RAG si comportano male in questo tipo di compiti perché solo pochi chunk possono essere inseriti nell’LLM e questi chunk sono sparsi. Sarebbe impossibile per l’LLM raccogliere le informazioni necessarie per iniziare.

Le applicazioni RAG sono per lo più basate su un LLM generatore, il che dà agli utenti l’impressione che l’applicazione RAG debba avere una capacità di ragionamento di alto livello simile all’LLM perfetto. Tuttavia, poiché l’LLM ha un input inadeguato rispetto al modello perfetto, le applicazioni RAG non hanno lo stesso livello di potere di ragionamento. La consapevolezza dei limiti delle informazioni di input può aiutarci a capire cosa può fare e cosa non può fare RAG. Dovremmo cercare il campo più adatto per RAG ed evitare di forzarlo nel posto sbagliato.

Verso un’applicazione RAG migliore

Dopo aver discusso delle limitazioni dell’applicazione RAG, vediamo come possiamo migliorarne le prestazioni.

Tratta il tuo LLM

Spesso, quando si gestisce la query di input, accettiamo semplicemente ciò che l’utente invia. Questo non è ideale, non solo a causa dei rischi di sicurezza come la divulgazione della query e l’inserimento della query, ma anche perché le prestazioni potrebbero essere deludenti.

Secondo i ricercatori, gli LLM sono sensibili a errori di battitura e differenze nel modo di esprimersi nella query [1]. Per assicurarsi che gli LLM funzionino al massimo delle prestazioni, considera di correggere tutti gli errori di battitura e di riformulare l’input in una forma più facile per gli LLM.

Mantieni il modello di incorporamento sulla stessa pagina

Nella maggior parte dei casi, l’utente invia query brevi, come ad esempio “Parlami di Tony Abbott”. Quindi, la query viene convertita in un vettore di incorporamento, che cattura l’essenza di quella specifica query. Effettuare una ricerca semantica con una query diretta può essere impegnativo perché:

Le query dell’utente sono brevi e formulare come domande. Contengono poche caratteristiche semantiche. Mentre gli incorporamenti dei documenti sono lunghi, formulati in varie forme di affermazioni, gli incorporamenti dei documenti hanno informazioni molto più ricche nei loro vettori.
A causa delle poche caratteristiche semantiche nella query dell’utente, la funzione di ricerca semantica tende a sovrainterpretare dettagli banali nella query. L’incorporamento del documento può contenere un alto livello di rumore. Il chunking peggiora la situazione perché molte relazioni, contesti e connessioni sequenziali sono assenti.
I modelli di incorporamento e gli LLM generativi appartengono a famiglie diverse. Sono addestrati in modo diverso e hanno comportamenti diversi. I modelli di incorporamento non hanno lo stesso livello di capacità di ragionamento degli LLM generativi. Non rispettano nemmeno i dettagli linguistici tanto quanto gli LLM generativi. Fare una query direttamente con l’input dell’utente, nel caso peggiore, farà sì che la funzione di ricerca semantica si declassi a una ricerca per parole chiave.
Poiché gli incorporamenti e gli LLM generativi sono due modelli diversi che svolgono ruoli diversi nell’intero processo, non sono sulla stessa pagina. I due modelli fanno la propria parte del lavoro in base alla loro comprensione di ciò che è richiesto, ma non parlano tra loro. Le informazioni recuperate potrebbero non essere ciò che l’LLM ha bisogno per produrre il miglior risultato. Questi due modelli non hanno un modo per allinearsi tra loro.

Per evitare questo problema, probabilmente vuoi utilizzare prima un LLM generativo per arricchire le query degli utenti. Considera il seguente esempio:

Query originale dell’utente: Parlami di Tony Abbott.

E le query aggiunte che sono state riformulate sulla base della query originale utilizzando Bard:
– Qual è l’esperienza politica di Tony Abbott?
– Quali sono i risultati più significativi di Tony Abbott?
– Quali sono le opinioni politiche di Tony Abbott?
– Quali sono gli interessi personali di Tony Abbott?
– Quali sono alcune delle controversie in cui è stato coinvolto Tony Abbott?

Riesci a notare il miglioramento dell’informazione? Le query aggiunte forniscono più dettagli, producendo quindi un risultato di ricerca migliore. Inoltre, inviando le query aggiunte, il LLM ha l’opportunità di comunicare al modello di incorporamento ciò di cui ha bisogno, e il modello di incorporamento può svolgere un lavoro migliore nel fornire chunk di alta qualità al LLM. Ecco come i due modelli possono lavorare insieme.

L’importanza della strategia di frazionamento

La dimensione dei chunk è uno dei pochi superparametri che possiamo regolare per un’applicazione RAG. Per ottenere un risultato migliore, è consigliabile utilizzare dimensioni di chunk più piccole. Un’analisi di questo tipo è stata condotta da Microsoft [2]:

Dimensione del chunk vs. prestazioni. Da [2]

Quando dividiamo il testo, possiamo anche scegliere diverse strategie di suddivisione. Il modo più semplice è tagliare al termine di una parola. Possiamo anche provare diverse strategie, come tagliare al termine di una frase o di un paragrafo. E per ottenere un risultato ancora migliore, possiamo sovrapporre i chunk adiacenti. Il confronto delle strategie di frazionamento dell’analisi di Microsoft [2]:

Impatto di diverse strategie di suddivisione. Da [2]

I modelli di incorporamento hanno un potere limitato di estrazione semantica. Sono meno efficaci nel presentare corpora multi-argomento e multi-turno rispetto a quelli semplici. Ecco perché il RAG preferisce chunk più brevi. Quindi quale dimensione di chunk è la migliore? Nell’analisi di Microsoft, la dimensione di chunk più piccola era di 512 token. Dev’essere stata ispirata dalla scoperta che chunk più piccoli funzionano meglio; la dimensione di chunk in alcune applicazioni commerciali RAG era di circa 100 token. La dimensione di chunk più piccola ottiene sempre il miglior risultato?

Come discusso in precedenza, la strategia di frazionamento spezzerà il corpo del testo in piccoli pezzi, causando una perdita di informazioni. Più piccola è la dimensione del chunk, maggiore sarà la perdita di informazioni. Quindi, esiste una dimensione di chunk ottimale. Chunk troppo piccoli potrebbero non essere ideali. Tuttavia, cercare la dimensione di chunk ottimale è come regolare un superparametro. Dovrai sperimentare con i tuoi dati.

Precisione vs. dimensione del chunk. Da Autore

Ridurre la perdita di informazioni

L’analisi di Microsoft ha scoperto che frazionando con una significativa sovrapposizione si migliora la precisione. Perché aiuta e possiamo trovare un modo migliore per migliorare le prestazioni del RAG?

La ragione dietro la sovrapposizione era che essa può aiutare a collegare i chunk adiacenti e fornire migliori informazioni contestuali per il chunk. Tuttavia, anche la sovrapposizione molto aggressiva del 25% può migliorare la precisione solo dell’1,5%, passando dal 42,4% al 43,9%. Ciò significa che questa non è il modo più efficiente per ottimizzare le prestazioni del RAG. Non possiamo migliorare ulteriormente le prestazioni del RAG aumentando la sovrapposizione. Ricorda che il frazionamento sovrapposto non è nemmeno un’opzione per i chunk più piccoli.

Come dimostrato dalla strategia di frazionamento sovrapposto, preservare le informazioni può aiutare LLM a fornire risposte migliori. Come possiamo preservare al massimo le informazioni di input?

La strategia di divisione sovrapposta sperava semplicemente che le ultime frasi del blocco precedente potessero fornire ulteriori informazioni contestuali. E come possiamo capire, le ultime frasi potrebbero non essere molto rappresentative. Probabilmente possiamo usare invece un riassunto generato da LLM del blocco precedente anziché la sovrapposizione.

E ricorda che il testo di input ha più livelli di informazioni contestuali. Se questo è il caso con la tua applicazione, forse desideri inserire anche le informazioni contestuali stratificate nel blocco. Oppure un modo più efficiente potrebbe essere quello di memorizzare le informazioni contestuali come metadati.

RAG con Knowledge Graph è una tendenza attuale. Con l’aiuto dei grafi di conoscenza, RAG può memorizzare le relazioni nel database a grafo. La connessione tra i blocchi può essere completamente preservata. Questa è una soluzione molto considerevole se il ragionamento sulle relazioni è critico per il tuo progetto.

Tuttavia, RAG con Knowledge Graph non è privo di sfide. Creare un grafo di conoscenza da un testo non strutturato non è semplice. Ci sono parecchi esperimenti sull’estrazione delle triplette entità-relazione dall’input testuale. È una storia diversa quando devi mettere in produzione la soluzione. Le entità e le relazioni estratte automaticamente possono contenere molto rumore e omettere troppe informazioni reali. Devi ispezionare attentamente la qualità del risultato. Anche dopo la popolazione del grafo di conoscenza, le query supportate sono strettamente legate alla progettazione del database a grafo.

Non è altrettanto elegante come RAG con Knowledge Graph, ma il database relazionale abilitato alla ricerca vettoriale è anche un componente molto importante nel toolkit. Un database come pgvector ti consente di memorizzare informazioni sofisticate come colonne preservando le funzioni di ricerca semantica. È molto più facile da integrare con altri sistemi aziendali e molto più flessibile rispetto a un grafo di conoscenza.

Tutte queste sono opzioni valide da considerare. L’unico avviso è che molti database a grafo abilitati alla ricerca vettoriale, motori di ricerca e database relazionali non sono completamente ottimizzati come database vettoriali. La loro velocità nel gestire indici vettoriali su larga scala potrebbe non essere ideale, specialmente quando devono aggiornare molto spesso l’indice. Per ulteriori dettagli sull’introduzione ai diversi tipi di archivi vettoriali, consulta [3].

LLM Empathy

A volte, ci accorgiamo che RAG non risponde alle nostre domande in modo soddisfacente. Invece di girare tutte le manopole per migliorarne le prestazioni, dovremmo probabilmente considerare le seguenti domande:

L’LLM ha tutte le informazioni di cui ha bisogno?
Le informazioni sono organizzate in un modo friendly per LLM?

Consideriamo il seguente esempio:

Stiamo costruendo un’applicazione RAG su un sito web di SharePoint. Una delle pagine web riguarda tutti i progetti e i membri del team, inclusi tutti i profili delle persone. Dobbiamo assicurarci che RAG risponda con precisione alle domande sui progetti rispetto ai membri del team; tuttavia, il risultato iniziale è stato molto deludente.

L’indagine iniziale ha mostrato che il sito web di SharePoint non organizza i contenuti in modo strutturato in modo tale che l’affiliazione delle informazioni possa essere facilmente compresa. Dopo aver rimosso tutti i tag HTML, il contenuto della pagina web appare come segue:

progetto AContatto cliente: SteveMembri del team: persona Apersona Bemail di persona Aemail di persona Brolo di persona Aruolo di persona Bdescrizione di persona Adescrizione di persona Bprogetto B...

Se gli umani trovano difficile capire chi è chi, anche RAG avrà difficoltà. Per organizzare meglio le informazioni, abbiamo usato il codice Python per aggregare insieme le informazioni in base alle proprietà HTML, separando ogni progetto e i nomi dei membri del team in un singolo file di testo e mettendo le informazioni di ogni persona nel suo file separato:

file project_A.txt:nome del progetto: project_AContatto cliente: SteveMembri del team:Adam SmithJobs Muskfile person_A.txt:nome: Adam Smithemail: [email protected]: ingegneredescrizione: Passioni/hobby: arrampicata su roccia...

I file di testo generati sono piccoli, il che sembra non essere in linea con la pratica di divisione in blocchi di RAG. Il motivo è che i file molto concentrati evitano il problema della suddivisione e riducono completamente il rumore. Con i file appena generati, RAG non ha problemi a rispondere a domande come “chi sta lavorando al progetto x?” e “qual è l’hobby di Adam Smith?”.

Tuttavia, RAG ha avuto difficoltà quando abbiamo invertito la domanda: “Su quale progetto sta lavorando Adam Smith?” Abbiamo visto Adam Smith elencato tra i membri del progetto. Non siamo molto sicuri del motivo per cui il modello di incorporamento non lo riconosce. Per aiutare LLM a completare il lavoro, possiamo mettere in evidenza le informazioni. Abbiamo aggiunto una riga nel file della persona che indica esplicitamente l’ingaggio nel progetto:

file person_A.txt:nome: Adam Smithemail: [email protected]: ingegneredescrizione: Passioni/hobby: arrampicata su rocciaprogetto: project_A

E questa linea aggiuntiva rende l’applicazione RAG in grado di rispondere alle domande sopra elencate con precisione al 100%.

Conclusioni

RAG come tecnologia emergente è in rapida evoluzione. Ho scoperto che mi ha aiutato molto quando ho esaminato i suoi mattoni uno per uno. Analizzando i dettagli, posso ottenere una visione più approfondita dei pro e dei contro della tecnologia e sviluppare un’idea di quanto importante possa essere una nuova proposta. Ci sono alcuni framework molto popolari che aiutano le persone a sviluppare applicazioni RAG. Ho trovato alcune idee di implementazione stimolanti; tuttavia, non consiglio di imparare o sviluppare il proprio RAG solo perché è facile iniziare.

Se hai seguito questo articolo fino a questo punto, devi essere d’accordo sul fatto che RAG sia un’architettura complicata. I framework popolari hanno avvolto tutti i dettagli, facendo pensare alle persone che quei dettagli non fossero importanti. Il mio suggerimento è di imparare RAG con l’implementazione di base e considerare le funzionalità aggiuntive successivamente. In questo modo, conoscerai gli elementi essenziali e l’impatto di ogni parte mobile. Non è così difficile iniziare con un minimo RAG e analizzare come funziona. Ti invito a leggere il mio articolo, Svantaggi di RAG.

Riferimenti

Robustezza della richiesta: come misurarla e come potenziarla

Discussione sulla robustezza della richiesta LLM, misurazione, potenziamento e utilizzo di PromptBench.

pub.towardsai.net

Azure Cognitive Search: superare la ricerca vettoriale con capacità ibride di recupero e classificazione

Come trovare il miglior contenuto per alimentare i tuoi modelli AI generativi? In questo post, ti mostriamo come utilizzare Azure…

techcommunity.microsoft.com

Ciò che dobbiamo sapere prima di adottare un database vettoriale

Per continuare il nostro percorso verso un’applicazione di Generative AI, vorrei discutere alcune delle sfide di…

VoAGI.com

Svantaggi di RAG

Di recente, la diffusione dei modelli di linguaggio di grandi dimensioni (LLMs) ha suscitato molto interesse nei sistemi RAG. Molti professionisti sono…