Blog
Creación de RAG con la base de datos vectorial Milvus autodesplegada y Snowpark Container Services

Creación de RAG con la base de datos vectorial Milvus autodesplegada y Snowpark Container Services

Jun 28, 202415 min read

Jiang Chen, Head of Ecosystem & AI Platform en Zilliz, habló recientemente sobre cómo podemos integrar sin problemas Milvus con Snowflake en una charla en el Unstructured Data Meetup. Específicamente, exploró cómo construir un sistema de Retrieval Augmented Generation (RAG) con la base de datos vectorial Milvus y su integración con el ecosistema de Snowflake usando Snowpark Container Service (SPCS).

< Mira la charla de Jiang Chen en Youtube >

Esta publicación resumirá los puntos clave de Jiang y cubrirá tres temas importantes.

Primero, hablaremos sobre el uso de Milvus para la búsqueda vectorial, un paso esencial para construir un sistema RAG. A continuación, hablaremos sobre cómo integrar Milvus en Snowflake con SPCS. Finalmente, también hablaremos sobre el panorama futuro de RAG. Antes de profundizar en los temas, exploremos cómo la IA ha transformado la recuperación de información.

Cómo la IA revoluciona el proceso de recuperación de información

El avance y la popularidad de la IA han cambiado rápidamente todo el panorama de la recuperación de información. Antes del auge de la IA, la recuperación de información dependía en gran medida de modelos estadísticos y métodos de coincidencia de palabras clave como el etiquetado. Por ejemplo, el propietario de una tienda en línea tendría que introducir manualmente etiquetas para cada producto en categorías predefinidas. Si tiene un catálogo enorme de productos, este proceso no sería práctico.

Del mismo modo, como clientes, tendríamos que introducir etiquetas apropiadas para obtener el producto exacto que queremos. El problema es que, si introducimos una etiqueta que no es exacta pero tiene un significado similar al producto que queremos, la recuperación de información mediante el método de etiquetado no nos dará los productos adecuados. En otras palabras, el método de etiquetado no considera el significado semántico de una consulta.

La IA revoluciona cómo usamos los datos no estructurados La IA revoluciona cómo usamos los datos no estructurados

La aparición de los modelos de embedding ha transformado por completo la forma en que recuperamos información. La mayoría de los modelos de embedding utilizan la famosa arquitectura Transformer como su columna vertebral. El modelo Transformer aprovecha varios bloques codificador-decodificador, cada uno con una capa de atención especializada. Esta capa permite al modelo percibir el significado semántico de cada token de entrada con respecto a toda la secuencia de entrada, lo que hace que los modelos de embedding puedan inferir el significado semántico de las palabras de entrada.

Arquitectura Transformer

Arquitectura Transformer

Los modelos de embedding transformarán consultas, imágenes o descripciones de texto en sus representaciones numéricas llamadas vector embeddings. Un vector embedding contiene un significado rico en semántica de la entrada que representa, y podemos comparar la similitud entre dos vector embeddings mediante similitud coseno o distancia coseno. Si la similitud es alta, entonces dos vector embeddings tienen un significado similar, y viceversa.

Textos sin procesar a incrustaciones vectoriales.png

Textos sin procesar a incrustaciones vectoriales

Debido a estas potentes características, los modelos de incrustación hacen que implementar el concepto de recuperación de información sea mucho más fácil y flexible.

Generación Aumentada por Recuperación (RAG)

El rápido avance de los modelos de incrustación y el auge de los modelos de lenguaje grandes (LLMs) han llevado al surgimiento de RAG, un método de recuperación de información muy sofisticado. RAG está diseñado para mejorar la calidad de respuesta de un LLM al proporcionar al LLM contexto relevante de una base de conocimiento interna junto con la consulta. Luego, el LLM utilizará el contexto proporcionado para responder a la consulta.

Arquitectura RAG

