Che cos'è il recupero della generazione aumentata (RAG)?

La RAG fornisce dati contestuali e aggiornati che amplificano l'utilità degli LLM.

La RAG è una tecnica che risolve i limiti degli LLM fornendo loro l'accesso a dati contestuali e aggiornati. Le implementazioni RAG, a volte denominate modelli RAG, uniscono un LLM pre-addestrato a un sistema di reperimento di informazioni facilmente accessibili. Il sistema di reperimento si occupa di trovare informazioni rilevanti all'interno di una libreria di conoscenze, per esempio un database. I modelli RAG consentono al LLM, o modello di fondazione, di generare una risposta più accurata con un contesto aggiornato e pertinente all'attività da svolgere.

I modelli RAG si sono dimostrati efficaci per una serie di attività ad alta intensità di conoscenza, tra cui:

• attività di generazione del linguaggio, come rispondere a domande in modo esauriente e informativo, o generare diversi formati creativi di contenuti testuali, come poesie, copioni, brani musicali, e-mail, lettere, ecc.
• attività di elaborazione del linguaggio naturale (NLP), come fornire riassunti di conversazioni, registrazioni audio e videochiamate.
• Attività che richiedono classificazione, come la sicurezza informatica e la conformità, o ragionamenti per attività come la pianificazione aziendale

Inoltre, si può ricorrere alla RAG anche per consentire a un'applicazione basata su IA generativa di osservare alcuni stati di background e personalizzarne di conseguenza le generazioni. Un esempio potrebbe essere la capacità di scrivere codice in base al codice scritto da un utente. Altri esempi includono:

• Contesto applicativo. Supponiamo che si stia creando un assistente di Excel basato su IA: sarebbe utile se conoscesse i nomi dei fogli di calcolo, il nome del file, gli intervalli di celle selezionati, ecc. La RAG inserirà nel prompt queste "informazioni sulle attività in background" in modo che il LLM possa fornire un'assistenza su misura per il foglio di calcolo in questione. *Dati personali (ad es. chatbot agente di assistenza). Supponiamo che si stia creando un bot per l'assistenza clienti. Il bot può recuperare le conversazioni precedenti e la cronologia del CRM relativa a quello specifico cliente per personalizzare la conversazione (saluti, personalizzazione delle opzioni, ecc.). Senza questa cronologia, il LLM non sarà in grado di eseguire in modo efficace la personalizzazione o di fornire assistenza per i problemi esistenti.
• Numeri grezzi, metriche, dati tabellari (ad es. CSV, Parquet, JSON ecc.). La RAG non opera solo con il contesto testuale, ma anche con le informazioni quantitative. Un chatbot di business intelligence (BI) utilizzerebbe sicuramente la RAG su dati tabulari grezzi.
• Altri tipi di dati multimodali come immagini, video e audio. Molti modelli, come DALL-E 2, possono servirsi del testo per creare o aumentare le immagini. E viceversa, possono sintetizzare immagini o video in linguaggio naturale. Se dotata del contesto relativo a determinate immagini o fattori di forma del design, la RAG è in grado di potenziare le app di IA generativa in relazione alla creazione di risorse di marketing o alla redazione di riepiloghi e traduzioni da video contenenti informazioni estremamente specifiche e contestuali.

La RAG è utile anche per i dati che non si possono incorporare come dati di addestramento

• Dati altamente volatili/sensibili al tempo: dati come le notizie relative al mercato azionario invecchiano rapidamente. Pertanto, è più logico ottimizzare gli LLM solo con le informazioni più recenti, idealmente ad ogni richiesta durante le inferenze, anziché tentare di riaddestrare gli LLM con questo corpus.
• Dati sensibili: molti degli LLM più performanti (come GPT di OpenAI o Claude di Anthropic) sono pay per use e di proprietà delle rispettive aziende. L'uso di informazioni personali e sensibili nei dati di addestramento finalizzati all'ottimizzazione degli LLM può portare alla diffusione di dati privati e perciò è potenzialmente pericoloso. Ecco quindi che a volte la RAG è l’unica opzione sicura.

