RAG explicado: como dar conhecimento atualizado a um LLM

Um modelo de linguagem não sabe nada sobre a sua empresa. Ele sabe estatística sobre a linguagem humana. Essa distinção, que parece filosófica, é a origem de quase todo problema prático que você vai ter ao colocar um LLM em produção: alucinação, resposta desatualizada, confiança onde deveria haver dúvida. O RAG — Retrieval-Augmented Generation, geração aumentada por recuperação — não é um truque de engenharia para contornar isso. É a admissão honesta de que o conhecimento de um modelo e o conhecimento que você precisa que ele use são duas coisas separadas, e que a segunda tem que ser injetada no momento da pergunta.

A ideia central cabe em uma frase: recuperar antes de gerar. Antes de o modelo escrever uma palavra, um sistema busca os documentos relevantes para a pergunta e os coloca dentro do contexto da requisição. O modelo então responde olhando para aquele material, não para a névoa estatística que ele destilou durante o treinamento. É a diferença entre um candidato respondendo de cabeça em uma prova e o mesmo candidato respondendo com o livro aberto na página certa.

Por que o modelo sozinho erra

Vale entender o mecanismo, porque ele explica os dois problemas que o RAG ataca. Um LLM é treinado para prever o próximo token de uma sequência. Ao longo de bilhões de exemplos, ele comprime regularidades da linguagem e do mundo em seus pesos. Esse conhecimento é paramétrico: está embutido nos parâmetros, não em um banco de dados que você consulta. Duas consequências decorrem disso.

A primeira é a desatualização. Os pesos são congelados no fim do treinamento. Tudo que aconteceu depois — uma mudança na sua política de reembolso, um novo release, o preço de ontem — simplesmente não existe para o modelo. Ele não sabe que não sabe. Vai responder com o que tinha, e vai soar igualmente convicto.

A segunda é a alucinação. Como o objetivo do modelo é produzir uma continuação plausível, e não verdadeira, quando falta informação ele preenche a lacuna com algo que se encaixa na forma esperada da resposta. Um número que parece razoável, uma citação com a cara de citação, um nome de função que segue a convenção da biblioteca mas não existe. Não é mentira no sentido humano; é o modelo fazendo exatamente aquilo para que foi otimizado, na ausência de âncora. Peça a fonte de uma afirmação inventada e ele inventa a fonte também, porque a fonte também é só mais um trecho de texto plausível.

O RAG muda o jogo porque muda a natureza da tarefa. A pergunta deixa de ser “o que você sabe sobre X” e passa a ser “dado este texto, responda sobre X”. A segunda formulação é muito mais fácil de acertar e muito mais difícil de errar com convicção — o modelo tem material contra o qual se ancorar, e o custo de inventar sobe quando a verdade está literalmente na janela de contexto.

A anatomia mínima

Um sistema de RAG tem duas fases. A primeira, offline, é a indexação. Você quebra seus documentos em pedaços — os chunks — e passa cada pedaço por um modelo de embedding, que o converte em um vetor: uma lista de números que representa o significado daquele trecho em um espaço de alta dimensão. Trechos com sentido próximo ficam próximos nesse espaço. Esses vetores vão para um banco de dados vetorial, que sabe fazer busca por proximidade de forma rápida.

A segunda fase, online, acontece a cada pergunta. A pergunta do usuário também vira um vetor, pelo mesmo modelo de embedding. O banco retorna os chunks cujos vetores estão mais próximos do vetor da pergunta — os candidatos semanticamente relevantes. Esses trechos são montados em um prompt junto com a pergunta original e uma instrução do tipo “responda usando apenas o contexto abaixo”. O LLM gera a resposta. Recuperar, aumentar, gerar.