En una aplicación RAG, usamos los modelos de incrustación elegidos para transformar nuestros datos y la consulta de entrada en incrustaciones. Luego, calculamos la similitud entre la incrustación de nuestra consulta y las incrustaciones de nuestros propios datos. Los datos más similares a nuestra consulta se pasarán entonces a un LLM como contexto junto con nuestra consulta. En última instancia, nuestro LLM puede generar una respuesta a la consulta basándose en el contexto proporcionado. De esta manera, podemos mejorar la precisión de respuesta de un LLM sin necesidad de ajustarlo finamente.

Integración de la base de datos vectorial Milvus y Snowflake con Snowpark Container Service

Milvus es una base de datos vectorial de código abierto que te permite almacenar una enorme cantidad de incrustaciones vectoriales útiles para aplicaciones RAG y realizar búsquedas vectoriales sobre ellas en una fracción de segundo. Hay varias opciones para instalar y usar Milvus:

Milvus Lite: Una versión ligera de Milvus que es adecuada para la creación rápida de prototipos. Milvus Lite no requiere un servidor; puedes ejecutarlo en tu propio dispositivo. El proceso de instalación es tan simple como usar un comando pip install.

!pip install "pymilvus>=2.4.2"
from pymilvus import MilvusClient
client = MilvusClient("milvus_demo.db")

Milvus en Docker: Si quieres usar tu base de datos vectorial Milvus en producción y solo tienes una pequeña cantidad de datos, puedes ejecutarla como un contenedor Docker. El proceso también es sencillo, ya que solo necesitas ejecutar estos comandos en tu línea de comandos:

# Download the installation script
$ curl -sfL <https://raw.githubusercontent.com/milvus-io/milvus/master/scripts/standalone_embed.sh> -o standalone_embed.sh

# Start the Docker container
$ bash standalone_embed.sh start

# In your Python IDE
from pymilvus import MilvusClient

client = MilvusClient(
uri="<http://milvus:19530>",
)

Milvus en Kubernetes: Esta opción es adecuada si tienes cantidades masivas de datos o tus aplicaciones RAG tienen una cantidad masiva de usuarios. Puedes almacenar hasta 100 mil millones de vectores con Kubernetes. El proceso de instalación con Kubernetes es un poco más complicado que el de Milvus Lite y Docker. Por lo tanto, consulta la documentación de instalación para obtener información detallada.

Milvus ofrece una integración fluida con kits de herramientas de IA populares como OpenAI, HuggingFace, Cohere, LangChain, LlamaIndex y Snowflake. Estas integraciones facilitan la creación de tus propios sistemas RAG u otras aplicaciones GenAI. Esta sección te mostrará cómo ejecutar Milvus dentro del ecosistema de Snowflake.

Milvus ofrece una integración fluida con todos los kits de herramientas de IA populares

Milvus ofrece una integración fluida con todos los kits de herramientas de IA populares

Snowflake es una plataforma de almacenamiento de datos que te permite almacenar, procesar y analizar datos de manera eficiente y fiable. Con la introducción de Snowpark Container Service (SPCS), ahora puedes ejecutar aplicaciones en contenedores dentro del entorno de Snowflake. De este modo, tu aplicación puede interactuar con los datos almacenados dentro de Snowflake, lo que te permite crear una amplia gama de aplicaciones, incluido un sistema RAG.

En esta sección, primero crearemos una aplicación con Milvus que realiza una búsqueda vectorial. A continuación, contenerizaremos la aplicación usando Docker y ejecutaremos el contenedor dentro de Snowflake con SPCS.

Para empezar, creemos una aplicación de Milvus para realizar una búsqueda vectorial con Jupyter Notebook. Si quieres seguir el proceso, consulta este repositorio para ver el notebook completo y el script para crear el modelo de embeddings.

from pymilvus import MilvusClient
from pymilvus import DataType
import os
import mode

