O que é RAG (Retrieval-Augmented Generation) e quando usar

RAG significa Retrieval-Augmented Generation, ou geração aumentada por recuperação. É uma técnica que conecta um modelo de linguagem a uma base de conhecimento externa: antes de responder, o sistema busca trechos relevantes de documentos reais e os injeta no prompt. O modelo então gera a resposta usando esse material como referência, em vez de depender apenas do que aprendeu no treinamento.

É uma das arquiteturas mais úteis para construir aplicações de IA sérias, e este texto explica por que ela existe, como funciona por dentro e quando faz sentido adotá-la.

O problema que o RAG resolve

Um LLM aprende padrões de linguagem e fatos durante o treinamento, mas esse conhecimento tem limites. Ele é congelado na data em que o treinamento terminou, então o modelo não conhece eventos recentes. Ele não tem acesso aos seus dados privados, como a documentação interna da sua empresa ou o histórico de um cliente específico. E quando não sabe algo, ele tende a inventar uma resposta plausível, o fenômeno das alucinações que já discutimos no texto sobre o que é um LLM.

Você poderia tentar resolver isso re-treinando o modelo com seus dados, mas isso é caro, lento e precisa ser refeito toda vez que a informação muda. RAG oferece um caminho mais simples: em vez de ensinar o fato ao modelo, você entrega o fato no momento da pergunta. O conhecimento fica numa base externa que você atualiza livremente, e o modelo apenas consulta e redige.

Como o RAG funciona por dentro

O fluxo tem duas grandes fases: a preparação da base e o atendimento a uma consulta. Vale entender cada uma.

Indexação: preparando a base de conhecimento

Antes de qualquer pergunta, você processa seus documentos. Primeiro os quebra em pedaços menores, chamados chunks, geralmente de alguns parágrafos cada. Isso porque um documento inteiro é grande demais para caber no contexto e porque trechos menores são mais precisos na busca.

Cada chunk passa por um modelo de embedding, que converte o texto em um vetor: uma lista de números que representa o significado daquele trecho. Textos com sentido parecido geram vetores próximos no espaço matemático. Esses vetores são guardados num banco de dados vetorial, junto com o texto original. Essa etapa é feita uma vez e reaproveitada em todas as consultas.

Recuperação e geração: atendendo a pergunta

Quando o usuário faz uma pergunta, o sistema converte essa pergunta em um vetor usando o mesmo modelo de embedding. Depois busca no banco vetorial os chunks cujos vetores são mais próximos do vetor da pergunta, ou seja, os trechos semanticamente mais relacionados. Essa é a parte retrieval.

Os trechos recuperados são então inseridos no prompt, junto com a pergunta original e uma instrução do tipo "responda usando apenas o contexto abaixo". O LLM gera a resposta ancorada nesse material. Essa é a parte generation. O resultado é uma resposta que combina a fluência do modelo com a precisão factual dos seus documentos.

Por que a busca é semântica e não por palavra-chave

Um detalhe importante é que a busca do RAG não funciona como um Ctrl+F. Se o usuário pergunta "como cancelo minha assinatura" e o documento diz "para encerrar seu plano, acesse as configurações", uma busca por palavra-chave falharia, porque as palavras não batem. A busca por embeddings acerta, porque "cancelar assinatura" e "encerrar plano" têm significados próximos e, portanto, vetores próximos.

Essa capacidade de encontrar por significado, e não por correspondência literal, é o que torna o RAG robusto. O usuário não precisa usar exatamente as mesmas palavras dos documentos. Na prática, muitos sistemas combinam busca semântica com busca por palavra-chave tradicional, uma abordagem chamada busca híbrida, para pegar o melhor dos dois mundos.

Quando usar RAG

RAG brilha em cenários específicos. Vale considerá-lo quando você reconhece alguma destas situações:

• Conhecimento privado ou proprietário: chatbots de suporte que respondem com base na sua documentação, assistentes internos que consultam políticas da empresa, ferramentas que buscam em contratos ou manuais.
• Informação que muda com frequência: catálogos de produtos, preços, status de pedidos, qualquer dado que ficaria desatualizado se estivesse "cozido" no modelo.
• Necessidade de citar fontes: como você sabe exatamente quais trechos alimentaram a resposta, pode mostrar ao usuário de onde veio a informação, o que aumenta a confiança e permite auditoria.
• Redução de alucinações: ancorar a resposta em material real diminui bastante a tendência do modelo de inventar.

Quando RAG talvez não seja a resposta

RAG não é solução universal. Se a tarefa não depende de conhecimento externo, ele só adiciona complexidade. Para reescrever um texto, resumir algo que o usuário já forneceu ou fazer uma tradução, o modelo puro basta. Nesses casos, o conteúdo relevante já está no prompt e não há nada a recuperar.

