Regras, RAG ou agentes: como escolher a arquitetura

Para escolher entre regras, geração aumentada por recuperação (RAG) e agentes de IA, comece pelo trabalho que o produto precisa resolver. Regras resolvem melhor decisões estáveis e auditáveis. RAG ajuda quando a resposta depende de conhecimento recuperável. Agentes fazem sentido quando o produto precisa planejar passos, usar ferramentas e adaptar a execução. Quanto maior a autonomia, maior precisa ser o controle sobre risco, medição e revisão.

O erro comum é escolher a arquitetura antes do tipo de trabalho

A pergunta “devemos usar RAG ou agentes de IA?” costuma aparecer cedo demais. Antes dela, existe outra mais útil: qual decisão, resposta ou execução o produto precisa sustentar?

Em uma funcionalidade inteligente, tarefas diferentes podem estar misturadas na mesma tela. Uma parte pode ser uma decisão binária, como bloquear ou liberar uma ação. Outra pode ser uma resposta baseada em uma política interna. Outra pode exigir consultar dados, acionar um sistema, pedir confirmação e concluir uma operação. Chamar tudo isso de “IA” empobrece a decisão técnica e aumenta o risco de construir uma arquitetura maior do que o problema.

A Anthropic distingue fluxos com caminhos predefinidos de agentes que decidem dinamicamente seu processo e uso de ferramentas, além de recomendar começar pela solução mais simples e acrescentar complexidade quando necessário, em seu texto sobre padrões de agentes. Essa distinção é útil porque tira o agente do lugar de destino inevitável. Às vezes, o melhor produto inteligente é uma regra bem desenhada. Às vezes, é uma busca com geração de resposta. Às vezes, é um agente com autonomia limitada.

A decisão de arquitetura precisa caber na operação do produto. Se a equipe não consegue explicar por que uma resposta foi dada, medir exceções, revisar erros e limitar ações, aumentar a autonomia apenas desloca a complexidade para produção.

Quando regras resolvem melhor do que IA generativa

Regras de negócio são instruções explícitas que determinam o comportamento do sistema diante de condições conhecidas. Elas funcionam bem quando a lógica é estável, os critérios são claros e a organização precisa auditar a decisão sem interpretar uma resposta probabilística.

Use regras quando a tarefa se parece com isto:

• Se o status for A e a condição B estiver presente, aplicar C.
• Se a solicitação não cumprir um critério mínimo, bloquear a ação.
• Se houver uma exceção conhecida, encaminhar para revisão.
• Se uma prioridade depender de campos estruturados, ordenar por uma regra definida.

O valor das regras está na previsibilidade. Elas são mais fáceis de testar, explicar e manter quando o domínio não muda o tempo todo. Também podem ser a melhor escolha quando um erro operacional tem impacto alto e a organização prefere uma decisão determinística a uma resposta fluida.

O limite aparece quando a quantidade de exceções cresce tanto que a manutenção vira o verdadeiro produto. Se cada nova situação exige mais uma regra, mais uma exceção e mais uma condição encadeada, talvez a tarefa não seja tão estável quanto parecia. Ainda assim, isso não leva automaticamente a agentes. Pode levar a uma revisão do processo, a uma base de conhecimento melhor ou a um desenho de experiência mais explícito.

Um critério simples: se uma liderança de produto consegue descrever a decisão em condições estáveis e a equipe consegue testar os principais caminhos sem depender de interpretação semântica, regras provavelmente são suficientes.

Quando RAG ou agentes de IA entram em decisões diferentes

RAG significa geração aumentada por recuperação: o modelo gera uma resposta usando informações recuperadas de uma fonte externa. O artigo de Lewis e colaboradores apresenta essa combinação entre geração e recuperação de passagens. Para a decisão de produto discutida aqui, RAG é uma opção quando a resposta depende de conhecimento disponível. A pergunta do usuário pode variar, mas a fonte de resposta precisa estar ancorada em informações recuperáveis.

A Anthropic define engenharia de contexto como a seleção e manutenção das informações disponíveis ao modelo durante a inferência, incluindo instruções, ferramentas, dados externos e histórico, dentro de uma janela limitada, em seu material sobre engenharia de contexto. Essa definição ajuda a separar duas coisas que o mercado mistura: recuperar contexto não é o mesmo que dar autonomia.