# init client
client = MilvusClient(
uri="<http://milvus:19530>",
)

# init model
model = model.Onnx()

# Create a collection in quick setup mode
client.create_collection(
collection_name="quick_demo",
dimension=model.dimension,
)

print("Collection Created!")

En el código anterior, creamos una colección llamada “quick_demo” dentro de una base de datos vectorial Milvus y cargamos el modelo para transformar textos en embeddings. Usaremos ALBERT como nuestro modelo de embeddings, que mapea un texto de entrada a un embedding vectorial de 768 dimensiones.

A continuación, inserta algunos datos de texto en nuestra colección “quick_demo”.

# Data from which embeddings are to be generated
docs=[
"Artificial intelligence was founded as an academic discipline in 1956.",
"Alan Turing was the first person to conduct substantial research in AI.",
"Born in Maida Vale, London, Turing was raised in southern England.",
]

# Insert data into the collection
data=[]
for i in range(len(docs)):
data.append({
'id': i,
'vector': model.to_embeddings(docs[i]),
'doc_str': docs[i]
})

res = client.insert(
collection_name="quick_demo",
data=data
)

En el código anterior, transformamos nuestros textos de entrada en embeddings con ALBERT y los almacenamos dentro de la colección con sus IDs y textos sin procesar.

Ahora, si tenemos una consulta como “¿Quién inició la investigación en IA?” y queremos obtener el contexto relevante que podría contener la respuesta relevante a nuestra consulta, podemos realizar una búsqueda vectorial fácilmente con Milvus de la siguiente manera:

# Search with a text query
query = "Who started AI research?"
query_embeddings = model.to_embeddings(query)

res = client.search(
collection_name="quick_demo",
data=[query_embeddings],
limit=1,
output_fields=["doc_str"],
)

print(res)
"""
Expected output:
"Alan Turing was the first person to conduct substantial research in AI."
"""

Y eso es todo para nuestra aplicación de Milvus.

En esta etapa, tenemos un Jupyter Notebook para realizar una búsqueda vectorial con Milvus. Supongamos que queremos contenerizar este notebook para ejecutarlo dentro del ecosistema de Snowflake. Lo primero que debemos hacer es configurar el rol y los privilegios para crear y ejecutar el servicio proporcionado por Snowflake.

Primero, descarga SnowSQL siguiendo las instrucciones en la página de documentación de instalación de SnowSQL. A continuación, ejecuta el siguiente comando en la terminal:

snowsql -a ${instance_name} -u ${user_name}

donde el formato de ${instance_name} es ${org_name}-${acct_name}, y puedes encontrar información sobre estos dos campos dentro de tu cuenta de Snowflake. Ahora podemos configurar el rol y los privilegios con los siguientes comandos dentro del shell de SnowSQL:

USE ROLE ACCOUNTADMIN;
CREATE SECURITY INTEGRATION SNOWSERVICES_INGRESS_OAUTH
  TYPE=oauth
  OAUTH_CLIENT=snowservices_ingress
  ENABLED=true;
  
USE ROLE ACCOUNTADMIN;
GRANT BIND SERVICE ENDPOINT ON ACCOUNT TO ROLE SYSADMIN;

USE ROLE SECURITYADMIN;
CREATE ROLE MILVUS_ROLE;

USE ROLE USERADMIN;
CREATE USER milvus_user
  PASSWORD='milvususerok'
  DEFAULT_ROLE = MILVUS_ROLE
  DEFAULT_SECONDARY_ROLES = ('ALL')
  MUST_CHANGE_PASSWORD = FALSE;
  
USE ROLE SECURITYADMIN;
GRANT ROLE MILVUS_ROLE TO USER milvus_user;

Dado que Snowflake es una plataforma de almacenamiento de datos, interactuamos con todos los objetos dentro de Snowflake mediante un comando similar a una consulta SQL, como puedes ver arriba. A continuación, podemos crear el almacén de datos y la base de datos dentro de Snowflake con los siguientes comandos:

