RAG con Java: database vettoriali e ricerca semantica

L'integrazione di grandi modelli linguistici (LLM) generativi nelle applicazioni Java rappresenta una frontiera promettente per numerosi casi d'uso, offrendo soluzioni innovative che ogni sviluppatore esperto dovrebbe considerare per il proprio arsenale di strumenti. Tuttavia, l'adozione di questi modelli non è priva di sfide, la più notevole delle quali è la tendenza a produrre output di scarsa qualità, spesso caratterizzati da "allucinazioni", ovvero informazioni generate in modo convincente ma prive di fondamento fattuale. Questo articolo intraprende un viaggio nel mondo dell'intelligenza artificiale generativa (GenAI), esplorando il pattern di soluzione noto come Retrieval-augmented Generation (RAG) attraverso esempi pratici di codice. Come sempre, l'obiettivo è presentare soluzioni interamente open source, senza componenti a pagamento o proprietari, e completamente eseguibili in locale sul notebook dello sviluppatore.

L'intelligenza artificiale generativa, i grandi modelli linguistici (LLM) e il machine learning si stanno affermando come approcci risolutivi in quasi tutti gli ambiti e gli strumenti lungo il processo di sviluppo software. Oltre a essere utilizzati come strumenti di supporto nella creazione e manutenzione di sistemi software, l'IA può essere impiegata come componente integrante all'interno di tali sistemi. Da un punto di vista economico, l'utilizzo di potenti LLM open source per la generazione di soluzioni complesse si preannuncia particolarmente interessante. Questa sembra essere una valutazione diffusa sul mercato, come dimostrato dalla reazione delle borse globali all'emergere di modelli OS come Deepseek R1 dalla Cina all'inizio dell'anno.

La sfida degli LLM: conoscenza limitata e allucinazioni

Nonostante il rilascio continuo di modelli sempre più potenti, gli attuali modelli linguistici generativi di ultima generazione presentano ancora un problema significativo: incontrano difficoltà con compiti che richiedono conoscenze di dominio specialistiche. Tipicamente, gli LLM vengono addestrati su enormi set di dati che includono contributi dai social media, libri, articoli scientifici e siti web scansionati, il che consente loro di acquisire una potente conoscenza generale. Tuttavia, senza accesso a conoscenze esterne, un modello generativo è limitato a produrre risposte basate esclusivamente sulla conoscenza parametrica che ha appreso durante la sua fase di addestramento.

I set di dati di addestramento per i modelli generativi sono inevitabilmente incompleti sotto diversi aspetti, poiché non contengono, ad esempio, le seguenti informazioni:

• Temi di nicchia: Conoscenze altamente specifiche che non sono ampiamente diffuse nei dati di addestramento generici.
• Sviluppi successivi alla data limite del dataset: Informazioni recenti o eventi accaduti dopo l'ultimo aggiornamento del set di dati.
• Conoscenza da database o repository interni: Dati proprietari, documenti aziendali o informazioni confidenziali non disponibili pubblicamente.

Questa mancanza di conoscenza specializzata può portare a problemi in cui il modello genera informazioni inaccurate o inventate. La propensione a offrire informazioni false o inventate in modo convincente è definita allucinazione e può causare danni finanziari significativi, ma soprattutto danni reputazionali, in casi d'uso commerciali dell'IA.

RAG: estendere le capacità degli LLM

Queste carenze nei dati di addestramento sono particolarmente pronunciate nell'addestramento di LLM OS generici, ma nel panorama DV aziendale, le informazioni mancanti sono disponibili in misura più che sufficiente. La chiave per migliorare le prestazioni degli LLM generici in compiti specializzati e per ridurre le allucinazioni consiste, di conseguenza, nel fornire ai modelli informazioni aggiuntive che non erano presenti nei loro dati di addestramento.

