Cos'è la Retrieval-Augmented Generation (RAG)?

Cos'è la Retrieval Augmented Generation, o RAG?

La Retrieval Augmented Generation (RAG) è un framework di AI ibrido che potenzia i Large Language Model (LLM) combinandoli con fonti di dati esterne e aggiornate. Invece di affidarsi esclusivamente a dati di addestramento statici, la RAG recupera i documenti pertinenti al momento della query e li fornisce al modello come contesto. Incorporando dati nuovi e sensibili al contesto, l'AI può generare risposte più accurate, aggiornate e specifiche per il dominio.

La RAG sta diventando rapidamente l'architettura di riferimento per la creazione di applicazioni di AI di livello aziendale. Secondo recenti sondaggi, oltre il 60% delle organizzazioni sta sviluppando strumenti di recupero basati sull'AI per migliorare l'affidabilità, ridurre le allucinazioni e personalizzare i risultati utilizzando dati interni.

Mentre l'AI generativa si espande in funzioni aziendali come il servizio clienti, la gestione della conoscenza interna e la conformità, la capacità della RAG di colmare il divario tra l'AI generale e la conoscenza organizzativa specifica la rende una base essenziale per implementazioni affidabili nel mondo reale.

Come funziona la RAG

La RAG migliora l'output di un modello linguistico inserendovi informazioni in tempo reale e sensibili al contesto recuperate da una fonte di dati esterna. Quando un utente invia una query, il sistema attiva innanzitutto il modello di recupero, che utilizza un database vettoriale per identificare e "recuperare" documenti, database o altre fonti semanticamente simili per ottenere informazioni pertinenti. Una volta identificati, combina questi risultati con il prompt di input originale e li invia a un modello di AI generativa, che sintetizza le nuove informazioni nel proprio modello.

Ciò consente all'LLM di produrre risposte più accurate e sensibili al contesto, basate su dati aggiornati o specifici dell'azienda, anziché affidarsi semplicemente al modello su cui è stato addestrato.

Le pipeline RAG prevedono in genere quattro fasi: preparazione e suddivisione dei documenti (chunking), indicizzazione vettoriale, recupero e aumento del prompt. Questo flusso di processo aiuta gli sviluppatori ad aggiornare le fonti di dati senza dover riaddestrare il modello e rende la RAG una soluzione scalabile ed economica per la creazione di applicazioni LLM in settori come il supporto clienti, le knowledge base e la ricerca interna.

Quali sfide risolve l'approccio Retrieval Augmented Generation?

Problema 1: I modelli LLM non conoscono i tuoi dati

Gli LLM utilizzano modelli di deep learning e vengono addestrati su enormi dataset per comprendere, riassumere e generare nuovi contenuti. La maggior parte degli LLM è addestrata su un'ampia gamma di dati pubblici, in modo che un singolo modello possa rispondere a molti tipi di attività o domande. Una volta addestrati, molti LLM non hanno la capacità di accedere a dati oltre la data limite dei loro dati di addestramento (cutoff). Questo rende gli LLM statici e può causare risposte errate, non aggiornate o allucinazioni quando vengono poste domande su dati per i quali non sono stati addestrati.

Problema 2: Le applicazioni di AI devono sfruttare i dati personalizzati per essere efficaci

Affinché gli LLM forniscano risposte pertinenti e specifiche, le organizzazioni hanno bisogno che il modello comprenda il loro dominio e fornisca risposte a partire dai loro dati, anziché fornire risposte ampie e generalizzate. Ad esempio, le organizzazioni creano bot di assistenza clienti con gli LLM e queste soluzioni devono fornire risposte specifiche dell'azienda alle domande dei clienti. Altre stanno creando bot di Q&A interni che dovrebbero rispondere alle domande dei dipendenti sui dati HR interni. Come fanno le aziende a creare tali soluzioni senza riaddestrare questi modelli?

Soluzione: La retrieval augmentation è ormai uno standard del settore