Também existe a alternativa de simplesmente colocar todo o material no contexto, sem busca, quando a base é pequena. Se você tem um único documento de poucas páginas, jogá-lo inteiro no prompt pode ser mais simples do que montar um pipeline de recuperação. RAG começa a valer a pena quando a base é grande demais para caber no contexto de uma vez.

E há tarefas que pedem fine-tuning em vez de RAG. Se você quer que o modelo adote um estilo de escrita muito específico ou domine um formato de saída peculiar, ajustar o modelo pode ser melhor do que recuperar exemplos. RAG entrega conhecimento; fine-tuning molda comportamento. Muitas vezes a resposta ideal combina os dois.

Os desafios reais de um sistema RAG

Montar um RAG que funciona em uma demonstração é fácil. Fazê-lo funcionar bem em produção envolve decisões que impactam diretamente a qualidade. O tamanho dos chunks é uma delas: pedaços grandes demais trazem ruído junto com o sinal; pequenos demais perdem contexto. A escolha do modelo de embedding afeta a qualidade da busca. A quantidade de trechos recuperados equilibra abrangência e custo, já que cada trecho ocupa espaço no contexto e consome tokens.

Há também o problema de quando a recuperação falha. Se os documentos não contêm a resposta, um sistema bem construído deve reconhecer isso e dizer que não sabe, em vez de forçar uma resposta com material irrelevante. A instrução no prompt e a avaliação contínua do sistema são o que garantem esse comportamento. Como em qualquer aplicação que usa IA, também é preciso pensar em segurança, tema que aprofundamos no texto sobre segurança em aplicações que usam IA.

RAG e engenharia de prompt trabalham juntos

Vale entender que RAG não elimina a necessidade de escrever bons prompts; na verdade, os dois se combinam. Depois que o sistema recupera os trechos relevantes, é a instrução que você dá ao modelo que determina como ele os usa. Um prompt bem construído nessa etapa diz ao modelo para se basear apenas no contexto fornecido, para citar de onde tirou cada afirmação e para admitir quando o material não contém a resposta. Sem essa orientação, o modelo pode ignorar os trechos recuperados e responder de memória, desperdiçando todo o trabalho da recuperação.

As técnicas de engenharia de prompt que cobrimos no guia prático de engenharia de prompt se aplicam diretamente aqui. Definir claramente o papel do modelo, especificar o formato da resposta e instruir sobre o tratamento de incerteza são exatamente o que separa um RAG que responde bem de um que ignora seus documentos. Pense na recuperação e na geração como duas engrenagens que precisam estar bem ajustadas para o sistema girar.

Avaliar a qualidade do sistema

Um erro comum é montar um RAG e assumir que ele funciona só porque respondeu bem a duas ou três perguntas de teste. Sistemas de recuperação falham de formas sutis: às vezes trazem trechos irrelevantes, às vezes deixam de fora o trecho que continha a resposta, às vezes o modelo interpreta mal o material recuperado. Sem medir, você não sabe onde está o problema.

A prática é montar um conjunto de perguntas representativas com as respostas esperadas e avaliar o sistema contra ele de forma sistemática. Você mede separadamente a qualidade da recuperação, se os trechos certos foram encontrados, e a qualidade da geração, se a resposta final está correta e ancorada nos trechos. Separar as duas dimensões é essencial, porque a correção de cada uma exige ações diferentes. Um problema de recuperação pede ajuste no chunking ou no embedding; um problema de geração pede ajuste no prompt.

Um exemplo mental do fluxo completo

Imagine um assistente para a documentação de uma biblioteca de software. Na indexação, você quebra toda a documentação em chunks, gera embeddings e guarda no banco vetorial. Um desenvolvedor pergunta "como configuro o timeout de conexão". O sistema transforma a pergunta em vetor, recupera os três trechos mais próximos, que por acaso vêm da seção de configuração de rede, e monta um prompt com esses trechos mais a pergunta. O modelo lê o material e responde com a instrução exata, talvez citando o nome do parâmetro. O desenvolvedor recebe uma resposta correta e atual, sem que o modelo precisasse ter sido treinado naquela documentação.

Conclusão

RAG é a ponte entre o poder linguístico de um LLM e o conhecimento específico e atualizado que sua aplicação precisa. A ideia central é simples e elegante: em vez de tentar enfiar todo o conhecimento dentro do modelo, você deixa o conhecimento numa base externa e recupera só o relevante no momento da pergunta. Isso resolve os três maiores limites dos LLMs de uma vez, o corte temporal do treinamento, a falta de acesso a dados privados e a tendência a alucinar.

Se você está construindo qualquer aplicação que responde perguntas sobre um corpo de conhecimento específico, RAG provavelmente faz parte da solução. Comece com um pipeline simples, meça a qualidade das respostas com casos reais e refine os pontos que mais importam: chunking, recuperação e as instruções que orientam a geração.