USE ROLE SYSADMIN;
CREATE OR REPLACE WAREHOUSE MILVUS_WAREHOUSE WITH
WAREHOUSE_SIZE='X-SMALL'
AUTO_SUSPEND = 180
AUTO_RESUME = true
INITIALLY_SUSPENDED=false;

USE ROLE SYSADMIN;
CREATE DATABASE IF NOT EXISTS MILVUS_DEMO;
USE DATABASE MILVUS_DEMO;
CREATE IMAGE REPOSITORY MILVUS_DEMO.PUBLIC.MILVUS_REPO;
CREATE OR REPLACE STAGE YAML_STAGE;
CREATE OR REPLACE STAGE DATA ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');
CREATE OR REPLACE STAGE FILES ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');

--GRANT ROLE PRIVILEGES--

USE ROLE SECURITYADMIN;
GRANT ALL PRIVILEGES ON DATABASE MILVUS_DEMO TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON SCHEMA MILVUS_DEMO.PUBLIC TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON WAREHOUSE MILVUS_WAREHOUSE TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON STAGE MILVUS_DEMO.PUBLIC.FILES TO MILVUS_ROLE;

--CONFIGURE ACL--

USE ROLE ACCOUNTADMIN;
USE DATABASE MILVUS_DEMO;
USE SCHEMA PUBLIC;
CREATE NETWORK RULE allow_all_rule
TYPE = 'HOST_PORT'
MODE= 'EGRESS'
VALUE_LIST = ('0.0.0.0:443','0.0.0.0:80');

CREATE EXTERNAL ACCESS INTEGRATION allow_all_eai
ALLOWED_NETWORK_RULES=(allow_all_rule)
ENABLED=TRUE;

GRANT USAGE ON INTEGRATION allow_all_eai TO ROLE SYSADMIN;

Para ejecutar una aplicación en contenedor dentro de Snowflake, necesitamos crear la imagen de Docker de nuestra aplicación en nuestra máquina local. En este proyecto, necesitamos crear dos imágenes de Docker diferentes: una para instanciar la base de datos vectorial Milvus y otra para ejecutar el archivo de notebook que creamos anteriormente.

Sin embargo, necesitamos un Dockerfile para crear una imagen de Docker. Para facilitar las cosas, clona el siguiente repositorio. Encontrarás todos los archivos necesarios para crear las dos imágenes que necesitamos en este repositorio. Después de clonar el repositorio, puedes crear las dos imágenes de Docker con los siguientes comandos en tu terminal local:

cd ${repo_git_root_path}
docker build --rm --no-cache --platform linux/amd64 -t milvus ./images/milvus
docker build --rm --no-cache --platform linux/amd64 -t jupyter ./images/jupyter

Luego, podemos agregar etiquetas apropiadas a las dos imágenes recién creadas con los siguientes comandos:

docker login ${instance_name}.registry.snowflakecomputing.com -u ${user_name}

docker tag milvus ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/milvus
docker tag jupyter ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/jupyter

Finalmente, podemos subir las imágenes a SPCS con los siguientes comandos:

docker push ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/milvus
docker push ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/jupyter

Ahora que hemos enviado las imágenes a SPCS, lo único que tenemos que hacer es crear dos servicios de cómputo, uno para cada imagen, como puedes ver en los siguientes comandos dentro de la shell de SnowSQL:

USE ROLE SYSADMIN;
CREATE COMPUTE POOL IF NOT EXISTS MILVUS_COMPUTE_POOL
  MIN_NODES = 1
  MAX_NODES = 1
  INSTANCE_FAMILY = CPU_X64_S
  AUTO_RESUME = true;
CREATE COMPUTE POOL IF NOT EXISTS JUPYTER_COMPUTE_POOL
  MIN_NODES = 1
  MAX_NODES = 1
  INSTANCE_FAMILY = CPU_X64_S
  AUTO_RESUME = true;

