O Modelo Mental do Pipeline RAG e do Loop de Agente
Todas as páginas desta seção, seja sobre LangChain, LlamaIndex, bancos de dados vetoriais ou o Protocolo de Contexto do Modelo, são detalhes de implementação que se baseiam em exatamente dois modelos mentais.
O primeiro é o pipeline de geração aumentada por recuperação (RAG): uma sequência fixa de estágios que transforma um monte de documentos em respostas fundamentadas e citadas.
O segundo é o loop de agente: um ciclo que permite que um modelo de linguagem decida o que fazer a seguir, chame uma ferramenta, observe o resultado e decida novamente.
Compreender esses dois modelos primeiro torna cada escolha específica de biblioteca - qual banco de dados vetorial, qual reranker, qual framework de orquestração - uma decisão muito menor do que parece inicialmente.
Resumo
- RAG fundamenta a geração em evidências recuperadas através de um pipeline chunk-embed-retrieve-rerank-generate; agentes envolvem a geração em um loop que pode agir no mundo através de ferramentas.
- Por que Importa: Nem uma chamada LLM bruta nem uma única consulta ao banco de dados resolvem "responda a esta pergunta usando nossos dados e tome uma ação" - você precisa de um pipeline e um loop, e a maioria dos bugs vem de tratar qualquer um deles como um único passo.
- Conceitos-Chave: chunking (divisão em pedaços), embedding (vetorização), retrieval (recuperação), reranking (reclassificação), generation (geração), agent loop (loop de agente), tool use (uso de ferramentas), grounding (fundamentação).
- Quando Usar: Resposta a perguntas específicas de domínio, pesquisa de conhecimento interno, suporte ao cliente sobre documentos privados e qualquer tarefa que exija raciocínio multi-etapa com ações externas (reservar, consultar, escrever arquivos).
- Limitações / Trade-offs: RAG só ajuda quando a resposta realmente existe em seu corpus; loops de agente trocam determinismo e previsibilidade de custo por flexibilidade, e ambos adicionam estágios de latência que uma única chamada de modelo não tem.
- Tópicos Relacionados: busca vetorial, engenharia de prompt, chamada de função, frameworks de orquestração.
Fundamentos
A geração aumentada por recuperação existe porque os modelos de linguagem têm dois limites rígidos: uma janela de contexto fixa e um corte de treinamento.
Você não pode colar sua base de conhecimento inteira em um prompt, e o modelo não pode saber sobre documentos escritos após seu treinamento.
RAG resolve ambos recuperando apenas a fatia relevante de texto no momento da consulta e entregando-a ao modelo como contexto.
O pipeline tem cinco estágios conceituais, e cada um existe para corrigir uma falha específica do estágio anterior.
Chunking (divisão em pedaços) divide documentos longos em partes de tamanho recuperável, porque vetorizar um PDF inteiro como um único vetor perde o significado granular de qualquer parágrafo individual dentro dele.
Embedding (vetorização) converte cada pedaço em um vetor, uma lista de números que coloca textos semanticamente semelhantes próximos uns dos outros em um espaço de alta dimensão.
Retrieval (recuperação) pega uma consulta, a vetoriza da mesma forma e encontra os vetores de pedaços mais próximos, que é o primeiro ponto de falha real do pipeline, já que "mais próximo" não é o mesmo que "correto".
Reranking (reclassificação) pega os principais candidatos da recuperação e os reclassifica com um modelo mais caro e mais preciso, porque a busca aproximada rápida em milhões de vetores necessariamente deixa resultados relevantes classificados mais abaixo do que deveriam.
Generation (geração) é o passo final, onde o LLM escreve uma resposta usando apenas o contexto recuperado (e reclassificado), idealmente com citações de volta aos pedaços de origem.
O loop de agente é um modelo diferente, mas complementar.
Onde RAG é um pipeline reto (os dados fluem em uma direção, uma vez), um loop de agente é um ciclo: o modelo recebe o estado, decide sobre uma ação, uma ação é executada e o resultado é realimentado como novo estado.
A imagem mental mais simples é um termostato: sentir a temperatura, decidir se aquece ou esfria, agir, sentir novamente.
Para um agente LLM, "sentir" é a conversa e os resultados das ferramentas até agora, "decidir" é o modelo escolhendo uma chamada de ferramenta ou uma resposta final, e "agir" é realmente invocar essa ferramenta.
Tool use (uso de ferramentas) (às vezes chamado de chamada de função) é o que torna o loop útil: em vez de o modelo apenas produzir prosa, ele produz uma solicitação estruturada - um nome de função e argumentos - que seu código executa e realimenta como uma observação.
Mecânicas e Interações
Os dois modelos interagem constantemente em sistemas reais, porque a ferramenta de agente mais comum é um recuperador RAG.
O passo "decidir" de um loop de agente comumente se resolve em "chamar a ferramenta search_docs", que aciona todo o pipeline RAG, cuja saída se torna o passo "observar" que alimenta a próxima decisão.
É por isso que os dois modelos mentais pertencem à mesma página: RAG sem um loop é um sistema de Q&A de tiro único, e um loop de agente sem RAG não tem como fundamentar suas ações em seus dados reais.
Dentro do pipeline RAG, o modelo de embedding usado no momento da indexação e o modelo de embedding usado no momento da consulta devem ser o mesmo modelo (ou pelo menos compatível), porque vetores de modelos diferentes não compartilham um espaço de coordenadas.
Este é um detalhe mecânico sutil, mas crítico: trocar modelos de embedding significa re-vetorizar e re-indexar cada pedaço, não apenas as novas consultas.
A qualidade da recuperação é geralmente descrita com recall (o pedaço relevante apareceu no conjunto de candidatos) e precision (quanta parte do conjunto de candidatos é realmente relevante), e estes se contrapõem.
Um top_k maior melhora o recall, mas dilui a precisão e aumenta os tokens enviados para o estágio de geração, que é exatamente o problema que a reclassificação foi projetada para resolver: recuperar amplamente e de forma barata, depois refinar com precisão e de forma cara.
No loop de agente, o detalhe mecânico crítico é a terminação.
Um LLM não sabe inerentemente quando parar de chamar ferramentas, então todo framework de agente real impõe um limite - um número máximo de iterações, um limite de recursão, ou um sinal explícito de "resposta final" que o modelo deve emitir.
Sem esse limite, um modelo que continua decidindo "preciso de mais informações" chamará ferramentas indefinidamente, queimando custo e tempo sem uma saída natural.
def run_agent_loop(model, tools: dict, state: list, max_steps: int = 8):
for _ in range(max_steps):
decision = model.decide(state) # LLM escolhe: resposta ou chamar uma ferramenta
if decision.is_final_answer:
return decision.content
result = tools[decision.tool_name](**
Este trecho não é um agente de produção (frameworks reais como LangGraph lidam com ramificações, persistência e chamadas de ferramentas paralelas), mas torna a forma do loop explícita: decidir, agir, observar, repetir, com uma parada rígida.
Considerações Avançadas e Aplicações
Em escala, ambos os modelos desenvolvem modos de falha que não aparecem em uma demonstração com dez documentos.
Pipelines RAG construídos em um único índice vetorial plano degradam à medida que o corpus cresce para milhões de pedaços, porque a busca aproximada pelo vizinho mais próximo troca recall por velocidade, e essa troca piora à medida que o índice cresce, a menos que você adicione filtragem, busca híbrida (combinando palavra-chave/BM25 com similaridade vetorial) ou recuperação hierárquica.
Loops de agente desenvolvem um modo de falha paralelo: à medida que você adiciona mais ferramentas, o passo de decisão do modelo fica mais difícil, porque ele agora deve escolher corretamente entre um conjunto maior e mais ambíguo de opções, e pequenas mudanças no prompt ou na descrição da ferramenta podem alterar o comportamento de forma imprevisível.
A observabilidade também difere entre os dois modelos.
Pipelines RAG são depurados inspecionando o que foi recuperado - se a resposta estiver errada, a primeira pergunta é sempre "o pedaço certo estava no conjunto de candidatos?"
Loops de agente são depurados inspecionando o trace de decisões e chamadas de ferramentas, já que a falha geralmente está vários passos antes da resposta errada final, não na última etapa em si.
A segurança também diverge: a superfície de ataque do RAG é o envenenamento de dados (conteúdo malicioso injetado no corpus que é recuperado e tratado como contexto confiável), enquanto a superfície de ataque de um loop de agente é a injeção de prompt através de saídas de ferramentas - um resultado de ferramenta que em si contém instruções que o modelo pode seguir.
| Abordagem | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| RAG Ingênuo (recuperar + gerar uma vez) | Simples, baixa latência, fácil de raciocinar | Sem autocorreção se a recuperação falhar | Corpora pequenos e bem curados |
| Recuperação + reclassificação | Maior precisão em consultas ambíguas | Latência extra e uma segunda chamada de modelo | Corpora maiores com pedaços ruidosos |
| RAG Agente (loop chama recuperação como ferramenta) | Pode tentar novamente, reformular consultas, combinar fontes | Custo mais alto, mais difícil de limitar e testar | Perguntas de múltiplos saltos, tarefas de estilo de pesquisa |
| Agente de ferramenta única fixa | Previsível, fácil de isolar | Não pode se adaptar a subtarefas inesperadas | Automações bem definidas (uma ação, um propósito) |
| Loop multi-ferramenta / multi-agente | Lida com tarefas abertas | Maior raio de explosão, mais difícil de avaliar | Fluxos de trabalho complexos com portões de revisão humana |
Conceitos Equivocados Comuns
- "RAG significa apenas adicionar um banco de dados vetorial." Um banco de dados vetorial é um componente de um estágio (recuperação); sem chunking deliberado, um modelo de embedding compatível e, muitas vezes, reclassificação, um banco de dados vetorial por si só produz respostas medíocres e difíceis de depurar.
- "Mais contexto recuperado é sempre melhor." Colocar mais pedaços no prompt aumenta a chance de texto irrelevante ou contraditório abafar a resposta correta, e custa mais tokens; recall e precisão devem ser equilibrados, não maximizados independentemente.
- "Agentes são autônomos e não supervisionados por design." Todo loop de agente de produção tem um limite explícito - um limite de passos, uma lista de permissão de ferramentas ou um portão de aprovação humana explícito - porque loops ilimitados são um passivo, não um recurso.
- "Um modelo maior corrige a recuperação ruim." Se a informação correta nunca entra na janela de contexto, nenhuma quantidade de capacidade do modelo a recupera; a qualidade da recuperação é frequentemente a correção de maior alavancagem em relação ao tamanho do modelo.
- "O uso de ferramentas é apenas saída estruturada." A saída estruturada é necessária, mas não suficiente; o loop também precisa de uma condição de término, tratamento de erros para chamadas de ferramentas com falha e uma maneira de realimentar os resultados como novo estado.
FAQs
Qual é a diferença entre RAG e apenas ajustar um modelo com meus dados?
- O fine-tuning incorpora conhecimento nos pesos do modelo e é lento para atualizar.
- RAG recupera contexto fresco no momento da consulta, então atualizar o corpus atualiza as respostas imediatamente.
- A maioria dos sistemas de produção combina ambos: fine-tuning para estilo/formato, RAG para fatos.
Por que preciso de chunking? Por que não vetorizar documentos inteiros?
Um embedding de documento inteiro mistura muitos tópicos diferentes em um único vetor, então uma consulta sobre um parágrafo não corresponderá de forma confiável. O chunking mantém cada vetor focado em uma unidade de significado coerente.
Qual deve ser o tamanho de um chunk?
Não há um número universal; depende do contexto efetivo do modelo de embedding e da granularidade do seu conteúdo. A maioria das equipes começa com algumas centenas de tokens com sobreposição modesta e ajusta com base nos resultados da avaliação de recuperação.
O que um reranker realmente adiciona em relação à busca vetorial?
A busca vetorial usa uma passagem de embedding para aproximar a relevância rapidamente em um índice enorme. Um reranker executa um modelo mais caro apenas na lista curta, cruzando a consulta e cada candidato diretamente, o que produz uma ordenação mais precisa em uma escala muito menor.
Um "agente" é apenas um chatbot com plugins?
Não exatamente. Um chatbot com plugins pode chamar uma ferramenta por turno sob direção humana. Um loop de agente pode fazer múltiplas decisões internas e chamadas de ferramentas antes de produzir uma única resposta final, sem um humano entre cada etapa.
Como o modelo realmente "decide" chamar uma ferramenta?
O modelo recebe esquemas de ferramentas (nome, descrição, tipos de argumento) junto com a conversa, e é treinado/prompted para emitir uma chamada estruturada em vez de prosa quando uma ferramenta corresponde à tarefa. O código de chamada então executa a função real.
O que impede um loop de agente de rodar para sempre?
Um limite explícito definido pelo desenvolvedor: uma contagem máxima de iterações ou recursão, um orçamento de tokens/custo, ou um sinal necessário de "resposta final" que o modelo deve produzir para sair do loop.
Quando eu NÃO deveria usar um loop de agente?
- Quando a tarefa é uma consulta única e bem definida (RAG simples é mais rápido, mais barato e mais previsível).
- Quando você não pode tolerar latência ou custo variável por solicitação.
- Quando o espaço de ação é pequeno o suficiente para ser codificado como um script linear.
RAG e loops de agente podem ser usados um sem o outro?
Sim. RAG simples (recuperar uma vez, gerar uma vez) não precisa de nenhum loop. Um loop de agente pode existir sem qualquer recuperação, usando apenas outras ferramentas como uma calculadora ou uma API de calendário.
O que é "grounding" neste contexto?
Grounding significa que a resposta do modelo está ligada a evidências recuperadas específicas em vez de ser gerada puramente a partir de seus dados de treinamento, o que torna as citações e a redução de alucinações possíveis.
Por que frameworks como LangChain, LlamaIndex e LangGraph existem se os modelos são os mesmos?
Eles implementam os mesmos dois modelos mentais com ergonomia diferente: LlamaIndex pende para conveniência de carregamento e indexação de dados, LangChain para cadeias compostas, e LangGraph para loops explícitos com estado e ciclos. Os conceitos subjacentes de pipeline e loop não mudam.
Qual é o bug mais comum em um sistema RAG?
Uma incompatibilidade ou desvio entre o modelo de embedding usado no momento da indexação versus o momento da consulta, ou uma estratégia de chunking que divide a resposta real em dois pedaços separados para que nenhum deles sozinho seja recuperado como totalmente relevante.
Relacionados
- Noções Básicas de RAG - um guia prático do pipeline chunk-embed-retrieve-generate
- Recuperação e Reclassificação - mecânicas mais profundas dos estágios de recuperação e reclassificação
- Bancos de Dados Vetoriais - onde os embeddings são armazenados e pesquisados
- LangGraph e Loops de Agente - implementando o loop de agente como um grafo de estado
- Uso de Ferramentas e Chamada de Função - a mecânica por trás do passo "agir"
- Avaliação e Barreiras de Proteção - medindo a qualidade da recuperação e do agente
Versões da Stack: Esta página foi escrita para Python 3.14.0 (estável 3.14, manutenção 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, e uv 0.6+.