O que é RAG: como conectar uma IA aos seus próprios dados

Você conecta um chatbot na intranet da empresa, pergunta "qual é a política de reembolso de viagem?", e o modelo responde com uma confiança absoluta — citando um valor, um prazo e até um formulário que não existe. O texto parece perfeito. Está inteiramente errado. O problema não é o modelo ser "burro": é que ele nunca viu a sua documentação interna. Um LLM só conhece o que estava nos dados de treino, que congelaram numa data passada e nunca incluíram o PDF que o RH atualizou semana passada.

Este artigo explica o que é RAG (retrieval augmented generation), como ele resolve esse buraco conectando o modelo aos seus próprios dados, e quando ele é — ou não é — a ferramenta certa.

O problema: o modelo não conhece os seus dados

Um LLM é, na prática, uma memória comprimida do que leu durante o treino. Duas consequências práticas seguem disso. Primeiro, ele tem um corte de conhecimento: qualquer coisa que aconteceu depois, ou que seja privada da sua empresa, simplesmente não existe para ele. Segundo, quando você pergunta sobre algo que ele não sabe, ele raramente diz "não sei" — ele preenche a lacuna com a continuação estatisticamente mais provável. Isso é a hallucination: texto plausível, factualmente inventado.

Se você quer entender por que o modelo gera com tanta confiança mesmo quando erra, vale ler como os LLMs geram respostas — ajuda a calibrar quanto confiar na saída bruta.

A reação comum é "então a gente precisa treinar o modelo nos nossos dados". Quase sempre essa é a conclusão errada, e vou voltar nisso. A solução mais barata e direta na maioria dos casos é outra: não mude o modelo, mude o que você coloca na pergunta.

O que é RAG, em uma frase

RAG é dar ao modelo, no momento da pergunta, os trechos relevantes dos seus dados — colados dentro do prompt como contexto — antes de ele responder. Em vez de confiar na memória de treino, o modelo lê o material que você acabou de entregar e responde com base nele.

A analogia honesta: é a diferença entre um aluno fazer uma prova de cabeça e fazer a mesma prova com consulta. O aluno continua sendo o mesmo; muda o que está na mesa dele na hora de responder. RAG é a técnica de colocar a página certa na mesa, automaticamente, para cada pergunta.

O "retrieval" é a parte de buscar o trecho certo. O "augmented generation" é gerar a resposta com esse trecho injetado no prompt. Nada disso reescreve o modelo — ele continua o mesmo arquivo de pesos de sempre.

O pipeline, do ingest à resposta

Dá pra dividir em duas fases. Uma roda uma vez (ou sempre que os dados mudam), a outra roda a cada pergunta.

Fase de indexação (offline):

documentos
  -> chunk      (quebra cada doc em pedacos de ~200-800 tokens)
  -> embed      (cada chunk vira um vetor de numeros)
  -> store      (guarda vetor + texto num vector DB)

Fase de query (a cada pergunta):

pergunta do usuario
  -> embed                 (a pergunta vira um vetor, no mesmo espaco)
  -> similarity search     (acha os top-k chunks mais proximos)
  -> stuff no prompt       (cola os chunks + a pergunta num so prompt)
  -> generate              (o LLM responde usando esse contexto)

O ponto-chave: o modelo nunca "decora" seus dados. A cada pergunta, o sistema busca os pedaços relevantes e os entrega frescos no prompt. Atualizou um documento? Basta re-indexar aquele documento — sem retreinar nada.

Embeddings e vector DBs, sem misticismo

Um embedding é um jeito de transformar texto em uma lista de números (um vetor) de tal forma que textos com significado parecido fiquem próximos nesse espaço numérico. "Política de reembolso" e "como sou ressarcido de despesas" têm palavras diferentes, mas embeddings próximos, porque significam quase a mesma coisa. É exatamente isso que faz a busca funcionar mesmo quando o usuário não usa as palavras exatas do documento.

Um vector DB (Pinecone, Qdrant, pgvector, etc.) é um banco otimizado para uma operação: dado um vetor de consulta, devolver rápido os k vetores mais próximos. "Próximos" costuma ser medido por similaridade de cosseno. Para volumes pequenos, você nem precisa de um banco dedicado — uma busca em memória resolve. O vector DB vira necessário quando são milhões de chunks.

Chunking: a decisão que mais afeta a qualidade

Aqui mora a parte que as pessoas subestimam. Você não embedda o documento inteiro — embedda pedaços (chunks). E o tamanho e o corte desses pedaços determinam o que o retrieval consegue achar.