Dentro del repo que clonamos antes hay una carpeta llamada “specs.” Dentro de esa carpeta hay dos archivos YAML, uno para cada imagen. Abre cada archivo YAML y cambia ${org_name}-${acct_name} en el campo image según tu propia cuenta de Snowflake.

A continuación, usando SnowSQL, sube los archivos YAML modificados con los siguientes comandos:

PUT file://${path/to/jupyter.yaml} @yaml_stage overwrite=true auto_compress=false;
PUT file://${path/to/milvus.yaml} @yaml_stage overwrite=true auto_compress=false;

Y finalmente, podemos crear los servicios para ambas imágenes de la siguiente manera:

USE ROLE SYSADMIN;
USE DATABASE MILVUS_DEMO;
USE SCHEMA PUBLIC;

CREATE SERVICE MILVUS
  IN COMPUTE POOL MILVUS_COMPUTE_POOL 
  FROM @YAML_STAGE
  SPEC='milvus.yaml'
  MIN_INSTANCES=1
  MAX_INSTANCES=1;

CREATE SERVICE JUPYTER
  IN COMPUTE POOL JUPYTER_COMPUTE_POOL 
  FROM @YAML_STAGE
  SPEC='jupyter.yaml'
  MIN_INSTANCES=1
  MAX_INSTANCES=1;

Ahora, si escribes el comando SHOW SERVICE, deberías ver la siguiente salida:

SHOW SERVICES;

+---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
| name    | database_name | schema_name | owner    | compute_pool         | dns_name                                               | ......
|---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
| JUPYTER | MILVUS_DEMO   | PUBLIC      | SYSADMIN | JUPYTER_COMPUTE_POOL | jupyter.public.milvus-demo.snowflakecomputing.internal | ...... 
| MILVUS  | MILVUS_DEMO   | PUBLIC      | SYSADMIN | MILVUS_COMPUTE_POOL  | milvus.public.milvus-demo.snowflakecomputing.internal  | ......
+---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------

Ahora estamos listos para ejecutar la base de datos vectorial Milvus y probar nuestro notebook dentro de Snowflake. Primero, concede permiso al rol que creamos antes para acceder a la aplicación en contenedor.

USE ROLE SECURITYADMIN;
GRANT USAGE ON SERVICE MILVUS_DEMO.PUBLIC.JUPYTER TO ROLE MILVUS_ROLE;

A continuación, comprueba el endpoint de nuestro contenedor de notebook dentro de Snowflake con el siguiente comando:

USE ROLE SYSADMIN;
SHOW ENDPOINTS IN SERVICE MILVUS_DEMO.PUBLIC.JUPYTER;

Endpoint de Jupyter, como se muestra en ingress_url

Endpoint de Jupyter, como se muestra en ingress_url

Si todo se ejecuta sin problemas, puedes ver una columna llamada “ingress_url” como salida. Abre tu navegador, copia y pega esa “ingress_url,” y deberías ver cómo se inicia Jupyter. Luego puedes abrir el archivo de notebook dentro del contenedor y ejecutar cada celda del notebook normalmente.

El panorama futuro de RAG

RAG es una técnica muy popular hoy en día. Sin embargo, su aplicación actual está lejos de ser perfecta. Según Jiang Chen, aquí hay varias predicciones sobre el uso futuro y la mejora de las aplicaciones RAG.

Evaluación continua y observabilidad

Crear RAG se ha vuelto más fácil con la disponibilidad de diversas plataformas o bibliotecas que simplifican y abstraen el proceso de desarrollo de RAG. Por ejemplo, podemos crear un prototipo de RAG en minutos con la ayuda de tres plataformas diferentes: Milvus, LangChain y OpenAI.

