Construindo Sistemas de IA: De RAG a Agentes

A maioria das equipes começa com RAG, descobre seus limites e depois adiciona fine-tuning. Ambos resolvem recuperação e raciocínio. Nenhum dos dois resolve orquestração: decidir quando agir, quantos agentes criar, quando parar e o que significa consenso. Construí um sistema de deliberação multi-agente (3.500 linhas de Python, 86 hooks, 141 testes) que lida com os três.

TL;DR

RAG recupera documentos no momento da consulta. Fine-tuning modifica os pesos do modelo com dados de domínio. Ambos são ferramentas de recuperação e raciocínio. Nenhum lida com orquestração: coordenar múltiplos agentes, validar consenso ou decidir quando uma tarefa precisa de uma chamada ao modelo versus doze. Encontrei essa barreira ao construir um sistema de qualidade para blog que precisava de linting paralelo, pontuação de profundidade, verificação de citações e avaliação por LLM em 33 posts. A solução foi uma camada de orquestração de agentes com deliberação acionada por confiança, gerenciamento de orçamento de spawn e validação de consenso com quatro verificações. Este post cobre a decisão RAG versus fine-tuning, e depois vai onde a maioria dos guias para: o que acontece quando você precisa de agentes.

Parte 1: RAG vs Fine-Tuning

Um estudo da Databricks de 2024 revelou que 78% das equipes corporativas de IA escolheram RAG primeiro, mas 34% depois descobriram que fine-tuning teria sido a melhor abordagem, desperdiçando em média 3,2 meses de tempo de implementação.¹

A decisão não é uma coisa ou outra. É sobre combinar a técnica ao problema.

Quando RAG vence

Conhecimento que muda frequentemente. RAG recupera documentos atuais no momento da consulta. Quando a base de conhecimento é atualizada diariamente (documentação de produtos, artigos de suporte, registros regulatórios), RAG fornece informações atuais sem retreinamento.²

Requisitos de atribuição de fontes. RAG cita documentos específicos porque a recuperação produz uma lista explícita de fontes. Em setores regulamentados (saúde, finanças, jurídico), a atribuição de fontes é frequentemente um requisito de conformidade.³

Grandes bases de conhecimento. Um sistema RAG sobre 10 milhões de documentos tem desempenho comparável a um sobre 1 milhão, desde que a qualidade da recuperação seja consistente. Modelos com fine-tuning atingem limites de capacidade determinados pelo tamanho do modelo.⁴

Quando fine-tuning vence

Padrões de raciocínio específicos do domínio. RAG fornece informação. Fine-tuning fornece capacidade. Um modelo com fine-tuning em conversas de diagnóstico médico aprende padrões de diagnóstico diferencial: como ponderar sintomas, quando considerar condições raras, como formular perguntas de acompanhamento. RAG pode fornecer o conhecimento médico, mas o padrão de raciocínio requer ajuste de pesos.⁵

Requisitos rigorosos de formato de saída. Fine-tuning impõe saída estruturada (JSON, XML, schemas específicos) de forma mais confiável do que engenharia de prompt. Para sistemas onde falhas de formato causam erros em cascata, fine-tuning oferece maior confiabilidade.⁶

Aplicações críticas em latência. RAG adiciona latência de recuperação: converter a consulta em embedding, buscar no banco de dados vetorial, recuperar documentos, injetá-los no prompt. Para aplicações com metas de resposta abaixo de 200ms, eliminar a recuperação por meio de fine-tuning pode ser necessário.⁷

A matriz de comparação

A abordagem combinada

A maioria dos sistemas em produção combina ambas as técnicas. Aplique fine-tuning no modelo para padrões de raciocínio de domínio e formatos de saída. Use RAG para fornecer conhecimento atual e atribuível no momento da consulta. O modelo com fine-tuning sabe como raciocinar sobre o domínio. O sistema RAG fornece sobre o que raciocinar.⁸

Parte 2: Quando você precisa de agentes

RAG e fine-tuning lidam com recuperação e raciocínio. Nenhum dos dois lida com orquestração: decidir se uma tarefa precisa de uma chamada ao modelo ou doze, quando criar workers paralelos, como validar suas saídas e quando escalar para um humano.