Repare no que é elegante aqui: você atualiza o conhecimento do sistema sem retreinar nada. Mudou a política? Reindexa o documento novo. O modelo continua o mesmo; o que ele lê é que mudou. Comparado a fine-tuning — que ajusta pesos, custa mais caro de operacionalizar, e é péssimo para fatos que mudam toda semana — o RAG é a forma mais barata e reversível de manter um sistema informado. Fine-tuning é a ferramenta para ensinar comportamento e estilo. RAG entrega fato fresco. São ferramentas para problemas diferentes, e confundir as duas é um erro comum e caro.

Onde o RAG ingênuo quebra

Aqui está a parte que os tutoriais não contam. O pipeline que descrevi acima — o RAG ingênuo, o de poucas linhas de código — funciona lindamente na demo e decepciona em produção. Os pontos de falha são específicos e vale nomeá-los.

O primeiro é a recuperação. Todo o edifício repousa sobre uma premissa: que os chunks recuperados são os certos. Quando não são, o modelo recebe contexto irrelevante e, pior, tenta responder mesmo assim — agora com a falsa segurança de ter “consultado a base”. Busca por embedding captura similaridade semântica, que nem sempre é a mesma coisa que relevância. A pergunta “quando expira minha garantia” e um parágrafo sobre “prazo de validade da promoção” podem ficar perigosamente próximos no espaço vetorial. Recuperação ruim não é um problema secundário do RAG; é o problema. Garbage in, garbage out, com verniz de autoridade.

O segundo é o chunking. Como você corta o documento determina o que é possível recuperar. Corte muito fino e você fragmenta a informação — a resposta está espalhada em três pedaços e você recupera um. Corte muito grosso e cada chunk vira um borrão de vários assuntos, diluindo o sinal do embedding e enchendo o contexto de ruído. Não existe tamanho universal; existe o tamanho certo para a estrutura dos seus documentos, e descobri-lo é trabalho empírico, não configuração default.

O terceiro é a pergunta que não bate com o texto. Usuários perguntam em linguagem coloquial; documentos são escritos em linguagem formal. O embedding da pergunta “como cancelo” pode não chegar perto do trecho que diz “para efetuar o encerramento contratual”. É o problema do vocabulário, e é por isso que sistemas sérios não confiam só na busca vetorial. Combinam-na com busca lexical clássica, por palavra-chave — a chamada busca híbrida — e frequentemente adicionam um segundo estágio: um reranker, um modelo mais caro que reordena os candidatos por relevância real antes de mandá-los para o LLM. Recuperar um lote maior e refinar para os poucos melhores costuma bater recuperar poucos diretamente.

O quarto, o mais silencioso, é a ausência de recuperação. Nem toda pergunta deveria disparar uma busca, e o contexto recuperado nem sempre contém a resposta. Um RAG ingênuo empurra os chunks para o modelo e reza. Um RAG maduro dá ao modelo permissão explícita para dizer “isto não está na base” — e mede quantas vezes ele deveria ter dito e não disse. A honestidade sobre o vazio é uma feature, não um bug a ser suprimido com um prompt mais insistente.

O que separa demo de produto

O RAG resolve os problemas certos, e por isso virou a arquitetura padrão para colocar LLMs em cima de conhecimento que muda. Mas ele desloca a dificuldade em vez de eliminá-la. O modelo deixa de ser o gargalo; a recuperação passa a ser. E recuperação é um problema de information retrieval de mais de meio século, com todas as suas armadilhas conhecidas, agora vestido de novidade.

A tese que carrego de qualquer projeto de RAG é esta: a qualidade da resposta é limitada pela qualidade da recuperação, não pela inteligência do modelo. Trocar o LLM por um mais caro não conserta um retriever que traz o parágrafo errado — só o faz alucinar em prosa mais elegante sobre a base errada. O investimento que paga é o menos glamouroso: avaliar a recuperação isoladamente, medir se os chunks certos aparecem, corrigir o chunking, adicionar reranking, montar um conjunto de avaliação com perguntas reais e respostas verificadas. Quem trata RAG como problema de prompt fica preso na demo. Quem trata como problema de busca constrói algo que aguenta usuário de verdade.