Sin embargo, a menudo nos enfrentamos a desafíos al pasar una aplicación impulsada por RAG de prototipo a producción. En producción, nuestros sistemas RAG necesitan manejar millones o incluso miles de millones de documentos, lo que hace que sea crucial supervisar continuamente la calidad de las respuestas generadas por nuestro LLM

Evaluación continua del sistema RAG

Antes de implementar mejoras para aumentar la calidad de nuestro RAG, es importante establecer un enfoque sistemático para evaluarlo y mejorarlo continuamente.

Algunos elementos clave de este enfoque sistemático incluyen:

Construir una infraestructura dedicada a la mejora: En esta infraestructura, podemos implementar varios métodos para mejorar la calidad de RAG y luego comparar sus respuestas mediante pruebas A/B.
Planificar un ciclo de lanzamiento: Una vez que encontremos un enfoque que mejore la calidad de RAG según nuestro caso de uso, necesitamos planificar cómo lanzarlo e integrarlo en nuestro sistema para reemplazar el anterior sin interrumpir la experiencia del usuario.
Implementar un sistema de observabilidad: También necesitamos construir un sistema para observar el rendimiento de nuestro RAG en producción y determinar su eficacia. Si el rendimiento no es satisfactorio, podemos explorar e implementar mejoras a través de la infraestructura dedicada a la mejora.

Hasta ahora, hemos utilizado principalmente RAG en procesamiento del lenguaje natural. Esto significa que usamos texto como prompt o consulta, y las respuestas de nuestro LLM también están en forma de texto.

Sin embargo, el panorama de RAG podría cambiar en el futuro con la introducción de RAG multi-modal. RAG multi-modal es posible debido al auge de los modelos de embedding multi-modales en los últimos años. En los últimos años, la investigación ha concluido que los Transformers pueden procesar el lenguaje natural como entradas y otras modalidades, como imágenes y sonidos.

Los modelos Vision Transformers (ViT) y DETR han demostrado que los Transformers pueden usarse como potentes modelos de clasificación de imágenes y detección de objetos. Basándose en ViT, OpenAI presentó un modelo multi-modal llamado CLIP, que puede calcular la similitud entre dos entradas de diferentes modalidades: texto e imagen.

Las capacidades multimodales mostradas por estos modelos basados en Transformer pueden servir como base para futuras aplicaciones RAG multimodales. En este sistema, podemos usar una combinación de texto e imagen como consulta, y el LLM generará una imagen basada en nuestras consultas multimodales.

Como ejemplo, digamos que queremos que nuestro LLM genere una imagen que se parezca mucho a una imagen de consulta proporcionada. Podemos enriquecer nuestra imagen de consulta con una descripción de texto para afinar aún más el tipo de imágenes que queremos que genere nuestro LLM, como puedes ver en la visualización a continuación:

Aplicación RAG multi-modal, combinación de consultas de texto e imagen

En la visualización anterior, pedimos a nuestros modelos de embedding que devolvieran imágenes que se parecieran a la imagen de la parte superior izquierda, y añadimos un prompt de texto, como "una imagen de una montaña durante la hora dorada," junto a la imagen superior izquierda. Los resultados son las otras tres imágenes generadas en función de la consulta multi-modal.

Este enfoque multi-modal de RAG abre nuevas posibilidades para una recuperación y generación de información más intuitiva y expresiva, combinando las fortalezas de las modalidades de texto y visual.

Un buen RAG proviene de buenos datos

La calidad de nuestro sistema RAG depende en gran medida de la calidad de los datos que tenemos en nuestra base de datos. Por lo tanto, cuando la respuesta generada por nuestro RAG no es óptima, no debemos apresurarnos a concluir que el modelo necesita mejorarse. Primero, siempre debemos comprobar la calidad de nuestros datos.

Como quizá ya sepas, la calidad de respuesta de RAG depende de los contextos pasados junto con la consulta. Si nuestro LLM no puede encontrar respuestas adecuadas a la consulta a partir de los contextos proporcionados, entonces no es sorprendente que la calidad de la respuesta generada por nuestro sistema RAG sea deficiente.

