Retrieval Augemented Generation (Generazione potenziata dal recupero)
Riepilogo
- Scopri come funziona la generazione potenziata dal recupero (RAG) combinando grandi modelli di linguaggio (LLMs) con dati esterni in tempo reale per output più accurati e pertinenti.
- Vedi come RAG risolve problemi specifici, come la riduzione delle allucinazioni e la fornitura di risposte specifiche per settore, tutto senza costosi riaddestramenti.
- Esplora casi d'uso reali per RAG e future tendenze in settori come l'assistenza clienti, la conformità e la ricerca aziendale.
Che cos'è la generazione potenziata dal recupero, o RAG?
La generazione potenziata dal recupero (RAG) è un framework di intelligenza artificiale ibrida che rafforza i grandi modelli linguistici (LLMs) combinandoli con fonti di dati esterne e aggiornate. Invece di fare affidamento esclusivamente su dati di addestramento statici, RAG recupera documenti pertinenti al momento della query e li alimenta nel modello come contesto. Incorporando nuovi dati consapevoli del contesto, l'IA può generare risposte più accurate, attuali e specifiche per il dominio.
RAG si sta rapidamente affermando come l'architettura di riferimento per la costruzione di applicazioni AI di livello aziendale. Secondo recenti sondaggi, oltre il 60% delle organizzazioni stanno sviluppando strumenti di recupero alimentati da AI per migliorare l'affidabilità, ridurre le allucinazioni e personalizzare i risultati utilizzando i dati interni.
Mentre l'IA generativa si espande in funzioni aziendali come il servizio clienti, la gestione delle conoscenze interne e la conformità, la capacità di RAG di colmare il divario tra l'IA generale e la conoscenza organizzativa specifica la rende una base essenziale per implementazioni affidabili nel mondo reale.
Ecco altre informazioni utili
Come funziona RAG
RAG migliora l'output di un modello linguistico iniettandolo con informazioni consapevoli del contesto e in tempo reale recuperate da una fonte di dati esterna. Quando un utente invia una query, il sistema attiva prima il modello di recupero, che utilizza un database vettoriale per identificare e "recuperare" documenti, database o altre fonti semanticamente simili per informazioni pertinenti. Una volta identificati, combina poi questi risultati con il prompt di input originale e lo invia a un modello di AI generativo, che sintetizza le nuove informazioni nel suo stesso modello.
Ciò consente al LLM di produrre risposte più accurate e consapevoli del contesto, che si basano su dati specifici per l'impresa o aggiornati, piuttosto che fare affidamento semplicemente sul modello su cui è stato addestrato.
I pipeline RAG prevedono tipicamente quattro passaggi: preparazione e suddivisione dei documenti, indicizzazione dei vettori, recupero e potenziamento dei prompt. Questo flusso di lavoro aiuta gli sviluppatori a aggiornare le fonti di dati senza dover rieseguire l'addestramento del modello e rende RAG una soluzione scalabile ed economica per la costruzione di applicazioni LLM in ambiti come l'assistenza clienti, le basi di conoscenza e la ricerca interna.
Quali problemi risolve la generazione potenziata dal recupero?
Problema 1: i LLM non conoscono i tuoi dati
I LLM utilizzano modelli di deep learning e si addestrano su enormi set di dati per comprendere, sintetizzare e generare contenuti. La maggior parte dei LLM viene addestrata su un'ampia gamma di dati pubblici, in modo da poter rispondere a molti tipi di task o domande. Una volta addestrati, molti LLM non hanno la possibilità di accedere a dati che esulino da quelli utilizzati per l'addestramento. Questo li rende statici e può indurli a rispondere in modo errato, a dare risposte non aggiornate o ad allucinare quando vengono poste loro domande su dati sui quali non sono stati addestrati.
Problema 2: le applicazioni di AI devono poter sfruttare dati personalizzati per essere efficaci
Affinché i LLM forniscano risposte pertinenti e specifiche, le organizzazioni hanno bisogno di modelli che comprendano il loro settore e forniscano risposte basate sui loro dati, anziché risposte ampie e generalizzate. Ad esempio, le organizzazioni utilizzano i LLM per costruire bot per l'assistenza clienti, e queste soluzioni devono fornire ai clienti risposte che siano pertinenti e legate ai servizi e prodotti dell'azienda. Altre organizzazioni costruiscono bot interni per rispondere alle domande dei dipendenti relative a dati delle risorse umane. Come possono le aziende costruire queste soluzioni senza addestrare nuovamente i modelli?
Soluzione: la generazione potenziata dal recupero è oggi uno standard di settore
Un modo semplice e molto diffuso per utilizzare i propri dati è quello di fornirli come parte del prompt con cui si interroga il LLM. Questo approccio è noto come Retrieval Augmented Generation (RAG) e consiste nel recuperare i dati rilevanti e di utilizzarli come contesto potenziato per un LLM. Invece di affidarsi esclusivamente alla conoscenza derivata dai dati di addestramento, un flusso di lavoro RAG estrae le informazioni rilevanti e collega i LLM statici a funzionalità di recupero dei dati in tempo reale.
Con l'architettura RAG, le aziende possono implementare qualsiasi LLM e potenziarlo in modo che restituisca risultati rilevanti per la loro organizzazione, fornendogli soltanto una piccola quantità di dati, senza il dispendio di tempo e denaro che occorrerebbe per l'ottimizzazione o il preaddestramento.
Quali sono i casi d'uso della RAG?
I casi d'uso della RAG sono molteplici. Tra i più comuni:
Chatbot per domande e risposte: l'integrazione dei LLM con i chatbot consente a questi ultimi di ricavare automaticamente risposte più accurate dai documenti e dalle knowledge base aziendali. I chatbot vengono utilizzati per automatizzare l'assistenza ai clienti e il follow-up dei lead dei siti, rispondendo alle domande e risolvendo rapidamente i problemi.
Ad esempio, Experian, un broker di dati multinazionale e società di reportistica del credito al consumo, voleva sviluppare un chatbot per soddisfare le esigenze interne e rivolte ai clienti. Si sono resi conto rapidamente che le loro attuali tecnologie di chatbot faticavano a scalare per soddisfare la domanda. Costruendo il loro chatbot GenAI - Latte - sulla Piattaforma di Intelligenza dei Dati di Databricks, Experian è riuscito a migliorare la gestione dei prompt e l'accuratezza del modello, il che ha fornito ai loro team una maggiore flessibilità per sperimentare con diversi prompt, perfezionare gli output e adattarsi rapidamente alle evoluzioni della tecnologia GenAI.
- Potenziamento della ricerca: l'integrazione di LLM con motori di ricerca che potenziano i risultati delle ricerche con risposte generate da questi può soddisfare meglio le richieste di informazioni e consentire agli utenti di trovare facilmente ciò di cui hanno bisogno.
Motore di conoscenza — per porre domande sui dati della tua azienda (ad esempio HR, documenti di conformità): i dati aziendali possono essere utilizzati come contesto per i LLM per consentire ai dipendenti di ottenere facilmente risposte alle loro domande, comprese quelle in ambito HR relative a benefit e politiche e quelle sulla sicurezza e la conformità.
Un modo in cui ciò viene implementato è presso Cycle & Carriage, un gruppo automobilistico leader nel Sud-est asiatico. Si sono rivolti a Databricks Mosaic AI per sviluppare un chatbot RAG che migliora la produttività e l'interazione con il cliente attingendo alle loro basi di conoscenza proprietarie, come manuali tecnici, trascrizioni del supporto clienti e documenti sui processi aziendali. Questo 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 presenta una serie di vantaggi fondamentali, tra cui:
- Fornire risposte aggiornate e accurate: l'approccio RAG garantisce che la risposta di un LLM non si basi esclusivamente su dati di addestramento statici e non aggiornati. Il modello utilizza invece sorgenti di dati esterne e aggiornate per fornire risposte.
- Ridurre le risposte imprecise o le allucinazioni: basando l'output del LLM su conoscenze esterne rilevanti, la RAG cerca di ridurre il rischio di risposte con informazioni errate o inventate (note anche come "allucinazioni"). I risultati possono includere citazioni delle fonti originali, consentendo una verifica umana.
- Fornire risposte pertinenti e specifiche per il settore: utilizzando la RAG, il LLM sarà in grado di fornire risposte contestualmente pertinenti e adeguate ai dati proprietari o settoriali specifici di un'organizzazione.
- Essere efficiente e conveniente: rispetto ad altri approcci utilizzati per personalizzare i LLM con dati specifici del settore, la RAG è semplice ed economica. Le organizzazioni possono implementare l'approccio RAG senza dover personalizzare il modello. Questo è particolarmente vantaggioso quando i modelli devono essere aggiornati frequentemente con nuovi dati.
Quando usare l'approccio RAG e quando invece ottimizzare il modello?
La RAG è il giusto punto di partenza perché è facile e forse del tutto sufficiente per alcuni casi d'uso. L'ottimizzazione è più appropriata quando si vuole modificare il comportamento del LLM o fargli imparare un altro "linguaggio". I due approcci non sono mutualmente esclusivi. Come passo futuro, si può decidere di ottimizzare un modello in modo che comprenda meglio il linguaggio settoriale e la forma di output desiderata e utilizzare la RAG per migliorare qualità e pertinenza della risposta.
Quando voglio personalizzare il mio modello LLM con i dati, quali sono le mie opzioni? E qual è il metodo migliore (ingegneria dei prompt, RAG, ottimizzazione, preaddestramento...)?
Ci sono quattro pattern architettonici da considerare quando si personalizza un'applicazione LLM con i dati della propria organizzazione. Le tecniche descritte di seguito non si escludono a vicenda. Al contrario, possono (e devono) essere combinate per sfruttare i punti di forza di ciascuna.
Metodo | Definizione | Caso d'uso primario | Requisiti dei dati | Vantaggi | Considerazioni |
---|---|---|---|---|---|
Ingegneria dei prompt | Creazione di prompt specializzati per guidare il comportamento dei LLM | Guida rapida, in tempo reale del modello | Nessuno | Veloce, economico, non richiede addestramento | Meno controllo rispetto all'ottimizzazione |
Retrieval Augmented Generation (RAG, Generazione potenziata dal recupero) | Combinazione tra un LLM e il recupero di conoscenze esterne | Set di dati dinamici e conoscenze esterne | Base di conoscenza o database esterno (ad esempio, database vettoriale) | Contesto aggiornato dinamicamente, maggiore precisione | Aumenta la lunghezza dei prompt e la computazione inferenziale |
Ottimizzazione | Adattamento di un LLM preaddestrato a set di dati o settori specifici | Specializzazione del settore o del compito | Migliaia di esempi specifici del settore o di esempi di istruzioni | Controllo granulare, alta specializzazione | Richiede dati etichettati, costo computazionale |
Pre-addestramento | Addestramento di un modello LLM da zero | Compiti unici o corpora specifici del settore | Grandi set di dati (da miliardi a migliaia di miliardi di token) | Massimo controllo, adatto a esigenze specifiche | Estremamente oneroso dal punto di vista delle risorse |
Indipendentemente dalla tecnica scelta, costruire una soluzione in modo ben strutturato e modulare garantisce alle organizzazioni di essere pronte a iterare e adattarsi. Per saperne di più su questo approccio e su altri aspetti, consulta The Big Book of MLOps.
Sfide comuni nell'implementazione di RAG
Implementare RAG su larga scala introduce diverse sfide tecniche e operative.
- Qualità del recupero. Anche i LLM più potenti possono generare risposte scadenti se recuperano documenti irrilevanti o di bassa qualità. Pertanto, è fondamentale sviluppare un efficace pipeline di recupero che includa una attenta selezione di modelli di embedding, metriche di somiglianza e strategie di classificazione.
- Limitazioni della finestra di contesto. Con l'intera documentazione del mondo a portata di mano, i rischi possono essere l'inserimento di troppo contenuto nel modello, portando a fonti troncate o risposte diluite. Le strategie di suddivisione dovrebbero bilanciare la coerenza semantica con l'efficienza dei token.
- Freschezza dei dati Il vantaggio di RAG risiede nella sua capacità di raccogliere informazioni aggiornate. Tuttavia, gli indici dei documenti possono rapidamente diventare obsoleti senza lavori di ingestione programmati o aggiornamenti automatici. Assicurandoti che i tuoi dati siano freschi, puoi evitare allucinazioni o risposte obsolete.
- Latenza. Quando si lavora con grandi set di dati o API esterne, la latenza può interferire con il recupero, il ranking e la generazione.
- Valutazione RAG. A causa della natura ibrida di RAG, i modelli tradizionali di valutazione dell'IA non sono sufficienti. Valutare l'accuratezza degli output richiede una combinazione di giudizio umano, punteggio di rilevanza e controlli di fondatezza per valutare la qualità della risposta.
Qual è l'architettura di riferimento per le applicazioni RAG?
Esistono molti modi per implementare un sistema di generazione potenziata dal recupero, a seconda delle esigenze specifiche e delle tipologie di dati. Per aiutarti a capire le basi del processo, riportiamo di seguito un flusso di lavoro comunemente adottato.
- Preparazione dei dati: i dati dei documenti vengono raccolti insieme ai metadati e sottoposti a una elaborazione iniziale; ad esempio, si gestiscono le informazioni di identificazione personale o PII (rilevamento, filtraggio, redazione, sostituzione). Per poter essere utilizzati nelle applicazioni RAG, i documenti devono essere suddivisi in parti di lunghezza appropriata in base alla scelta del modello di embedding e all'applicazione LLM a valle che li utilizzerà come contesto.
- Indicizzazione dei dati rilevanti: produrre embedding di documenti e importare questi dati in un indice Vector Search.
- Recupero dei dati rilevanti: recuperare le parti dei dati che sono rilevanti per la domanda di un utente. Questi dati testuali vengono poi forniti come parte del prompt utilizzato per il LLM.
- Sviluppo di applicazioni LLM: eseguire il wrapping dei componenti del potenziamento del prompt e interrogare il LLM in un endpoint. L'endpoint può quindi essere esposto ad applicazioni come i chatbot di Q&A tramite una semplice API REST.
Databricks consiglia inoltre alcuni elementi chiave di un'architettura RAG:
- Database vettoriale: alcune applicazioni LLM (ma non tutte) utilizzano database vettoriali per eseguire rapide ricerche di similarità, in genere per fornire contesto o conoscenze di settore nelle query LLM. Per garantire che il modello linguistico implementato abbia accesso a informazioni aggiornate, è possibile programmare aggiornamenti regolari del database vettoriale come job. Si noti che la logica per recuperare dal database vettoriale e iniettare le informazioni nel contesto LLM può essere inserita nell'artefatto del modello registrato in MLflow usando le tipologie LangChain o PyFunc del modello MLflow.
- MLflow LLM Deployments o Model Serving: nelle applicazioni basate su LLM in cui viene utilizzata un'API LLM di terze parti, si può usare il supporto di MLflow LLM Deployments o Model Serving come interfaccia standardizzata per instradare le richieste di fornitori come OpenAI e Anthropic. Oltre a fornire un gateway API di livello aziendale, MLflow LLM Deployments o Model Serving centralizza la gestione delle chiavi API e offre la possibilità di applicare controlli sui costi.
- Model Serving: nel caso di una RAG che utilizza un'API di terze parti, un cambiamento architettonico fondamentale è che la pipeline LLM effettuerà chiamate API esterne, dall'endpoint Model Serving ad API LLM interne o di terze parti. Va notato che questo aggiunge complessità, potenziale latenza e un ulteriore livello di gestione delle credenziali. Al contrario, nell'esempio del modello ottimizzato, il modello e il suo ambiente saranno distribuiti.
Risorse
- Post sul blog Databricks
- Demo Databricks
- E-book Databricks — The Big Book of MLOps
Clienti Databricks che utilizzano la RAG
JetBlue
JetBlue si è affidato alla tecnologia Databricks per implementare "BlueBot", un chatbot che utilizza modelli di AI generativa open source integrati da dati aziendali. Il chatbot può essere utilizzato da tutti i team di JetBlue per ottenere accesso ai dati in base al ruolo. Ad esempio, il team finanziario può vedere i dati del sistema SAP e i documenti normativi, mentre il team operativo vede solo le informazioni sulla manutenzione.
Leggi anche questo articolo.
Chevron Phillips
Chevron Phillips Chemical utilizza Databricks per supportare le sue iniziative di AI generativa, compresa l'automazione dei processi documentali.
Thrivent Financial
Thrivent Financial sta valutando l'impiego dell'AI generativa per rendere più efficienti le ricerche, produrre informazioni meglio sintetizzate e più accessibili e aumentare la produttività dell'ingegneria.
Dove posso trovare ulteriori informazioni sulla generazione potenziata dal recupero?
Sono disponibili molte risorse per trovare maggiori informazioni sulla RAG, tra cui:
Blog
- Creare applicazioni RAG di alta qualità con Databricks
- Anteprima pubblica di Databricks Vector Search
- Migliora la qualità di risposta delle applicazioni RAG con dati strutturati in tempo reale
- Costruisci velocemente applicazioni AI di nuova generazione con le nuove funzionalità di Foundation Model
- Best practice per la valutazione tramite LLM di applicazioni RAG
- Using MLflow AI Gateway and Llama 2 to Build Generative AI Apps (Achieve greater accuracy using retrieval augmented generation (RAG) with your own data)
E-book
Demo
Contatta Databricks per programmare una demo e parlarci dei tuoi progetti di LLM e generazione potenziata dal recupero (RAG)
Il futuro della tecnologia RAG
RAG si sta evolvendo rapidamente da una soluzione di fortuna a un componente fondamentale dell'architettura AI aziendale. Man mano che gli LLM diventano più capaci, il ruolo di RAG sta cambiando. Si sta passando dal semplice colmare le lacune nella conoscenza a sistemi che sono strutturati, modulari e più intelligenti.
Un modo in cui RAG si sta sviluppando è attraverso architetture ibride, dove RAG viene combinato con strumenti, database strutturati e agenti di chiamata di funzione. In questi sistemi, RAG fornisce un ancoraggio 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 sviluppo importante è il co-training tra il recuperatore e il generatore. Questo è un modello in cui il recupero RAG e il generatore vengono addestrati insieme per ottimizzare la qualità delle risposte reciproche. Questo potrebbe ridurre la necessità di ingegneria manuale delle sollecitazioni o di perfezionamento e porta a cose come l'apprendimento adattivo, ridotte allucinazioni e migliore performance complessiva di retriever e generatori.
Man mano che le architetture LLM maturano, è probabile che RAG diventi più fluido e contestuale. Superando le limitate riserve di memoria e informazione, questi nuovi sistemi saranno in grado di gestire flussi di dati in tempo reale, ragionamento su multi-documenti e memoria persistente, rendendoli assistenti esperti e affidabili.
Domande frequenti (FAQ)
Che cos'è la Retrieval Augmented Generation (RAG)? RAG è un'architettura di intelligenza artificiale che potenzia gli LLM recuperando documenti pertinenti e iniettandoli nel prompt. Ciò consente risposte più accurate, attuali e specifiche per il dominio senza impiegare tempo per riaddestrare il modello.
Quando dovrei usare RAG invece del fine-tuning?
Usa RAG quando vuoi incorporare dati dinamici senza il costo o la complessità del fine-tuning. È ideale per casi d'uso in cui sono richieste informazioni accurate e tempestive.
RAG riduce le allucinazioni negli LLM?
Sì. Ancorando la risposta del modello in contenuti recuperati e aggiornati, RAG riduce la probabilità di allucinazioni. Questo è particolarmente vero in settori che richiedono un'alta precisione, come l'assistenza sanitaria, il lavoro legale o il supporto aziendale.
Quali tipi di dati necessita RAG?
RAG utilizza dati di testo non strutturato - pensa a fonti come PDF, email e documenti interni - memorizzati in un formato recuperabile. Questi vengono tipicamente memorizzati in un database vettoriale, e i dati devono essere indicizzati e aggiornati regolarmente per mantenere la loro rilevanza.
Come si valuta un sistema RAG?
I sistemi RAG vengono valutati utilizzando una combinazione di punteggi di rilevanza, controlli di radicamento, valutazioni umane e metriche di performance specifiche per il compito. Ma come abbiamo visto, le possibilità di co-training tra il recupero e il generatore potrebbero rendere più facile la valutazione regolare poiché i modelli imparano l'uno dall'altro e si allenano reciprocamente.