Con la Generazione aumentata da recupero (Retrieval-augmented Generation - RAG), è stato ideato un concetto di soluzione nel 2020 per tenere conto di questo aspetto. RAG è uno dei diversi metodi per estendere le capacità degli LLM generativi con aspetti di conoscenza mancanti. Il vantaggio di questo concetto risiede nel fatto che i pesi del modello generativo sottostante non devono essere aggiornati. RAG consente ai modelli di accedere dinamicamente a dati esterni, migliorando così la precisione senza la necessità di un riaddestramento costoso e dispendioso in termini di tempo. Ciò la rende un'opzione di soluzione pratica per le applicazioni nell'elaborazione dati aziendale.

Alternative a RAG, come il fine-tuning, modificano solitamente i pesi dell'LLM originale e richiedono quindi un (ri)addestramento e, di conseguenza, l'infrastruttura di machine learning adeguata. RAG, al contrario, non altera la conoscenza parametrica interna del modello, ma la arricchisce con conoscenza non parametrica esterna, fornita al momento dell'inferenza. Questo approccio è notevolmente più efficiente e flessibile per scenari in cui la conoscenza cambia frequentemente o è proprietaria.

Le componenti fondamentali di RAG

In linea di principio, il concetto RAG è un modello a pipeline composto da due fasi e tre componenti fondamentali (come illustrato schematicamente in un tipico diagramma RAG, spesso riferito come **Fig.1**). Vediamo nel dettaglio queste componenti:

1. Database di conoscenza di dominio esterno

La prima componente è il Database di conoscenza di dominio esterno. La conoscenza di dominio esterna è la conoscenza non parametrica che aggiungiamo alla conoscenza parametrica interna degli LLM tramite RAG. Fonti popolari di conoscenza esterna includono dati e documenti provenienti da database aziendali interni e pagine intranet. Anche altre fonti di dati private, come i sistemi di gestione documentale, possono essere utilizzate in RAG. I dati possono variare notevolmente per tema e formato e sono spesso specifici per il compito. Il compito principale del database di conoscenza di dominio è fornire blocchi di dati rilevanti dalla conoscenza di dominio per svolgere un compito specifico. Ciò significa che il database di conoscenza di dominio, pur rappresentando o contenendo tutta la conoscenza esterna, fornisce solo le parti rilevanti della conoscenza sotto forma di blocchi di dati per la soluzione di una richiesta concreta. A tal fine, viene solitamente eseguita una ricerca semantica basata sulla richiesta specifica attraverso l'intera base di conoscenza. Per questa ricerca, vengono spesso impiegati database vettoriali, che permettono di confrontare le rappresentazioni numeriche (embedding) della query con quelle dei documenti, trovando rapidamente i contenuti semanticamente più vicini.

2. Prompt template

La seconda componente è il Prompt Template. I prompt sono gli input testuali che utilizziamo per inviare le nostre richieste ai modelli generativi. I prompt possono contenere diversi elementi, ma tipicamente includono una richiesta, istruzioni e un contesto che guida il modello nella generazione di una risposta pertinente. Un prompt template è un modello strutturato per creare prompt standardizzati, in cui possono essere inseriti sia la richiesta originale dell'utente che i suoi contesti di conoscenza esterni. In sostanza, il prompt template funge da ponte tra i dati esterni e il modello, fornendo al modello informazioni contestualmente rilevanti durante l'inferenza per generare una risposta più precisa. Un semplice template per un LLM in lingua inglese potrebbe apparire come mostrato nel Listing 1:

Listing 1
prompt_template = "Context information is below.\n"
                  "---------------------\n"
                  "{context_str}\n"
                  "---------------------\n"
                  "Given the context information and not prior knowledge, "
                  "answer the query.\n"
                  "Query: {query_str}\n"
                  "Answer: "

In questo esempio, {context_str} sarà sostituito dai blocchi di conoscenza recuperati dal database esterno, mentre {query_str} conterrà la domanda originale dell'utente. Il template istruisce il modello a basare la sua risposta solo sul contesto fornito, mitigando così il rischio di allucinazioni.

3. LLM generativo

