RAG em 2026: por que seu sistema erra em contratos

Existe uma ironia nos projetos corporativos de IA: as empresas passam semanas debatendo qual LLM usar — GPT, Claude, Gemini, modelo aberto — e depois montam a camada de recuperação de documentos em uma tarde, com a receita mais simples que encontraram num tutorial. O resultado é previsível: um sistema que responde com confiança sobre contratos e políticas internas, mas erra de formas difíceis de detectar.

A tese deste artigo é direta: em RAG, o modelo é a parte menos importante do projeto. A documentação técnica da OpenClaw sobre RAG empresarial coloca números nessa afirmação: 80% da qualidade de um sistema RAG vem da estratégia de preparação e recuperação de dados, e apenas 20% do LLM em si. Quem inverte essa proporção — e a maioria inverte — está construindo um produto bonito em cima de uma fundação rachada.

A receita de 2023 virou passivo técnico

O RAG básico funciona assim: quebram-se os documentos em pedaços, geram-se embeddings, e quando alguém pergunta algo, o sistema recupera os k trechos mais semelhantes por semântica e entrega ao modelo. Simples, elegante — e insuficiente para corpora corporativos reais.

O problema aparece quando a base tem milhares de documentos parecidos entre si. Pense em uma empresa com milhares de contratos que compartilham a maior parte das cláusulas. A busca puramente semântica não distingue bem a versão vigente do aditivo antigo, nem o contrato do cliente A do contrato quase idêntico do cliente B. Os materiais avançados da própria OpenClaw alertam que essa recuperação top-k simplista pode levar a respostas juridicamente incorretas exatamente nesse cenário.

Os padrões de arquitetura descritos pela NH Labs para 2026 existem para resolver isso, e formam o que hoje se considera o stack padrão de RAG corporativo:

Retrieval hierárquico: primeiro filtrar por área ou tipo de documento (contratos, políticas de RH, manuais), depois buscar semanticamente dentro do subconjunto;
Busca híbrida: combinar busca vetorial com busca por palavra-chave (BM25), com fusão ponderada — a recomendação típica citada pela OpenClaw é 70% de peso para semântica e 30% para palavras-chave;
Reranker: uma camada que reordena os trechos recuperados por relevância e confiabilidade antes de entregá-los ao modelo.

Quem implementou RAG na arquitetura simplificada de 2023 e nunca revisitou o desenho está operando com passivo técnico. E, diferentemente de dívida técnica comum, essa não gera erro de sistema: gera resposta errada com cara de resposta certa.

Os números que justificam o esforço

O argumento a favor de fazer direito não é estético. A documentação da OpenClaw sobre pipelines RAG conectados a bases de conhecimento Odoo — indexando contratos, propostas comerciais e políticas operacionais — reporta redução das taxas de alucinação de 15–25% para menos de 3% quando as respostas são fundamentadas em documentos internos verificados, com citação da fonte original: link para o contrato, a política ou o manual técnico de onde a resposta saiu.

Essa queda — de até 25% para menos de 3% de alucinação — não é incremental. É a diferença entre um brinquedo em que ninguém do jurídico ou do financeiro vai confiar e uma ferramenta que a operação usa todo dia. Quando um vendedor pergunta "qual é o prazo de rescisão do contrato do cliente X?" e recebe o trecho exato do documento, com referência, o sistema deixa de ser IA generativa e passa a ser infraestrutura.

A Snowflake segue a mesma lógica na sua plataforma: descreve o RAG como forma de conectar LLMs a dados corporativos sem retreinar o modelo fundacional, apoiado em um pipeline governado de chunking e embeddings, com políticas de atualização e controle de acesso. O ponto central é o mesmo: o valor está no encanamento de dados, não no modelo.

Sem conjunto de avaliação, tudo é intuição

Aqui está a parte que quase nenhuma empresa faz — e que separa projetos sérios de demos glorificadas. Os guias da NH Labs são taxativos: sem um conjunto de avaliação realista e contínuo, toda otimização de RAG vira intuição. Você troca o modelo de embedding, ajusta o tamanho dos chunks, adiciona um reranker — e não tem como saber se melhorou ou piorou.

A recomendação prática, segundo os materiais da OpenClaw, é montar um dataset de 200 a 500 pares de perguntas e respostas, distribuídos de forma deliberada: 60% de perguntas comuns, 20% de casos extremos, 10% de casos negativos — situações em que o sistema deve se recusar a responder — e 10% de perguntas multi-hop, que exigem cruzar mais de dois documentos.

Repare nos 10% de casos negativos. Para setores regulados — jurídico, saúde, financeiro —, essa é talvez a fatia mais importante do teste. Um sistema que responde sobre um contrato que o usuário não deveria acessar, ou que inventa uma política de reembolso quando o documento não existe, é pior do que não ter sistema nenhum. Saber calar é uma feature, e precisa ser testada como qualquer outra.

O erro silencioso: a versão errada do documento certo

Há um risco pouco comentado que merece destaque: o RAG não distingue, por conta própria, o documento vigente do documento obsoleto. Se a indexação incluir uma versão desatualizada de um contrato ou uma política adaptada informalmente por uma filial, o sistema vai responder com alta confiança — baseado em regras que não valem mais. A recuperação semântica não sabe o que é "autoridade documental"; isso precisa ser regra explícita do pipeline: versionamento, hierarquia de fontes e descarte de documentos vencidos.

O mesmo vale para sigilo. Embeddings não carregam contexto organizacional. Se os controles de acesso não forem aplicados na camada de recuperação — segmentando bases por perfil, como as análises de mercado sobre RAG corporativo em 2026 descrevem para agentes que operam sobre contratos, CRM e políticas —, a busca vetorial pode expor trechos sensíveis a quem não deveria vê-los. Não porque o modelo "vazou", mas porque a recuperação foi desenhada sem essa camada.

O que isso significa para empresas brasileiras

Para o gestor brasileiro, três conclusões práticas. Primeira: se sua empresa já tem um piloto de RAG rodando, a pergunta certa não é "qual modelo estamos usando?", e sim "temos retrieval hierárquico, busca híbrida e um conjunto de avaliação com casos negativos?". Se a resposta for não, você tem um protótipo de 2023 em produção — e o risco cresce junto com o uso.

Segunda: a LGPD torna a governança da camada de recuperação inegociável. Consultar históricos de clientes e contratos via IA exige controle de acesso por perfil, trilha de auditoria das consultas e, em setores regulados como bancos e seguradoras, avaliação séria de arquiteturas on-premise ou com isolamento forte de dados — caminho que os roteiros de implantação corporativa recomendam explicitamente para dados sensíveis.

Terceira: comece medindo o baseline antes de construir. Quanto tempo sua equipe gasta hoje procurando uma cláusula, uma política, um histórico? Quantos erros nascem de informação não encontrada? Pilote em um departamento, com dataset de avaliação desde o dia um, e só então escale. RAG bem feito não é projeto de modelo — é projeto de dados, com um modelo na ponta. Quem entender isso primeiro vai ter o ativo; quem não entender vai ter o passivo, respondendo com confiança e errando em silêncio.

Seu RAG ainda é de 2023 — e é por isso que ele erra em contratos