RAG é caro. Quando NÃO usar.

RAG (Retrieval-Augmented Generation) é a primeira coisa que time técnico tenta quando precisa de IA com base de conhecimento. Vector store + embeddings + retrieval + LLM. Pareceu padrão. Mas RAG tem custo escondido e nem sempre é a resposta certa.

Esse post é o oposto do hype. Quando NÃO usar RAG, o que usar no lugar, e como evitar virar refém de Pinecone.

O custo escondido de RAG

Time vê demo de RAG e pensa "fácil". A realidade em produção:

• Vector store custa. Pinecone, Weaviate, Qdrant — todos cobram por documento ou por consulta. 50k documentos viram R$ 800-2.000/mês.
• Embeddings custam. Cada documento processado custa tokens. Re-embedding ao mudar modelo: paga tudo de novo.
• Manutenção é constante. Documento atualiza, você re-indexa. Documento sai, você remove. Pipeline ETL pra isso é trabalho permanente.
• Qualidade nem sempre escala. RAG genérico funciona bem com 100 docs. Em 50k docs, sem chunking inteligente e re-ranking, retrieval traz lixo.
• Latência aumenta. Cada chamada vira: embedding da pergunta + retrieval + LLM. 3 etapas, 3 latências.

Soma: RAG mal-feito vira sistema lento, caro e que mente confiantemente em casos de borda.

Quando RAG faz sentido

Antes de bater forte, vale dizer: tem caso onde RAG é a opção certa.

• Base muito grande (100k+ documentos) com consulta rara. Custo amortizado.
• Documentos heterogêneos que não cabem no contexto. PDF, .docx, planilha misturados.
• Atualização frequente com necessidade de busca em tempo real. Vector store atualiza, sistema responde com info nova.
• Multi-tenancy onde cada cliente tem sua base e busca isolada.

Esses casos justificam o investimento. O resto, vamos olhar alternativa.

4 alternativas a RAG (e quando usar cada uma)

1. Long-context puro

Modelos de fronteira hoje aceitam 200k-1M tokens. Se sua base inteira cabe, mande tudo no prompt. Vantagens:

• Zero infraestrutura. Sem vector store, sem embeddings.
• Qualidade superior. Modelo vê tudo, sem chunking burrinho perdendo contexto.
• Mais barato em volume baixo. Claude Sonnet com 200k tokens custa ~$3 por chamada. Se você faz 100 chamadas/dia, são $300/mês — mais barato que Pinecone + embeddings.

Quando: base estática ou semi-estática até ~500 documentos. FAQ extenso, manual de produto, docs internos.

2. Prompt caching

Anthropic e OpenAI hoje permitem cache do prompt. Você manda toda a base 1 vez, paga 1 vez. Próximas chamadas usam cache barato. Reduz custo em ~90% em padrões repetitivos.

Quando: base grande mas poucos usuários simultâneos. Atendimento que repete 80% do contexto.

3. Estruturação prévia + tool calling

Em vez de dar texto cru pra LLM buscar, estrutura primeiro. Catálogo de produto vira JSON. Tabela de preço vira função getPricing(sku, qty). Documentação vira FAQ indexado.

LLM chama tool quando precisa de info, não busca em vector. Vantagens:

• Resposta determinística.
• Mais barato (estrutura é compacta).
• Auditável (você sabe qual tool foi chamada).

Quando: dado tem estrutura óbvia. Catálogo, tabela de preço, regra de negócio.

4. Fine-tuning leve (LoRA / adapters)

Casos extremos com domínio muito específico (jurídico, médico) e volume alto: fine-tuning de um modelo menor pode sair mais barato e mais rápido que RAG sobre modelo grande.

Quando: vocabulário muito específico + volume justifica + tempo pra calibrar.

A regra que aplicamos

Na Kode, perguntamos isso antes de partir pra RAG:

1. Cabe no contexto? Se sim, vai de long-context. Avalia depois.
2. Tem estrutura óbvia? Se sim, vai de tool calling.
3. Repete contexto? Se sim, prompt caching.
4. Realmente precisa de busca semântica em volume alto? Aí sim, RAG.

A maioria dos casos cai em 1, 2 ou 3. RAG fica pra ~20% dos projetos onde realmente é a melhor escolha.

A pegadinha do "padrão"

A maior armadilha do RAG é o canto de "tem que ser RAG porque é o padrão". Não tem padrão. Tem o que faz sentido pra seu caso. RAG mal-feito custa mais que SaaS pronto, demora mais pra entregar e funciona pior.

A engenharia AI-native começa por escolher a ferramenta certa, não por aplicar o template de moda.