RAG na prática: como dar à IA o contexto da sua empresa

O problema que RAG resolve

Um modelo de linguagem sabe muito sobre o mundo e absolutamente nada sobre a sua empresa. Ele não viu o seu manual interno, o contrato do cliente X, a política de garantia revisada mês passado nem os dez mil chamados que o suporte já respondeu.

Pior: quando perguntado sobre isso, ele não diz que não sabe. Ele produz algo plausível — que é exatamente o comportamento mais perigoso em ambiente corporativo, porque a resposta errada chega com a mesma confiança da certa.

RAG — geração aumentada por recuperação — inverte o fluxo. Em vez de esperar que o modelo saiba, o sistema busca a informação na sua base, entrega os trechos relevantes junto com a pergunta e pede que a resposta seja construída a partir daquele material, com a fonte citada.

"Por que não colar tudo no prompt?"

É a primeira reação de quem descobre que os modelos aceitam contextos cada vez maiores. E funciona — para dez páginas. A partir daí, três coisas quebram:

• Custo. Você paga por tudo que entra, em toda pergunta. Reenviar um manual inteiro a cada consulta multiplica a conta por um fator que não fecha.
• Latência. Contexto grande é resposta lenta. Um assistente que demora quinze segundos não é usado.
• Precisão. Este é o ponto contraintuitivo: mais contexto piora a resposta quando a maior parte dele é irrelevante. A informação certa se dilui no ruído e a resposta perde foco.

RAG não existe só por limite técnico. Existe porque entregar cinco trechos certos produz resposta melhor do que entregar quinhentas páginas onde eles estão.

A anatomia de um sistema RAG

Há duas fases, e elas acontecem em momentos diferentes.

Indexação — antes, uma vez por documento

1. Extração. Ler o conteúdo real de PDFs, planilhas, páginas, e-mails e sistemas — preservando estrutura, tabelas e hierarquia de títulos.
2. Fragmentação. Quebrar em pedaços que façam sentido sozinhos. É a etapa mais subestimada e a que mais determina a qualidade final.
3. Enriquecimento. Anexar metadados a cada trecho: origem, data, versão, área, permissão de acesso.
4. Vetorização. Gerar a representação numérica que permite busca por significado, e não por palavra exata.

Consulta — a cada pergunta

1. Interpretação da pergunta, incluindo o histórico da conversa quando "e o segundo caso?" só faz sentido com o que veio antes.
2. Recuperação dos trechos candidatos, filtrada pelas permissões daquele usuário.
3. Reordenação dos candidatos por relevância real, descartando o que sobrou.
4. Geração da resposta com instrução explícita de se limitar ao material fornecido e citar a fonte.
5. Verificação — checar se o que foi afirmado está sustentado pelos trechos recuperados.

Onde os projetos de RAG quebram

Fragmentação ingênua

Cortar o documento a cada mil caracteres é o padrão de todo tutorial e a causa número um de resposta ruim. Ele parte tabelas ao meio, separa o título da seção do seu conteúdo e produz fragmentos que, isolados, não significam nada — "o prazo é de 30 dias" sem dizer prazo de quê.

A fragmentação boa respeita a estrutura do documento, mantém cada pedaço autocontido e carrega o caminho hierárquico junto: capítulo, seção, subseção. Custa mais para implementar e é onde está o maior ganho de qualidade por hora investida.

Busca só por vetor

Busca semântica é excelente para significado e ruim para o literal. Se o usuário procura um código de peça, um número de contrato ou uma sigla interna, a busca vetorial tende a trazer coisas parecidas em vez da exata.

A solução é combinar: busca por palavra-chave e busca semântica em paralelo, resultados fundidos. A combinação supera qualquer uma das duas isoladamente em praticamente todo cenário corporativo.

Ignorar permissões

Se a base tem documentos de RH, jurídico e financeiro, o filtro de acesso precisa acontecer na recuperação — não depois. Um sistema que recupera tudo e tenta esconder na resposta vaza informação na primeira pergunta bem formulada. Permissão é parte da consulta, não da apresentação.

Não tratar o "não sei"

Quando a recuperação não encontra nada relevante, o comportamento correto é dizer que não há informação — e, idealmente, oferecer o caminho humano. Um sistema que sempre responde alguma coisa é um sistema que vai inventar quando não souber, e uma resposta inventada custa mais caro que dez respostas ausentes.

Base desatualizada

Documentos mudam. Sem processo de reindexação, o assistente vai responder com a política do ano passado com total convicção. Versionamento, data de validade e reindexação automática precisam estar no escopo desde o começo — não na fase dois que nunca chega.

Avaliação: o que separa engenharia de tentativa

A pergunta que decide se um projeto de RAG é profissional ou artesanal: como você sabe que ficou melhor?

Sem um conjunto de avaliação, cada ajuste de prompt é uma aposta. Alguém muda uma instrução, testa três perguntas, acha que melhorou, e ninguém percebe que outras vinte pioraram.

Um conjunto mínimo tem três camadas:

• Qualidade da recuperação. Para uma pergunta conhecida, o trecho correto apareceu entre os recuperados? Essa métrica isola o problema — se a recuperação falha, nenhum ajuste de prompt salva.
• Fidelidade da resposta. Tudo que foi afirmado está sustentado pelos trechos recuperados, ou o modelo acrescentou coisa de fora?
• Utilidade. A resposta serve para quem perguntou? É a única que ainda exige julgamento humano, ainda que amostral.

Quando RAG não é a resposta

RAG virou reflexo, e nem sempre é o certo. Alguns casos em que existe caminho melhor:

• Dados estruturados. Se a pergunta é "quanto vendemos em junho", a resposta está numa consulta ao banco — não numa busca por similaridade. O padrão correto é gerar a consulta, não recuperar texto.
• Base pequena e estável. Com poucos documentos que raramente mudam, colocar tudo no contexto é mais simples, mais barato de manter e mais preciso.
• Ação, não informação. Se o usuário quer fazer algo — abrir chamado, emitir documento, alterar cadastro — o que se precisa é de um agente com ferramentas, não de recuperação de texto.

Na prática, sistemas maduros combinam os três: consulta estruturada para número, RAG para documento, ferramentas para ação — com uma camada de roteamento decidindo qual usar. É assim que a NasteSoft desenha produtos com IA.

Conclusão

RAG é conceitualmente simples e operacionalmente exigente. A parte fácil — vetorizar documentos e buscar por similaridade — é uma tarde de trabalho e está em qualquer tutorial. A parte que decide se o sistema é confiável está no tratamento dos documentos, na estratégia de recuperação, no controle de acesso, no comportamento diante da ausência de informação e na avaliação contínua.

É por isso que tantos pilotos impressionam na demonstração e decepcionam no uso real. A diferença não está no modelo. Está na engenharia em volta dele.