O que é RAG: guia prático para empresas brasileiras
Se você ouviu falar de "RAG" em alguma reunião e ficou em dúvida se era marketing ou tecnologia de verdade — boa notícia: é tecnologia de verdade, e mais simples do que parece. Este artigo explica o conceito sem buzzword, mostra quando faz (e quando não faz) sentido para sua empresa e dá uma referência de custo realista para o mercado brasileiro.
O que é RAG, em uma frase
RAG (Retrieval-Augmented Generation, ou "geração aumentada por recuperação") é um padrão de arquitetura que faz um modelo de linguagem (LLM) responder com base nos seus documentos, e não apenas no que ele aprendeu durante o treino.
Em termos práticos: antes de pedir ao LLM que escreva uma resposta, o sistema busca os trechos mais relevantes da sua base (manuais, contratos, tickets, FAQ interno) e os injeta no prompt como contexto. O LLM lê o contexto e gera a resposta ancorada nesses trechos.
Por que isso importa para empresas?
Modelos como ChatGPT, Claude e Gemini são treinados com dados públicos da internet. Eles não conhecem:
- O contrato de prestação de serviços da sua empresa;
- O manual interno que ninguém lê mas todo mundo precisaria ler;
- Os 12.000 tickets de suporte que viram conhecimento institucional;
- A jurisprudência específica da área de atuação do seu escritório;
- O catálogo de produtos com 8.000 SKUs.
Sem RAG, você precisaria colar tudo isso no prompt — o que não cabe e ficaria caro. Com RAG, o sistema cola só os 3-5 trechos relevantes para a pergunta atual.
Como funciona, passo a passo
Existe uma fase de preparo (uma vez) e uma fase de uso (toda hora):
Fase de preparo (indexação)
- Quebra (chunking): seus documentos são partidos em pedaços de ~500-1000 caracteres.
- Embedding: cada pedaço vira um vetor numérico — uma "impressão digital" semântica.
- Armazenamento: os vetores ficam em uma vector database (pgvector, Qdrant, Pinecone, etc.).
Fase de uso (consulta)
- A pergunta do usuário também vira um vetor.
- Busca semântica: o sistema acha os 3-5 chunks mais parecidos com a pergunta (similaridade de vetores).
- Montagem do prompt: os chunks são colados como contexto: "Com base nestes trechos, responda: …"
- O LLM gera a resposta, idealmente com citação dos trechos.
Quando RAG faz sentido?
Bons cenários:
- Atendimento ao cliente sobre uma base documental grande e estável (manuais, políticas, FAQ).
- Suporte técnico interno (helpdesk consultando documentação do produto).
- Pesquisa em base jurídica, médica ou regulatória (sempre com revisão humana para domínios críticos).
- Onboarding de funcionários — "pergunte qualquer coisa sobre a empresa".
- E-commerce — descrição e comparação de produtos com base no catálogo real.
Cenários onde RAG não é a resposta:
- Quando a tarefa exige raciocínio matemático ou agendamento, não recuperação. Use ferramentas (tools/MCP) ou agentes.
- Quando o conhecimento muda a cada minuto (cotações, estoque). Aí a fonte tem que ser uma API em tempo real, não embedding.
- Quando o vocabulário do domínio é tão específico que nem o melhor modelo de embedding pega. Aí pode valer fine-tuning de embedding antes do RAG.
Quanto custa, na vida real (2026, Brasil)
Esta é a pergunta mais comum, então vou ser direto. Faixas reais que pratico em projetos B2B brasileiros:
- MVP em produção: R$ 25 mil a R$ 120 mil de implementação, dependendo do volume documental e qualidade exigida.
- Custo operacional mensal: R$ 800 a R$ 6 mil, dominado por:
- chamadas ao LLM (OpenAI, Anthropic ou modelo open-source self-hosted);
- vector database (R$ 0 com pgvector self-hosted, R$ 200-1.500 em SaaS);
- embeddings re-gerados quando a base muda.
- Tempo do zero ao MVP: 4 a 8 semanas para escopos bem definidos. 10-16 semanas com integrações legadas e LGPD.
Cinco armadilhas que vejo direto
- Chunking ingênuo — quebrar por número fixo de caracteres ignora estrutura. Capítulos, seções e metadados precisam virar contexto.
- Embedding genérico em domínio técnico — modelos default confundem termos jurídicos, médicos ou contábeis. Avalie antes de produção.
- Sem avaliação — projetos que rodam sem métrica de recall/precisão acabam virando "parece que funciona".
- Falta de fallback — quando a busca não encontra nada relevante, o sistema deveria dizer que não sabe, não inventar.
- LGPD ignorada — documentos com dado pessoal precisam de redação, anonimização e controle de acesso por papel.
Como começar (sem queimar orçamento)
Se você quer testar a ideia antes de investir pesado:
- Pegue 50-100 documentos reais do problema (FAQ, manual, contratos modelo).
- Construa um POC em 2 semanas — pgvector + um LLM via API + um chat simples. Custa < R$ 500 em infra.
- Teste com 10-20 perguntas reais de usuários de verdade. Anote acertos e erros.
- Decida: se acertou ≥ 70% nas perguntas relevantes, vale investir no MVP de produção. Se ficou abaixo, é sinal de problema na base documental, não na tecnologia.
Conclusão
RAG não é mágica nem moda passageira. É uma técnica simples de juntar busca semântica com geração de texto — e que resolve o problema mais comum de IA generativa em empresas: "como faço o LLM saber das minhas coisas".
Se você quer aplicar isso na sua empresa, o caminho honesto é começar pequeno: um POC de duas semanas com perguntas reais já mostra se o problema é tratável ou não. Se faz sentido conversar sobre seu caso específico, o diagnóstico inicial é gratuito.