Uma busca com RAG pode responder: “qual política se aplica a este caso?”, “como este recurso funciona?” ou “quais passos o usuário deve seguir?”. Ela não precisa decidir sozinha que sistemas acionar, que exceções negociar ou que operação concluir.

O limite do RAG é igualmente importante. Ele não transforma conhecimento desorganizado em decisão confiável por si só. Se a base está desatualizada, ambígua ou contraditória, a resposta pode ficar bem escrita e ainda assim ser ruim. RAG aumenta a capacidade de trazer contexto para o modelo, mas não substitui curadoria, governança de conteúdo e desenho de limites.

Por isso, antes de usar RAG, vale perguntar: o produto tem conhecimento recuperável, com fonte, escopo e atualização minimamente controlados? Se a resposta for não, a primeira melhoria pode estar no conhecimento de domínio, não no modelo. Esse ponto se conecta diretamente ao trabalho de organizar conhecimento de domínio para IA no produto.

Quando agentes de IA fazem sentido no produto

Agentes de IA fazem sentido quando a tarefa exige mais do que responder. O sistema precisa decidir dinamicamente quais passos seguir, quando consultar uma ferramenta, como adaptar o caminho diante de uma resposta intermediária e quando parar.

Isso pode incluir investigar uma solicitação, consultar diferentes sistemas, comparar informações, propor uma ação e executá-la dentro de limites definidos. O ponto não é o agente “pensar” de forma abstrata. O ponto é o produto delegar ao sistema parte da escolha do processo.

Essa autonomia muda o tipo de risco. Uma resposta incorreta em uma busca assistida já pode ser problemática. Uma ação incorreta executada por um agente pode gerar retrabalho, perda de confiança ou uma operação difícil de reverter. Por isso, agentes pedem limites de permissão, trilhas de decisão, observabilidade, testes por tipo de tarefa e critérios de interrupção.

A escolha madura separa execução automatizável, revisão necessária e decisão que não deve ser delegada.

Um bom sinal para considerar agentes é a presença simultânea de variação no caminho, uso de ferramentas e necessidade de adaptação durante a execução. Se a tarefa sempre segue o mesmo caminho, um fluxo predefinido pode resolver. Se a tarefa exige apenas consultar conhecimento, RAG pode bastar. Se a tarefa exige escolher caminhos diferentes e acionar recursos para concluir um objetivo, agentes entram na conversa.

Critérios para escolher a menor camada suficiente

Antes de escolher regras, RAG ou agentes de IA, responda às perguntas abaixo e escolha a menor camada que passa no critério. O objetivo não é reduzir ambição. É evitar que a sofisticação técnica esconda uma tarefa mal definida.

• Condições estáveis e poucas exceções: regras tendem a ser suficientes.
• Consulta a documentos, políticas, histórico ou base de conhecimento antes da resposta: RAG tende a ser mais proporcional do que regras puras.
• Escolha de passos diferentes durante a execução: agentes podem ser considerados.
• Acionamento de ferramentas ou sistemas externos para concluir a tarefa: agentes podem fazer sentido, desde que haja limites, permissões e revisão.
• Erro com potencial de perda financeira, quebra de confiança ou ação irreversível: reduza autonomia, explicite aprovação humana ou mantenha regras determinísticas.
• Medição de qualidade, latência, custo e exceções por tipo de tarefa: sem medição mínima, evite aumentar autonomia.
• Mudança frequente ou contexto incompleto: prefira uma abordagem que exponha limites e permita revisão antes de automatizar execução.

A comparação prática fica assim: regras são melhores para decisões estáveis, auditáveis e com critérios explícitos. RAG é melhor para respostas que precisam recuperar conhecimento antes de gerar uma síntese. Agentes são melhores para tarefas com múltiplos passos, uso de ferramentas e adaptação durante a execução.

O alerta é diferente em cada caso. Regras ficam frágeis quando as exceções dominam. RAG fica frágil quando o conhecimento é ruim. Agentes ficam frágeis quando a autonomia cresce sem controle operacional.

Exemplo fictício: suporte a cobranças em um SaaS

Imagine um SaaS com uma área de suporte a cobranças. O exemplo é fictício, criado apenas para aplicar os critérios.