Un modo semplice e diffuso per utilizzare i propri dati consiste nel fornirli come parte del prompt con cui si interroga il modello LLM. Questo processo è chiamato Retrieval Augmented Generation (RAG), poiché si recuperano i dati pertinenti e li si utilizza come contesto aumentato per l'LLM. Invece di affidarsi esclusivamente alle conoscenze derivate dai dati di addestramento, un flusso di lavoro RAG estrae le informazioni pertinenti e collega gli LLM statici con il recupero dei dati in tempo reale.

Con l'architettura RAG, le organizzazioni possono distribuire qualsiasi modello LLM e potenziarlo per restituire risultati pertinenti per la propria azienda fornendogli una piccola quantità di dati, senza i costi e i tempi di fine-tuning o pre-addestramento del modello.

Quali sono i casi d'uso della RAG?

Esistono molti casi d'uso diversi per la RAG. I più comuni sono:

1. Chatbot per domande e risposte: L'integrazione degli LLM nei chatbot consente loro di ricavare automaticamente risposte più accurate dai documenti aziendali e dalle knowledge base. I chatbot vengono utilizzati per automatizzare il supporto clienti e il follow-up dei lead del sito web per rispondere alle domande e risolvere rapidamente i problemi.

   Ad esempio, Experian, una società multinazionale di data broker e di reportistica sul credito al consumo, voleva creare un chatbot per soddisfare le esigenze interne e dei clienti. Si sono resi presto conto che le loro attuali tecnologie di chatbot faticavano a scalare per soddisfare la domanda. Sviluppando il loro chatbot GenAI — Latte — sulla Databricks Data Intelligence Platform, Experian è stata in grado di migliorare la gestione dei prompt e l'accuratezza del modello, offrendo ai propri team una maggiore flessibilità per sperimentare diversi prompt, perfezionare i risultati e adattarsi rapidamente alle evoluzioni della tecnologia GenAI.

2. Ottimizzazione della ricerca: L'integrazione degli LLM con i motori di ricerca che arricchiscono i risultati di ricerca con risposte generate dagli LLM consente di rispondere meglio alle query informative e facilita la ricerca delle informazioni necessarie agli utenti per svolgere il proprio lavoro.

3. Motore di conoscenza: porre domande sui propri dati (ad es. HR, documenti di conformità): i dati aziendali possono essere utilizzati come contesto per gli LLM e consentire ai dipendenti di ottenere facilmente risposte alle loro domande, comprese le domande HR relative a benefit e policy e le domande sulla sicurezza e sulla conformità.

   Un esempio di questa implementazione è Cycle & Carriage, un gruppo automobilistico leader nel sud-est asiatico. Si sono rivolti a Databricks per sviluppare un chatbot RAG che migliora la produttività e il coinvolgimento dei clienti attingendo alle loro knowledge base proprietarie, come manuali tecnici, trascrizioni del supporto clienti e documenti sui processi aziendali. Ciò ha reso più facile per i dipendenti cercare informazioni tramite query in linguaggio naturale che forniscono risposte contestuali in tempo reale.

Quali sono i vantaggi della RAG?

L'approccio RAG offre una serie di vantaggi chiave, tra cui:

1. Fornire risposte aggiornate e accurate: la RAG garantisce che la risposta di un LLM non si basi esclusivamente su dati di addestramento statici e obsoleti. Al contrario, il modello utilizza fonti di dati esterne aggiornate per fornire le risposte.
2. Ridurre le risposte imprecise o le allucinazioni: basando l'output del modello LLM su conoscenze esterne e pertinenti, la RAG cerca di mitigare il rischio di rispondere con informazioni errate o inventate (noto anche come allucinazioni). I risultati possono includere citazioni delle fonti originali, consentendo la verifica umana.
3. Fornire risposte pertinenti e specifiche per il dominio: utilizzando la RAG, l'LLM sarà in grado di fornire risposte contestualmente pertinenti e su misura per i dati proprietari o specifici del dominio di un'organizzazione.
4. Efficienza e convenienza economica: rispetto ad altri approcci per la personalizzazione degli LLM con dati specifici del dominio, la RAG è semplice ed economica. Le organizzazioni possono implementare la RAG senza la necessità di personalizzare il modello. Questo è particolarmente vantaggioso quando i modelli devono essere aggiornati frequentemente con nuovi dati.

