3 modelli chiave per costruire RAG multimodale: una guida completa
I Large Language Model (LLM) sono molto apprezzati per la loro versatilità, poiché possiamo utilizzarli in numerose applicazioni di IA, come chatbot personalizzati, riassunto di documenti, risposta a domande sui documenti, classificazione di documenti e altro ancora.
Tuttavia, un problema chiave nell'utilizzo degli LLM è il rischio di allucinazione. L'allucinazione si riferisce a un fenomeno in cui gli LLM producono risposte molto convincenti ma non veritiere alle nostre query. È piuttosto difficile individuare le allucinazioni degli LLM, soprattutto se poniamo loro domande su argomenti che non conosciamo davvero bene.
Tra molti altri metodi, la Retrieval Augmented Generation (RAG) è un approccio che può aiutarci a mitigare il rischio di allucinazioni degli LLM. Nella sua implementazione iniziale, la RAG era più comunemente utilizzata solo per input testuali. Con l'avanzamento delle tecnologie di IA, ora possiamo utilizzare la RAG con diverse modalità di dati, come immagini, audio, video, ecc., ciò a cui ci riferiamo come RAG multimodale.
In questo articolo, discuteremo diversi approcci su come possiamo implementare la RAG multimodale nelle nostre applicazioni di IA. Prima di approfondire la RAG multimodale, ricapitoliamo innanzitutto i fondamenti della RAG.
I fondamenti della RAG
RAG è un approccio innovativo che aiuta a mitigare il rischio di allucinazione degli LLM fornendo un contesto pertinente a una query dell'utente nel prompt. Prima di rispondere a una query dell'utente, l'LLM può utilizzare questo contesto pertinente come base per la sua risposta, ottenendo risposte più contestualizzate.
Come suggerisce il nome, la RAG ha tre componenti principali: retrieval, augmentation e generation.
Retrieval: In questo componente, viene recuperato il contesto più pertinente per una query dell'utente. Ci sono due fasi in questo componente: recupero dei candidati e reranking. Nella fase di recupero dei candidati, vengono recuperati i top-n contesti più promettenti. Al contrario, nella fase di reranking, questi contesti vengono classificati o ordinati in base a metriche di similarità, come la similarità coseno o la distanza euclidea.
Augmentation: In questo componente, i contesti più promettenti vengono integrati con la query originale dell'utente per formare un unico prompt finale coerente. Questo prompt finale servirà quindi da input per il nostro LLM.
Generation: In questo componente, l'LLM genera la risposta in base al prompt di input, che contiene i contesti promettenti per rispondere alla query dell'utente. La risposta viene quindi inviata all'utente.
Figura: Il flusso di lavoro completo della RAG.
Tuttavia, dobbiamo configurare alcune cose prima di implementare la RAG nella nostra applicazione.
Ad esempio, abbiamo bisogno di un sistema di archiviazione efficiente e scalabile per memorizzare tutti i possibili contesti prima di poterli recuperare. Poiché i contesti tipicamente utili per la RAG sono dati non strutturati (testo, immagine, ecc.), i database vettoriali sono i sistemi di archiviazione più comuni utilizzati nelle applicazioni RAG.
In un database vettoriale, in genere memorizziamo la rappresentazione di embedding dei contesti invece dei contesti grezzi. Con gli embedding, possiamo eseguire ricerche di similarità per trovare i contesti più promettenti per qualsiasi query data. Pertanto, abbiamo anche bisogno di un modello di deep learning (modello di embedding) per trasformare i nostri contesti grezzi in embedding.
Embedding di parole simili in uno spazio vettoriale bidimensionale.
Il flusso di lavoro della pipeline RAG dall'inizio è quindi il seguente:
Trasforma i contesti grezzi in embedding con l'aiuto di un modello di embedding.
Archivia e indicizza questi embedding in un database vettoriale.
Per qualsiasi query data, trasforma la query in un embedding utilizzando lo stesso modello di embedding che abbiamo usato per i contesti grezzi.
Esegui una ricerca di similarità tra l'embedding della query e gli embedding dei contesti all'interno del database vettoriale.
Recupera i top-n contesti più rilevanti e integra tali contesti con la query originale in un unico prompt coerente come input per il nostro LLM.
L'LLM genera una risposta alla query utilizzando i contesti rilevanti forniti per dare un risultato più accurato.
I fondamenti del RAG multimodale
L'implementazione del RAG di cui abbiamo discusso nella sezione precedente si rivela davvero utile nel mitigare il rischio di allucinazione degli LLM e nel migliorare la qualità complessiva delle risposte degli LLM. Tuttavia, quando parliamo dei contesti nel RAG, normalmente ci riferiamo al contesto come testo. Nel frattempo, sappiamo che nelle applicazioni del mondo reale potremmo voler fornire altre modalità come contesti invece del solo testo.
Supponiamo di voler usare una raccolta di documenti come contesti per un'applicazione chatbot interna. Come sappiamo già, un documento in genere è composto non solo da testo, ma anche da immagini, grafici e tabelle, che contengono molte informazioni utili per rispondere alle query degli utenti. Con il RAG basato su testo, non possiamo archiviare come contesti le informazioni contenute in queste immagini, grafici e tabelle.
Il RAG multimodale è la soluzione a questo problema, poiché con questo metodo RAG possiamo archiviare tutti i contesti provenienti da diverse fonti di informazione, migliorando così anche l'accuratezza complessiva delle risposte degli LLM.
Figura: pipeline RAG multimodale.
Grazie alla nascita e all'ascesa dell'embedding multimodale e dei LLM multimodali, ora è possibile implementare il RAG multimodale. L'idea del RAG multimodale è esattamente la stessa del RAG usuale, ma ora siamo in grado di archiviare embedding da diverse modalità di dati, come immagini, audio e video. Tuttavia, dobbiamo assicurarci di utilizzare modelli di embedding multimodali e LLM multimodali se vogliamo implementare il RAG multimodale.
In generale, possiamo implementare il RAG multimodale in vari modi. In particolare, ci sono tre pattern diversi di cui parleremo in dettaglio in questo articolo:
Radicare tutte le modalità in una modalità primaria.
Incorporare tutte le modalità nello stesso spazio vettoriale.
Un recupero ibrido con accesso all'immagine grezza.
Discutiamo questi pattern uno per uno.
Pattern 1: radicare tutte le modalità in una modalità primaria (da multimedia a testo)
Il primo pattern prevede la trasformazione di tutte le modalità in una modalità primaria. Sebbene tu possa scegliere qualsiasi modalità come primaria, il testo è la più comunemente utilizzata nel RAG multimodale. Pertanto, useremo il testo come nostra modalità primaria in tutta questa sezione.
Per trasformare diverse modalità in testo, il trucco consiste nell'utilizzare un LLM multimodale per generare un riassunto testuale dei nostri dati. Per esempio, supponiamo di avere un documento che contiene un po' di testo e un'immagine. Poiché il testo è la nostra modalità primaria, non dobbiamo fare nulla con il testo nel documento. Nel frattempo, possiamo usare un Vision Language Model (VLM) come LLAVA, Gemini, Claude Sonnet, Qwen-VL, Pixtral, ecc., che accetta sia immagini sia testo come input per generare una sintesi testuale della nostra immagine.
Una volta ottenuto il riepilogo testuale della nostra immagine, possiamo trasformare questo testo insieme ad altro testo nel documento in embedding utilizzando un modello di embedding basato su testo. Esistono molti modelli di embedding basati su testo tra cui possiamo scegliere, come quelli di SentenceTransformers, OpenAI, VoyageAI, ecc. Gli embedding di questi testi vengono quindi archiviati e indicizzati in un database vettoriale.
Figura: flusso di lavoro del Pattern 1.
Ora, per qualsiasi query data, possiamo trasformarla in un embedding utilizzando lo stesso modello di embedding basato su testo che abbiamo usato in precedenza. Dopo di che, possiamo eseguire una ricerca di similarità per trovare i contesti più rilevanti e quindi utilizzare i contesti basati su testo come parte del prompt per i nostri LLM basati su testo o multimodali.
Se desideri saperne di più sui dettagli di implementazione di questo pattern, abbiamo un articolo dedicato che ti guiderà attraverso i passaggi per creare un RAG multimodale con questo pattern.
Questo pattern sarebbe perfetto da usare se non hai bisogno di accedere ai dati grezzi, non testuali, nel tuo caso d’uso. La tua applicazione potrebbe accettare immagini come input, ma l’output è sempre basato su testo. Ad esempio, potresti creare un’applicazione che abbia la funzionalità di spiegare il contenuto delle immagini in un documento interno.
Tuttavia, con questo pattern ci stiamo ancora basando su contesti testuali, proprio come nel solito sistema RAG. Nelle applicazioni reali, potremmo voler utilizzare immagini o altre modalità come contesti. Pertanto, parliamo del secondo pattern.
Pattern 2: Incorpora tutte le modalità nello stesso spazio vettoriale
Il secondo pattern prevede la trasformazione dei dati in tutte le modalità in embedding nello stesso spazio vettoriale. Il segreto dietro questo approccio è l’implementazione di modelli di embedding multimodali come CLIP e ALIGN. Prendiamo CLIP come esempio.
CLIP è un modello sviluppato da OpenAI che prende sia testo sia immagine come coppia di input ed è stato addestrato a determinare la similarità tra il testo e l’immagine. Di conseguenza, CLIP assegnerà un punteggio di similarità elevato se il testo si allinea con l’immagine, e viceversa.
Figura: embedding di dati con diverse modalità con CLIP in uno spazio vettoriale tridimensionale.
Come puoi vedere sopra, supponiamo di avere una frase "A smiling dog," e un’immagine di un cane sorridente. CLIP trasformerà prima sia il testo sia l’immagine in embedding con dimensioni simili e, se controlliamo lo spazio vettoriale, entrambi gli embedding saranno probabilmente posizionati vicini l’uno all’altro.
Poiché abbiamo un modello di embedding multimodale, il primo passo di questo pattern è trasformare i nostri dati in diverse modalità in embedding con questo modello di embedding multimodale. Successivamente, archiviamo e indicizziamo questi embedding all’interno di un database vettoriale come Milvus o Zilliz Cloud. Una volta ricevuta una query dell’utente, la trasformiamo utilizzando lo stesso modello di embedding multimodale, quindi possiamo eseguire una ricerca di similarità per trovare i contesti più rilevanti.
Figura: flusso di lavoro del Pattern 2.
I contesti recuperati quando si applica questo pattern possono essere dati con una varietà di modalità, come immagini e testo. Pertanto, dobbiamo utilizzare un LLM multimodale per tenere conto di questi contesti e generare la risposta finale. Se i nostri dati sono costituiti da immagini e testo, possiamo utilizzare un Vision Language Model (VLM) come LLAVA, Gemini, Claude Sonnet, Qwen-VL, Pixtral, ecc.
Se desideri saperne di più sui dettagli di implementazione di questo pattern, abbiamo un articolo dedicato che ti guiderà attraverso i passaggi per costruire un RAG multimodale con questo pattern. Tuttavia, tieni presente che in quell'articolo le immagini grezze non vengono archiviate direttamente all'interno del database vettoriale, ma piuttosto archiviate nella memoria locale.
Il principale vantaggio di questo pattern è la sua versatilità e semplicità. L'implementazione di un modello di embedding multimodale significa che non abbiamo bisogno di un passaggio aggiuntivo per convertire il contenuto di tutte le modalità in una modalità primaria come abbiamo fatto nel primo pattern. Inoltre, i contesti recuperati dopo la ricerca di similarità possono essere dati di qualsiasi modalità invece che di una sola modalità particolare.
Tuttavia, poiché siamo in grado di utilizzare qualsiasi modalità di dati come contesti rilevanti per il nostro LLM multimodale, dobbiamo anche archiviare i dati grezzi quando implementiamo questo pattern. Il problema è che la dimensione in memoria dei dati non testuali, come le immagini, è grande, e archiviarli direttamente in un database vettoriale può portare a un uso inefficiente delle risorse. Questo alla fine porterà anche a tempi di query più lenti e costi di archiviazione più elevati.
Pertanto, consigliamo di utilizzare questo pattern se hai bisogno di usare dati con modalità diverse come contesti, ma la scalabilità non è una preoccupazione per il tuo caso d'uso.
Pattern 3: Recupero ibrido con accesso alle immagini grezze.
Se hai bisogno di utilizzare dati con varie modalità come contesti, e anche la scalabilità è una preoccupazione, allora puoi implementare questo pattern. L'idea principale di questo pattern è la separazione delle responsabilità: utilizziamo un database vettoriale per eseguire ricerche di similarità rapide ed efficienti per trovare contesti rilevanti, e utilizziamo sistemi dedicati di object storage come AWS S3 o Google Cloud Storage per archiviare i dati grezzi.
Durante l'implementazione di questo pattern, dobbiamo eseguire due passaggi diversi. Innanzitutto, archiviamo i dati grezzi effettivi in un sistema dedicato di object storage come AWS S3 o Google Cloud Storage. In secondo luogo, archiviamo i metadati dei nostri dati grezzi all'interno del database vettoriale, come l'URL della nostra immagine che risiede nel sistema dedicato di object storage.
Figura: workflow del Pattern 3.
Poiché utilizziamo un sistema separato per archiviare i nostri dati grezzi, il modo in cui eseguiamo il RAG è quasi simile al primo pattern. Diciamo che il testo è la nostra modalità primaria. La prima cosa che dovremo fare è utilizzare un LLM multimodale per generare riassunti testuali dei nostri dati grezzi. Successivamente, possiamo utilizzare un modello di embedding basato sul testo per trasformare i riassunti testuali in embedding. Quindi archiviamo gli embedding e i metadati dei nostri dati grezzi (URL dei dati grezzi nel sistema di archiviazione dedicato) in un database vettoriale.
Per qualsiasi query data, utilizziamo lo stesso LLM multimodale per generare un riassunto testuale e poi trasformiamo il riassunto della query in un embedding utilizzando lo stesso modello di embedding basato sul testo. Successivamente, possiamo eseguire una ricerca di similarità e recuperare il riassunto testuale nonché l'URL dei contesti rilevanti. Infine, possiamo passare i dati grezzi a un LLM multimodale tramite l'URL recuperato.
Ancora una volta, puoi fare riferimento a questo articolo che ti guiderà attraverso i passaggi per costruire un RAG multimodale con questo pattern. Tuttavia, tieni presente che nell'articolo le immagini grezze non sono archiviate in un tipico sistema di archiviazione pronto per la produzione come AWS o GCP, ma piuttosto nella memoria locale.
Tra le tre opzioni, questo pattern è quello più scalabile grazie alla separazione dell’archiviazione dei dati grezzi. Come forse già sappiamo, i database vettoriali sono ottimizzati per interrogare dati non strutturati, non per archiviare e servire oggetti binari di grandi dimensioni come le immagini. Infatti, il recupero di oggetti binari dai database vettoriali è spesso più lento rispetto al loro recupero da un sistema dedicato di object storage.
Pertanto, ti consigliamo di utilizzare questo pattern se vuoi usare dati con varie modalità come contesti e la scalabilità è una grande preoccupazione per il tuo caso d’uso.
Come Milvus Vector Database supporta il RAG multimodale
Come menzionato nelle sezioni precedenti, i database vettoriali svolgono un ruolo cruciale nell’applicazione della Retrieval Augmented Generation (RAG). Milvus è un database vettoriale che sarebbe perfetto da usare nel tuo sistema RAG o in altre applicazioni di AI grazie alle sue funzionalità avanzate.
Milvus offre metodi di indicizzazione che vanno dai più semplici a quelli più avanzati come IVFFLAT, HNSW e SCANN, consentendoci di archiviare enormi raccolte di dati in modo rapido ed efficiente. L’implementazione di questi metodi di indicizzazione avanzati accelera anche il processo di ricerca per similarità per trovare contesti rilevanti in un’implementazione RAG.
Facile integrazione di Milvus con strumenti popolari per il RAG multimodale.
Milvus offre anche una facile integrazione con tutti i componenti RAG di cui abbiamo discusso nella sezione precedente, come modelli di embedding, LLM e strumenti di orchestrazione. Per quanto riguarda i modelli di embedding, puoi usare direttamente opzioni popolari di OpenAI, Cohere, SentenceTransformers, HuggingFace, VoyageAI e altri con l’SDK Python di Milvus chiamato pymilvus. Puoi installare pymilvus con un semplice comando pip:
pip install -U pymilvus
Ora supponiamo che tu voglia usare il modello di embedding di SentenceTransformers, puoi farlo facilmente con pymilvus come segue:
pip install "pymilvus[model]"
from pymilvus import model
sentence_transformer_ef = model.dense.SentenceTransformerEmbeddingFunction(
model_name='all-MiniLM-L6-v2', # Specify the model name
device='cpu' # Specify the device to use, e.g., 'cpu' or 'cuda:0'
)
doc = [
"Artificial intelligence was founded as an academic discipline in 1956."]
doc_embedding = sentence_transformer_ef.encode_documents(doc)
Puoi saperne di più sui diversi tipi di modelli di embedding supportati da Pymilvus in questa pagina di integrazione.
Per quanto riguarda LLM e strumenti di orchestrazione, Milvus può essere integrato facilmente con framework popolari come vLLM, Ollama, Gemini, LlamaIndex e Langchain. Se desideri saperne di più sull’integrazione di Milvus e tutti questi strumenti, abbiamo una raccolta di tutorial che puoi consultare su questa pagina. Abbiamo anche un semplice tutorial in cui puoi imparare a costruire un semplice RAG multimodale con Milvus in questa pagina della documentazione.
Conclusione
Il RAG multimodale rappresenta un progresso significativo nell’utilizzo di diverse modalità di dati per migliorare l’accuratezza delle risposte degli LLM. In questo articolo abbiamo discusso tre pattern chiave per implementare il RAG multimodale: radicare tutte le modalità in una modalità primaria, incorporarle in uno spazio vettoriale unificato o impiegare il recupero ibrido con accesso ai dati grezzi. La scelta di un pattern adatto dipende dalle esigenze specifiche della tua applicazione di AI.
Con i suoi metodi di indicizzazione avanzati e la facile integrazione con modelli di embedding, LLM e strumenti di orchestrazione, il database vettoriale Milvus offre un sistema adatto per implementare sistemi RAG multimodali. Con l’espansione delle applicazioni di IA in termini di portata e complessità, l’utilizzo di un sistema di database vettoriale scalabile come Milvus diventa sempre più cruciale.
Continua a leggere
Zilliz Cloud On-Demand Compute: Pay Only for What You Use
The customer case behind Zilliz Cloud On-Demand: how a $10K vector search bill came down to under $500, and the engineering changes that made it possible.
Zilliz Cloud Update: Smarter Autoscaling for Cost Savings, Stronger Compliance with Audit Logs, and More
What's new in Zilliz Cloud? Smarter autoscaling with scale-down, audit logs GA, enhanced SSO, and Milvus 2.6 in Private Preview.
Announcing the General Availability of Zilliz Cloud BYOC on Google Cloud Platform
Zilliz Cloud BYOC on GCP offers enterprise vector search with full data sovereignty and seamless integration.