Blog
Criando RAG com o banco de dados vetorial Milvus autoimplantado e Snowpark Container Services

Criando RAG com o banco de dados vetorial Milvus autoimplantado e Snowpark Container Services

Jun 28, 202415 min read

Jiang Chen, Head de Ecossistema & Plataforma de IA na Zilliz, discutiu recentemente como podemos integrar perfeitamente o Milvus ao Snowflake em uma palestra no Unstructured Data Meetup. Especificamente, ele explorou como construir um sistema de Retrieval Augmented Generation (RAG) com o banco de dados vetorial Milvus e sua integração com o ecossistema Snowflake usando o Snowpark Container Service (SPCS).

< Assista à palestra de Jiang Chen no Youtube >

Esta publicação recapitulará os principais pontos de Jiang e abordará três tópicos importantes.

Primeiro, discutiremos a utilização do Milvus para busca vetorial, uma etapa essencial para construir um sistema RAG. Em seguida, discutiremos como integrar o Milvus ao Snowflake com o SPCS. Por fim, também discutiremos o cenário futuro do RAG. Antes de nos aprofundarmos nos tópicos, vamos explorar como a IA transformou a recuperação de informações.

Como a IA revoluciona o processo de recuperação de informações

O avanço e a popularidade da IA mudaram rapidamente todo o cenário da recuperação de informações. Antes da ascensão da IA, a recuperação de informações dependia fortemente de modelos estatísticos e métodos de correspondência por palavras-chave, como a marcação. Por exemplo, o proprietário de uma loja online precisaria inserir manualmente tags para cada produto em categorias predefinidas. Se ele tiver um catálogo enorme de produtos, esse processo não seria prático.

Da mesma forma, como clientes, precisaríamos inserir tags apropriadas para obter o produto exato que queremos. O problema é que, se inserirmos uma tag que não seja exata, mas tenha um significado semelhante ao do produto que queremos, a recuperação de informações pelo método de marcação deixará de nos fornecer os produtos apropriados. Em outras palavras, o método de marcação não considera o significado semântico de uma consulta.

A IA revoluciona como usamos dados não estruturados A IA revoluciona como usamos dados não estruturados

O surgimento dos modelos de embedding transformou completamente a forma como recuperamos informações. A maioria dos modelos de embedding usa a famosa arquitetura Transformer como sua base. O modelo Transformer aproveita vários blocos codificador-decodificador, cada um contendo uma camada de atenção especializada. Essa camada permite que o modelo perceba o significado semântico de cada token de entrada em relação a toda a sequência de entrada, tornando os modelos de embedding capazes de inferir o significado semântico das palavras de entrada.

Arquitetura Transformer

Arquitetura Transformer

Os modelos de embedding transformarão consultas, imagens ou descrições de texto em suas representações numéricas chamadas embeddings vetoriais. Um embedding vetorial carrega um significado semanticamente rico da entrada que representa, e podemos comparar a similaridade entre dois embeddings vetoriais por meio da similaridade de cosseno ou distância de cosseno. Se a similaridade for alta, então dois embeddings vetoriais têm significado semelhante, e vice-versa.

Textos brutos para embeddings vetoriais.png

Textos brutos para embeddings vetoriais

Devido a essas características poderosas, os modelos de embedding tornam a implementação do conceito de recuperação de informações muito mais fácil e flexível.

Geração Aumentada por Recuperação (RAG)

O rápido avanço dos modelos de embedding e a ascensão dos grandes modelos de linguagem (LLMs) levaram ao surgimento da RAG, um método de recuperação de informações muito sofisticado. A RAG foi projetada para melhorar a qualidade da resposta de um LLM fornecendo ao LLM contexto relevante de uma base de conhecimento interna junto com a consulta. O LLM então usará o contexto fornecido para responder à consulta.

Arquitetura RAG