Quando dovrei usare la RAG e quando dovrei eseguire il fine-tuning del modello?

La RAG è il punto di partenza ideale, essendo semplice e potenzialmente del tutto sufficiente per alcuni casi d'uso. Il fine-tuning è più appropriato in una situazione diversa, ovvero quando si desidera modificare il comportamento dell'LLM o fargli apprendere un "linguaggio" diverso. Queste opzioni non si escludono a vicenda. Come passo futuro, è possibile prendere in considerazione il fine-tuning di un modello per comprendere meglio il linguaggio del dominio e la forma di output desiderata, e utilizzare anche la RAG per migliorare la qualità e la pertinenza della risposta.

Quando desidero personalizzare il mio LLM con i dati, quali sono tutte le opzioni e qual è il metodo migliore (prompt engineering vs. RAG vs. fine-tuning vs. pre-addestramento)?

Ci sono quattro pattern architetturali da considerare quando si personalizza un'applicazione LLM con i dati della propria organizzazione. Queste tecniche sono descritte di seguito e non si escludono a vicenda. Al contrario, possono (e dovrebbero) essere combinate per sfruttare i punti di forza di ciascuna.

Indipendentemente dalla tecnica selezionata, la creazione di una soluzione in modo ben strutturato e modulare garantisce che le organizzazioni siano pronte a iterare e ad adattarsi. Scopri di più su questo approccio e altro ancora in The Big Book of MLOps.

Sfide comuni nell'implementazione di RAG

L'implementazione di RAG su scala presenta diverse sfide tecniche e operative.

1. Qualità del recupero. Anche i LLM più potenti possono generare risposte scadenti se recuperano documenti irrilevanti o di bassa qualità. Pertanto, è fondamentale sviluppare una pipeline di recupero efficace che includa un'attenta selezione di modelli di embedding, metriche di somiglianza e strategie di ranking.
2. Limitazioni della finestra di contesto. Avendo a disposizione l'intera documentazione mondiale, il rischio può essere quello di inserire troppi contenuti nel modello, con conseguente troncamento delle fonti o risposte diluite. Le strategie di chunking dovrebbero bilanciare la coerenza semantica con l'efficienza dei token.
3. Freschezza dei dati. Il vantaggio di RAG risiede nella sua capacità di raccogliere informazioni aggiornate. Tuttavia, gli indici dei documenti possono diventare rapidamente obsoleti senza job di ingestion pianificati o aggiornamenti automatici. Garantendo la freschezza dei dati, è possibile evitare allucinazioni o risposte obsolete.
4. Latenza. Quando si gestiscono dataset di grandi dimensioni o API esterne, la latenza può interferire con il recupero, il ranking e la generazione.
5. Valutazione di RAG. A causa della natura ibrida di RAG, i modelli di valutazione dell'IA tradizionali si rivelano insufficienti. La valutazione dell'accuratezza degli output richiede una combinazione di giudizio umano, scoring di rilevanza e verifiche di groundedness per valutare la qualità della risposta.
   

Cos'è un'architettura di riferimento per le applicazioni RAG?

Esistono molti modi per implementare un sistema di retrieval augmented generation, a seconda delle esigenze specifiche e delle sfumature dei dati. Di seguito è riportato un flusso di lavoro comunemente adottato per fornire una comprensione fondamentale del processo.

