O que é RAG e por que ele é a maneira mais barata de a IA conhecer o seu negócio

O que você leva deste artigo

• RAG busca primeiro e responde depois: o modelo lê o seu material em vez de tentar lembrar dele.
• Atualizar a base é trocar um arquivo, não retreinar nada.
• A resposta pode citar o trecho de origem, o que torna a conferência rápida.
• A qualidade do RAG depende muito mais da preparação dos documentos do que do modelo escolhido.
• Ele não resolve pergunta que exige contar, somar ou cruzar a base inteira.
• Sem controle de permissão na busca, o RAG vira vazamento de documento interno.

O problema que o RAG resolve

Um modelo de linguagem foi treinado em texto público até uma certa data. Ele não conhece a sua tabela de preços, o seu contrato padrão, o manual do seu equipamento nem o histórico do seu cliente. Perguntar sobre isso a um modelo puro produz uma resposta inventada com aparência de correta, porque ele preenche a lacuna com o que seria plausível para uma empresa do seu setor.

A reação intuitiva de quem descobre isso é querer treinar o modelo com os próprios dados. É a solução mais cara, mais lenta e, na esmagadora maioria dos casos, a errada. Ela exige preparação de milhares de exemplos, custa caro, precisa ser refeita quando a informação muda e ainda assim não garante que o modelo lembre corretamente de um detalhe específico.

O RAG resolve por outro caminho, e o caminho é quase óbvio depois que você ouve: em vez de fazer o modelo saber, faça-o ler. A cada pergunta, o sistema procura na sua base os trechos que têm a ver com aquilo, cola esses trechos no pedido e pede uma resposta baseada neles.

A analogia mais próxima é a de uma pessoa nova na equipe com acesso ao arquivo. Ela não decorou o manual, e não precisa: quando chega uma pergunta, ela procura a página certa e responde a partir dali. É mais confiável do que decorar, e muito mais fácil de manter atualizado.

Em vez de fazer o modelo saber, faça ele ler. Quase todo projeto que começa querendo treinar uma IA na verdade precisava disso.

Como funciona, passo a passo

O sistema tem duas metades. Uma acontece antes, uma única vez por documento; a outra acontece a cada pergunta.

Antes, a preparação. Seus documentos são quebrados em pedaços de tamanho gerenciável, normalmente entre um e três parágrafos. Cada pedaço é convertido em uma lista de números que representa o significado dele, chamada de vetor. Esses vetores vão para um banco especializado em achar o vetor mais parecido com outro. Trechos que falam de coisas parecidas ficam com vetores parecidos, mesmo sem compartilhar as mesmas palavras.

Na hora da pergunta. A pergunta também vira vetor. O banco devolve os trechos mais próximos, tipicamente entre três e dez. Esses trechos são colados no pedido junto com uma instrução do tipo "responda usando apenas o material abaixo e cite de onde tirou". O modelo responde. Fim.

A vantagem prática que essa arquitetura dá é enorme e pouco alardeada: como você controla o que entra no pedido, você controla a resposta. Trocou o documento, a resposta muda na próxima pergunta. Removeu um arquivo, ele deixa de ser usado imediatamente. Não há retreinamento, não há espera, não há custo de ajuste.

O que isso resolve na prática

Imagine uma distribuidora de material de construção com um catálogo de 4.000 itens, tabela de preço que muda toda semana e uma equipe de vendas que passa o dia respondendo as mesmas perguntas por WhatsApp. Um assistente com RAG sobre o catálogo e as regras comerciais responde disponibilidade, equivalência de produto e condição de pagamento sem que ninguém decore nada, e a atualização é o mesmo arquivo que já era gerado toda semana.

Ou um escritório de contabilidade com centenas de páginas de procedimento interno. A dúvida de um assistente júnior sobre qual anexo se aplica a um cliente específico é exatamente o tipo de pergunta em que o material existe, está escrito, e ninguém acha.

O padrão comum entre os casos que funcionam é este: a resposta já existe escrita em algum lugar, e o problema é de localização, não de raciocínio. Quando esse é o formato do problema, o RAG é a ferramenta certa e o retorno aparece rápido.