Principali casi d'uso della RAG.

Sulla base di quanto detto sopra, i casi d'uso più indicati per la RAG sono:

• Risposta a domande su qualsiasi conoscenza estrinseca del dominio, come la documentazione e le Knowledge Base specifiche dell'azienda, i sistemi operativi live, i sistemi di back office e così via: per definizione, l'uso degli LLM con qualsiasi dato al di fuori del loro limite di conoscenze richiede la RAG. Inoltre, le domande e le risposte relative a contesti molto sensibili al tempo e in rapida evoluzione (dati che diventano rapidamente obsoleti) sono impossibili da integrare negli LLM attraverso l'ottimizzazione.
• Per ridurre le allucinazioni e aumentare l'accuratezza dei fatti: in generale, la RAG può migliorare l'accuratezza dei fatti anche per rispondere a domande su informazioni contenute nel corpus di addestramento degli LLM. Infatti, la RAG trasforma l'attività di risposta alle domande in un'attività tipo "quiz a libro aperto", più semplice rispetto all'attività di risposta a domande senza limiti.
• La personalizzazione è un caso d'uso canonico della RAG. In questo caso, il prompt viene arricchito con i dati dell'utente. Volendo, è possibile eliminare tutti i dati di identificazione personale prima dell'inserimento nel prompt.
• Fornire risposte contestuali (all'interno dei copiloti). Come dimostra il copilota di Github, i contenuti generati dagli LLM possono essere più pertinenti se basati sullo stato dell'applicazione (il documento corrente, i metadati complessivi del progetto, l'URL o la pagina che si sta visitando, ecc)
• Qualsiasi applicazione di IA generativa che opera con contesti estremamente specifici del dominio. Per esempio nell'ambito della sanità, dei servizi finanziari, dell'attività istruttoria e in ambito scientifico e tecnico. In questo tipo di domini, i dati di addestramento sono spesso scarsi, perciò la RAG è essenziale per creare app di IA generativa effettivamente utili.

Perché la RAG? Quali sono le alternative alla RAG nello sviluppo di applicazioni di IA generativa?

Esistono numerose alternative alla RAG nello sviluppo di applicazioni di IA generativa. Alcune delle alternative più diffuse sono:

• Addestramento degli LLM: anche se l'addestramento del proprio LLM è giustificabile, probabilmente crearne uno che possa competere con i molti modelli a pagamento (GPT di OpenAI) e open source (LLaMa di Meta) disponibili sul mercato risulterebbe troppo oneroso in termini sia di tempo che di costi.
• Ottimizzazione di un LLM esistente: una tecnica in base alla quale un LLM pre-addestrato viene riaddestrato su un dataset più piccolo specifico per quell'attività. L'ottimizzazione può servire a migliorare le prestazioni di un LLM per una specifica attività, ma può anche richiedere molto tempo e avere costi elevati. L'ottimizzazione non finisce mai: man mano che si rendono disponibili nuovi dati, il modello deve essere nuovamente ottimizzato. Quando l'app di IA generativa richiede l'accesso a dati operativi in tempo reale, l'ottimizzazione non ha alcuna efficacia in questo senso.

Perché optare per la RAG anziché per l'ottimizzazione di un LLM?

• L'ottimizzazione è un altro modo di usare gli LLM con "dati personalizzati", ma a differenza della RAG, che equivale a fornire a un LLM un quiz a libro aperto, l'ottimizzazione equivale a memorie completamente nuove o a una lobotomia. L'ottimizzazione adatta il modello in modo che sia possibile modificarne le prestazioni, il comportamento, il profilo di costo, ecc. Richiede tempo e risorse e generalmente non è la scelta più indicata per preparare gli LLM a un contesto specifico ed è particolarmente inadatta per i dati operativi live dell'azienda.

Gli elementi costitutivi di un'architettura RAG di base.

Un'architettura RAG di base è costituita da tre componenti principali:

• Un LLM pre-addestrato: il LLM è responsabile della generazione di testo, immagini, audio e video.
• Ricerca vettoriale (o ricerca semantica): Il sistema di reperimento è responsabile della ricerca di informazioni pertinenti all'interno di una Knowledge Base esterna al LLM. È possibile scegliere tra una serie di database generici o di database vettoriali monofunzionali in grado di memorizzare gli incorporamenti vettoriali ed eseguire su di essi query di ricerca approximate nearest neighbor. La ricerca vettoriale è fondamentale per poter arricchire con precisione la conoscenza proprietaria fornita a un LLM generico.
• Incorporamenti vettoriali: a volte indicati semplicemente come "vettori" o "incorporamenti", gli incorporamenti vettoriali sono essenzialmente rappresentazioni numeriche che acquisiscono il significato semantico o sottostante di un dato. In generale, sono un array di float, dove ciascun float rappresenta una singola dimensione delle rappresentazioni numeriche.
• Orchestrazione: il meccanismo di fusione è responsabile dell'unione dell'output del LLM con le informazioni del sistema di reperimento per generare l'output finale.

Il diagramma seguente mostra un'architettura RAG di base con lo stesso esempio retail di prima:

Per ovviare a questa mancanza di contesto specifico del dominio, l'utilizzo della RAG avviene come descritto di seguito:

• Recuperiamo le descrizioni dei prodotti più pertinenti da un database (spesso un database con ricerca vettoriale) contenente il catalogo prodotti più recente
• Quindi inseriamo (arricchiamo) queste descrizioni nel prompt del LLM
• Infine, chiediamo a LLM di "fare riferimento" a queste informazioni di prodotto aggiornate quando risponde alla domanda

Quanto descritto in precedenza porta a tre considerazioni:

• La RAG non è altro che una tecnica riguardante il tempo di inferenza (non richiede riaddestramento). I passaggi da 1 a 3 di cui sopra avvengono tutti durante il tempo di inferenza. Non sono necessarie modifiche al modello (ad es. modifica dei pesi del modello).
• La RAG è ideale per le personalizzazioni in tempo reale di quanto generato dal LLM. Poiché non è necessario ripetere l'addestramento e tutto viene eseguito tramite l'apprendimento contestuale, l'inferenza basata su RAG è veloce (latency inferiore a 100 ms) e adatta per essere utilizzata all'interno di applicazioni operative in tempo reale.
• La RAG rende più accurati e utili i contenuti generati dal LLM. Ogni volta che il contesto cambia, l'LLM genererà una risposta diversa. Pertanto, con la RAG tutto ciò che viene generato dal LLM dipenderà dal contesto reperito.

Ridurre al minimo la complessità della RAG, rendendola comunque sufficientemente sofisticata per ottenere prestazioni affidabili su larga scala.

Per avere un'architettura RAG performante, ma di complessità ridotta, è necessario scegliere i sistemi giusti. Quando si scelgono i sistemi, o le tecnologie, per implementare una RAG, è importante scegliere sistemi, o un sistema, in grado di ottenere quanto segue:

• Supportare i nuovi requisiti dei dati vettoriali senza aggiungere proliferazione, costi e complessità eccessive alle operazioni IT.
• Assicurarsi che le esperienze di IA generativa create abbiano accesso ai dati live con una latency minima.
• Avere la flessibilità necessaria per soddisfare i nuovi requisiti di dati e app e allo stesso tempo consentire ai team di sviluppo di rimanere agili.
• Attrezzare al meglio i team di sviluppo per portare l'intero ecosistema IA nei loro dati, e non il contrario.

Le opzioni spaziano dai database vettoriali monofunzionali ai database documentali e relazionali con funzionalità vettoriali native, ai data warehouse e ai lakehouse. Tuttavia, i database vettoriali monofunzionali aggiungeranno immediatamente proliferazione e complessità. I data warehouse e i lakehouse sono intrinsecamente progettati per query di tipo analitico a esecuzione prolungata su dati storici, in contrasto con i requisiti di volume elevato, bassa latenza e dati aggiornati delle app di IA generativa basate su RAG. Inoltre, i relational database offrono schemi rigidi che limitano la flessibilità di aggiungere facilmente nuovi dati e requisiti delle app. In questo modo i database documentali possono usufruire di funzionalità vettoriali native o integrate. In particolare, MongoDB è costruito sul modello di documento flessibile e dispone di una ricerca vettoriale nativa, pertanto è un database vettoriale per la RAG, oltre a essere il database leader del settore per qualsiasi applicazione moderna.

Portare la potenza degli LLM a un livello superiore con funzionalità aggiuntive nell'implementazione della RAG.

Oltre ai componenti principali, ci sono una serie di funzionalità aggiuntive che possono essere aggiunte a un'implementazione RAG per portare la potenza degli LLM a un livello superiore. Alcune di queste funzionalità aggiuntive includono:

• Multimodalità: i modelli RAG multimodali possono generare testo basato su dati sia testuali che non testuali, come immagini, video e audio. L'archiviazione di questi data multimodali insieme ai dati operativi live semplifica la progettazione e la gestione dell'implementazione della RAG.
• Definire filtri aggiuntivi nella query di ricerca vettoriale: la possibilità di aggiungere la ricerca per parole chiave, la ricerca geospaziale e i filtri per elemento e a intervallo sulla stessa query vettoriale può aggiungere precisione e velocità al contesto fornito al LLM.
• Specificità del dominio: i modelli di RAG specifici per il dominio possono essere addestrati sui dati di un dominio specifico, come la sanità o la finanza. Ciò consente al modello RAG di generare testo più accurato e pertinente per quel dominio.

Assicurarsi che le applicazioni basate sull'IA generativa rimangano sicure, ad alte prestazioni, affidabili e scalabili anche quando disponibili a livello globale.

È possibile intervenire in vari modi per assicurarsi che le applicazioni basate sull'IA generativa create con una RAG rimangano sicure, ad alte prestazioni, affidabili e scalabili anche quando disponibili a livello globale. Per esempio:

• Utilizzare una piattaforma sicura e dotata delle adeguate capacità di governance dei dati: la governance dei dati è un termine ampio che comprende tutto ciò che si fa per garantire che i dati siano sicuri, privati, accurati, disponibili e utilizzabili. Include i processi, le politiche, le misure, la tecnologia, gli strumenti e i controlli relativi al ciclo di vita dei dati. Pertanto, la piattaforma dovrebbe essere sicura per impostazione predefinita, disporre di crittografia end-to-end e aver raggiunto la conformità ai massimi livelli.
• Utilizzare una piattaforma basata su cloud: oltre alle funzionalità di sicurezza e scalabilità fornite dalle piattaforme basate su cloud, i principali provider cloud sono tra i principali innovatori per quanto riguarda l'infrastruttura IA. La scelta di una piattaforma indipendente dal cloud consente ai team di trarre vantaggio dalle innovazioni dell'IA indipendentemente da dove arrivano.
• Utilizzare una piattaforma in grado di isolare l'infrastruttura del carico di lavoro vettoriale da altre infrastrutture di database: è importante che i normali carichi di lavoro OLTP e i carichi di lavoro vettoriali non condividano l'infrastruttura, in modo che i due carichi di lavoro possano girare su hardware ottimizzato per ciascuno di essi, e che non competano per le risorse pur essendo in grado di sfruttare gli stessi dati.
• Utilizzare una piattaforma che è stata collaudata su larga scala: un provider può sempre affermare di essere in grado di operare su larga scala, ma ha effettivamente una comprovata esperienza con clienti aziendali globali? Ha una tolleranza ai guasti mission-critical e la capacità di espandersi in scala orizzontalmente e può dimostrarlo con esempi di clienti?

Seguendo questi suggerimenti, è possibile creare applicazioni basate sull'IA generativa con architetture RAG sicure, ad alte prestazioni, affidabili e scalabili.

Con l'introduzione di Atlas Vector Search, la principale piattaforma di dati per sviluppatori di MongoDB fornisce ai team un database vettoriale che consente di creare architetture RAG sofisticate e ad alte prestazioni, in grado di operare su larga scala. Il tutto mantenendo i più alti livelli di sicurezza e indipendenza dal cloud, e soprattutto senza aggiungere complessità e costi inutili.