1. Preparazione dei dati: I dati dei documenti vengono raccolti insieme ai metadati e sottoposti a una pre-elaborazione iniziale, ad esempio la gestione delle PII (rilevamento, filtraggio, redazione, sostituzione). Per essere utilizzati nelle applicazioni RAG, i documenti devono essere suddivisi in frammenti (chunk) di lunghezza appropriata in base alla scelta del modello di embedding e dell'applicazione LLM a valle che utilizza questi documenti come contesto.
2. Indicizzazione dei dati rilevanti: Generare gli embedding dei documenti e popolare un indice di AI Search con questi dati.
3. Recupero dei dati rilevanti: Recupero delle parti di dati rilevanti per la query di un utente. Tali dati di testo vengono quindi forniti come parte del prompt utilizzato per il LLM.
4. Creazione di applicazioni LLM: Includere i componenti di prompt augmentation e la query al LLM in un endpoint. Questo endpoint può quindi essere esposto ad applicazioni come i chatbot di Q&A tramite una semplice API REST.

Databricks consiglia inoltre alcuni elementi architetturali chiave di un'architettura RAG:

• Database vettoriali: Alcune (ma non tutte) le applicazioni LLM utilizzano database vettoriali per ricerche rapide di somiglianza, il più delle volte per fornire contesto o conoscenza del dominio nelle query LLM. Per garantire che il modello linguistico distribuito abbia accesso a informazioni aggiornate, gli aggiornamenti regolari del database vettoriale possono essere pianificati come job. Tieni presente che la logica per il recupero dal database vettoriale e l'inserimento delle informazioni nel contesto del LLM può essere inclusa nell'artefatto del modello registrato in MLflow utilizzando i flavor di modello MLflow LangChain o PyFunc.
• MLflow LLM Deployments o Model Serving: Nelle applicazioni basate su LLM in cui viene utilizzata un'API LLM di terze parti, il supporto di MLflow LLM Deployments o Model Serving per i modelli esterni può essere utilizzato come interfaccia standardizzata per instradare le richieste da provider come OpenAI e Anthropic. Oltre a fornire un gateway API di livello enterprise, MLflow LLM Deployments o Model Serving centralizza la gestione delle chiavi API e offre la possibilità di applicare controlli dei costi.
• Model Serving: Nel caso di RAG che utilizza un'API di terze parti, una modifica architetturale chiave è che la pipeline LLM effettuerà chiamate API esterne, dall'endpoint di Model Serving alle API LLM interne o di terze parti. Si noti che ciò aggiunge complessità, potenziale latenza e un ulteriore livello di gestione delle credenziali. Al contrario, nell'esempio del modello sottoposto a fine-tuning, verranno distribuiti il modello e il relativo ambiente.

Risorse

• Post del blog di Databricks
  • Using MLflow AI Gateway and Llama 2 to Build Generative AI Apps
  • Best Practices for LLM Evaluation of RAG Applications
• Demo di Databricks
• eBook di Databricks — The Big Book of MLOps

Clienti Databricks che utilizzano RAG

JetBlue

JetBlue ha implementato "BlueBot", un chatbot che utilizza modelli di AI generativa open source integrati con dati aziendali, basato su Databricks. Questo chatbot può essere utilizzato da tutti i team di JetBlue per accedere a dati regolati in base al ruolo. Ad esempio, il team finanziario può visualizzare i dati di SAP e i documenti normativi, mentre il team operativo vedrà solo le informazioni sulla manutenzione.

Leggi anche questo articolo.

Chevron Phillips

Chevron Phillips Chemical utilizza Databricks per supportare le proprie iniziative di AI generativa, inclusa l'automazione dei processi documentali.

Thrivent Financial

Thrivent Financial punta sull'AI generativa per migliorare la ricerca, produrre insight meglio sintetizzati e più accessibili, e ottimizzare la produttività del team di engineering.

Dove posso trovare maggiori informazioni sulla retrieval augmented generation?

Sono disponibili molte risorse per trovare maggiori informazioni su RAG, tra cui:

Blog

