3 patrones clave para crear RAG multimodal: una guía completa
Los modelos de lenguaje grandes (LLMs) son muy valorados por su versatilidad, ya que podemos usarlos en numerosas aplicaciones de IA, como chatbots personalizados, resumen de documentos, respuesta a preguntas sobre documentos, clasificación de documentos y más.
Sin embargo, un problema clave al usar LLMs es el riesgo de alucinación. La alucinación se refiere a un fenómeno en el que los LLMs producen respuestas muy convincentes pero falsas a nuestras consultas. Es bastante difícil detectar alucinaciones de los LLMs, especialmente si les hacemos preguntas sobre temas con los que no estamos realmente familiarizados.
Entre muchos otros métodos, Retrieval Augmented Generation (RAG) es un enfoque que puede ayudarnos a mitigar el riesgo de alucinaciones de los LLMs. En su implementación inicial, RAG se usaba más comúnmente solo para entrada de texto. Con el avance de las tecnologías de IA, ahora podemos usar RAG con diferentes modalidades de datos, como imágenes, audio, videos, etc., a lo que nos referimos como RAG multimodal.
En este artículo, vamos a analizar diferentes enfoques sobre cómo podemos implementar RAG multimodal en nuestras aplicaciones de IA. Antes de profundizar en RAG multimodal, primero repasemos los fundamentos de RAG.
Los fundamentos de RAG
RAG es un enfoque novedoso que ayuda a mitigar el riesgo de alucinación de los LLM al proporcionar contexto relevante a una consulta de usuario en el prompt. Antes de responder a una consulta de usuario, el LLM puede usar este contexto relevante como base para su respuesta, lo que da como resultado respuestas más contextualizadas.
Como sugiere el nombre, RAG tiene tres componentes principales: recuperación, aumento y generación.
Recuperación: En este componente, se obtiene el contexto más relevante para una consulta de usuario. Hay dos etapas en este componente: recuperación de candidatos y reranking. En la etapa de recuperación de candidatos, se obtienen los top-n contextos más prometedores. En cambio, en la etapa de reranking, estos contextos se clasifican u ordenan según métricas de similitud, como la similitud del coseno o la distancia euclidiana.
Aumento: En este componente, los contextos más prometedores se integran con la consulta original del usuario para formar un único prompt final coherente. Este prompt final servirá entonces como entrada para nuestro LLM.
Generación: En este componente, el LLM genera la respuesta basándose en el prompt de entrada, que contiene los contextos prometedores para responder a la consulta del usuario. La respuesta se envía luego de vuelta al usuario.
Figura: El flujo de trabajo completo de RAG.
Sin embargo, necesitamos configurar algunas cosas antes de implementar RAG en nuestra aplicación.
Por ejemplo, necesitamos un sistema de almacenamiento eficiente y escalable para almacenar todos los contextos posibles antes de poder recuperarlos. Dado que los contextos típicamente útiles para RAG son datos no estructurados (texto, imagen, etc.), las bases de datos vectoriales son los sistemas de almacenamiento más comunes utilizados en aplicaciones RAG.
En una base de datos vectorial, normalmente almacenamos la representación de embedding de los contextos en lugar de los contextos sin procesar. Con embeddings, podemos realizar búsquedas de similitud para encontrar los contextos más prometedores para cualquier consulta dada. Por lo tanto, también necesitamos un modelo de deep learning (modelo de embedding) para transformar nuestros contextos sin procesar en embeddings.
Embedding de palabras similares en un espacio vectorial bidimensional.
El flujo de trabajo del pipeline RAG desde el principio es entonces el siguiente:
Transformar contextos sin procesar en embeddings con la ayuda de un modelo de embeddings.
Almacenar e indexar estos embeddings en una base de datos vectorial.
Para cualquier consulta dada, transformar la consulta en un embedding utilizando el mismo modelo de embeddings que usamos para los contextos sin procesar.
Realizar una búsqueda de similitud entre el embedding de la consulta y los embeddings de contexto dentro de la base de datos vectorial.
Recuperar los top-n contextos más relevantes e integrar esos contextos con la consulta original en un único prompt coherente como entrada para nuestro LLM.
El LLM genera una respuesta a la consulta utilizando los contextos relevantes proporcionados para ofrecer un resultado más preciso.
Los fundamentos del RAG multimodal
La implementación de RAG que analizamos en la sección anterior demuestra ser realmente útil para mitigar el riesgo de alucinación de los LLM y mejorar la calidad general de las respuestas de los LLM. Sin embargo, cuando hablamos de los contextos en RAG, normalmente nos referimos al contexto como texto. Mientras tanto, sabemos que en aplicaciones del mundo real, podríamos querer proporcionar otras modalidades como contextos en lugar de solo texto.
Digamos que queremos usar una colección de documentos como contextos para una aplicación interna de chatbot. Como ya sabemos, un documento normalmente consta no solo de texto, sino también de imágenes, gráficos y tablas, que contienen mucha información útil para responder a las consultas de los usuarios. Con RAG basado en texto, no podemos almacenar como contextos la información contenida en estas imágenes, gráficos y tablas.
El RAG multimodal es la solución a este problema, ya que con este método de RAG podemos almacenar todos los contextos de diferentes fuentes de información, mejorando así también la precisión general de las respuestas de los LLM.
Figura: canalización de RAG multimodal.
Gracias al surgimiento y auge de los embeddings multimodales, así como de los LLM multimodales, ahora es posible implementar RAG multimodal. La idea del RAG multimodal es exactamente la misma que la del RAG habitual, pero ahora podemos almacenar embeddings de diferentes modalidades de datos, como imágenes, audio y videos. Sin embargo, debemos asegurarnos de usar modelos de embeddings multimodales, así como LLM multimodales, si queremos implementar RAG multimodal.
En general, podemos implementar RAG multimodal de varias maneras. Específicamente, hay tres patrones diferentes de los que hablaremos en detalle en este artículo:
Fundamentar todas las modalidades en una modalidad principal.
Incrustar todas las modalidades en el mismo espacio vectorial.
Una recuperación híbrida con acceso a imágenes sin procesar.
Analicemos estos patrones uno por uno.
Patrón 1: Fundamentar todas las modalidades en una modalidad principal (de multimedia a texto)
El primer patrón implica transformar todas las modalidades en una modalidad principal. Aunque puedes elegir cualquier modalidad como principal, el texto es la más comúnmente utilizada en RAG multimodal. Por lo tanto, vamos a usar texto como nuestra modalidad principal a lo largo de esta sección.
Para transformar diferentes modalidades en texto, el truco es usar un LLM multimodal para generar un resumen textual de nuestros datos. Por ejemplo, digamos que tenemos un documento que contiene un montón de texto y una imagen. Dado que el texto es nuestra modalidad principal, no necesitamos hacer nada con el texto del documento. Mientras tanto, podemos usar un Modelo de Lenguaje Visual (VLM) como LLAVA, Gemini, Claude Sonnet, Qwen-VL, Pixtral, etc., que acepta tanto imágenes como texto como entradas para generar un resumen textual de nuestra imagen.
Una vez que tenemos el resumen textual de nuestra imagen, podemos transformar este texto junto con otro texto del documento en embeddings utilizando un modelo de embeddings basado en texto. Hay muchos modelos de embeddings basados en texto entre los que podemos elegir, como los de SentenceTransformers, OpenAI, VoyageAI, etc. Los embeddings de estos textos se almacenan e indexan luego en una base de datos vectorial.
Figura: Flujo de trabajo del Patrón 1.
Ahora, para cualquier consulta dada, podemos transformarla en un embedding utilizando el mismo modelo de embeddings basado en texto que usamos antes. Después de eso, podemos realizar una búsqueda de similitud para encontrar los contextos más relevantes y luego usar los contextos basados en texto como parte del prompt para nuestros LLM basados en texto o multimodales.
Si quieres obtener más información sobre los detalles de implementación de este patrón, tenemos un artículo dedicado que te guiará por los pasos para crear un RAG multimodal con este patrón.
Este patrón sería perfecto si no necesitas acceso a los datos sin procesar y no textuales en tu caso de uso. Tu aplicación podría aceptar imágenes como entradas, pero la salida siempre está basada en texto. Por ejemplo, podrías crear una aplicación que tenga la funcionalidad de explicar el contenido de imágenes en un documento interno.
Sin embargo, seguimos dependiendo de contextos basados en texto con este patrón, igual que el sistema RAG habitual. En aplicaciones del mundo real, podríamos querer usar imágenes u otras modalidades como contextos. Por lo tanto, hablemos del segundo patrón.
Patrón 2: Insertar todas las modalidades en el mismo espacio vectorial
El segundo patrón implica transformar datos en todas las modalidades en embeddings en el mismo espacio vectorial. El secreto detrás de este enfoque es la implementación de modelos de embeddings multimodales como CLIP y ALIGN. Tomemos CLIP como ejemplo.
CLIP es un modelo desarrollado por OpenAI que toma tanto texto como imagen como un par de entradas, y ha sido entrenado para determinar la similitud entre el texto y la imagen. Como resultado, CLIP dará una puntuación de similitud alta si el texto se alinea con la imagen, y viceversa.
Figura: Embeddings de datos con diferentes modalidades con CLIP en un espacio vectorial tridimensional.
Como puedes ver arriba, digamos que tenemos una oración "Un perro sonriente" y una imagen de un perro sonriente. CLIP primero transformará tanto el texto como la imagen en embeddings con dimensiones similares, y si revisamos el espacio vectorial, ambos embeddings probablemente se ubicarán cerca uno del otro.
Dado que tenemos un modelo de embeddings multimodal, el primer paso de este patrón es transformar nuestros datos en diferentes modalidades en embeddings con este modelo de embeddings multimodal. A continuación, almacenamos e indexamos estos embeddings dentro de una base de datos vectorial como Milvus o Zilliz Cloud. Una vez que tenemos una consulta de usuario, la transformamos usando el mismo modelo de embeddings multimodal, y luego podemos realizar una búsqueda de similitud para encontrar los contextos más relevantes.
Figura: Flujo de trabajo del Patrón 2.
Los contextos recuperados al aplicar este patrón pueden ser datos con una variedad de modalidades, como imagen y texto. Por lo tanto, necesitamos usar un LLM multimodal para tener en cuenta estos contextos y generar la respuesta final. Si nuestros datos consisten en imágenes y texto, podemos usar un Vision Language Model (VLM) como LLAVA, Gemini, Claude Sonnet, Qwen-VL, Pixtral, etc.
Si quieres obtener más información sobre los detalles de implementación de este patrón, tenemos un artículo dedicado que te guiará por los pasos para crear un RAG multimodal con este patrón. Sin embargo, ten en cuenta que en ese artículo, las imágenes sin procesar no se almacenan directamente dentro de la base de datos vectorial, sino que se almacenan en la memoria local.
La principal ventaja de este patrón es su versatilidad y simplicidad. La implementación de un modelo de embeddings multimodal significa que no necesitamos un paso adicional para convertir el contenido de todas las modalidades en una modalidad principal como hicimos en el primer patrón. Además, los contextos recuperados después de la búsqueda por similitud pueden ser datos de cualquier modalidad en lugar de una sola modalidad en particular.
Sin embargo, dado que podemos usar cualquier modalidad de datos como contextos relevantes para nuestro LLM multimodal, también necesitamos almacenar los datos sin procesar al implementar este patrón. El problema es que el tamaño de memoria de los datos que no son texto, como las imágenes, es grande, y almacenarlos directamente en una base de datos vectorial puede llevar a un uso ineficiente de los recursos. Esto eventualmente también provocará tiempos de consulta más lentos y mayores costos de almacenamiento.
Por lo tanto, recomendamos usar este patrón si necesitas usar datos con diferentes modalidades como contextos, pero la escalabilidad no es una preocupación para tu caso de uso.
Patrón 3: Una recuperación híbrida con acceso a imágenes sin procesar.
Si necesitas usar datos con diversas modalidades como contextos, y la escalabilidad también es una preocupación, entonces puedes implementar este patrón. La idea principal de este patrón es la separación de responsabilidades: usamos una base de datos vectorial para realizar búsquedas por similitud rápidas y eficientes para encontrar contextos relevantes, y usamos sistemas dedicados de almacenamiento de objetos como AWS S3 o Google Cloud Storage para almacenar los datos sin procesar.
Durante la implementación de este patrón, necesitamos realizar dos pasos diferentes. Primero, almacenamos los datos sin procesar reales en un sistema dedicado de almacenamiento de objetos como AWS S3 o Google Cloud Storage. Segundo, almacenamos los metadatos de nuestros datos sin procesar dentro de la base de datos vectorial, como la URL de nuestra imagen que reside en el sistema dedicado de almacenamiento de objetos.
Figura: Flujo de trabajo del patrón 3.
Dado que usamos un sistema separado para almacenar nuestros datos sin procesar, la forma en que realizamos RAG es casi similar al primer patrón. Digamos que el texto es nuestra modalidad principal. Lo primero que tendremos que hacer es usar un LLM multimodal para generar resúmenes de texto de nuestros datos sin procesar. A continuación, podemos usar un modelo de embeddings basado en texto para transformar los resúmenes de texto en embeddings. Luego almacenamos los embeddings, así como los metadatos de nuestros datos sin procesar (URL de los datos sin procesar en el sistema de almacenamiento dedicado), en una base de datos vectorial.
Para cualquier consulta dada, usamos el mismo LLM multimodal para generar un resumen de texto y luego transformamos el resumen de la consulta en un embedding usando el mismo modelo de embeddings basado en texto. A continuación, podemos realizar una búsqueda por similitud y obtener el resumen de texto, así como la URL de los contextos relevantes. Finalmente, podemos pasar los datos sin procesar a un LLM multimodal mediante la URL recuperada.
De nuevo, puedes consultar este artículo que te guiará por los pasos para crear un RAG multimodal con este patrón. Sin embargo, ten en cuenta que en el artículo, las imágenes sin procesar no se almacenan en un sistema de almacenamiento típico listo para producción como AWS o GCP, sino en la memoria local.
De las tres opciones, este patrón es el más escalable debido a la separación del almacenamiento de datos sin procesar. Como quizá ya sepamos, las bases de datos vectoriales están optimizadas para consultar datos no estructurados, no para almacenar y servir objetos binarios grandes como imágenes. De hecho, recuperar objetos binarios desde bases de datos vectoriales suele ser más lento que recuperarlos desde un sistema dedicado de almacenamiento de objetos.
Por lo tanto, recomendamos usar este patrón si quieres utilizar datos con diversas modalidades como contextos y la escalabilidad es una gran preocupación para tu caso de uso.
Cómo la base de datos vectorial Milvus admite RAG multimodal
Como se mencionó en las secciones anteriores, las bases de datos vectoriales desempeñan un papel crucial en la aplicación de la Generación Aumentada por Recuperación (RAG). Milvus es una base de datos vectorial que sería perfecta para usar en tu sistema RAG u otras aplicaciones de IA debido a sus funciones avanzadas.
Milvus ofrece métodos de indexación que van desde los más simples hasta otros más avanzados, como IVFFLAT, HNSW y SCANN, lo que nos permite almacenar enormes colecciones de datos de manera rápida y eficiente. La implementación de estos métodos de indexación avanzados también acelera el proceso de búsqueda por similitud para encontrar contextos relevantes en una implementación de RAG.
Integración sencilla de Milvus con herramientas populares para RAG multimodal.
Milvus también ofrece una integración sencilla con todos los componentes de RAG que hemos tratado en la sección anterior, como modelos de embeddings, LLMs y herramientas de orquestación. En cuanto a los modelos de embeddings, puedes usar directamente opciones populares de OpenAI, Cohere, SentenceTransformers, HuggingFace, VoyageAI y otros con el SDK de Python de Milvus llamado pymilvus. Puedes instalar pymilvus con un simple comando pip:
pip install -U pymilvus
Ahora supongamos que quieres usar el modelo de embeddings de SentenceTransformers; puedes hacerlo fácilmente con pymilvus de la siguiente manera:
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)
Puedes obtener más información sobre los distintos tipos de modelos de embeddings compatibles con Pymilvus en esta página de integración.
En cuanto a los LLMs y las herramientas de orquestación, Milvus puede integrarse fácilmente con frameworks populares como vLLM, Ollama, Gemini, LlamaIndex y Langchain. Si te gustaría aprender más sobre la integración de Milvus y todas estas herramientas, tenemos una colección de tutoriales que puedes consultar en esta página. También tenemos un tutorial sencillo donde puedes aprender a crear un RAG multimodal simple con Milvus en esta página de documentación.
Conclusión
RAG multimodal representa un avance significativo en el uso de diversas modalidades de datos para mejorar la precisión de las respuestas de los LLM. En este artículo hemos tratado tres patrones clave para implementar RAG multimodal: fundamentar todas las modalidades en una modalidad primaria, incrustarlas en un espacio vectorial unificado o emplear recuperación híbrida con acceso a datos sin procesar. La elección de un patrón adecuado depende de las necesidades específicas de tu aplicación de IA.
Con sus métodos avanzados de indexación y su fácil integración con modelos de embeddings, LLM y herramientas de orquestación, la base de datos vectorial Milvus ofrece un sistema adecuado para implementar sistemas RAG multimodales. A medida que las aplicaciones de IA aumentan en alcance y complejidad, utilizar un sistema de base de datos vectorial escalable como Milvus se vuelve cada vez más crucial.
Sigue leyendo
Expanding Our Global Reach: Zilliz Cloud Launches in Azure Central India
Zilliz Cloud expands to Azure Central India. This new region helps customers meet compliance, reduce latency, and optimize cloud costs when building AI applications.
How to Build RAG with Milvus, QwQ-32B and Ollama
Hands-on tutorial on how to create a streamlined, powerful RAG pipeline that balances efficiency, accuracy, and scalability using the QwQ-32B and Milvus.
OpenAI o1: What Developers Need to Know
In this article, we will talk about the o1 series from a developer's perspective, exploring how these models can be implemented for sophisticated use cases.