RAG na Prática: Como Conectar Modelos de IA aos Dados da Sua Empresa Sem Alucinações

Quem já colocou um chatbot de IA para responder dúvidas de clientes ou funcionários conhece o problema: o modelo responde com muita confiança, mas às vezes inventa. Cita uma política de reembolso que não existe, descreve um produto com características erradas, ou simplesmente não sabe nada sobre os processos internos da empresa. O motivo é simples: modelos de linguagem foram treinados com dados públicos até determinada data e não têm acesso aos seus contratos, manuais, tabelas de preço ou base de conhecimento.

A técnica que se tornou o padrão de mercado para resolver isso se chama RAG, sigla em inglês para Retrieval-Augmented Generation, ou geração aumentada por recuperação. Em vez de depender só da memória do modelo, o sistema busca trechos relevantes nos seus documentos e entrega esse material ao modelo junto com a pergunta. O resultado são respostas ancoradas em fontes reais, com possibilidade de citar de onde a informação veio.

Neste guia, a ideia é mostrar como o RAG funciona por dentro, quando ele faz sentido (e quando não faz), quais são as etapas de uma implementação e os erros que mais derrubam a qualidade desses sistemas na prática.

O que é RAG e por que ele resolve o problema das alucinações

Um modelo de linguagem funciona prevendo a próxima palavra mais provável com base no que aprendeu durante o treinamento. Quando não tem a informação, ele não responde "não sei" por padrão: gera algo plausível. Esse comportamento é o que chamamos de alucinação, e ele é inerente à forma como esses modelos operam, como explica a própria Wikipédia em sua página sobre geração aumentada por recuperação.

O RAG muda a dinâmica em três movimentos:

1. Recuperar: a pergunta do usuário é usada para buscar os trechos mais relevantes em uma base de documentos.
2. Aumentar: esses trechos são inseridos no prompt, junto com a instrução de responder apenas com base neles.
3. Gerar: o modelo redige a resposta usando o material fornecido, idealmente citando as fontes.

Pense em uma prova com consulta. O modelo continua sendo o aluno que sabe escrever bem, mas agora tem o material certo aberto na mesa. Se o material não traz a resposta, a instrução correta é admitir isso, e não improvisar.

RAG não é o mesmo que treinar um modelo

É comum a confusão entre RAG e ajuste fino (fine-tuning). No ajuste fino, você altera os pesos do modelo com exemplos próprios, o que é caro, lento e ruim para informação que muda com frequência. No RAG, o modelo permanece o mesmo e a informação fica em uma base externa que pode ser atualizada a qualquer momento. Subiu uma nova tabela de preços? Basta reindexar o documento. Para a maioria dos casos de negócio, como atendimento, suporte interno e consulta a políticas, o RAG é mais barato, mais auditável e mais fácil de manter.

Quando o RAG faz sentido para sua empresa

Nem todo projeto de IA precisa de RAG. Ele brilha quando existe uma base de conhecimento volumosa, que muda com o tempo e que as pessoas têm dificuldade de consultar. Alguns cenários típicos:

• Suporte ao cliente: respostas baseadas em manuais, FAQ e histórico de políticas.
• Onboarding e RH: funcionários perguntando sobre benefícios, férias, normas internas.
• Jurídico e compliance: busca em contratos e normativos, inclusive para apoiar processos de adequação à LGPD.
• Vendas técnicas: consulta rápida a catálogos, fichas técnicas e propostas anteriores.
• Engenharia: perguntas sobre documentação de código e arquitetura.

Por outro lado, se o problema é classificar textos, extrair campos de documentos padronizados ou executar tarefas com regras fixas, uma abordagem mais simples (ou até automação com OCR e IA) costuma resolver melhor e com menos custo. E se a base de conhecimento cabe em poucas páginas, muitas vezes basta colocar o texto inteiro no prompt, sem montar infraestrutura de busca.

Como um sistema RAG funciona por dentro

Um pipeline de RAG tem duas fases: a de preparação (indexação) e a de consulta. Entender cada peça ajuda a diagnosticar problemas depois.

Fase 1: Indexação dos documentos

1. Coleta e limpeza. Você reúne PDFs, páginas de wiki, planilhas, e-mails, tickets. Aqui já aparece o primeiro gargalo: documentos escaneados precisam de OCR, tabelas viram texto bagunçado e cabeçalhos repetidos poluem o conteúdo. Dedicar tempo a essa limpeza costuma render mais qualidade do que trocar de modelo.

