O que é RAG e por que todo agente de IA sério usa

Quando uma empresa coloca IA para responder clientes, a primeira pergunta deveria ser: de onde vêm as respostas?

Se a resposta for “do treinamento do modelo”, o projeto tem data de validade. Modelos de linguagem sabem muito sobre o mundo, mas não sabem nada sobre o seu estoque, seus preços de ontem ou a política de troca que mudou na semana passada.

RAG resolve esse problema. A sigla vem de Retrieval-Augmented Generation, e a ideia é simples na essência: antes de gerar uma resposta, o sistema busca informação relevante nas fontes da empresa. Depois, usa essa informação como contexto para formular a resposta.

Busca primeiro, responde depois. A maioria dos chatbots no mercado não faz isso.

Como funciona na prática

Imagine um vendedor novo na empresa. No primeiro dia, ele não sabe de cor todas as tabelas de preço, condições de pagamento, prazos de entrega. Mas ele sabe onde encontrar essas informações: no sistema, na planilha, no manual. Ele consulta, entende, e responde o cliente com base no que acabou de ler.

RAG faz a mesma coisa, com três etapas:

1. Indexação. Os documentos da empresa (PDFs, planilhas, conteúdo do ERP, base de conhecimento) são processados e transformados em representações numéricas chamadas embeddings. Cada pedaço de texto vira um ponto num espaço matemático onde textos com significados parecidos ficam próximos. Esse índice fica armazenado numa base vetorial.
2. Recuperação.Quando alguém faz uma pergunta, o sistema transforma a pergunta no mesmo tipo de representação numérica e busca os trechos mais relevantes na base. Não é uma busca por palavra-chave. É uma busca por significado: “qual o prazo de entrega para São Paulo?” encontra o trecho certo mesmo que o documento diga “frete para capital paulista: 3 dias úteis”.
3. Geração. Os trechos recuperados são inseridos como contexto junto com a pergunta original. O modelo de linguagem lê tudo e gera uma resposta fundamentada. Ele não está inventando. Está respondendo com base no que acabou de consultar.

O resultado: uma resposta que soa natural e que tem lastro nos dados reais da operação. Não é chute. É consulta.

Por que não treinar o modelo direto?

Se o modelo pode aprender coisas, por que não alimentar ele com os dados da empresa e pronto?

Porque treinar (ou fazer fine-tuning de verdade) esbarra em três problemas práticos:

Primeiro, dados de empresa mudam. Preços mudam, estoque muda, políticas mudam. Um modelo treinado com dados de janeiro não sabe o que mudou em março. Retreinar é caro e lento.

Segundo, fine-tuning ensina estilo e formato, não fatos. Se você treina um modelo com seus documentos, ele aprende a falar como sua empresa, mas não necessariamente memoriza cada dado. E quando ele não lembra, inventa. Com convicção.

Terceiro, rastreabilidade. Com RAG, cada resposta pode apontar para o documento de origem. Com fine-tuning, não existe como saber de onde veio cada pedaço da resposta.

Os melhores sistemas combinam os dois. Fine-tuning para o modelo entender o tom e o domínio da empresa. RAG para garantir que os fatos estejam corretos e atualizados.

Onde RAG pode falhar

RAG não é mágico. Se a base de documentos estiver desorganizada, duplicada ou desatualizada, as respostas vão refletir essa bagunça. Lixo entra, lixo sai. Isso vale para qualquer sistema, mas com IA a consequência é pior: o modelo vai gerar uma resposta fluente e confiante usando informação errada.

Outro ponto: a forma como os documentos são fatiados (chunking) importa muito. Cortar um parágrafo no lugar errado pode fazer o sistema recuperar um trecho sem contexto suficiente. O modelo vai tentar preencher a lacuna, e aí entra a alucinação.

Por isso a engenharia do pipeline de RAG importa tanto quanto a escolha do modelo. A diferença entre um agente que funciona e um que inventa respostas está quase sempre nos detalhes da indexação: como os dados foram limpos, como foram fatiados, como os embeddings foram gerados e como a busca vetorial foi calibrada.

Como usamos RAG na MGV Tech

Todos os agentes que construímos usam RAG como camada fundamental. Mas nenhum projeto começa pelo modelo. Começa pelos dados.

No caso da Replas, a maior distribuidora brasileira de resinas plásticas, os agentes de WhatsApp consultam o ERP em tempo real. Quando um vendedor pergunta sobre estoque de um produto específico, o agente não tem essa informação memorizada. Ele consulta, naquele instante, os dados do sistema. Se o estoque mudou cinco minutos atrás, a resposta já reflete a mudança.

Na UGB, universidade com milhares de alunos e múltiplos campi, o agente responde dúvidas sobre cursos, valores, datas de prova e matrícula. A base de conhecimento é a documentação institucional da universidade. Quando a instituição altera uma data ou um valor, o agente reflete a mudança sem precisar ser retreinado.

No Grupo Prexx, o caso é diferente. A IA copilot que auxilia análise de crédito não consulta documentos. Consulta o histórico completo de decisões da própria analista. RAG aqui serve para recuperar padrões de decisão passados e sugerir aprovações com base em precedentes reais, não em regras genéricas.

Em todos esses projetos, o Koda opera como camada de interação via WhatsApp, enquanto o pipeline de RAG cuida do acesso aos dados. São peças complementares: o Koda é a interface, o RAG é a inteligência por trás das respostas.

Quando RAG faz sentido

RAG faz sentido quando a empresa precisa que a IA responda com dados que mudam, que são proprietários ou que não existem no conhecimento geral do modelo. Isso cobre a maioria dos casos de uso empresariais:

• Atendimento ao cliente com dados de produto atualizados
• Consulta a políticas internas, manuais e procedimentos
• Acesso a dados de ERP, CRM ou sistemas legados via linguagem natural
• Suporte interno a equipes (RH, DP, TI)
• Análise de documentos (contratos, propostas, relatórios)

Se a informação que a IA precisa para responder existe em algum sistema da empresa e muda com alguma frequência, RAG é quase certamente a abordagem certa.

O que muda com RAG

A diferença entre um chatbot genérico e um agente que gera valor real para a operação está, na maioria dos casos, na presença ou ausência de RAG. Sem ele, o modelo responde com base no que sabe do treinamento geral. Com ele, responde com base nos dados da sua empresa, naquele momento.

Essa diferença técnica se traduz diretamente em adoção: a ferramenta que as pessoas testam uma vez e esquecem versus a que vira parte do dia a dia da operação.