Quando NÃO usar RAG: 4 padrões que parecem RAG mas não são

Toda squad que ouviu falar em RAG quer fazer RAG. O resultado é stack com vector store, indexador, ranker, cache, observabilidade e fatura de embedding rodando pra resolver problema que cabia em consulta SQL ou chamada direta de modelo. Reconhecer o que não é RAG economiza meses de engenharia e milhares de reais por mês em conta de Azure OpenAI.

Primeiro padrão: FAQ estruturada. Quando a base de conhecimento é fechada, cabe em alguns milhares de pares pergunta-resposta e muda devagar, a solução correta é lookup com chave normalizada, cache em Redis e fallback pra modelo só quando o match falha. Embedding de pergunta de usuário pra recuperar resposta canônica é overkill, e pior, introduz não-determinismo onde o cliente espera resposta idêntica em consulta idêntica. Custo cai em ordem de grandeza, latência idem.

Segundo padrão: classificação de documento em categorias conhecidas. Roteamento de chamado, triagem de e-mail, marcação de tipo contratual. Um fine-tune pequeno em modelo open source como Llama 3 8B ou um classificador clássico em cima de embeddings com regressão logística bate retrieval em precisão e custa frações do RAG em produção. Retrieval só ganha quando as categorias mudam toda semana e o conjunto de exemplos é instável, e isso é raro fora de moderação de conteúdo.

Terceiro padrão: busca exata por identificador, SKU, CPF, número de pedido, código de produto. Postgres com índice GIN e tsvector resolve em milissegundos por centavos de hospedagem, e a precisão é cem por cento porque o match é literal. Jogar embedding em cima disso degrada qualidade, porque vetor é bom em similaridade semântica e péssimo em igualdade exata. Vi time inteiro debater por que a busca por número de nota fiscal estava errando, quando bastava trocar o índice.

Quarto padrão: sumarização ou Q&A sobre documento único que cabe na janela de contexto. Modelos atuais aceitam centenas de milhares de tokens, e GPT-5 ou Claude Opus 4.6 leem contrato de cem páginas inteiro sem reclamar. Quebrar em chunk, indexar, recuperar top-k e remontar prompt adiciona três pontos de falha pra resolver problema que uma chamada direta resolve com qualidade melhor. Use retrieval quando o corpus não cabe, não como reflexo arquitetural.

RAG é a resposta certa quando a pergunta é aberta, o corpus é dinâmico, grande demais pra contexto, e a resposta precisa de citação verificável pra auditoria ou compliance. Suporte ao cliente sobre documentação técnica que muda toda semana, pesquisa jurídica sobre jurisprudência viva, análise de base de conhecimento corporativa com controle de acesso por documento. Fora desse shape, escolher RAG é escolher pagar caro pelo prazer da arquitetura interessante.