2. Divisão em trechos (chunking). Documentos longos são quebrados em pedaços menores, normalmente de algumas centenas de palavras, muitas vezes com uma pequena sobreposição entre eles para não cortar ideias ao meio. O tamanho do trecho é uma decisão crítica: pequeno demais perde contexto, grande demais dilui a relevância e gasta espaço no prompt.

3. Geração de embeddings. Cada trecho é convertido em um vetor numérico (embedding) que representa seu significado. Textos com sentido parecido ficam "próximos" nesse espaço matemático, mesmo que usem palavras diferentes. Assim, uma busca por "devolução de produto" encontra um trecho que fala em "política de troca".

4. Armazenamento em banco vetorial. Os vetores são guardados em um banco otimizado para busca por similaridade. Há opções dedicadas, como Pinecone, Qdrant, Weaviate e Milvus, e também extensões para bancos conhecidos, como o pgvector para PostgreSQL, que costuma ser suficiente para projetos de porte pequeno e médio e evita adicionar mais uma peça à infraestrutura.

Fase 2: Consulta

Quando o usuário faz uma pergunta, o sistema converte a pergunta em embedding, busca os trechos mais próximos no banco vetorial, monta um prompt com esses trechos e envia ao modelo de linguagem. Um prompt típico tem esta estrutura:

• Instrução de papel e tom (ex.: assistente de atendimento da empresa).
• Regra explícita: responder somente com base nos trechos fornecidos e dizer "não encontrei essa informação" quando não houver base.
• Os trechos recuperados, identificados por documento e seção.
• A pergunta do usuário.

A qualidade dessa instrução faz diferença. Técnicas de estruturação de prompts, como as que abordamos em prompt engineering avançado, aplicam-se diretamente aqui, principalmente a exigência de citar a fonte de cada afirmação.

Os erros que mais prejudicam projetos de RAG

A maioria das equipes descobre que o RAG "funciona na demo e falha em produção". Os motivos se repetem com frequência.

Busca que não encontra o trecho certo

Se o trecho correto não chega ao modelo, nenhuma engenharia de prompt vai salvar a resposta. Os problemas comuns incluem chunking mal dimensionado, documentos com texto sujo e perguntas que usam siglas internas ou jargões que o modelo de embeddings não conhece. Uma estratégia muito eficaz é a busca híbrida, que combina a busca semântica (vetores) com a busca por palavras-chave tradicional (como BM25). Códigos de produto, nomes de cláusulas e números de norma são casos em que a busca por palavra exata supera a semântica.

Excesso ou falta de contexto

Enviar dez trechos "só por garantia" costuma piorar a resposta, porque o modelo se distrai com informação irrelevante e o custo por consulta sobe. Muitos sistemas adotam uma etapa de reranking: a busca inicial traz, por exemplo, vinte candidatos, e um modelo menor reordena para escolher apenas os três ou cinco realmente úteis.

Ausência de controle de acesso

Este é um risco que muita gente ignora. Se o assistente indexa documentos de todos os departamentos, um estagiário pode conseguir, com uma pergunta bem feita, trechos de uma folha de pagamento ou de um contrato confidencial. A permissão precisa ser aplicada na recuperação: cada trecho deve carregar metadados de quem pode vê-lo, e a busca precisa filtrar por esse perfil antes de montar o prompt. Isso conecta o RAG diretamente a práticas de segurança de APIs e proteção de integrações, já que o pipeline costuma envolver vários serviços trocando dados sensíveis.

Dados pessoais indexados sem critério

Documentos de RH, atendimentos e contratos frequentemente contêm CPF, endereço e dados de saúde. Ao indexá-los, você cria uma nova cópia desses dados, em um novo sistema, possivelmente processada por um provedor externo de modelos. Antes de subir qualquer coisa, vale mapear o que é dado pessoal, definir base legal, anonimizar o que for possível e verificar onde o provedor processa e armazena as informações. Esse cuidado é parte do dia a dia de quem precisa cumprir a LGPD.

Não medir a qualidade

Sem avaliação, qualquer mudança é um chute. Monte um conjunto de teste com perguntas reais e as respostas esperadas, e acompanhe separadamente duas coisas: se a recuperação trouxe o trecho certo e se a geração usou esse trecho corretamente. Separar os dois permite descobrir onde está o gargalo. Ferramentas de código aberto como o Ragas ajudam a automatizar parte dessas métricas.

Roteiro prático para o primeiro projeto

Para quem quer sair do zero, um caminho enxuto e realista:

1. Escolha um caso de uso estreito. "Responder dúvidas sobre políticas de RH" é melhor do que "responder qualquer coisa da empresa". Escopo pequeno facilita avaliar e ganhar confiança.
2. Reúna e limpe 50 a 200 documentos representativos. Remova versões obsoletas: documentos desatualizados geram respostas desatualizadas.
3. Monte um conjunto de 30 a 50 perguntas reais com respostas de referência, vindas de quem faz o atendimento hoje.
4. Construa o protótipo. Frameworks como LangChain e LlamaIndex aceleram o começo, e as plataformas de IA dos grandes provedores também oferecem recursos prontos de busca em documentos. Para o código, o ecossistema Python é o mais maduro, e quem já domina automação de processos com Python terá curva de aprendizado curta.
5. Meça, ajuste e só então amplie. Teste tamanhos de trecho, busca híbrida e reranking, sempre comparando contra o conjunto de teste.
6. Libere para um grupo piloto com botão de feedback (útil / não útil) em cada resposta. Esse retorno é ouro para encontrar lacunas na base.

Quanto custa, em linhas gerais

O custo varia bastante conforme o volume, mas a estrutura é previsível: pagamento por uso de embeddings (geralmente barato e feito uma vez por documento), custo do banco vetorial (que pode ser zero se você usar uma extensão em um banco que já possui), e o custo por consulta ao modelo de linguagem, que depende do tamanho do prompt. Em um piloto pequeno, é plausível que o gasto mensal fique na casa de algumas centenas de reais; o que costuma pesar mais é o tempo da equipe para limpar documentos e avaliar resultados. Consulte sempre as tabelas de preço atualizadas dos provedores, que mudam com frequência.

RAG, agentes e o que vem depois

O RAG básico, em que a busca acontece uma vez antes da resposta, é só o ponto de partida. Arquiteturas mais recentes dão ao modelo autonomia para decidir quando buscar, reformular a pergunta, consultar várias fontes (documentos, banco de dados, APIs) e verificar a própria resposta antes de entregá-la. É a evolução rumo aos sistemas de agentes, que já aparece no suporte ao cliente e na automação de fluxos de trabalho com IA. Mesmo nessas arquiteturas mais sofisticadas, a base continua a mesma: informação de qualidade, bem organizada e com controle de acesso.

Se você está avaliando qual modelo usar como "cérebro" do sistema, vale a leitura sobre como escolher e implementar modelos de linguagem no contexto brasileiro, já que a qualidade em português e as condições de processamento de dados variam entre provedores.

Perguntas frequentes sobre RAG

O RAG elimina completamente as alucinações?

Não. Ele reduz bastante o problema ao fornecer fontes e permitir que o modelo diga "não sei", mas ainda pode haver interpretações erradas dos trechos ou lacunas na recuperação. Por isso é recomendável exibir as fontes na resposta e manter revisão humana em temas de alto risco, como jurídico e saúde.

Preciso de um banco vetorial dedicado?

Nem sempre. Para bases pequenas e médias, extensões como o pgvector em um PostgreSQL existente costumam atender bem. Bancos dedicados fazem mais sentido quando o volume de dados e de consultas cresce muito ou quando você precisa de recursos avançados de filtragem e escala.

Posso usar RAG com modelos que rodam localmente?

Sim. É possível rodar modelos abertos na própria infraestrutura, o que ajuda quando há restrições sobre enviar dados a terceiros. O trade-off é que você assume o custo de hardware e a manutenção, e a qualidade pode ser menor que a dos maiores modelos comerciais, dependendo da tarefa.

Quanto tempo leva para ter um protótipo funcionando?

Um protótipo básico pode ficar de pé em poucos dias. O que leva semanas é a parte menos glamorosa: limpar documentos, montar o conjunto de avaliação e ajustar a recuperação até a qualidade ficar aceitável para uso real.

Por onde começar se minha equipe não tem experiência com IA?

Comece pelo caso de uso mais restrito possível, use um serviço gerenciado que ofereça busca em documentos pronta e invista cedo em avaliação. Só depois de entender onde estão os gargalos vale migrar para uma arquitetura própria.

Conclusão prática

O RAG não é mágica nem moda passageira: é uma forma pragmática de fazer a IA trabalhar com a informação que realmente importa para o seu negócio, de maneira atualizável, auditável e com menos risco de invenção. O sucesso depende menos de escolher o modelo mais famoso e mais de três coisas pouco glamorosas: documentos limpos, recuperação bem ajustada e avaliação constante. Quem acerta essa base consegue transformar pastas esquecidas de PDFs em um assistente que equipe e clientes realmente usam.