E existe um ganho lateral que costuma ser o mais valorizado depois de alguns meses: as perguntas que o sistema não consegue responder viram um relatório do que está faltando na sua documentação. Isso revela buracos que ninguém mapeava.

O que o RAG não resolve

Vale ser específico aqui, porque expectativa errada é o que mata projeto.

Pergunta que exige a base inteira. "Quantos contratos vencem em março?" não é uma pergunta de RAG. A busca traz os trechos mais parecidos com a pergunta, não todos os contratos. Contar, somar e cruzar são trabalho de banco de dados e de consulta estruturada. Muita gente tenta forçar isso no RAG e recebe um número inventado com cara de certo.

Informação que não está escrita. Se a regra vive na cabeça do gerente e nunca foi documentada, o RAG não tem o que buscar. Ele não deduz política a partir de histórico. Uma parte considerável do trabalho real em projeto de RAG é escrever o que nunca foi escrito.

Documento que a máquina não lê. PDF que é foto de página escaneada, planilha com informação em cor de célula, contrato com a cláusula importante dentro de uma imagem. Tudo isso precisa passar por reconhecimento de texto antes, e a qualidade dessa etapa define o teto de tudo que vem depois.

E ele reduz, mas não elimina, a alucinação. O modelo ainda pode interpretar mal um trecho ou juntar dois pedaços que não deveriam ser juntados. Exigir a citação do trecho é o que torna esse erro fácil de pegar.

Onde a montagem costuma dar errado

Um RAG que funciona mal quase nunca é problema do modelo. É problema de preparação, e sempre nos mesmos pontos.

O tamanho do pedaço. Pedaço grande demais traz muito ruído junto com a resposta e confunde. Pequeno demais corta a informação ao meio, e a resposta chega sem a condição que estava no parágrafo seguinte. O ajuste é empírico, feito com perguntas reais, e é o parâmetro de maior impacto no resultado final.

A perda de contexto do pedaço. Um trecho que diz "o prazo é de 30 dias" é inútil solto: 30 dias para quê, em qual contrato, sob qual condição. Cada pedaço precisa carregar de onde veio, de qual documento, de qual seção, de qual versão. Sem isso, a busca acha e a resposta erra.

A busca puramente por significado. Vetores são ótimos para achar assunto parecido e ruins para achar código exato. Se alguém pergunta pela peça "XR-4410", a busca por significado pode trazer peças parecidas em vez daquela. A solução conhecida é combinar busca por significado com busca por palavra literal, e ordenar o resultado das duas.

A base suja. Três versões do mesmo contrato, sendo duas antigas. O sistema não sabe qual vale e cita a errada com a mesma segurança. Antes de qualquer coisa técnica, alguém precisa decidir qual documento é a versão válida. Esse é o trabalho mais chato do projeto e o mais determinante.

• Pedaço de um a três parágrafos, ajustado com perguntas reais, não com palpite.
• Cada pedaço carrega documento, seção, versão e data de origem.
• Busca combinada: por significado e por palavra literal, com reordenação do resultado.
• Uma versão válida por documento, decidida por uma pessoa antes de indexar.
• Resposta obrigada a citar o trecho, para conferência rápida.

A parte de segurança que quase todo projeto esquece

Este é o risco mais sério de um RAG mal montado, e ele aparece tarde, quando o sistema já está em uso.

Se a busca não respeita permissão, qualquer pessoa que converse com o assistente pode extrair qualquer coisa que esteja na base. Um funcionário pergunta sobre política de férias e, se a base tem a planilha de salários, o trecho pode vir junto. Não é falha do modelo: é falha de arquitetura. A permissão precisa ser aplicada na busca, filtrando o que pode ser recuperado para aquele usuário, antes de o modelo ver qualquer coisa.

Filtrar depois não funciona. Instruir o modelo a não falar de salário é uma barreira frágil, contornável com uma pergunta bem formulada, e ela quebra em silêncio. Se o trecho chegou ao modelo, ele já saiu do seu controle.

