3 Padrões-chave para Construir RAG Multimodal: Um Guia Abrangente
Grandes Modelos de Linguagem (LLMs) são altamente valorizados por sua versatilidade, pois podemos usá-los em inúmeras aplicações de IA, como chatbots personalizados, sumarização de documentos, perguntas e respostas sobre documentos, classificação de documentos e muito mais.
No entanto, um problema fundamental ao usar LLMs é o risco de alucinação. Alucinação refere-se a um fenômeno em que LLMs produzem respostas altamente convincentes, porém falsas, às nossas consultas. É bastante complicado identificar alucinações de LLMs, especialmente se estivermos fazendo perguntas sobre tópicos com os quais não estamos realmente familiarizados.
Entre muitos outros métodos, Geração Aumentada por Recuperação (RAG) é uma abordagem que pode nos ajudar a mitigar o risco de alucinações dos LLMs. Em sua implementação inicial, RAG era mais comumente usada apenas para entrada de texto. Com o avanço das tecnologias de IA, agora podemos usar RAG com diferentes modalidades de dados, como imagens, áudio, vídeos etc., o que chamamos de RAG multimodal.
Neste artigo, vamos discutir diferentes abordagens sobre como podemos implementar RAG multimodal em nossas aplicações de IA. Antes de nos aprofundarmos em RAG multimodal, vamos primeiro recapitular os fundamentos de RAG.
Os Fundamentos de RAG
RAG é uma abordagem inovadora que ajuda a mitigar o risco de alucinação de LLM ao fornecer contexto relevante para uma consulta do usuário no prompt. Antes de responder a uma consulta do usuário, o LLM pode usar esse contexto relevante como base para sua resposta, resultando em respostas mais contextualizadas.
Como o nome sugere, RAG tem três componentes principais: recuperação, aumento e geração.
Recuperação: Neste componente, o contexto mais relevante para uma consulta do usuário é buscado. Há duas etapas neste componente: recuperação de candidatos e reranqueamento. Na etapa de recuperação de candidatos, os top-n contextos mais promissores são buscados. Em contraste, na etapa de reranqueamento, esses contextos são ranqueados ou ordenados por métricas de similaridade, como similaridade de cosseno ou distância euclidiana.
Aumento: Neste componente, os contextos mais promissores são integrados à consulta original do usuário para formar um prompt final coerente. Esse prompt final então servirá como entrada para nosso LLM.
Geração: Neste componente, o LLM gera a resposta com base no prompt de entrada, que contém os contextos promissores para responder à consulta do usuário. A resposta é então enviada de volta ao usuário.
Figura: O fluxo de trabalho completo de RAG.
No entanto, precisamos configurar algumas coisas antes de implementar RAG em nossa aplicação.
Por exemplo, precisamos de um sistema de armazenamento eficiente e escalável para armazenar todos os contextos possíveis antes de podermos recuperá-los. Como os contextos normalmente úteis para RAG são dados não estruturados (texto, imagem etc.), bancos de dados vetoriais são os sistemas de armazenamento mais comuns usados em aplicações de RAG.
Em um banco de dados vetorial, normalmente armazenamos a representação de embeddings dos contextos em vez dos contextos brutos. Com embeddings, podemos realizar buscas por similaridade para encontrar os contextos mais promissores para qualquer consulta dada. Portanto, também precisamos de um modelo de deep learning (modelo de embedding) para transformar nossos contextos brutos em embeddings.
Embedding de palavras semelhantes em um espaço vetorial bidimensional.
O fluxo de trabalho do pipeline de RAG desde o início é então o seguinte:
Transforme contextos brutos em embeddings com a ajuda de um modelo de embedding.
Armazene e indexe esses embeddings em um banco de dados vetorial.
Para qualquer consulta dada, transforme a consulta em um embedding usando o mesmo modelo de embedding que usamos para os contextos brutos.
Realize uma busca por similaridade entre o embedding da consulta e os embeddings de contexto dentro do banco de dados vetorial.
Busque os top-n contextos mais relevantes e integre esses contextos com a consulta original em um prompt coerente como entrada para o nosso LLM.
O LLM gera uma resposta à consulta usando os contextos relevantes fornecidos para dar um resultado mais preciso.
Os Fundamentos do RAG Multimodal
A implementação de RAG que discutimos na seção anterior prova ser realmente útil para mitigar o risco de alucinação do LLM e melhorar a qualidade geral das respostas do LLM. No entanto, quando falamos sobre os contextos no RAG, normalmente nos referimos ao contexto como texto. Enquanto isso, sabemos que em aplicações do mundo real, talvez queiramos fornecer outras modalidades como contextos em vez de apenas texto.
Digamos que queremos usar uma coleção de documentos como contextos para uma aplicação de chatbot interna. Como já sabemos, um documento normalmente consiste não apenas em texto, mas também em imagens, gráficos e tabelas, que contêm muitas informações úteis para responder às consultas dos usuários. Com RAG baseado em texto, não conseguimos armazenar informações contidas nessas imagens, gráficos e tabelas como contextos.
O RAG multimodal é a solução para esse problema, pois, com este método de RAG, podemos armazenar todos os contextos de diferentes fontes de informação, melhorando assim também a precisão geral das respostas do LLM.
Figura: pipeline de RAG multimodal.
Graças ao surgimento e à ascensão do embedding multimodal, bem como dos LLMs multimodais, agora é possível implementarmos RAG multimodal. A ideia do RAG multimodal é exatamente a mesma do RAG usual, mas agora somos capazes de armazenar embeddings de diferentes modalidades de dados, como imagens, áudio e vídeos. No entanto, precisamos garantir que estamos usando modelos de embedding multimodal, bem como LLMs multimodais, se quisermos implementar RAG multimodal.
Em geral, podemos implementar RAG multimodal de várias maneiras. Especificamente, há três padrões diferentes sobre os quais falaremos em detalhes neste artigo:
Aterre todas as modalidades em uma modalidade primária.
Incorpore todas as modalidades no mesmo espaço vetorial.
Uma recuperação híbrida com acesso à imagem bruta.
Vamos discutir esses padrões um por um.
Padrão 1: Aterrar Todas as Modalidades em Uma Modalidade Primária (Multimídia para Texto)
O primeiro padrão envolve transformar todas as modalidades em uma modalidade primária. Embora você possa escolher qualquer modalidade como a primária, texto é a mais comumente usada em RAG multimodal. Portanto, vamos usar texto como nossa modalidade primária ao longo desta seção.
Para transformar diferentes modalidades em texto, o truque é usar um LLM multimodal para gerar um resumo textual dos nossos dados. Por exemplo, digamos que temos um documento que contém um monte de texto e uma imagem. Como texto é nossa modalidade primária, não precisamos fazer nada com o texto no documento. Enquanto isso, podemos usar um Modelo de Linguagem Visual (VLM) como LLAVA, Gemini, Claude Sonnet, Qwen-VL, Pixtral, etc., que aceita tanto imagens quanto texto como entradas para gerar um resumo textual da nossa imagem.
Depois de termos o resumo textual da nossa imagem, podemos transformar esse texto, juntamente com outros textos no documento, em embeddings usando um modelo de embedding baseado em texto. Há muitos modelos de embedding baseados em texto que podemos escolher, como os da SentenceTransformers, OpenAI, VoyageAI, etc. Os embeddings desses textos são então armazenados e indexados em um banco de dados vetorial.
Figura: Fluxo de trabalho do Padrão 1.
Agora, para qualquer consulta dada, podemos transformá-la em um embedding usando o mesmo modelo de embedding baseado em texto que usamos antes. Depois disso, podemos realizar uma busca por similaridade para encontrar os contextos mais relevantes e, então, usar os contextos baseados em texto como parte do prompt para nossos LLMs baseados em texto ou multimodais.
Se você quiser saber mais sobre os detalhes de implementação desse padrão, temos um artigo dedicado que guiará você pelas etapas para criar um RAG multimodal com esse padrão.
Esse padrão seria perfeito para usar se você não precisar de acesso aos dados brutos e não textuais no seu caso de uso. Sua aplicação pode aceitar imagens como entradas, mas a saída é sempre baseada em texto. Por exemplo, você pode criar uma aplicação que tenha a funcionalidade de explicar o conteúdo de imagens em um documento interno.
No entanto, ainda estamos contando com contextos baseados em texto com esse padrão, assim como no sistema RAG usual. Em aplicações do mundo real, talvez queiramos usar imagens ou outras modalidades como contextos. Portanto, vamos falar sobre o segundo padrão.
Padrão 2: Incorporar Todas as Modalidades no Mesmo Espaço Vetorial
O segundo padrão envolve transformar dados em todas as modalidades em embeddings no mesmo espaço vetorial. O segredo por trás dessa abordagem é a implementação de modelos de embedding multimodais, como CLIP e ALIGN. Vamos usar o CLIP como exemplo.
CLIP é um modelo desenvolvido pela OpenAI que recebe texto e imagem como um par de entradas e foi treinado para determinar a similaridade entre o texto e a imagem. Como resultado, o CLIP dará uma pontuação de similaridade alta se o texto estiver alinhado com a imagem, e vice-versa.
Figura: Embeddings de dados com diferentes modalidades com CLIP em um espaço vetorial tridimensional.
Como você pode ver acima, digamos que temos uma frase "Um cachorro sorridente" e uma imagem de um cachorro sorridente. O CLIP primeiro transformará tanto o texto quanto a imagem em embeddings com dimensões semelhantes e, se verificarmos o espaço vetorial, ambos os embeddings provavelmente serão colocados próximos um do outro.
Como temos um modelo de embedding multimodal, o primeiro passo desse padrão é transformar nossos dados em diferentes modalidades em embeddings com esse modelo de embedding multimodal. Em seguida, armazenamos e indexamos esses embeddings dentro de um banco de dados vetorial como Milvus ou Zilliz Cloud. Depois que tivermos uma consulta do usuário, nós a transformamos usando o mesmo modelo de embedding multimodal e, então, podemos realizar uma busca por similaridade para encontrar os contextos mais relevantes.
Figura: Fluxo de trabalho do Padrão 2.
Os contextos recuperados ao aplicar esse padrão podem ser dados com uma variedade de modalidades, como imagem e texto. Portanto, precisamos usar um LLM multimodal para levar esses contextos em conta e gerar a resposta final. Se nossos dados consistem em imagens e texto, podemos usar um Vision Language Model (VLM) como LLAVA, Gemini, Claude Sonnet, Qwen-VL, Pixtral, etc.
Se você quiser saber mais sobre os detalhes de implementação desse padrão, temos um artigo dedicado que guiará você pelas etapas para criar um RAG multimodal com esse padrão. No entanto, lembre-se de que, nesse artigo, as imagens brutas não são armazenadas diretamente dentro do banco de dados vetorial, mas sim armazenadas na memória local.
A principal vantagem desse padrão é sua versatilidade e simplicidade. A implementação de um modelo de embedding multimodal significa que não precisamos de uma etapa adicional para converter o conteúdo de todas as modalidades em uma modalidade primária, como fizemos no primeiro padrão. Além disso, os contextos recuperados após a busca por similaridade podem ser dados de quaisquer modalidades, em vez de apenas uma modalidade específica.
No entanto, como podemos usar quaisquer modalidades de dados como contextos relevantes para nosso LLM multimodal, também precisamos armazenar os dados brutos ao implementar esse padrão. O problema é que o tamanho de memória de dados não textuais, como imagens, é grande, e armazená-los diretamente em um banco de dados vetorial pode levar a um uso ineficiente de recursos. Isso também acabará levando a tempos de consulta mais lentos e custos de armazenamento maiores.
Portanto, recomendamos usar esse padrão se você precisar usar dados com diferentes modalidades como contextos, mas a escalabilidade não for uma preocupação para o seu caso de uso.
Padrão 3: Uma recuperação híbrida com acesso a imagens brutas.
Se você precisa usar dados com várias modalidades como contextos, e a escalabilidade também é uma preocupação, então você pode implementar esse padrão. A ideia principal desse padrão é a separação de responsabilidades: usamos um banco de dados vetorial para realizar buscas por similaridade rápidas e eficientes para encontrar contextos relevantes, e usamos sistemas dedicados de armazenamento de objetos, como AWS S3 ou Google Cloud Storage, para armazenar os dados brutos.
Durante a implementação desse padrão, precisamos realizar duas etapas diferentes. Primeiro, armazenamos os dados brutos reais em um sistema dedicado de armazenamento de objetos, como AWS S3 ou Google Cloud Storage. Segundo, armazenamos os metadados de nossos dados brutos dentro do banco de dados vetorial, como a URL da nossa imagem que reside no sistema dedicado de armazenamento de objetos.
Figura: fluxo de trabalho do Padrão 3.
Como usamos um sistema separado para armazenar nossos dados brutos, a forma como realizamos RAG é quase semelhante ao primeiro padrão. Digamos que texto seja nossa modalidade primária. A primeira coisa que precisaremos fazer é usar um LLM multimodal para gerar resumos em texto dos nossos dados brutos. Em seguida, podemos usar um modelo de embedding baseado em texto para transformar os resumos em texto em embeddings. Então armazenamos os embeddings, bem como os metadados dos nossos dados brutos (URL dos dados brutos no sistema de armazenamento dedicado), em um banco de dados vetorial.
Para qualquer consulta dada, usamos o mesmo LLM multimodal para gerar um resumo em texto e, em seguida, transformamos o resumo da consulta em um embedding usando o mesmo modelo de embedding baseado em texto. Em seguida, podemos realizar uma busca por similaridade e buscar o resumo em texto, bem como a URL dos contextos relevantes. Por fim, podemos passar os dados brutos para um LLM multimodal por meio da URL recuperada.
Novamente, você pode consultar este artigo que guiará você pelas etapas para criar um RAG multimodal com esse padrão. No entanto, lembre-se de que, no artigo, as imagens brutas não são armazenadas em um sistema de armazenamento típico pronto para produção, como AWS ou GCP, mas sim na memória local.
Dentre as três opções, este padrão é o mais escalável devido à separação do armazenamento de dados brutos. Como talvez já saibamos, bancos de dados vetoriais são otimizados para consultar dados não estruturados, não para armazenar e servir grandes objetos binários como imagens. Na verdade, recuperar objetos binários de bancos de dados vetoriais costuma ser mais lento do que recuperá-los de um sistema dedicado de armazenamento de objetos.
Portanto, recomendamos que você use este padrão se quiser usar dados com várias modalidades como contextos e a escalabilidade for uma grande preocupação para o seu caso de uso.
Como o Banco de Dados Vetorial Milvus Suporta RAG Multimodal
Como mencionado nas seções anteriores, bancos de dados vetoriais desempenham um papel crucial na aplicação de Geração Aumentada por Recuperação (RAG). Milvus é um banco de dados vetorial que seria perfeito para uso no seu sistema RAG ou em outras aplicações de IA devido aos seus recursos avançados.
Milvus oferece métodos de indexação que vão dos mais simples a opções mais avançadas, como IVFFLAT, HNSW e SCANN, permitindo-nos armazenar enormes coleções de dados de maneira rápida e eficiente. A implementação desses métodos avançados de indexação também acelera o processo de busca por similaridade para encontrar contextos relevantes em uma implementação de RAG.
Integração fácil do Milvus com ferramentas populares para RAG multimodal.
Milvus também oferece integração fácil com todos os componentes de RAG que discutimos na seção anterior, como modelos de embeddings, LLMs e ferramentas de orquestração. Em termos de modelos de embeddings, você pode usar diretamente opções populares da OpenAI, Cohere, SentenceTransformers, HuggingFace, VoyageAI e outras com o SDK Python do Milvus chamado pymilvus. Você pode instalar o pymilvus com um comando pip simples:
pip install -U pymilvus
Agora, digamos que você queira usar o modelo de embeddings da SentenceTransformers, você pode fazer isso facilmente com o pymilvus da seguinte forma:
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)
Você pode aprender mais sobre diferentes tipos de modelos de embeddings suportados pelo Pymilvus em esta página de integração.
Em termos de LLMs e ferramentas de orquestração, Milvus pode ser integrado facilmente a frameworks populares como vLLM, Ollama, Gemini, LlamaIndex e Langchain. Se você quiser saber mais sobre a integração do Milvus com todas essas ferramentas, temos uma coleção de tutoriais que você pode conferir em esta página. Também temos um tutorial simples onde você pode aprender como criar um RAG multimodal simples com Milvus nesta página da documentação.
Conclusão
RAG multimodal representa um avanço significativo na utilização de diversas modalidades de dados para melhorar a precisão das respostas dos LLMs. Discutimos três padrões principais para implementar RAG multimodal neste artigo: fundamentar todas as modalidades em uma modalidade primária, incorporá-las em um espaço vetorial unificado ou empregar recuperação híbrida com acesso a dados brutos. A escolha de um padrão adequado depende das necessidades específicas da sua aplicação de IA.
Com seus métodos avançados de indexação e fácil integração com modelos de embedding, LLMs e ferramentas de orquestração, o banco de dados vetorial Milvus oferece um sistema adequado para implementar sistemas RAG multimodais. À medida que as aplicações de IA se expandem em escopo e complexidade, utilizar um sistema de banco de dados vetorial escalável como o Milvus torna-se cada vez mais crucial.
Continue lendo
Notion's Vector Search Is Excellent. Their Next Problem Is Harder.
Notion solved vector search scaling in two years. The next bottleneck — offline context engineering, unified data, and the real-time/offline gap — is harder.
A Developer's Guide to Exploring Milvus 2.6 Features on Zilliz Cloud
Milvus 2.6 marks a shift from “vector search + glue code” to a more advanced retrieval engine, and it is now Generally Available (GA) on Zilliz Cloud (a managed Milvus service).
Top 10 Context Engineering Techniques You Should Know for Production RAG
A practical guide to context engineering for production LLM systems, covering RAG, context processing, memory, agents, and multimodal context.