Encontrei essa barreira ao construir minha infraestrutura de qualidade para blog. Tinha 33 posts para avaliar, corrigir e verificar. Uma única chamada ao modelo por post não era suficiente. Cada post precisava de linting (12 módulos), pontuação de profundidade (5 sinais), análise de legibilidade, verificação de citações e avaliação por LLM. Executar tudo sequencialmente demorava demais. Executar em paralelo sem coordenação produzia conflitos e resultados inconsistentes.

A solução não era mais RAG ou melhor fine-tuning. Era uma camada de orquestração de agentes.

O que a orquestração de agentes exige

O pipeline tradicional de ML assume fluxo linear: dados, pré-processamento, modelo, avaliação, deploy.⁹ Sistemas de agentes são não-lineares. Um agente pode:

1. Avaliar sua própria confiança e decidir que precisa de ajuda
2. Criar 5 sub-agentes paralelos com diferentes especialidades
3. Coletar e classificar suas saídas
4. Detectar quando os agentes convergem rápido demais (pensamento de grupo)
5. Validar consenso contra limiares de qualidade
6. Gerar uma recomendação final

Cada etapa requer infraestrutura que RAG e fine-tuning não fornecem.

Parte 3: O que eu construí

A arquitetura

Meu sistema de deliberação abrange 3.500 linhas de Python em 12 módulos:

Deliberation System
├── confidence.py       Triggers deliberation based on ambiguity/complexity/stakes
├── state_machine.py    Workflow: idle → research → ranking → consensus
├── agents.py           5+ persona templates (Architect, Security, Performance...)
├── context_isolation.py  RLM L0-L3 layers prevent context contamination
├── ranking.py          Stack ranking with weighted consensus calculation
├── spawner.py          Parallel agent spawning via Task API
├── conformity.py       Detects groupthink and premature convergence
├── mailbox.py          Multi-round debate protocol
├── memory.py           Cross-session learning and persona tracking
├── scaling.py          Dynamic agent count based on complexity
├── prd_generator.py    Converts decisions into product requirements
└── observability.py    Session metrics and audit replay

O sistema se apoia em 86 hooks que interceptam operações em seis pontos do ciclo de vida (PreToolUse, PostToolUse, Stop e três outros). Cada spawn de agente, cada escrita de arquivo, cada comando git passa por validação.

O gatilho de confiança

Nem toda tarefa precisa de cinco agentes debatendo. Construí um algoritmo de pontuação de confiança que avalia quatro dimensões:

1. Ambiguidade — A consulta tem múltiplas interpretações válidas? (Padrões detectados: “melhor forma de,” “devo,” “compare vs,” “prós e contras”)
2. Complexidade de domínio — Requer conhecimento especializado? (Padrões detectados: “arquitetura,” “segurança,” “performance,” “schema de banco de dados”)
3. Impacto — A decisão é reversível? (Padrões detectados: “produção,” “breaking change,” “deletar,” “vulnerabilidade de segurança”)
4. Dependência de contexto — Requer compreensão do sistema mais amplo?

A pontuação mapeia para três níveis:

• ALTA (0,85+): Prosseguir sem deliberação
• MÉDIA (0,70-0,84): Prosseguir com nota de confiança registrada
• BAIXA (abaixo de 0,70): Acionar deliberação multi-agente completa

O limiar se adapta por tipo de tarefa. Decisões de segurança exigem 85% de consenso. Mudanças de documentação precisam apenas de 50%. Isso evita engenharia excessiva em tarefas simples enquanto garante que decisões arriscadas recebam o escrutínio adequado.

O problema do orçamento de spawn

Minha primeira implementação usava limites de recursão baseados em profundidade: agente na profundidade 0 cria profundidade 1, que cria profundidade 2, bloqueado na profundidade 3. Isso falhou imediatamente. Agentes de deliberação precisam rodar em paralelo, não em série. Cinco agentes na profundidade 1 não é recursão profunda. É colaboração ampla.

A correção: um modelo de orçamento de spawn. O agente raiz recebe um orçamento (máximo de 12 agentes). Ele gasta esse orçamento criando workers paralelos. Workers herdam o orçamento restante, mas não podem excedê-lo. Isso previne cadeias descontroladas enquanto permite a execução paralela que a deliberação exige.