Existe ainda um risco menos óbvio: se a sua base indexa documento que veio de fora, como e-mail de cliente ou página da web, um texto malicioso plantado ali pode conter instruções endereçadas ao modelo. Conteúdo recuperado é dado, nunca comando, e o sistema precisa ser construído assumindo isso.

Quanto custa e por onde começar

RAG é a alternativa barata, e vale entender por quê. Não há treinamento, então não há aquele custo. O que existe é o custo de gerar os vetores uma vez por documento, que é baixo, e o custo de cada pergunta, que é o texto dos trechos recuperados mais a pergunta e a resposta.

A conta muda quando você entende que os trechos recuperados vão no pedido a cada pergunta. Trazer dez trechos grandes em vez de quatro trechos certeiros multiplica o custo de toda pergunta e ainda piora a resposta. Recuperação precisa é economia e qualidade ao mesmo tempo, o que é raro. Os detalhes de como esse custo se acumula estão em token e janela de contexto.

Por onde começar, na ordem que evita desperdício: escolha um conjunto de perguntas que a equipe responde muito e cuja resposta já existe escrita. Junte só os documentos que respondem essas perguntas. Escreva vinte perguntas reais com a resposta correta ao lado, feitas por quem conhece o assunto. Monte o sistema mais simples possível e meça contra essas vinte.

Essas vinte perguntas são o item mais valioso do projeto inteiro, e são o que quase todo mundo pula. Sem elas, ninguém sabe dizer se uma mudança melhorou ou piorou, e o projeto anda por opinião. Se você quer montar isso na sua empresa com esse rigor desde o começo, é assim que a consultoria em IA da ROO3 estrutura a primeira entrega.

Perguntas frequentes

O que significa RAG?

RAG é a sigla de retrieval augmented generation, ou geração aumentada por recuperação. O nome descreve a ordem das operações: o sistema primeiro recupera trechos relevantes dos seus documentos e só depois gera a resposta, usando esses trechos como base.

Qual a diferença entre RAG e treinar um modelo com meus dados?

Treinar altera o modelo e é caro, lento e precisa ser refeito quando a informação muda. RAG deixa o modelo intacto e entrega o documento junto com a pergunta. Atualizar é trocar um arquivo, e a resposta pode citar a origem, o que o treinamento não oferece.

Meus documentos vão para dentro do modelo?

Não. Eles ficam na sua base e apenas os trechos relevantes são enviados junto de cada pergunta. Se o trecho enviado será ou não usado em treinamentos futuros do provedor depende do contrato do serviço, e planos corporativos normalmente excluem isso. Vale confirmar antes de indexar dado sensível.

RAG serve para perguntar quantos clientes eu tenho?

Não. Contar, somar e cruzar exigem consulta estruturada a um banco de dados, não busca por semelhança. O RAG traz os trechos mais parecidos com a pergunta, não a base inteira, e forçar esse tipo de pergunta produz números inventados com aparência de corretos.

Preciso de um modelo caro para fazer RAG?

Geralmente não. Como o material vem junto da pergunta, a tarefa é ler e resumir em vez de saber, e modelos intermediários dão conta bem. O dinheiro rende mais investido na preparação dos documentos e na qualidade da busca do que na troca de modelo.

Quanto tempo leva para montar um RAG?

Uma primeira versão útil sobre um conjunto pequeno e bem definido de documentos leva semanas, não meses. O que estende o prazo quase sempre é a limpeza da base: decidir qual documento é a versão válida, converter o que está em imagem e escrever o que nunca foi documentado.

Fontes

• Lewis et al.: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (arXiv)
• Anthropic: Contextual Retrieval

Rodrigo Fávaro

Fundador da ROO3, agência de marketing e tecnologia em São José do Rio Preto. Constrói produtos com IA em produção (Tobia, gerar.app, Pense Mercado) e mantém o AI Benchmark, ranking público de modelos de IA. Veja a consultoria em IA da ROO3.

X @rodmf LinkedIn rodrigofavaro