RAG, l’IA arricchita con i dati aziendali: concetti base e implementazione
Indice dell'articolo
Uno dei termini più usati quando si parla di soluzioni di IA generativa per aziende è RAG, che sta perRetrieval Augmented Generation, e il motivo è presto detto: la RAG permette infatti di superare due limiti dei large language model preaddestrati e che sono particolarmente penalizzanti per le aziende: l’incapacità di dare risposte su argomenti che non erano presenti nei dati di addestramento e la possibilità di restituire informazioni verosimili ma false.
Con la RAG si punta a implementare un sistema che combini la versatilità dei Large Language Model con l’affidabilità e l’aggiornamento di una knowledge base informativa definita ad hoc. Quest’ultima, elemento centrale del processo, è rappresentata da una collezione di documenti contenenti le informazioni verificate su cui l’LLM deve lavorare: potrebbe trattarsi di informazioni di nostra proprietà, ma niente vieta di includere fonti di informazioni esterne recuperate da importanti agglomerati quali potrebbero essere Wikipedia, fonti normative o altro ancora. Oltre a documenti con informazioni non strutturate, è anche possibile specificare come fonte un database organizzato o dei servizi da consultare attraverso API.
Attraverso la consultazione di queste fonti, si possono superare sia il problema dell’aggiornamento delle informazioni, sia quello dell’incertezza dovuta alla natura statistica e probabilistica dei modelli generativi preaddestrati. Un problema, quest’ultimo, che è più rilevante quando gli argomenti trattati sono di nicchia e quindi presenti solo in poche occorrenze nei dati di training.
Lo scopo di tutto ciò quindi si vuole ottenere un output di altissimo livello in cui vengano coniugati la capacità creativa di un LLM, sia dal punto di vista logico sia da quello espressivo, con fonti di informazione autorevoli, verificate, contestualizzate e aggiornate.
Implementazione di una RAG
Per implementare praticamente una RAG servono quindi due ingredienti: un LLM a nostra scelta e la knowledge base.
Le fasi di attuazione si possono riassumere in questo schema:
- il sistema riceve l’input dall’utente ottenendo essenzialmente una query, una richiesta di informazioni. Questa è la parte che tipicamente nell’Intelligenza Artificiale attuale non manca mai. È quell’aspetto di dialogo, di chat, che ha reso così comuni queste tecnologie;
- in base agli elementi salienti della query viene attuata una ricerca di elementi pertinenti nella knowledge base, ovvero nell’insieme di documenti messi a disposizione. Si recupera ciò che può essere utile per costituire una risposta la più accurata, qualificata e aggiornata possibile;
- la richiesta di informazioni, accompagnata dagli elementi pertinenti recuperati dalla knowledge base viene fornita al modello linguistico, insieme al prompt con la richiesta iniziale;
- l’LLM elabora la risposta e la invia all’utente.
Knowledge base per la RAG e database vettoriali
Recuperare velocemente informazioni da un archivio di dati come la knowledge base potrebbe non essere così comodo ed efficiente e questo impatterebbe negativamente sull’agilità della risposta del sistema: elemento fondamentale considerando che molto spesso i RAG si offrono agli utenti nella forma esteriore di un meccanismo di Q&A (question and aswering).
Pertanto è necessaria una fase di indicizzazione della knowledge base che spesso sfrutta, come avviene non di rado nell’Intelligenza Artificiale, i database vettoriali.
Esistendo vari framework per l’attuazione di tale paradigma e volendo noi qui mantenerci su un approccio tendenzialmente universale, riassumiamo quelle che sono le fasi per una generica attività di indexing:
- per prima cosa serve il caricamento dei dati, l’accumulazione dei documenti in qualche punto di storage a nostra disposizione. Parliamo di documenti in senso generico, ma il principio si applica a informazioni di diverso tipo. Consideriamo che questo bacino di dati può essere caratterizzato dai formati più disparati e può essere stato pretrattato in precedenza o fornito grezzo. Ricordiamo sempre che in questo punto convogliano le conoscenze di un’azienda, che spesso sono costituite da elementi molto diversi tra loro che coesistono in un unico flusso di lavoro (immaginiamo per esempio un documento in Word con un report finanziario, corredato di specifiche tecniche da seguire in formato PDF e accompagnato dagli allegati analitici in fogli di calcolo Excel);
- i documenti accumulati al punto precedente possono essere troppo complessi da trattare e inoltre rischierebbero di celare e mischiare tra loro le informazioni che includono. Per questo è necessaria una fase di splitting in cui vengono suddivisi in porzioni di dimensioni inferiori per isolare le informazioni puntuali. Ciascun blocco di conoscenza (chunk) avrà quindi una maggior pertinenza su una singola unità di informazione;
- si procede poi all’embedding ovvero la trasformazione delle porzioni di informazione in vettori. Parliamo di un’attività in cui le informazioni vengono trasformate in numeri e collocate in uno spazio vettoriale, al fine di permettere di “misurare” l’affinità che intercorre tra loro;
- il tutto finisce tipicamente con l’immagazzinamento in un database vettoriale.
Il processo appena descritto ha le sembianze di una grossa digestione, in quanto inizia con un immagazzinamento (nello store dei documenti), una scomposizione in elementi fondamentali e si conclude con un altro immagazzinamento, nel database vettoriale. Si tratta però di una fase cruciale nell’implementazione di una RAG. Per la sua esecuzione esistono diversi framework, che tratteremo successivamente.
La seconda attività cruciale, ovvero il richiamo di un LLM per la generazione della risposta, non richiede nessun modello specifico. Per la scelta del “motore” di intelligenza artificiale potremo adottare il modello che preferiremo, seguendo i criteri già trattati nella nostra guida: LLM open source da installare in locale o disponibile come servizio, più o meno costoso, di maggior quantità di parametri o minore, open source o proprietario e via dicendo.
RAG e fine-tuning a confronto
Trattando e sperimentando LLM, ci si trova spesso faccia a faccia con un altro concetto: il fine-tuning, espressione che potremmo considerare una sorta di messa a punto di un LLM. Da descrizioni sommarie potrebbero sembrare simili ma consideriamo alcuni aspetti che li distinguono fortemente e soprattutto possono aiutarci a comprendere se le nostre attività aziendali necessitino di un RAG o del fine-tuning di un modello:
- il RAG è fortemente incentrato sulla knowledge base, la sua vera forza sta nella qualità delle informazioni che produce, l’uso di un LLM aggiunge per lo più la creatività della generazione linguistica: tutto ciò diventa ancora più evidente considerando bene i termini che compongono l’acronimo infatti parliamo di una generazione (generation) incrementata (augmented) con la forza di una grande attività di recupero (retrieval) di informazioni;
- il fine-tuning può essere considerato un perfezionamento, anche importante, di un LLM. La base conoscitiva del modello resta comunque ciò che questo ha imparato studiando il suo set di addestramento e quello che noi facciamo non è altro che fornire ulteriori informazioni per arricchirlo e renderlo più preciso in base alle nostre necessità. Il fine tuning aumenta la competenza di un modello su un certo argomento (per esempio il gergo specifico di un settore), o permette di avvicinare il risultato a un certo stile, ma non può garantire l’accuratezza dei risultati su informazioni specifiche e puntuali, come può invece fare la RAG.
Inoltre, consideriamo che il fine-tuning porta ad un modello incrementato ma comunque pur sempre ad un modello che deve essere ancora incluso in un’implementazione più ampia che lo trasformi in un vero e proprio servizio, il RAG invece rappresenta già un sistema completo, fine a sé stesso, che va dal prompt alla gestione dello storage di informazioni, fino al loro recupero e si conclude con la produzione della risposta all’utente.
È chiaro quindi che gli LLM sono elementi imprescindibili ma da soli non bastano. Necessitano per forza di essere integrati in sistemi più complessi, in pipeline dedicate alla gestione delle informazioni con knowledge base attendibili, aggiornate e attinenti ai servizi che offriamo o alle attività che le nostre aziende svolgono. Che la risposta risieda nell’implementazione di una RAG o in un’attività di fine-tuning le soluzioni applicabili sono tante ed in continuo aumento: sulle pagine delle nostre guide continueremo ad illustrarvele.