Em uma aplicação RAG, usamos os modelos de embedding escolhidos para transformar nossos dados e a consulta de entrada em embeddings. Em seguida, calculamos a similaridade entre o embedding da nossa consulta e os embeddings dos nossos próprios dados. Os dados mais semelhantes à nossa consulta serão então passados para um LLM como contexto junto com a nossa consulta. Por fim, nosso LLM pode gerar uma resposta à consulta com base no contexto fornecido. Dessa forma, podemos melhorar a precisão da resposta de um LLM sem a necessidade de fazer seu ajuste fino.

Integração do Banco de Dados Vetorial Milvus e do Snowflake com o Snowpark Container Service

Milvus é um banco de dados vetorial de código aberto que permite armazenar uma enorme quantidade de embeddings vetoriais úteis para aplicações RAG e realizar buscas vetoriais neles em uma fração de segundo. Há várias opções para instalar e usar o Milvus:

Milvus Lite: Uma versão leve do Milvus adequada para prototipagem rápida. O Milvus Lite não requer um servidor; você pode executá-lo no seu próprio dispositivo. O processo de instalação é tão simples quanto usar um comando pip install.

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

Milvus no Docker: Se você quiser usar seu banco de dados vetorial Milvus em produção e tiver apenas uma pequena quantidade de dados, poderá executá-lo como um contêiner Docker. O processo também é simples, pois você só precisa executar estes comandos na sua linha de comando:

# 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 no Kubernetes: Esta opção é adequada se você tiver enormes quantidades de dados ou se suas aplicações RAG tiverem um número enorme de usuários. Você pode armazenar até 100 bilhões de vetores com Kubernetes. O processo de instalação com Kubernetes é um pouco mais complicado do que o do Milvus Lite e do Docker. Portanto, consulte a documentação de instalação para obter informações detalhadas.

Milvus oferece integração perfeita com kits de ferramentas de IA populares, como OpenAI, HuggingFace, Cohere, LangChain, LlamaIndex e Snowflake. Essas integrações facilitam a criação dos seus próprios sistemas RAG ou outras aplicações GenAI. Esta seção mostrará como executar o Milvus dentro do ecossistema Snowflake.

Milvus oferece integração perfeita com todos os kits de ferramentas de IA populares

Milvus oferece integração perfeita com todos os kits de ferramentas de IA populares

Snowflake é uma plataforma de data warehousing que permite armazenar, processar e analisar dados de forma eficiente e confiável. Com a introdução do Snowpark Container Service (SPCS), agora você pode executar aplicações em contêiner dentro do ambiente Snowflake. Dessa forma, sua aplicação pode interagir com os dados armazenados dentro do Snowflake, permitindo que você crie uma ampla variedade de aplicações, incluindo um sistema RAG.

Nesta seção, primeiro criaremos uma aplicação com o Milvus que realiza uma busca vetorial. Em seguida, colocaremos a aplicação em um contêiner usando Docker e executaremos o contêiner dentro do Snowflake com SPCS.

Para começar, vamos criar uma aplicação Milvus para realizar uma busca vetorial com o Jupyter Notebook. Se quiser acompanhar, consulte este repositório para o notebook completo e o script para criar o modelo de embedding.

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!")

No código acima, criamos uma coleção chamada “quick_demo” dentro de um banco de dados vetorial Milvus e carregamos o modelo para transformar textos em embeddings. Usaremos ALBERT como nosso modelo de embedding, que mapeia um texto de entrada para um embedding vetorial de 768 dimensões.

Em seguida, insira alguns dados de texto em nossa coleção “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
)

No código acima, transformamos nossos textos de entrada em embeddings com ALBERT e os armazenamos dentro da coleção com seus IDs e textos brutos.

Agora, se tivermos uma consulta como “Quem iniciou a pesquisa em IA?” e quisermos obter o contexto relevante que possa conter a resposta relevante para nossa consulta, podemos realizar uma busca vetorial facilmente com o Milvus da seguinte forma:

