Implementando RAG Agêntico Usando Claude 3.5 Sonnet, LlamaIndex e Milvus
À medida que os sistemas de IA continuam a evoluir rapidamente, depender apenas de large language models (LLMs) já não é suficiente para atender às diversas necessidades das indústrias atuais. Esses desafios crescentes exigem o desenvolvimento de arquiteturas mais complexas, capazes de resolver problemas com mais eficiência e eficácia.
No Unstructured Data Meetup organizado pela Zilliz, Bill Zhang, Diretor de Engenharia da Zilliz, apresentou o conceito de Sistemas de IA Compostos, que foi destacado no blog Berkeley AI Research (BAIR). Essa abordagem modular integra vários componentes para lidar com diversas tarefas, em vez de depender de um único modelo de IA, entregando resultados mais personalizados e eficientes. Você pode assistir à apresentação de Bill no canal Zilliz YouTube.
Neste blog, recapitularemos os principais pontos de Bill, incluindo a evolução das arquiteturas de apps de LLM, os conceitos de Retrieval Augmented Generation (RAG) e Agentic RAG, e seus desafios e benefícios. Também mostraremos passo a passo como criar um Agentic RAG usando Claude 3.4 Sonnet, LlamaIndex e o banco de dados vetorial Milvus.
O Desenvolvimento da Arquitetura de Aplicações de LLM
Os LLMs fazem parte do cenário de IA há mais de uma década, mas o surgimento de foundation models disponíveis publicamente, particularmente o ChatGPT da OpenAI, nos últimos três anos acelerou significativamente o desenvolvimento de aplicações de LLM, impulsionando sua rápida expansão. No Unstructured Data Meetup, Bill resumiu os principais componentes das arquiteturas de IA atuais e seu desenvolvimento.
Figura 1- Evolução do Sistema de LLM .png
Figura 1: Evolução do Sistema de LLM
Depender exclusivamente do conhecimento pré-treinado dos LLMs
A forma mais simples de usar um LLM é confiar em seu conhecimento “próprio” para responder à sua consulta. No entanto, esse método tem uma limitação: os LLMs não conseguem cobrir todos os tópicos ou casos de uso, o que pode levar a respostas imprecisas ou “alucinadas”. Uma forma de resolver esse problema é usar múltiplos LLMs, cada um adaptado a diferentes tipos de perguntas, mas esse método tornaria o sistema excessivamente complexo e difícil de escalar.
Sistemas de IA compostos: adicionando componentes extras ao seu pipeline de LLM
Então, como podemos resolver esse problema? A solução está nos Sistemas de IA Compostos. Adicionar componentes extras ao pipeline de LLM pode melhorar o desempenho do sistema. Um exemplo comum é a Retrieval Augmented Generation (RAG). A RAG introduz uma "base de conhecimento" ou "contexto", normalmente armazenado em um banco de dados vetorial como Milvus ou Zilliz Cloud (o Milvus gerenciado), onde informações específicas são salvas para buscas por similaridade. Você pode acessar informações personalizadas para o seu caso de uso alimentando seu conhecimento no sistema RAG. A RAG aproveita o poder do LLM combinado com um prompt personalizado composto pela consulta do usuário e pelo contexto recuperado do banco de dados vetorial, produzindo respostas mais precisas e relevantes.
Agentes
Então, precisamos implementar mais módulos? Isso depende do caso de uso específico. No entanto, assim como os LLMs, o RAG também tem limitações, pois depende do modelo específico. Por exemplo, e se sua consulta envolver a realização de uma tarefa de comparação, mas seu modelo tiver sido treinado para sumarização? Como diferentes tipos de perguntas podem ser gerenciados de forma eficaz? É aqui que um módulo adicional entra em prática: Agents. Agentes de IA são sistemas complexos que adicionam etapas “semelhantes às humanas” ao pipeline, como raciocínio, ferramentas usadas ou planejamento. Vamos nos aprofundar primeiro nos fundamentos do RAG para entender os benefícios dos agentes.
Retrieval Augmented Generation (RAG)
Como mencionado acima, os sistemas RAG aprimoram a saída dos LLMs incorporando um banco de dados vetorial como base de conhecimento. As etapas básicas para construir um sistema RAG podem ser resumidas da seguinte forma:
Chunking: Dividir documentos em partes menores para melhorar a relevância do conteúdo recuperado do banco de dados vetorial usando busca semântica, uma característica central de bancos de dados vetoriais como Zilliz Cloud e Milvus.
Embedding: Vetorizar (criar representações numéricas de) os chunks que serão ingeridos no banco de dados vetorial.
Prompt: Instruções foram dadas ao LLM para pesquisar no banco de dados vetorial com base na consulta para obter a resposta
Query: A pergunta feita ao LLM
Essas etapas são baseadas principalmente em similaridade. O modelo procura os chunks mais semelhantes no banco de dados e gera a resposta mais precisa com base nisso.
Figura 2- Etapas básicas do RAG .png
Figura 2: Etapas básicas do RAG
No entanto, uma busca por similaridade semântica não é uma solução mágica. A resposta resultante também ficará aquém se os chunks mais semelhantes não forem precisos o suficiente. Bill explorou algumas das fraquezas dos sistemas RAG, particularmente em casos de uso em que os LLMs podem não ter desempenho ideal, incluindo sumarização, comparação e perguntas de múltiplas partes.
No entanto, o problema com o RAG, ou seja, sua falta de capacidades de raciocínio e incapacidade de recuperar os documentos necessários com precisão, pode ser abordado de forma eficaz pela introdução de Agents. Essas Entidades desempenham um papel crucial em todo o processo, oferecendo uma solução potencial para os desafios apresentados pelo RAG.
Agentic RAG
Agora que entendemos as limitações dos LLMs e do RAG, podemos explorar mais profundamente os benefícios dos agentes. No diagrama abaixo, os agentes LLM contêm vários componentes que interagem entre si em um processo iterativo. Agora, não se trata apenas de similaridade, mas também de planejamento, raciocínio, uso de ferramentas e memorização.
Figura 3- Agentes LLM .png
Figura 3: Agentes LLM
Embora existam várias arquiteturas e frameworks agentivos, um dos mais populares é o ReAct (Reasoning/Acting). O ReAct envolve várias etapas: planejamento/raciocínio, ação (uso de ferramentas), observação/avaliação e geração de respostas. Bill destacou essas etapas como parte de um processo iterativo.
Na etapa de observação/avaliação, se o modelo não encontrar a resposta, ele continuará procurando alternativas retornando à etapa de raciocínio ou até mesmo solicitando um prompt adicional ao usuário.
Figura 4- Framework ReAct.png
Figura 4: Framework ReAct (Fonte)
Então, como podemos usar esses agentes em um pipeline RAG? O bom é que eles podem ser implementados em todas as etapas do pipeline, seja no roteamento/planejamento para o pipeline RAG downstream ou na chamada de ferramentas. Até mesmo a base de conhecimento pode ser considerada uma ferramenta ou um framework ReAct.
Figure 5- How An Agentic RAG works .png
Figura 5: Como um Agentic RAG funciona
Durante a palestra, Bill explicou cinco possíveis implementações agênticas dentro de um pipeline RAG:
Roteamento: A consulta do usuário é redirecionada para uma base de conhecimento específica relevante para a consulta.
- Exemplo: Se o usuário pedir recomendações de tipos específicos de livros, a consulta pode ser roteada para a base de conhecimento, que contém informações sobre esses tipos de livros.
Planejamento de Consultas: A consulta é dividida em subconsultas, com cada subconsulta direcionada ao pipeline RAG relevante.
- Exemplo: Se você quiser saber os resultados financeiros de uma empresa nos últimos três anos, o agente cria subconsultas para cada ano e direciona cada uma para a base de conhecimento apropriada.
Uso de Ferramentas: Um LLM interage com uma API ou ferramenta externa, determinando os parâmetros necessários para a interação.
- Exemplo: Se um usuário solicita uma previsão do tempo, o LLM chama uma API de previsão do tempo, determina parâmetros como localização e data e processa a resposta da API para fornecer a resposta.
ReAct: Um processo iterativo que incorpora raciocínio e ação, incluindo etapas de planejamento, uso de ferramentas e observação.
- Exemplo: Para gerar um itinerário de viagem detalhado, o sistema raciocina sobre as necessidades do usuário, usa APIs para coletar informações sobre atrações, restaurantes e hospedagem, observa os resultados quanto à precisão e relevância e, então, fornece um plano de viagem abrangente.
Planejamento Dinâmico de Consultas: O agente executa várias tarefas ou subconsultas em paralelo, em vez de sequencialmente, e agrega os resultados
Exemplo: Se você quiser comparar os resultados financeiros de duas empresas e calcular a diferença em uma métrica específica, o agente processa dados de ambas as empresas em paralelo e depois combina os resultados para fornecer a comparação. LLMCompiler é um exemplo de framework que permite uma orquestração eficiente e eficaz de chamadas de funções paralelas.
Figure 6- LLM Compiler.png
Figura 6: LLM Compiler (Fonte)
Então, os agentes adicionam uma camada extra ao pipeline RAG, aprimorando e melhorando a eficiência geral do processo. No entanto, assim como LLMs e RAG como sistemas independentes, os agentes também apresentam alguns desafios, como controlar suas etapas internas e personalizá-los para alcançar os melhores resultados em casos de uso específicos.
Agora, vamos mostrar um pipeline agêntico simples usando o banco de dados vetorial Milvus.
Agentic RAG usando Claude 3.5 Sonnet, LlamaIndex e Milvus
O seguinte notebook é um exemplo de um pipeline Agentic RAG criado com LlamaIndex como o framework agêntico, Milvus como o banco de dados vetorial e Claude 3.5 Sonnet como o LLM. Nesta seção, vou orientar você sobre como construir este agentic RAG.
Você também pode conferir o código completo em este notebook.
Etapa 1: Carregamento de Dados
Usamos as páginas de FAQ da Documentação do Milvus 2.4.x como conhecimento privado em nosso RAG, que é uma boa fonte de dados para um pipeline RAG simples.
!pip install -qq llama-index pymilvus llama-index-vector-stores-milvus llama-index-llms-anthropic
!wget https://github.com/milvus-io/milvus-docs/releases/download/v2.4.6-preview/milvus_docs_2.4.x_en.zip
!unzip -q /content/milvus_docs_2.4.x_en.zip -d /content/milvus_docs
from llama_index.core import SimpleDirectoryReader
# carregar documentos
documents = SimpleDirectoryReader(
input_files=["/content/milvus_docs/en/faq/operational_faq.md"]
).load_data()
print("ID do documento:", documents[0].doc_id)
Etapa 2: Variáveis de ambiente
Precisamos importar duas CHAVES DE API: Anthropic e OpenAI.
import os
from google.colab import userdata
os.environ["ANTHROPIC_API_KEY"] = userdata.get('ANTHROPIC_API_KEY')
os.environ["OPENAI_API_KEY"] = userdata.get('OPENAI_API_KEY')
Etapa 3: Indexação de dados
Um índice dos documentos é criado usando o banco de dados vetorial Milvus. Esta será nossa base de conhecimento. Como OpenAI é o modelo de embedding padrão no LlamaIndex (ele pode ser alterado), precisamos definir as mesmas dimensões (dim = 1536) no MilvusVectorStore. Além disso, um banco de dados local será criado após executar o código a seguir, que conterá nossa base de conhecimento.
from llama_index.core import VectorStoreIndex, StorageContext
from llama_index.vector_stores.milvus import MilvusVectorStore
vector_store = MilvusVectorStore(dim=1536)
storage_context = StorageContext.from_defaults(vector_store=vector_store)
index = VectorStoreIndex.from_documents(documents, storage_context=storage_context)
Etapa 4: Mecanismo de consulta simples
Vamos primeiro testar o mecanismo de consulta sem um agente. Ele é alimentado pelo Claude 3.5 Sonnet e busca conteúdo relevante dentro do nosso índice.
llm = Anthropic(model="claude-3-5-sonnet-20240620")
query_engine = index.as_query_engine(similarity_top_k=5, llm=llm)
res = query_engine.query("Qual é a dimensão vetorial máxima suportada no Milvus?")
print(res)
"""
Saída:
O Milvus suporta vetores com até 32.768 dimensões por padrão. No entanto, se você precisar trabalhar com vetores de dimensionalidade ainda maior, tem a opção de aumentar o valor do parâmetro 'Proxy.maxDimension'. Isso permite que o Milvus acomode vetores com dimensões que excedem o limite padrão.
"""
Etapa 5: Mecanismo de consulta agêntico
Agora, adicionamos o QueryEngineTool, que atuará como uma ferramenta wrapper para o mecanismo de consulta, que será usada pelo agente.
from llama_index.core import VectorStoreIndex
from llama_index.core.tools import QueryEngineTool, ToolMetadata
from llama_index.llms.anthropic import Anthropic
llm = Anthropic(model="claude-3-5-sonnet-20240620")
query_engine = index.as_query_engine(similarity_top_k=5, llm=llm)
query_engine_tool = QueryEngineTool(
query_engine=query_engine,
metadata=ToolMetadata(
name="knowledge_base",
description=(
"Fornece informações sobre o FAQ do Milvus."
"Use uma pergunta detalhada em texto simples como entrada para a ferramenta."
),
),
)
Etapa 6: Criação do agente de IA
O agente usado neste caso é o FunctionCallingAgentWorker do LlamaIndex, que emprega reflexão crítica sobre a resposta da consulta usando a ferramenta de mecanismo de consulta para gerar uma resposta aprimorada.
from llama_index.core.agent import FunctionCallingAgentWorker
agent_worker = FunctionCallingAgentWorker.from_tools(
[query_engine_tool], llm=llm, verbose=True
)
agent = agent_worker.as_agent()
response = agent.chat("Qual é a dimensão vetorial máxima suportada no Milvus?")
print(str(response))
"""
Saída:
Mensagem do usuário adicionada à memória: Qual é a dimensão vetorial máxima suportada no Milvus?
=== Resposta do LLM ===
Para responder à sua pergunta sobre a dimensão vetorial máxima suportada no Milvus, precisarei consultar a base de conhecimento do FAQ do Milvus. Deixe-me fazer isso para você.
=== Chamando função ===
Chamando função: knowledge_base com args: {"input": "Qual é a dimensão vetorial máxima suportada no Milvus?"}
=== Saída da Função ===
O Milvus oferece suporte a vetores com até 32.768 dimensões por padrão. No entanto, se você precisar trabalhar com vetores de dimensionalidade ainda maior, tem a opção de aumentar o valor do parâmetro 'Proxy.maxDimension'. Isso permite que o Milvus acomode vetores com dimensões que excedem o limite padrão.
=== Resposta do LLM ===
Com base nas informações da base de conhecimento de FAQ do Milvus, posso fornecer a seguinte resposta:
A dimensão vetorial máxima suportada no Milvus é 32.768 por padrão. Isso significa que, pronto para uso, o Milvus pode lidar com vetores com até 32.768 dimensões, o que é adequado para a maioria das aplicações.
No entanto, é importante observar que o Milvus oferece flexibilidade para casos em que você possa precisar trabalhar com vetores de dimensionalidade ainda maior. Se o seu caso de uso exigir vetores com dimensões superiores a 32.768, você tem a opção de aumentar esse limite. Isso pode ser feito ajustando o parâmetro 'Proxy.maxDimension' na configuração do Milvus.
Então, para resumir:
1. Dimensão máxima padrão: 32.768
2. Pode ser aumentada: Sim, modificando o parâmetro 'Proxy.maxDimension'
Essa flexibilidade permite que o Milvus acomode uma ampla variedade de casos de uso, desde aplicações típicas de machine learning e IA até cenários mais especializados que podem exigir vetores de dimensionalidade extremamente alta.
Com base nas informações da base de conhecimento de FAQ do Milvus, posso fornecer a seguinte resposta:
A dimensão vetorial máxima suportada no Milvus é 32.768 por padrão. Isso significa que, pronto para uso, o Milvus pode lidar com vetores com até 32.768 dimensões, o que é adequado para a maioria das aplicações.
No entanto, é importante observar que o Milvus oferece flexibilidade para casos em que você possa precisar trabalhar com vetores de dimensionalidade ainda maior. Se o seu caso de uso exigir vetores com dimensões superiores a 32.768, você tem a opção de aumentar esse limite. Isso pode ser feito ajustando o parâmetro 'Proxy.maxDimension' na configuração do Milvus.
Então, para resumir:
1. Dimensão máxima padrão: 32.768
2. Pode ser aumentada: Sim, modificando o parâmetro 'Proxy.maxDimension'
Essa flexibilidade permite que o Milvus acomode uma ampla variedade de casos de uso, desde aplicações típicas de machine learning e IA até cenários mais especializados que podem exigir vetores de dimensionalidade extremamente alta.
"""
A saída do agente fornece uma resposta mais detalhada, incluindo a fonte das informações, o raciocínio por trás da resposta e algumas sugestões adicionais relacionadas ao tópico. Isso nos ajuda a entender melhor a resposta dada pelo modelo LLM.
A Arquitetura RAG Agêntica
A arquitetura completa do RAG agêntico que acabamos de criar é como abaixo.
A arquitetura RAG agêntica construída com Milvus, LlamaIndex e Cluade 3.5 Sonnet.png
Figura 7: A arquitetura RAG agêntica construída com Milvus, LlamaIndex e Cluade 3.5 Sonnet
Conclusão
Em sua palestra, Bill Zhang explorou o cenário em evolução dos sistemas LLM, destacando a mudança de modelos independentes para arquiteturas mais complexas que incorporam RAG e agentes. Cada componente—LLMs, RAG e agentes—tem pontos fortes e fracos. O conceito de IA Composta permite a criação de sistemas modulares projetados para abordar vários gargalos, melhorando assim a eficiência geral do pipeline.
Embora os resultados desses sistemas avançados sejam promissores e implementações prontas para produção estejam se tornando mais comuns, vários desafios permanecem, particularmente no gerenciamento e na personalização do comportamento dos agentes dentro desses sistemas. Ajustar finamente esses componentes para funcionar de forma eficiente em casos de uso específicos é uma área de desenvolvimento contínuo.
Recursos Adicionais sobre GenAI, VectorDB e ML
Continue lendo
Why I’m Against Claude Code’s Grep-Only Retrieval? It Just Burns Too Many Tokens
Learn how vector-based code retrieval cuts Claude Code token consumption by 40%. Open-source solution with easy MCP integration. Try claude-context today.
Announcing VDBBench 1.0: Open-Source VectorDB Benchmarking with Your Real-World Production Workloads
Discover VDBBench 1.0, an open-source tool for benchmarking vector databases with real-world production data, streaming ingestion, and concurrent workloads.
Creating Collections in Zilliz Cloud Just Got Way Easier
We've enhanced the entire collection creation experience to bring advanced capabilities directly into the interface, making it faster and easier to build production-ready schemas without switching tools.