• Creare applicazioni RAG di alta qualità con Databricks
• Anteprima pubblica di Databricks AI Search
• Migliorare la qualità delle risposte delle applicazioni RAG con dati strutturati in tempo reale
• Sviluppare app di AI generativa più velocemente con le nuove funzionalità dei modelli foundation
• Best practice per la valutazione tramite LLM delle applicazioni RAG
• Utilizzare MLflow AI Gateway e Llama 2 per sviluppare app di AI generativa (Ottieni una maggiore precisione utilizzando la retrieval augmented generation (RAG) con i tuoi dati)

E-book

• Il grande libro dell'AI generativa
• La guida compatta a RAG
• Il grande libro di MLOps

Demo

• Implementare il tuo chatbot LLM con retrieval augmented generation (RAG), llama2-70B (MosaicML Inferences) e AI Search

Contatta Databricks per programmare una demo e parlare con un esperto dei tuoi progetti di LLM e retrieval augmented generation (RAG)

Il futuro della tecnologia RAG

La tecnologia RAG si sta rapidamente evolvendo da una soluzione di fortuna a un componente fondamentale dell'architettura AI aziendale. Con l'aumento delle capacità dei LLM, il ruolo di RAG sta cambiando, passando dal semplice colmare le lacune di conoscenza a sistemi strutturati, modulari e più intelligenti.

Una delle linee di sviluppo di RAG riguarda le architetture ibride, in cui RAG viene combinato con strumenti, database strutturati e agenti di function-calling. In questi sistemi, RAG fornisce un grounding non strutturato, mentre i dati strutturati o le API gestiscono compiti più precisi. Queste architetture multimodali offrono alle organizzazioni un'automazione end-to-end più affidabile.

Un altro importante sviluppo è il co-addestramento retriever-generator. Si tratta di un modello in cui il retriever RAG e il generator vengono addestrati congiuntamente per ottimizzare reciprocamente la qualità delle risposte. Questo può ridurre la necessità di prompt engineering manuale o fine-tuning, portando a vantaggi come l'apprendimento adattivo, la riduzione delle allucinazioni e migliori prestazioni complessive di retriever e generator.

Con la maturazione delle architetture LLM, RAG diventerà probabilmente più fluido e contestuale. Superando i limiti degli archivi finiti di memoria e informazioni, questi nuovi sistemi saranno in grado di gestire flussi di dati in tempo reale, ragionamenti multi-documento e memoria persistente, diventando assistenti esperti e affidabili.

Domande frequenti (FAQ)

Cos'è la retrieval augmented generation (RAG)?
RAG è un'architettura AI che potenzia i LLM recuperando documenti pertinenti e inserendoli nel prompt. Ciò consente di ottenere risposte più accurate, aggiornate e specifiche per il dominio, senza richiedere il tempo necessario per riaddestrare il modello.

Quando dovrei usare RAG invece del fine-tuning?
Utilizza RAG quando desideri integrare dati dinamici senza i costi o la complessità del fine-tuning. È ideale per i casi d'uso in cui sono richieste informazioni accurate e tempestive.

RAG riduce le allucinazioni nei LLM?
Sì. Basando la risposta del modello su contenuti recuperati e aggiornati, RAG riduce la probabilità di allucinazioni. Questo è particolarmente evidente in settori che richiedono un'elevata precisione, come la sanità, l'ambito legale o il supporto aziendale.

Di che tipo di dati ha bisogno RAG?
RAG utilizza dati di testo non strutturati (come PDF, e-mail e documenti interni) memorizzati in un formato recuperabile. Questi dati vengono solitamente archiviati in un vector database e devono essere indicizzati e aggiornati regolarmente per mantenerne la pertinenza.

Come si valuta un sistema RAG?
I sistemi RAG vengono valutati utilizzando una combinazione di punteggi di pertinenza, verifiche di groundedness, valutazioni umane e metriche di prestazioni specifiche per il task. Tuttavia, come abbiamo visto, le possibilità offerte dal co-addestramento retriever-generator potrebbero facilitare la valutazione regolare, poiché i modelli apprendono l'uno dall'altro e si addestrano a vicenda.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale