RAG corporativo: 7 padrões que aprendemos em deploys regulados
Permissões por documento, citações verificáveis, custo por consulta. As escolhas de arquitetura que mudam tudo quando o RAG sai do laboratório.
Retrieval Augmented Generation parece simples até o primeiro deploy regulado. Aí cada decisão pequena vira um problema. Listamos os sete padrões que recorrem em quase todo projeto que entrega bem.
1. Permissão por documento, não por usuário
A tentação inicial é mapear quem pode ler o quê no nível do usuário. Em organizações reais, isso vira um inferno de manutenção. O que funciona é etiquetar cada documento ingestado com seu próprio ACL e filtrar a recuperação por interseção entre o ACL do documento e o contexto do usuário no momento da consulta.
2. Citação obrigatória, sempre
Toda resposta precisa carregar a referência ao trecho fonte. Não como cortesia — como contrato. Se o modelo não conseguir citar, a resposta deve ser "não encontrei". A diferença entre 'sistema confiável' e 'demo divertida' está aqui.
3. Reranking importa mais que embedding
Trocar o modelo de embedding raramente muda KPI. Adicionar um reranker bem ajustado entre recuperação e geração quase sempre muda. É o investimento de melhor retorno em qualidade.
4. Cache em camadas
Cache na pergunta exata é trivial e dá pouco. Cache em embeddings semelhantes dá muito mais e exige cuidado com TTL. Cache de respostas inteiras com invalidação por mudança de documento é o que mata o custo de inferência.
5. Avaliação contínua, não pontual
Avaliação manual no início do projeto é necessária. Avaliação automatizada com golden questions é o que mantém o sistema vivo. Sem isso, você descobre que o sistema regrediu por uma reclamação, não por um alarme.
6. Quebra de chunks por estrutura, não por tamanho
Cortar o documento em pedaços de 500 tokens é o pior padrão e o mais comum. Cortar respeitando estrutura — seção, parágrafo, tabela — preserva contexto e melhora recuperação dramaticamente.
7. Modelo pequeno na borda, modelo grande no centro
Roteamento entre modelos por complexidade da pergunta corta custo em 50–70% sem perder qualidade percebida. Perguntas simples não precisam do modelo grande. Identificar quais são simples é uma classificação trivial.