Chunks grandes demais: o vetor vira uma média de vários assuntos, fica genérico, e a busca traz contexto demais que dilui o sinal. Chunks pequenos demais: você parte uma ideia no meio e o trecho recuperado não tem informação suficiente para responder. Cortar no meio de uma frase ou de uma tabela é uma fonte clássica de respostas ruins. Boas estratégias respeitam a estrutura do texto: quebrar por seção, por parágrafo, ou por heading, com um pequeno overlap entre chunks para não perder contexto na fronteira.

Antes de embeddar, vale gastar cinco minutos olhando o texto-fonte de verdade — analisar a frequência de termos ajuda a enxergar o vocabulário dominante, decidir o tamanho de chunk e identificar ruído (cabeçalhos repetidos, boilerplate de rodapé) que você não quer indexar. Não é mágica, é só um jeito barato de entender o material antes de jogar tudo no pipeline.

RAG ou fine-tuning?

Essa é a confusão mais comum, então seja direto: as duas coisas resolvem problemas diferentes.

RAG é para fatos e atualidade — "o que diz o nosso contrato com o cliente X", "qual o número da release de ontem". Você quer que o modelo cite informação específica e correta, que muda com frequência. Fine-tuning é para estilo e formato — fazer o modelo responder sempre num tom específico, num formato de JSON rígido, ou seguir um padrão de classificação. Fine-tuning ensina comportamento, não fatos novos confiáveis.

Minha opinião, depois de ver isso várias vezes: a maioria dos "precisamos fazer fine-tuning" é, na verdade, um problema de retrieval disfarçado. A pessoa quer que o modelo saiba dados internos, tenta ensinar via fine-tuning, gasta caro, e o modelo continua alucinando porque fine-tuning não é um jeito confiável de injetar fatos. Comece com RAG. Só pense em fine-tuning quando o problema for de comportamento, não de conhecimento.

Os limites: o retrieval é o teto

RAG não é mágica, e tem um limite duro: a qualidade da resposta nunca passa da qualidade do retrieval. Se a busca trouxe o chunk errado, o modelo vai responder com confiança a partir do material errado. Garbage in, garbage out continua valendo — agora aplicado ao que você recupera. Se a sua documentação é ambígua, desatualizada ou contraditória, o RAG vai refletir isso fielmente.

O outro limite é a context window: você só consegue injetar uma quantidade finita de chunks no prompt. Top-k grande demais não só custa mais como pode enterrar o trecho útil no meio de ruído. E vale lembrar que o modelo ainda pode alucinar mesmo com bom contexto — RAG reduz, não elimina. Vale instruir o prompt a responder "não encontrei isso nos documentos" quando o contexto não cobrir a pergunta.

Perguntas frequentes

RAG elimina hallucination?

Reduz bastante, não elimina. Ao ancorar a resposta em trechos reais, você tira a maior fonte de invenção — o modelo respondendo de cabeça sobre o que não sabe. Mas se o retrieval traz o trecho errado, ou se o modelo extrapola além do que o contexto diz, a alucinação volta. Por isso instrua o modelo a se basear só no contexto e a admitir quando não achar.

Preciso de um vector DB para começar?

Não. Para poucos documentos, uma busca de similaridade em memória resolve e é mais simples de depurar. O vector DB dedicado vira necessário quando o volume cresce para dezenas de milhares ou milhões de chunks e a latência da busca importa. Comece simples.

Qual o tamanho ideal de chunk?

Não há número universal, mas a faixa de 200 a 800 tokens funciona para a maioria dos textos, com um pequeno overlap. O certo é respeitar a estrutura do conteúdo: quebre por seção ou parágrafo em vez de cortar por contagem cega de caracteres. Teste com perguntas reais e ajuste.

RAG funciona com qualquer modelo?

Sim — RAG é independente do modelo, porque só muda o que entra no prompt, não o modelo em si. Modelos com context window maior conseguem receber mais chunks de uma vez, o que ajuda em casos com muito contexto, mas o pipeline é o mesmo.

Para levar

RAG resolve o problema mais comum de IA aplicada: o modelo não conhece seus dados privados nem nada recente. Em vez de reescrever o modelo, você busca os trechos certos no momento da pergunta e os injeta no prompt como contexto. O pipeline é direto — chunk, embed, store; depois embed da pergunta, similarity search top-k, stuff no prompt, generate. Os pontos que decidem o resultado são o chunking e a qualidade do retrieval, não o modelo. E se o seu instinto foi "precisamos fazer fine-tuning", desconfie: na maioria das vezes é um problema de retrieval, e começar com RAG é mais barato, mais rápido e mais fácil de corrigir.