La componente finale in RAG è l'LLM generativo, che viene utilizzato per generare una risposta finale alla richiesta originale dell'utente. L'input esteso, arricchito con informazioni dal database di conoscenza esterno, viene inviato al modello, che genera una risposta che combina la conoscenza interna del modello con i dati esterni appena recuperati. Questo è il punto in cui la magia della generazione avviene, ma con una base informativa solida e verificabile.

La pipeline RAG: fasi di funzionamento

In una pipeline RAG, sulla base dell'input originale (prompt), vengono recuperati blocchi di dati rilevanti dal database di conoscenza di dominio esterno e inseriti in un prompt template, estendendo così l'input originale con conoscenza di dominio non parametrica. L'input così esteso viene quindi inviato al grande modello linguistico generativo per la produzione dell'output finale.

Ora che abbiamo trattato le tre componenti principali del concetto RAG, esaminiamo le due fasi del suo funzionamento, che sono interconnesse per creare un flusso di lavoro efficiente e accurato.

Fase 1: Ingestione dei dati

Nella prima fase, l'Ingestione, è necessario innanzitutto preparare e strutturare la conoscenza di dominio esterna. Questo processo include diversi passaggi cruciali. Per prima cosa, i dati vengono caricati da varie fonti, che possono includere documenti PDF, file di testo, pagine web, database relazionali o non relazionali, e così via. Una volta caricati, questi dati vengono tipicamente suddivisi in "chunk" (blocchi di testo) più piccoli e gestibili. Questa frammentazione è fondamentale perché gli LLM hanno limiti di contesto e una maggiore granularità dei dati migliora la pertinenza del recupero. Ogni chunk viene poi trasformato in una rappresentazione numerica, chiamata "embedding", utilizzando un modello di embedding. Questi embedding sono vettori che catturano il significato semantico del testo. Infine, questi embedding vettoriali, spesso insieme ai metadati e al testo originale dei chunk, vengono archiviati in un database vettoriale. Questo database è ottimizzato per la ricerca di similarità vettoriale, permettendo di trovare rapidamente i chunk di testo semanticamente più vicini a una data query. La qualità e la pertinenza dei dati in questa fase sono cruciali per l'efficacia complessiva del sistema RAG.

Fase 2: Recupero e generazione

La seconda fase, quella di Recupero e Generazione, si attiva quando un utente pone una domanda. La query dell'utente viene innanzitutto processata e trasformata anch'essa in un embedding vettoriale. Questo embedding viene poi utilizzato per eseguire una ricerca semantica nel database vettoriale, identificando i chunk di testo più rilevanti che contengono informazioni utili per rispondere alla domanda. I chunk recuperati vengono quindi inseriti nel prompt template, arricchendo la query originale dell'utente con il contesto necessario. L'intero prompt, ora completo di query e contesto, viene inviato all'LLM generativo. Il modello elabora queste informazioni combinate, sfruttando la sua conoscenza parametrica interna e la nuova conoscenza non parametrica fornita, per formulare una risposta dettagliata, precisa e, soprattutto, basata sui fatti presenti nel contesto recuperato. Questo meccanismo riduce drasticamente le allucinazioni e aumenta l'affidabilità delle risposte generate, rendendo gli LLM più utili per applicazioni aziendali critiche.

Conclusione

La Retrieval-augmented Generation rappresenta un paradigma fondamentale per estendere le capacità degli LLM in Java, superando i limiti intrinseci di conoscenza e riducendo il rischio di allucinazioni. Integrando database di conoscenza esterni, prompt template intelligenti e potenti LLM, RAG offre una soluzione robusta, flessibile ed economicamente vantaggiosa per l'implementazione di sistemi di intelligenza artificiale generativa in ambienti aziendali. La possibilità di implementare tutto in modo locale e senza l'uso di componenti proprietari rende RAG accessibile e sostenibile per una vasta gamma di sviluppatori e organizzazioni, consolidando il suo ruolo come strumento indispensabile nel toolkit dell'ingegnere software moderno.