O teste real veio quando executei 10 agentes de revisão em posts de blog traduzidos. O limitador de recursão bloqueou os agentes 4 a 10 porque contava spawns como incrementos de profundidade. Após mudar para o modelo de orçamento, todos os 10 rodaram com sucesso. A profundidade nunca excedeu 1. A largura expandiu para corresponder à tarefa.¹⁰

Validação de consenso

Após os agentes concluírem, um hook pós-deliberação executa quatro verificações:

1. Prontidão de fase — A deliberação progrediu além da pesquisa até a classificação?
2. Quórum de agentes — Pelo menos 2 agentes concluíram? (Configurável por tipo de tarefa)
3. Limiar de consenso — O acordo atinge o nível exigido? (70% base, 85% para segurança)
4. Documentação de dissidência — Se os agentes discordam, as preocupações foram registradas?

A verificação 4 foi o insight que eu não esperava. As primeiras execuções produziam “consenso” onde os agentes simplesmente concordavam com a primeira resposta. O detector de conformidade agora sinaliza convergência prematura: se todos os agentes concordam na primeira rodada com pontuações de similaridade altas, o sistema força uma segunda rodada de análise adversarial.

O que aprendi da maneira difícil

Escritas atômicas de arquivo importam. Múltiplos agentes escrevendo no mesmo arquivo de estado simultaneamente corrompiam JSON. A correção: escrever em arquivos .tmp e depois usar mv atomicamente. O sistema operacional garante que mv é atômico no mesmo sistema de arquivos. Essa mudança de uma linha eliminou toda uma categoria de condições de corrida.

Isolamento de contexto previne pensamento de grupo. Cada agente recebe contexto independente através de quatro camadas (L0: conhecimento base, L1: específico da tarefa, L2: específico da persona, L3: específico da rodada). Sem isolamento, os agentes convergem para a primeira resposta plausível em vez de explorar o espaço de soluções. Com isolamento, o agente de Segurança e o agente de Performance chegam a conclusões genuinamente diferentes porque partem de premissas diferentes.

Testar infraestrutura de agentes é mais difícil que testar código de aplicação. O sistema tem 141 testes: 48 testes de integração bash para comportamento de hooks, 81 testes unitários Python para módulos da biblioteca e 12 simulações de pipeline ponta a ponta. Cada história de falha na memória do meu projeto (bloqueio de orçamento de spawn, falsos positivos na detecção de aspas, arquivos de plano do blog servidos acidentalmente como posts) se tornou um caso de teste após a correção. Bugs de agentes são mais difíceis de reproduzir que bugs de aplicação porque dependem de timing, ordenação e estado concorrente.

A divisão humano-agente

O padrão: humanos são responsáveis por decisões que exigem contexto organizacional, julgamento ético ou direção estratégica. Agentes são responsáveis por decisões que exigem busca computacional em grandes espaços de possibilidades.¹¹ Explorei essa divisão mais a fundo na minha análise de arquitetura de agentes.

O engenheiro de ML agêntico não codifica pipelines manualmente. O engenheiro de ML agêntico define objetivos, restrições e critérios de avaliação. Agentes lidam com o loop de implementação: propor, executar, avaliar, iterar. O papel humano muda de construtor para arquiteto: definindo guardrails, revisando saídas e fazendo julgamentos que requerem contexto de domínio que os agentes não possuem.¹²

Principais aprendizados

Para engenheiros começando com sistemas de IA: - Comece com RAG para qualquer caso de uso envolvendo conhecimento que muda frequentemente ou requisitos de atribuição de fontes; RAG fornece uma base funcional em dias, enquanto fine-tuning leva semanas de preparação de dados - Combine RAG e fine-tuning quando a aplicação precisa tanto de raciocínio de domínio QUANTO de conhecimento atual - Se você precisa de mais de uma chamada ao modelo por tarefa, você precisa de orquestração de agentes — e esse é um problema de engenharia diferente de RAG ou fine-tuning

Para equipes construindo sistemas de agentes: - Construa pontuação de confiança antes de construir agentes; a maioria das tarefas não precisa de deliberação, e o sistema que sabe quando usar agentes é mais valioso que os próprios agentes - Use orçamentos de spawn, não limites de profundidade, para arquiteturas de agentes paralelos; limites de profundidade bloqueiam padrões de colaboração ampla que a deliberação de agentes exige - Teste a qualidade do consenso, não apenas a existência de consenso; concordância prematura é pior que nenhuma concordância porque cria falsa confiança

Referências