# 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."
"""

E é isso para nossa aplicação Milvus.

Nesta etapa, temos um Jupyter Notebook para realizar uma busca vetorial com o Milvus. Digamos que queiramos colocar este notebook em um contêiner para executá-lo dentro do ecossistema Snowflake. A primeira coisa que precisamos fazer é configurar a função e os privilégios para criar e executar o serviço fornecido pelo Snowflake.

Primeiro, baixe o SnowSQL seguindo as instruções na página de documentação Installing SnowSQL. Em seguida, execute o seguinte comando no terminal:

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

onde o formato de ${instance_name} é ${org_name}-${acct_name}, e você pode encontrar informações sobre esses dois campos dentro da sua conta Snowflake. Agora podemos configurar a função e os privilégios com os seguintes comandos dentro do shell do 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;

Como o Snowflake é uma plataforma de data warehousing, interagimos com todos os objetos dentro do Snowflake por meio de um comando semelhante a uma consulta SQL, como você pode ver acima. Em seguida, podemos criar o data warehouse e o banco de dados dentro do Snowflake com os seguintes 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 executar um aplicativo conteinerizado dentro do Snowflake, precisamos criar a imagem Docker do nosso aplicativo em nossa máquina local. Neste projeto, precisamos criar duas imagens Docker diferentes: uma para instanciar o banco de dados vetorial Milvus e outra para executar o arquivo de notebook que criamos acima.

No entanto, precisamos de um Dockerfile para criar uma imagem Docker. Para facilitar, clone o seguinte repositório. Você encontrará todos os arquivos necessários para criar as duas imagens de que precisamos neste repositório. Depois de clonar o repositório, você pode criar as duas imagens Docker com os seguintes comandos no seu 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

Então, podemos adicionar tags apropriadas às duas imagens recém-criadas com os seguintes 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 enviar as imagens para o SPCS com os seguintes 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

Agora que enviamos as imagens para o SPCS, a única coisa que precisamos fazer é criar dois serviços de computação, um para cada imagem, como você pode ver nos seguintes comandos dentro do shell do 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 do repo que clonamos antes, há uma pasta chamada “specs.” Dentro dessa pasta, há dois arquivos YAML, um para cada imagem. Abra cada arquivo YAML e altere ${org_name}-${acct_name} no campo image de acordo com a sua própria conta Snowflake.

Em seguida, usando o SnowSQL, faça upload dos arquivos YAML modificados com os seguintes 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;

E finalmente, podemos criar os serviços para ambas as imagens da seguinte forma:

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;

Agora, se você digitar o comando SHOW SERVICE, deverá ver a seguinte saída:

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  | ......
+---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------

Agora, estamos prontos para executar o banco de dados vetorial Milvus e testar nosso notebook dentro do Snowflake. Primeiro, conceda permissão ao role que criamos antes para acessar a aplicação conteinerizada.

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

Em seguida, verifique o endpoint do nosso contêiner de notebook dentro do Snowflake com o seguinte comando:

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

Endpoint do Jupyter, conforme mostrado em ingress_url

Endpoint do Jupyter, conforme mostrado em ingress_url

Se tudo correr bem, você poderá ver uma coluna chamada “ingress_url” como saída. Abra seu navegador, copie e cole esse “ingress_url,” e você deverá ver um Jupyter iniciando. Então, você pode abrir o arquivo do notebook dentro do contêiner e executar cada célula do notebook normalmente.

O Cenário Futuro do RAG

RAG é uma técnica altamente popular hoje em dia. No entanto, sua aplicação atual está longe de ser perfeita. De acordo com Jiang Chen, aqui estão várias previsões sobre o uso futuro e a melhoria das aplicações RAG.

Avaliação Contínua e Observabilidade

Criar RAG ficou mais fácil com a disponibilidade de várias plataformas ou bibliotecas que simplificam e abstraem o processo de desenvolvimento de RAG. Por exemplo, podemos criar um protótipo de RAG em minutos com a ajuda de três plataformas diferentes: Milvus, LangChain e OpenAI.

No entanto, frequentemente enfrentamos desafios ao levar uma aplicação baseada em RAG do protótipo para a produção. Em produção, nossos sistemas RAG precisam lidar com milhões ou até bilhões de documentos, tornando crucial monitorar continuamente a qualidade das respostas geradas pelo nosso LLM

Avaliação contínua do sistema RAG

Antes de implementar melhorias para aumentar a qualidade do nosso RAG, é importante estabelecer uma abordagem sistemática para avaliá-lo e melhorá-lo continuamente.

Alguns elementos-chave dessa abordagem sistemática incluem:

Construir uma infraestrutura dedicada de melhoria: Nessa infraestrutura, podemos implementar vários métodos para melhorar a qualidade do RAG e, em seguida, comparar suas respostas por meio de testes A/B.
Planejar um ciclo de lançamento: Depois de encontrarmos uma abordagem que melhore a qualidade do RAG de acordo com nosso caso de uso, precisamos planejar como lançá-la e integrá-la ao nosso sistema para substituir a antiga sem interromper a experiência do usuário.
Implementar um sistema de observabilidade: Também precisamos criar um sistema para observar o desempenho do nosso RAG em produção e determinar sua eficácia. Se o desempenho for insatisfatório, podemos explorar e implementar melhorias por meio da infraestrutura dedicada de melhoria.

RAG multimodal

Até agora, utilizamos principalmente RAG em processamento de linguagem natural. Isso significa que usamos texto como prompt ou consulta, e as respostas do nosso LLM também são em forma de texto.

No entanto, o cenário do RAG pode mudar no futuro com a introdução do RAG multimodal. O RAG multimodal é possível devido ao surgimento de modelos de embedding multimodais nos últimos anos. Nos últimos anos, pesquisas concluíram que Transformers podem processar linguagem natural como entradas e outras modalidades, como imagens e sons.

Os modelos Vision Transformers (ViT) e DETR demonstraram que Transformers podem ser usados como poderosos modelos de classificação de imagens e detecção de objetos. Com base no ViT, a OpenAI introduziu um modelo multimodal chamado CLIP, que pode calcular a similaridade entre duas entradas de diferentes modalidades: texto e imagem.

As capacidades multimodais demonstradas por esses modelos baseados em Transformer podem servir como base para futuras aplicações RAG multimodais. Nesse sistema, podemos usar uma combinação de texto e imagem como consulta, e o LLM gerará uma imagem com base em nossas consultas multimodais.

Como exemplo, digamos que queremos que nosso LLM gere uma imagem que se assemelhe muito a uma imagem de consulta fornecida. Podemos enriquecer nossa imagem de consulta com uma descrição de texto para ajustar ainda mais o tipo de imagens que queremos que nosso LLM gere, como você pode ver na visualização abaixo:

Aplicação RAG multimodal, combinação de consultas de texto e imagem

Na visualização acima, pedimos aos nossos modelos de embedding que retornassem imagens semelhantes à imagem no canto superior esquerdo, e adicionamos um prompt de texto, como "uma imagem de uma montanha durante a hora dourada,", junto à imagem no canto superior esquerdo. Os resultados são as outras três imagens geradas com base na consulta multimodal.

Essa abordagem multimodal para RAG abre novas possibilidades para recuperação e geração de informações mais intuitivas e expressivas, combinando os pontos fortes das modalidades de texto e visual.

Um bom RAG vem de bons dados

A qualidade do nosso sistema RAG depende fortemente da qualidade dos dados que temos em nosso banco de dados. Portanto, quando a resposta gerada pelo nosso RAG não é ideal, não devemos nos apressar em concluir que o modelo precisa ser aprimorado. Primeiro, precisamos sempre verificar a qualidade dos nossos dados.

Como você talvez já saiba, a qualidade da resposta do RAG depende dos contextos passados junto com a consulta. Se o nosso LLM não consegue encontrar respostas apropriadas para a consulta a partir dos contextos fornecidos, então não é surpreendente que a qualidade da resposta gerada pelo nosso sistema RAG seja ruim.

Portanto, antes de optar por aprimorar os modelos de embedding e o LLM em nosso sistema RAG, devemos sempre fazer as seguintes perguntas:

Temos os dados certos em nosso banco de dados?
Coletamos todos os dados disponíveis das fontes de dados para o nosso banco de dados?
Implementamos o processo correto de limpeza de dados antes de passar os dados para os modelos de embedding?
Implementamos a abordagem apropriada de chunking aos nossos dados?
Implementamos os métodos corretos de pré-processamento de dados (por exemplo, análise de PDF, análise de OCR) aos nossos dados?

Abordar questões relacionadas aos dados é um primeiro passo crucial para otimizar o desempenho de uma aplicação baseada em RAG. Somente depois de verificar a qualidade dos dados devemos considerar refinar os modelos de embedding, o LLM ou outros componentes do sistema RAG.

Agentes: Roteamento de consultas com subconsultas

Atualmente, um sistema RAG comum recupera contextos relevantes para uma determinada consulta a partir de textos e embeddings salvos dentro de um banco de dados interno. No entanto, essa abordagem pode evoluir, pois o contexto poderia ser recuperado de bancos de dados internos e fontes externas, como pesquisas na web.

Visualização de agentes para roteamento de consultas

A pesquisa nessa área ainda está em andamento, mas adicionar um chamado "agente" dentro de um sistema RAG pode ajudar a determinar a fonte apropriada de contexto para uma determinada consulta.

Por exemplo, dada uma consulta como "Quem iniciou a pesquisa em IA?", o agente pode decidir se RAG é necessário ou não para responder a essa pergunta. Caso não seja, o sistema pode permitir que o LLM gere diretamente uma resposta à consulta sem nenhum contexto adicional.

Se RAG for considerado necessário, o agente deve determinar a fonte do contexto, seja um banco de dados interno ou uma fonte externa. Outra abordagem é o agente agregar informações de várias fontes em um único contexto resumido que possa ser usado pelo LLM para gerar uma resposta apropriada.

Conclusão

O poderoso desempenho dos LLMs na geração de respostas de texto semelhantes às humanas mudou todo o cenário da recuperação de informações. A introdução do RAG foi projetada para aprimorar a precisão das respostas dos LLMs, fornecendo-lhes contextos relevantes para uma determinada consulta. Esses contextos normalmente são armazenados como embeddings, que devem ser armazenados em um banco de dados vetorial como Milvus.

Como um banco de dados vetorial de código aberto com recursos avançados de busca vetorial, o Milvus oferece integração perfeita com toolkits populares de IA, como Snowflake. Com o Snowpark Container Service (SPCS) da Snowflake, os usuários agora podem executar o Milvus dentro do ecossistema Snowflake, permitindo que interajam facilmente com o Milvus usando dados armazenados no Snowflake.

Atualizado em Jul 13, 2026

Ruben Winastwan

Continue lendo

The Real Bottlenecks in Autonomous Driving — And How AI Infrastructure Can Solve Them

Autonomous driving faces a data bottleneck. Learn how AI-native vector databases like Zilliz solve scale, cost, and insight challenges across AV pipelines.

Why Deepseek is Waking up AI Giants Like OpenAI And Why You Should Care

Discover how DeepSeek R1's open-source AI model with superior reasoning capabilities and lower costs is disrupting the AI landscape and challenging tech giants like OpenAI.

DeepSeek-VL2: Mixture-of-Experts Vision-Language Models for Advanced Multimodal Understanding

Explore DeepSeek-VL2, the open-source MoE vision-language model. Discover its architecture, efficient training pipeline, and top-tier performance.