Quando RAG é a resposta errada: uma matriz de decisão para sistemas de IA

Use RAG quando o trabalho é recuperar informação relevante de textos que mudam e fundamentar a resposta nesses textos. Não use RAG quando o trabalho real é ler um sistema de registro, seguir um procedimento repetível ou executar uma ação determinística.

Essa distinção importa porque retrieval adiciona custo, latência, ruído de recuperação e superfície de segurança. Se o problema do produto é, na verdade, "consultar a verdade num banco de dados" ou "seguir um workflow conhecido com segurança", RAG não é sofisticação. É indireção.

Times costumam recorrer a RAG porque querem um de quatro resultados:

• respostas atualizadas a partir de documentos que mudam
• respostas fundamentadas, com citações
• acesso a conhecimento privado que não deveria viver no prompt
• uma forma de fazer um sistema fraco parecer mais esperto

Só os três primeiros são bons motivos. O quarto é sinal de alerta. Se a resposta já vive numa API de faturamento, num banco de contas ou num motor de regras, retrieval costuma ser a abstração errada.

RAG é mais forte quando a fonte da verdade é textual, grande e volátil. Essa é a motivação original do retrieval-augmented generation como forma de combinar modelos de linguagem com memória não-paramétrica, em vez de forçar cada fato para dentro dos pesos do modelo (Lewis et al.).

RAG é um bom encaixe quando:

• a resposta depende de documentos, não de estado transacional
• o corpus muda com frequência suficiente para prompts ou fine-tuning começarem a derivar
• citações ou evidências importam
• usuários querem síntese ou explicação mais do que ação
• o corpus é grande demais para caber num prompt de forma confiável

É por isso que RAG funciona bem para assistentes de manuais internos, bases de conhecimento de suporte, consulta de políticas e sumarização em estilo de pesquisa.

RAG costuma ser a resposta errada quando o problema é operacional, não documental.

Se o usuário pergunta "qual é o status da minha fatura?" ou "esse cliente tem direito a reembolso?", o sistema de registro já existe. Uma consulta a banco ou uma chamada de API é mais barata, mais rápida e mais fácil de auditar do que retrieval.

Se o modelo precisa triar uma solicitação, seguir um playbook de aprovação ou normalizar entradas antes de uma ação downstream, isso é memória procedural. Codifique o processo como uma skill reutilizável ou um workflow restrito, em vez de recuperar fragmentos de prosa e torcer para o modelo remontar o procedimento corretamente.

RAG pode ajudar um modelo a explicar uma decisão, mas não deveria ser dono da ação em si. Se o sistema precisa criar, atualizar, aprovar, reembolsar ou encerrar algo, uma chamada de ferramenta com contrato no servidor é a primitiva mais segura.

Retrieval não é grátis. Você paga por indexação, chunking, recuperação, montagem de prompt e tokens extras em cada requisição. Se o trabalho é uma consulta rápida ou uma ação delimitada, esse overhead costuma ser desperdício.

RAG também amplia a superfície de instrução. Texto recuperado não confiável pode contrabandear instruções maliciosas — é por isso que prompt injection é tratado hoje como categoria de risco primária no projeto GenAI da OWASP (OWASP LLM01). Se o sistema pode agir com base na resposta, esse risco vira arquitetural, não cosmético.

Use esta matriz antes de desenhar a feature:

O erro mais comum é usar RAG para resolver um problema de tools ou de skills. Retrieval pode dar contexto, mas não deveria carregar um workflow que de fato precisa de lógica explícita, avaliação e validação.

Rode este checklist antes de adicionar retrieval:

1. A fonte da verdade já é estruturada num banco ou API?
2. A resposta precisa de citações de um texto que muda?
3. O modelo precisa agir, ou apenas explicar?
4. A tarefa é um procedimento repetível, e não uma consulta de conhecimento?
5. Custo de execução e latência são fortemente restritos?
6. Conteúdo recuperado criaria exposição de segurança inaceitável?

Se você respondeu "sim" a 1, 3, 4 ou 6, comece desenhando tools ou skills em vez de partir para RAG por padrão.

Funcionários fazem perguntas sobre um manual que muda toda semana. Citações importam, o corpus é textual e a resposta é explicativa. RAG é o ponto de partida certo.

Usuários perguntam status de fatura, data de renovação ou elegibilidade para reembolso. Os dados já vivem no sistema de faturamento. Use ferramentas que chamam o sistema de registro, não retrieval.

O sistema precisa classificar um caso recebido, aplicar um playbook conhecido e escolher o próximo passo. Isso é memória procedural. Use uma skill ou workflow restrito — e avalie com a mesma disciplina descrita em avaliação antes da orquestração.

O trabalho é manter estilo consistente em muitas saídas. Se o mesmo comportamento se repete com frequência suficiente, fine-tuning pode ser mais eficiente que prompts carregados de retrieval. A orientação de fine-tuning da OpenAI faz a mesma distinção: use tuning quando o comportamento repetido importa mais que puxar fatos novos a cada requisição (guia de fine-tuning da OpenAI).

RAG costuma ser apresentado como técnica de grounding, mas o grounding é tão bom quanto a qualidade do retrieval e dos documentos.

Modos de falha comuns incluem:

• recuperar o chunk errado
• misturar trechos contraditórios
• citar material desatualizado
• esconder incerteza atrás de prosa fluente
• deixar texto malicioso recuperado influenciar instruções

Se o sistema precisa agir com base na resposta, valide a ação separadamente. A OWASP LLM Prompt Injection Prevention Cheat Sheet é útil aqui por um motivo simples: conteúdo recuperado é dado, não autoridade.

Não use RAG para compensar a falta de design de sistema.

RAG não substitui:

• APIs limpas
• fronteiras de domínio
• validação de ações
• observabilidade
• avaliação

Se o modelo precisa saber algo, recupere. Se o modelo precisa fazer algo, chame uma ferramenta. Se o modelo precisa seguir um processo, codifique o processo como skill. Se o modelo precisa de comportamento estável em escala, considere fine-tuning.

Essa separação mantém os sistemas mais fáceis de debugar, mais baratos de rodar e mais seguros de evoluir. Também deixa o UX mais claro — é por isso que o tema conecta naturalmente com desenhando UX útil para IA.