RAG existe porque o modelo não sabe o que não foi treinado

Um modelo de linguagem só conhece o que estava presente nos dados usados no seu treinamento, até uma certa data de corte. Ele não conhece o contrato que sua empresa assinou ontem, o manual interno que nunca saiu da intranet, nem o histórico de tickets de suporte do seu produto específico. RAG é a resposta prática mais comum pra esse problema.

O que é

RAG, sigla para retrieval-augmented generation ("geração aumentada por busca"), é um padrão de arquitetura relativamente simples na sua ideia central: antes de gerar a resposta final, o sistema busca trechos relevantes numa base de documentos própria e os injeta no prompt junto com a pergunta original. O modelo então responde com base naquele material recuperado, e não apenas na memória estatística que carrega do treinamento.

O fluxo típico tem três etapas bem definidas:

Indexar. Os documentos são quebrados em pedaços menores (chunks) e cada pedaço é convertido num vetor numérico, chamado embedding, que representa o significado semântico daquele trecho de forma matemática — textos com significado parecido geram vetores numericamente próximos entre si.
Buscar. No momento da pergunta, a própria pergunta é convertida no mesmo tipo de vetor, e o sistema recupera os pedaços de documento cujo vetor está mais próximo do vetor da pergunta — ou seja, os trechos semanticamente mais relacionados ao que foi perguntado.
Gerar. O sistema monta um prompt combinando esses trechos recuperados com a pergunta original, e entrega isso ao modelo, que gera a resposta final com base nesse material como referência.

Por que não basta "fazer fine-tuning com nossos dados"

Essa é a pergunta mais comum de quem está decidindo entre as duas abordagens, e vale entender a diferença de propósito, discutida com mais profundidade no post sobre fine-tuning ou prompt. Fine-tuning é bom pra ensinar um modelo a adotar um estilo, formato ou comportamento consistente — mas é um jeito estruturalmente ruim de armazenar fatos que mudam com frequência.

Um documento interno muda de versão, uma política de empresa é atualizada, um preço de produto é revisado — e refazer o processo de fine-tuning a cada mudança desse tipo é caro, lento, e exige um ciclo inteiro de re-treinamento antes que a informação nova esteja disponível. Com RAG, a solução é bem mais direta: você atualiza o índice de documentos, e a próxima pergunta já recupera a versão nova, sem precisar re-treinar nada. Além disso, RAG naturalmente permite citar a fonte exata de onde a informação veio — algo que fine-tuning não oferece, porque a informação fica diluída e implícita nos pesos internos do modelo, sem rastro de origem.

Como isso reduz alucinação (mas não elimina)

Um dos benefícios práticos mais importantes de RAG é reduzir a chance do modelo inventar informação — o que discuti no post sobre por que a IA alucina. Quando o modelo tem um trecho relevante e concreto na frente dele, a tendência é ele se basear nesse material em vez de "preencher a lacuna" com uma resposta estatisticamente plausível mas inventada.

Isso não é uma garantia absoluta. O modelo ainda pode interpretar mal o trecho recuperado, misturar informação de dois trechos diferentes de forma incorreta, ou até alucinar em cima do próprio material fornecido. RAG reduz a superfície do problema — dá ao modelo algo concreto pra se ancorar — mas não é uma solução mágica que elimina completamente o risco de erro.

Onde RAG falha na prática

A experiência de quem opera sistemas assim mostra um padrão consistente: o ponto de falha mais comum quase sempre está na etapa de busca, não na geração final feita pelo modelo. Os sintomas típicos incluem:

Chunk mal cortado. Se o processo de divisão dos documentos cortar um trecho relevante ao meio, nenhum dos dois pedaços resultantes carrega informação suficiente pra responder a pergunta sozinho — mesmo que a informação completa estivesse, tecnicamente, presente na base de documentos original.
Pergunta vaga ou dependente de contexto anterior. Uma pergunta de acompanhamento como "e o do ano passado?" não carrega sinal semântico suficiente pra recuperar algo útil sozinha — ela depende do contexto da pergunta anterior na conversa. Sistemas de RAG mais robustos reescrevem a pergunta incorporando esse contexto antes de fazer a busca.
Busca puramente semântica falha em termos exatos. Nome de produto específico, código de erro, número de contrato ou identificador técnico costumam funcionar melhor com busca tradicional por palavra-chave exata do que com busca por similaridade semântica — porque dois códigos de erro parecidos numericamente podem ter significados completamente diferentes, e a busca semântica não necessariamente captura essa distinção. Combinar as duas abordagens, chamada de busca híbrida, resolve boa parte desses casos.
Base de documentos desatualizada ou mal organizada. Se a fonte em si está errada, duplicada ou desatualizada, nenhuma melhoria na busca ou na geração resolve o problema — a raiz está antes de qualquer etapa de RAG.

O ponto prático

Quando um sistema baseado em RAG responde de forma errada, o primeiro lugar a investigar não é o prompt final nem o comportamento do modelo — é o que exatamente foi recuperado na etapa de busca. Na esmagadora maioria dos casos de falha, a resposta certa simplesmente nunca chegou até o modelo: ele não teve como acertar porque não recebeu a informação necessária. Depurar um sistema de RAG começa quase sempre olhando os trechos recuperados antes de olhar qualquer outra coisa.