O artigo mostra por que RAG corporativo falha em consultas de agregação em sistemas corporativos, quanto essa falha custa na prática e qual arquitetura corrige o problema sem descartar o investimento já feito.
Resumo
- Janelas de contexto maiores não corrigem a falha estrutural do RAG em queries de agregação. De fato, o problema é arquitetural, não de tamanho de modelo.
- A solução passa por roteamento híbrido: queries computacionais vão para um motor determinístico de varredura completa, não para o LLM.
- Em escala corporativa, governança, controle de acesso e custo por inferência determinam o sucesso do RAG tanto quanto a acurácia técnica.
Introdução
RAG corporativo chegou a muitas empresas brasileiras como resposta rápida para dar memória aos LLMs sobre dados internos. O raciocínio era simples: recupere os trechos certos, passe ao modelo, obtenha a resposta. De fato, funcionou bem para perguntas narrativas. No entanto, falhou para perguntas numéricas.
De fato, o problema aparece quando o usuário pergunta “qual foi o faturamento médio por cliente no último trimestre” ou “quantos chamados abertos têm SLA vencido hoje”. Perguntas de agregação exigem varredura completa e cálculo. O RAG, por definição, recupera fragmentos, não varre tudo.
Por isso, aumentar a janela de contexto do modelo não resolve. Claude Opus 4.7 e GPT-5 aceitam centenas de milhares de tokens, mas o gargalo não está no modelo. Está na etapa de recuperação, que nunca entrega o conjunto completo de dados para calcular.
O limite real do RAG corporativo em dados estruturados
Em testes com 100.000 linhas de dados tabulares, pipelines de recuperação padrão erram em mais de 60% das queries de agregação. O modelo recebe fragmentos e estima. A estimativa parece confiante, mas está errada.
O impacto no negócio é direto. Um gerente financeiro que usa um assistente RAG para consultar o ERP pode receber um número errado sem nenhum aviso. O sistema não sabe que errou. Ele responde com a mesma fluência de quando acerta.
Por outro lado, queries narrativas, como “resuma os termos do contrato com o fornecedor X”, funcionam bem. O RAG foi construído para isso. O erro está em aplicá-lo onde ele não serve.
Ou seja, o problema não é o RAG em si. É usar RAG para o tipo errado de pergunta.
Por que janelas maiores não ajudam
A lógica parece razoável: se o modelo vê mais contexto, vê mais dados e calcula melhor. Na prática, não é assim. O indexador ainda seleciona os chunks mais próximos semanticamente da query. Ele não sabe que precisa de todos os registros para somar ou calcular média.
Além disso, passar 100.000 linhas no contexto tem custo. Com GPT-5, 1 milhão de tokens de entrada custam entre 10 e 15 dólares. Uma consulta analítica pesada pode consumir 200.000 tokens. Dez consultas por hora de um analista somam um custo que nenhum orçamento de TI aprovou.
Dessa forma, a solução de “mais contexto” cria dois problemas: não resolve a acurácia e explode o custo operacional.
Arquitetura híbrida: roteamento como solução
Por isso, a arquitetura que resolve o problema separa as queries em duas rotas antes de qualquer chamada ao LLM. Queries narrativas seguem o pipeline RAG tradicional. Queries computacionais vão direto para um motor determinístico de varredura completa.
Por isso, o roteador classifica a intenção da pergunta. Se a pergunta envolve contagem, soma, média, máximo, mínimo ou comparação de séries, ela vai para SQL, Spark ou outro motor analítico. Por fim, o LLM só entra depois, para formatar ou interpretar o resultado.
Assim, o modelo nunca tenta calcular. Ele narra o que o motor calculou. Por isso, a acurácia sobe para próximo de 100% nas queries analíticas, porque o cálculo é determinístico.
Como construir o roteador na prática
Por exemplo, o roteador pode ser um modelo leve de classificação de intenção, treinado com exemplos das queries reais da empresa. De fato, não precisa ser um LLM grande. Um modelo de 7 bilhões de parâmetros fine-tunado resolve bem, com latência abaixo de 50ms.
Em seguida, o motor analítico executa a query gerada. A geração de SQL a partir de linguagem natural, chamada de text-to-SQL, já tem soluções maduras. Azure SQL, BigQuery e Redshift aceitam integração direta com camadas de geração de SQL via LLM.
Por fim, o resultado volta ao LLM principal para ser narrado em linguagem natural. O usuário recebe a resposta correta, formatada, sem saber que dois sistemas distintos trabalharam juntos.
Para saber mais sobre como a recuperação semântica funciona na base dessa arquitetura, veja busca semântica com transformers.
RAG corporativo: governança e segurança
A maioria dos projetos de RAG corporativo falha por acurácia ou por governança. Os dois problemas têm peso igual, mas o segundo aparece depois, quando o sistema já está em produção.
O risco central é o seguinte: o índice vetorial não respeita, por padrão, as permissões do sistema de origem. Um analista de vendas pode recuperar um documento de RH se o chunk estiver no mesmo índice. A violação da LGPD e o risco trabalhista são consequências reais.
Por isso, a arquitetura de RAG corporativo precisa de controle de acesso no nível do chunk, não só no nível do documento. Cada fragmento indexado carrega metadados de permissão do usuário de origem. O retriever filtra por esses metadados antes de passar qualquer coisa ao modelo.
Compliance e rastreabilidade
Além do controle de acesso, o sistema precisa registrar cada consulta com rastreabilidade completa. Qual chunk foi recuperado, qual versão do documento, qual usuário perguntou e qual resposta foi entregue. Esse log é auditável.
Em setores regulados, como financeiro e saúde, esse requisito não é opcional. O Banco Central e a ANS já exigem rastreabilidade de decisões assistidas por IA em processos que afetam clientes. Empresas que implementam RAG sem esse log enfrentam risco regulatório.
Igualmente importante é a política de retenção dos dados de log. Logs de consulta podem conter dados sensíveis do usuário. Eles precisam seguir a mesma política de retenção dos dados de origem.
O artigo sobre RAG em produção: memória, acurácia e o preço que o negócio paga aprofunda os critérios de confiabilidade em ambiente produtivo.
Custo de RAG corporativo em escala: o que o orçamento precisa prever
O custo de RAG em escala tem três componentes que a maioria dos projetos-piloto ignora: indexação contínua, inferência e reindexação por atualização de dados.
A indexação inicial de um corpus de 10 milhões de documentos pode custar entre 8.000 e 25.000 dólares em embeddings, dependendo do modelo e do provedor. De fato, esse custo é único, mas a reindexação não é.
Em empresas com dados que mudam diariamente, como ERPs e CRMs, o índice vetorial envelhece rápido. De fato, um chunk desatualizado gera uma resposta errada com a mesma confiança de um chunk correto. Por isso, a reindexação incremental precisa estar no orçamento recorrente.
Por outro lado, a inferência é o custo que mais surpreende. Um assistente corporativo com 500 usuários ativos, cada um com 20 consultas por dia, gera 10.000 chamadas diárias ao LLM. Com custo médio de 0,05 dólares por consulta, são 500 dólares por dia ou 180.000 dólares por ano. Ou seja, sem cache e sem roteamento, esse número dobra.
Estratégias para controlar o custo
Por exemplo, o cache semântico é a primeira alavanca. Assim, perguntas similares recebem a resposta armazenada sem nova chamada ao modelo. Nesse sentido, em ambientes corporativos, onde muitas perguntas se repetem, o cache reduz o volume de inferências em 30% a 50%.
Em seguida, o roteamento para modelos menores ajuda. Queries simples vão para modelos de menor custo. Apenas queries complexas chegam ao modelo principal. A estratégia corta o custo por inferência em até 70% sem perda perceptível de qualidade.
Afinal, o custo de RAG não é só o modelo. É a soma de embedding, armazenamento vetorial, inferência e operação. O TCO precisa incluir todos esses itens antes da aprovação do projeto.
Integração de RAG corporativo com sistemas legados e dados estruturados
A maioria das empresas brasileiras de médio e grande porte tem os dados mais valiosos em ERPs, CRMs e data warehouses relacionais. De fato, esses sistemas não falam vetores. Por isso, integrar RAG com eles exige uma camada de tradução.
Para dados não estruturados, como contratos em PDF e e-mails, o pipeline RAG clássico funciona. No caso de tabelas relacionais, o text-to-SQL é o caminho mais direto. Para dados semiestruturados, como logs e JSONs, o chunking precisa de estratégia específica.
Certamente, o maior erro nessa integração é tentar vetorizar tabelas relacionais linha por linha. O resultado é um índice enorme, caro e com baixa acurácia em queries analíticas. A abordagem correta é usar o RAG para recuperar contexto e o motor SQL para calcular.
Veja como o chunking afeta diretamente a qualidade da recuperação em chunking em RAG: o erro que derruba sistemas de IA corporativos em produção.
Monitoramento e drift de qualidade
Em produção, a qualidade do RAG degrada com o tempo. De fato, os dados mudam, o vocabulário dos usuários evolui e o índice envelhece. Por isso, sem monitoramento, a empresa só descobre o problema quando um usuário reclama de uma resposta errada.
Por isso, o monitoramento precisa medir três métricas continuamente: taxa de recuperação relevante, taxa de respostas com alucinação e latência por percentil. A meta de SLA para assistentes corporativos costuma ser abaixo de 3 segundos no percentil 95.
Além disso, o drift semântico precisa de atenção. Quando novos produtos, processos ou regulações entram na empresa, o índice precisa ser atualizado. Um pipeline de reindexação automatizado, acionado por eventos de atualização de dados, resolve isso sem intervenção manual.
Para entender por que respostas erradas aparecem mesmo com dados corretos no índice, consulte sistemas RAG em produção: por que respostas erradas aparecem mesmo com dados corretos.
Quando usar RAG corporativo e quando não usar
A decisão de usar RAG corporativo precisa partir da natureza das perguntas que o sistema vai responder, não da tecnologia disponível.
RAG serve bem quando as perguntas são narrativas e contextuais: “quais são as cláusulas de rescisão do contrato com o fornecedor Y?”, “resuma as reclamações dos clientes do segmento premium no último mês”. Nesse sentido, a recuperação semântica entrega o contexto certo e o modelo narra com precisão.
RAG não serve quando as perguntas exigem cálculo sobre o conjunto completo de dados. Nesses casos, a arquitetura híbrida com motor analítico é obrigatória. Usar RAG puro para essas queries é aceitar erros sistemáticos em produção.
Por isso, antes de aprovar qualquer projeto de RAG, o CIO precisa mapear os tipos de query que o sistema vai atender. Nesse sentido, esse mapeamento define a arquitetura, o custo e o risco antes de uma linha de código ser escrita.
Para a decisão entre fine-tuning e RAG, veja o guia em fine-tuning vs. RAG: o guia para CTOs que precisam decidir agora.
Conclusão
RAG corporativo funciona. No entanto, funciona para um subconjunto específico de problemas. De fato, o erro mais caro que uma empresa pode cometer é tratar o RAG como solução universal para acesso a dados internos.
Por isso, a arquitetura híbrida, com roteamento entre pipeline semântico e motor analítico, resolve o problema estrutural das queries de agregação. Ela não é mais complexa do que parece. O roteador classifica, o motor certo executa, o LLM narra.
Além disso, governança, controle de acesso por chunk e monitoramento contínuo não são detalhes de implementação. São requisitos de produção. Sem eles, o sistema gera risco regulatório e erosão de confiança dos usuários.
Por isso, o CIO que aprova um projeto de RAG hoje precisa garantir três coisas: mapeamento de tipos de query, arquitetura híbrida para dados estruturados e TCO com todos os componentes de custo incluídos. Com esses três elementos, o projeto tem chance real de gerar valor mensurável.
Perguntas frequentes
RAG corporativo funciona com dados de ERP?
Funciona para consultas narrativas sobre documentos gerados pelo ERP, como notas fiscais em texto ou contratos exportados. Para queries analíticas sobre tabelas relacionais, o RAG puro falha. A arquitetura correta combina RAG com um motor de text-to-SQL que executa as queries diretamente no banco de dados do ERP.
Qual é o custo médio de implementar RAG corporativo em escala?
O custo varia muito com o volume de dados e o número de usuários. Para uma empresa com 10 milhões de documentos e 500 usuários ativos, o TCO anual fica entre 300.000 e 600.000 dólares, considerando indexação, armazenamento vetorial, inferência e operação. Sem cache semântico e roteamento, esse valor pode dobrar. O piloto raramente revela esses números porque opera em escala reduzida.
Como garantir conformidade com a LGPD em RAG corporativo?
O controle de acesso precisa operar no nível do chunk, não só no nível do documento. Cada fragmento indexado carrega metadados de permissão que o retriever valida antes de qualquer recuperação. Além disso, todos os logs de consulta precisam de rastreabilidade completa e política de retenção alinhada com a política de dados da empresa. Auditorias periódicas do índice verificam se dados sensíveis foram indexados sem as permissões corretas.
RAG corporativo substitui a busca tradicional por palavras-chave?
Para a maioria dos casos de uso corporativo, a busca semântica do RAG supera a busca por palavras-chave em precisão contextual. No entanto, para buscas exatas, como número de contrato ou código de produto, a busca por palavras-chave ainda é mais confiável e mais rápida. A arquitetura madura combina as duas abordagens: busca semântica para contexto e busca exata para identificadores.
Quando faz sentido escolher fine-tuning em vez de RAG corporativo?
Fine-tuning faz sentido quando o comportamento do modelo precisa mudar, não apenas o conhecimento. Se a empresa quer que o modelo adote um tom específico, siga um formato fixo de resposta ou domine um jargão técnico muito especializado, o fine-tuning é a escolha certa. RAG é a escolha certa quando o dado muda com frequência e o modelo precisa de acesso a informações atualizadas sem novo treinamento.