Por lo tanto, antes de optar por mejorar los modelos de embedding y el LLM en nuestro sistema RAG, siempre debemos hacernos las siguientes preguntas:

¿Tenemos los datos correctos en nuestra base de datos?
¿Hemos recopilado todos los datos disponibles de las fuentes de datos en nuestra base de datos?
¿Hemos implementado el proceso adecuado de limpieza de datos antes de pasar los datos a los modelos de embedding?
¿Hemos implementado el enfoque de chunking adecuado para nuestros datos?
¿Hemos implementado los métodos correctos de preprocesamiento de datos (por ejemplo, análisis de PDF, análisis OCR) para nuestros datos?

Abordar los problemas relacionados con los datos es un primer paso crucial para optimizar el rendimiento de una aplicación impulsada por RAG. Solo después de verificar la calidad de los datos deberíamos considerar refinar los modelos de embedding, el LLM u otros componentes del sistema RAG.

Agentes: enrutamiento de consultas con subconsultas

Actualmente, un sistema RAG común recupera contextos relevantes para una consulta determinada a partir de textos y embeddings guardados dentro de una base de datos interna. Sin embargo, este enfoque podría evolucionar, ya que el contexto podría recuperarse de bases de datos internas y fuentes externas, como búsquedas web.

Visualización de agentes para el enrutamiento de consultas

La investigación en esta área aún está en curso, pero añadir un llamado "agente" dentro de un sistema RAG podría ayudar a determinar la fuente de contexto apropiada para una consulta determinada.

Por ejemplo, dada una consulta como "¿Quién inició la investigación en IA?", el agente puede decidir si RAG es necesario o no para responder a esa pregunta. Si no lo es, el sistema puede permitir que el LLM genere directamente una respuesta a la consulta sin ningún contexto adicional.

Si se considera que RAG es necesario, el agente debe determinar la fuente del contexto, ya sea una base de datos interna o una fuente externa. Otro enfoque es que el agente agregue información de varias fuentes en un único contexto resumido que pueda ser utilizado por el LLM para generar una respuesta adecuada.

Conclusión

El potente rendimiento de los LLM al generar respuestas de texto similares a las humanas ha cambiado todo el panorama de la recuperación de información. La introducción de RAG está diseñada para mejorar la precisión de las respuestas de los LLM proporcionándoles contextos relevantes para una consulta determinada. Estos contextos suelen almacenarse como embeddings, que deben guardarse en una base de datos vectorial como Milvus.

Como base de datos vectorial de código abierto con capacidades avanzadas de búsqueda vectorial, Milvus ofrece una integración fluida con toolkits de IA populares, como Snowflake. Con Snowpark Container Service (SPCS) de Snowflake, los usuarios ahora pueden ejecutar Milvus dentro del ecosistema de Snowflake, lo que les permite interactuar fácilmente con Milvus utilizando datos almacenados en Snowflake.

Actualizado el Jul 13, 2026

Ruben Winastwan

Sigue leyendo

Zilliz Cloud BYOC Now Available Across AWS, GCP, and Azure

Zilliz Cloud BYOC is now generally available on all three major clouds. Deploy fully managed vector search in your own AWS, GCP, or Azure account — your data never leaves your VPC.

Smarter Autoscaling in Zilliz Cloud: Always Optimized for Every Workload

With the latest upgrade, Zilliz Cloud introduces smarter autoscaling—a fully automated, more streamlined, elastic resource management system.

DeepSeek Always Busy? Deploy It Locally with Milvus in Just 10 Minutes—No More Waiting!

Learn how to set up DeepSeek-R1 on your local machine using Ollama, AnythingLLM, and Milvus in just 10 minutes. Bypass busy servers and enhance AI responses with custom data.