Definição estendida
RAG (Retrieval-Augmented Generation) é uma arquitetura que combina dois componentes: um sistema de recuperação que busca documentos relevantes a partir de uma consulta, e um modelo de geração de linguagem que produz a resposta condicionada nos documentos recuperados. A formalização canônica é Lewis et al. (2020, NeurIPS), que demonstrou ganhos significativos em tarefas de pergunta e resposta de domínio aberto ao combinar recuperador denso com modelo gerador. Funcionamento típico: a consulta é convertida em vetor de embedding, comparada por similaridade do cosseno contra base de documentos pré-indexada (FAISS, Qdrant, Weaviate, Pinecone), os top- documentos mais similares são recuperados, e injetados como contexto no prompt do modelo gerador (LLM). Karpukhin et al. (2020) é referência paralela para dense passage retrieval, componente comum em pipelines RAG modernos. A motivação central da arquitetura é dupla: permite que LLMs respondam sobre conhecimento posterior ao corte de treinamento ou específico de domínio sem ajuste, e reduz substancialmente alucinação ao ancorar a resposta em texto factual recuperado.
Quando se aplica
RAG é apropriado quando o sistema precisa responder a perguntas com base em corpus de conhecimento atualizado ou específico de domínio — bases de literatura científica, jurisprudência, documentação técnica, prontuários institucionais, manuais de produto. É padrão em chatbots empresariais, ferramentas de busca semântica em bibliotecas de PDFs, assistentes de pesquisa, e sistemas de Q&A em documentação. É também escolha quando custo de ajuste fino é proibitivo ou quando o conteúdo precisa ser atualizável sem retreinamento.
Quando NÃO se aplica
Não se aplica quando o conhecimento já está no modelo pré-treinado e o ganho de recuperação não justifica o overhead arquitetural. Não se aplica quando recuperação degrada qualidade — em domínios onde modelo generativo já tem cobertura forte e adicionar contexto recuperado introduz ruído. Não substitui pré-treinamento ou ajuste fino quando o problema é entender vocabulário ou estrutura específica de domínio — RAG adiciona conhecimento factual, não capacidade de processamento. Em escala muito grande (milhões de consultas/dia), latência da busca + geração pode ser inviável sem otimização agressiva. RAG não resolve viés ou alucinação quando o próprio corpus recuperado tem problemas — ancoragem em fontes ruins produz respostas confiantes e erradas.
Aplicações por área
— Pesquisa acadêmica e bibliometria: sistemas Q&A sobre literatura científica, sumarização de papers, busca semântica em corpora especializados. — Direito: consulta a jurisprudência atualizada, busca em precedentes, análise de contratos contra base normativa. — Saúde: suporte à decisão clínica baseado em literatura biomédica recente, busca em diretrizes atualizadas. — Empresarial: assistentes de produto baseados em documentação interna, ferramentas de onboarding, base de conhecimento técnico.
Armadilhas comuns
A primeira armadilha é depender de RAG sem avaliar qualidade da recuperação — sistema com 60% de recall traz documentos relevantes só metade do tempo, e respostas geradas refletem essa lacuna. Avaliação separada do componente recuperador é etapa essencial. A segunda é ignorar custo computacional e de armazenamento da indexação vetorial — embeddings densos para corpus grande têm custos não-triviais em FAISS/Qdrant/Pinecone. A terceira é confiar que RAG elimina alucinação: quando o corpus recuperado é insuficiente ou inadequado, o modelo gerador continua produzindo resposta confiante e factualmente incorreta. A quarta é misturar embeddings de modelos diferentes em mesmo índice — vetores não são comparáveis entre modelos, e busca produz resultado sem sentido. A quinta é não citar as fontes recuperadas na resposta final: para aplicação acadêmica e jurídica, citar é obrigatório, e arquitetura RAG facilita isso, mas requer engenharia explícita.