RAG (Retrieval-Augmented Generation) é a arquitetura que conecta um LLM ao conhecimento privado da sua empresa em tempo de execução, sem treinar modelo, sem expor dado para o provedor, e com a possibilidade de citar a fonte de cada resposta. Em 2026, é a abordagem padrão para chatbot interno, atendimento ao cliente, copilot de produto, suporte a engenharia e qualquer caso que precisa que a IA responda com base em seu conteúdo, não no conhecimento genérico do modelo.
Este guia explica como RAG funciona de verdade, quais decisões importam, quais armadilhas evitar e como medir qualidade para sair do "parece que funciona" para "funciona em produção com métrica".
Por que RAG e não fine-tuning
Existem três formas de fazer um LLM saber algo que ele não sabia: (1) colocar no prompt (in-context), (2) treinar o modelo (fine-tuning), (3) recuperar dinamicamente (RAG). RAG combina as vantagens das três: contexto fresco e atualizável como (1), capacidade de absorver corpus grande como (2), e custo operacional baixo como (3).
Fine-tuning brilha quando o estilo de resposta importa muito (voz, formato, tom) ou quando há padrões linguísticos específicos. Conhecimento factual, porém, é território natural de RAG: você pode atualizar a base sem retrainar, citar a fonte e revogar acesso a documentos específicos. Para a maioria dos casos corporativos, RAG vence.
Anatomia de um pipeline RAG completo
Sete etapas. 1. Ingestão: extração de conteúdo de fontes (PDF, HTML, Word, Confluence, Notion, repositórios, banco). Inclui OCR para imagens, parsing de tabela, preservação de hierarquia. 2. Limpeza e normalização: remoção de boilerplate, deduplicação, anonimização quando aplicável. 3. Chunking: divisão em pedaços com tamanho e estrutura adequados. 4. Geração de embeddings: cada chunk vira um vetor. 5. Indexação: vetores + metadados são guardados no vector DB. 6. Retrieval: dada uma query, recuperar os top-K chunks mais relevantes via similaridade + filtros + re-ranking. 7. Geração: chunks recuperados entram no prompt e o LLM gera a resposta, citando fontes.
Chunking: a decisão que mais impacta qualidade
Chunking ruim sabota qualquer modelo. Princípios. Respeite estrutura: dividir por seção, parágrafo ou bloco de código, não por contagem cega de tokens. Tamanho coerente com o domínio: 256-512 tokens para FAQ curto; 800-1200 para documentação técnica; 2000+ para código que precisa de contexto. Overlap entre chunks de 10-20% para preservar continuidade. Enriqueça com contexto: cada chunk carrega título do documento, breadcrumb da seção, data, autor, fonte.
Padrão avançado: contextual retrieval, em que cada chunk recebe uma frase curta gerada por LLM descrevendo o contexto do chunk dentro do documento maior. Esse pequeno enriquecimento eleva drasticamente o recall em queries ambíguas.
Retrieval híbrido e re-ranking
Busca puramente vetorial perde em queries com termo exato (nome de produto, sigla, código de erro). Busca puramente keyword perde em queries com paráfrase. O caminho moderno é híbrido: combinar BM25 com similaridade vetorial e fundir os resultados com um esquema como RRF (Reciprocal Rank Fusion).
Acima da fusão, vem o re-ranker. Pegando os top-50 do retrieval e reordenando com modelo especializado (Cohere Rerank, Voyage Reranker, BGE Reranker), você dobra a precisão em muitos casos, com custo marginal aceitável. Em RAG sério, re-ranker quase sempre vale a pena.
Prompt de geração: o último km
O prompt de geração faz ou quebra a resposta. Boas práticas. Injetar o contexto recuperado em bloco identificável, com fonte. Instruir a citar fonte em cada afirmação. Instruir a admitir não saber quando o contexto não cobre a pergunta. Limitar criatividade em domínios sensíveis (médico, jurídico, financeiro): "responda apenas com base no contexto fornecido". Pedir formato estruturado quando aplicável (JSON, markdown, bullet).
Avaliação de RAG: métricas que importam
Sem avaliação, RAG vira sensação. Métricas necessárias. Recall@k e Precision@k: do retrieval, quantos chunks relevantes apareceram nos top-k. MRR (Mean Reciprocal Rank): posição média do chunk certo. Faithfulness: a resposta gerada usa de fato o contexto, sem inventar. Answer relevancy: a resposta responde à pergunta. Context precision: o contexto recuperado é majoritariamente útil ou tem ruído. Frameworks como Ragas, TruLens, Phoenix e DeepEval automatizam essas métricas.
Monte cedo um dataset de avaliação com 50 a 200 pares pergunta/resposta esperada, e rode antes de cada mudança no pipeline. Sem isso, mudança boa às vezes piora a qualidade média e ninguém percebe.
Permissões e multi-tenant
Vector DB não tem ACL nativa em vários casos. Você precisa modelar permissões no nível de chunk. Padrões. Filtro de metadado: cada chunk traz lista de grupos/usuários que podem ver; consulta filtra pelo grupo do usuário. Coleção por tenant: cada cliente em uma coleção separada (mais isolamento, mais custo operacional). Camada de pós-processamento: filtra resultado antes de mandar pro LLM com base em ACL do sistema de origem.
Tratar permissão como afterthought é o erro mais caro em RAG corporativo: vazamento entre clientes ou entre departamentos vira incidente sério rapidamente.
Atualização e ingestão contínua
Dado muda. Sua base de conhecimento precisa ser incrementada continuamente, não reindexada toda vez. Padrão: fila de eventos de fontes (webhook do Confluence, polling do Drive, CDC do banco) que dispara ingestão incremental, com versionamento de documento e deduplicação de chunks. Documento removido na origem deve ser removido (ou marcado) na base; senão, IA cita fonte morta.
Onde RAG falha (e como contornar)
RAG sofre em alguns cenários. Perguntas agregativas ("quantos clientes pediram cancelamento este mês?"): vector DB não soma; combine RAG com SQL ou agente que delega para query estruturada. Perguntas que exigem raciocínio multi-hop ("se A depende de B e B mudou em janeiro, qual o impacto em C?"): RAG simples não navega cadeia; use agente que faz múltiplas buscas guiadas. Perguntas sobre código com referência a símbolo específico: chunking precisa preservar AST; busca pura por embedding perde. Use combinação com índice de símbolos.
RAG como produto, não como projeto
RAG bom é produto vivo: tem owner, métricas, ciclo de melhoria, evals contínuos, observabilidade. Empresas que tratam como projeto que "fica pronto" veem qualidade degradar com o tempo enquanto dado muda e padrão de uso evolui. Empresas que tratam como produto colhem ganho composto.
Na Steply, montamos RAG corporativo em ciclos curtos: do diagnóstico do conhecimento disponível ao primeiro caso de uso em produção, com observabilidade e evals, em poucas semanas. A partir daí, evolui com o uso real, conectando novas fontes, refinando re-ranking e expandindo para mais casos.