A equipe quer reduzir esforço em tickets recorrentes e acompanhar se a experiência do usuário se mantém aceitável. A primeira tentação é criar um agente que “resolva cobrança”. Mas “cobrança” não é uma única unidade de decisão. É uma área com classificações, respostas e fluxos de naturezas diferentes.

Para classificar o status de pagamento, regras podem resolver melhor. Se o pagamento está confirmado, a assinatura está ativa. Se a tentativa falhou, o produto mostra o motivo disponível e orienta a próxima ação. Se há divergência entre campos internos, encaminha para revisão. A decisão depende de dados estruturados e critérios explícitos.

Para responder dúvidas sobre política de reembolso, prazos ou emissão de segunda via, RAG pode ser mais proporcional. O usuário pergunta em linguagem natural, o produto recupera trechos da política, sintetiza a resposta e mostra limites. Aqui, a dificuldade está em encontrar e usar o conhecimento correto, não em planejar uma operação inteira.

Se a sequência de consultas e ações for sempre a mesma, um fluxo predefinido pode verificar a assinatura, consultar a tentativa de pagamento e encaminhar a solicitação. Um agente passa a ser uma alternativa quando precisa escolher dinamicamente o próximo passo conforme as informações encontradas. Mesmo nesse caso, ações como reenviar uma cobrança podem exigir confirmação explícita do usuário ou encaminhamento para uma pessoa.

Os efeitos esperados desse desenho seriam hipóteses a medir, não resultados presumidos. A hipótese pode ser que regras reduzam ambiguidades em classificações simples, que RAG melhore a consistência de respostas baseadas em política e que agentes ajudem em fluxos com muitas etapas. Cada hipótese precisa de observação em produção ou experimento controlado antes de virar convicção.

A Microsoft descreve sua plataforma ExP como uma forma de incorporar experimentação ao ciclo de desenvolvimento, validar hipóteses, medir impacto e iterar produtos, em sua página sobre experimentação. Isso não significa que feedback de usuário retreine automaticamente um modelo. Significa que decisões de produto podem ser tratadas como hipóteses verificáveis.

Como medir se a escolha continua adequada

A arquitetura certa no lançamento pode deixar de ser a certa depois. O volume muda, as exceções aparecem, o conhecimento fica desatualizado e o comportamento dos usuários revela tarefas que a equipe não tinha nomeado.

Acompanhe a escolha por tipo de tarefa, não apenas pela funcionalidade inteira. Uma mesma área do produto pode combinar regras, RAG e agentes. Se a medição mistura tudo, a equipe não sabe qual camada está funcionando e qual está aumentando custo ou risco.

Alguns sinais práticos merecem revisão:

• A taxa de exceções em regras cresce.
• As respostas com RAG dependem de documentos ambíguos ou desatualizados.
• O agente precisa pedir ajuda em etapas que deveriam estar bem definidas.
• A latência percebida prejudica o fluxo do usuário.
• O custo por tarefa cresce sem ganho proporcional de qualidade.
• A intervenção humana aparece tarde demais, apenas depois de uma ação ruim.
• A equipe não consegue explicar por que uma decisão foi tomada.

A confiabilidade entra na decisão de produto quando muda limites de autonomia, revisão e escala. O Google SRE define objetivos de nível de serviço como metas de confiabilidade que orientam decisões de engenharia, com acordo sobre metas, uso de orçamento de erro para priorização e processo de revisão, no guia sobre SLOs. Para funcionalidades inteligentes, essa lógica ajuda a discutir o nível aceitável de falha, atraso, exceção e revisão antes de escalar autonomia.

Isso se conecta ao desenho mais amplo de inteligência no produto: software com IA não melhora apenas porque ganhou um modelo. Ele melhora quando a organização aprende a separar tarefa, contexto, limite, métrica e responsabilidade.

A arquitetura mínima suficiente é a menor camada capaz de resolver a tarefa com qualidade aceitável: regras para decisões estáveis, RAG para respostas baseadas em conhecimento recuperável e agentes para execução dinâmica com ferramentas e limites claros. Antes de aumentar autonomia, a pergunta útil é simples: qual parte da tarefa realmente precisa decidir o próximo passo?

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

• Como escolher uma funcionalidade de IA para o produto

Fontes

• Lewis et al.: Retrieval-Augmented Generation

• Anthropic: Building effective agents
• Anthropic: Effective context engineering for AI agents
• Microsoft Research: Experimentation Platform
• Google SRE: Implementing SLOs