Por que a maioria dos RAGs corporativos falha no primeiro semestre

Existe um padrão que se repete em quase todo projeto de RAG corporativo que trava. A empresa monta o piloto, a demonstração funciona, todo mundo aplaude na reunião. Alguns meses depois, o sistema está no ar mas ninguém confia nele. As respostas às vezes estão certas, às vezes citam um documento que não existe, às vezes contradizem uma política interna que mudou no trimestre passado. O time técnico é acionado, começa a trocar o modelo de embedding, testa um vector store diferente, aumenta o tamanho do contexto. Nada resolve de verdade.

O diagnóstico da empresa costuma ser técnico: "nosso retrieval está ruim". A conclusão costuma ser comprar mais tecnologia. É justamente aí que o projeto entra no ciclo que o mata.

Este artigo defende uma tese que contraria o senso comum do mercado: o RAG corporativo raramente falha por causa do modelo. Ele falha porque a base de conhecimento que alimenta o sistema nunca foi tratada como um ativo governado. E essa não é só a minha leitura de quem constrói esses sistemas. É o que a pesquisa acadêmica sobre pontos de falha e os dados de mercado de 2025 e 2026 vêm mostrando de forma convergente.

Primeiro, o tamanho do problema

Antes de entrar no mecanismo técnico, vale estabelecer a escala. A taxa de fracasso de projetos de IA corporativa não é anedota, é dado consolidado por múltiplas fontes independentes.

A RAND Corporation, em análise divulgada no fim de 2025, documentou que mais de 80% dos projetos de IA corporativa não entregam o valor de negócio prometido, aproximadamente o dobro da taxa de fracasso de projetos de TI que não envolvem IA. O estudo do MIT, no relatório Project NANDA (The GenAI Divide, julho de 2025), foi ainda mais duro: cobrindo mais de 300 iniciativas e 150 entrevistas com executivos, encontrou que apenas 5% dos pilotos integrados de IA generativa extraem valor mensurável. Os outros 95% ficam presos sem impacto documentado no resultado.

A pergunta que importa é: por quê. E aqui a convergência das fontes é o que dá força ao argumento. A Gartner reporta que a qualidade e a disponibilidade de dados é o obstáculo técnico mais citado, e projeta que, ao longo de 2026, 60% dos projetos de IA sem dados prontos para IA (AI-ready data) serão abandonados. A pesquisa da Gartner do terceiro trimestre de 2024, com 248 líderes de gestão de dados, encontrou que 63% das organizações não têm ou não sabem se têm as práticas de gestão de dados adequadas para IA. A CDO Insights 2025, da Informatica, coloca qualidade e prontidão de dados como o obstáculo número um, citado por 43% dos respondentes, e registra que apenas 12% das organizações reportam ter dados de qualidade e acessibilidade suficientes para aplicações de IA.

O padrão é inequívoco. O gargalo dominante não é o modelo. É o dado que alimenta o modelo. E no caso específico de RAG, isso se manifesta de um jeito muito concreto.

O que a demo esconde

Uma demonstração de RAG é montada em condições artificiais. Você escolhe cinco ou dez documentos limpos, formula perguntas que você já sabe que os documentos respondem, e mostra o sistema acertando. É honesto no sentido de que o sistema realmente funciona naquelas condições. É enganoso no sentido de que aquelas condições não existem em produção.

Em produção, a base não tem dez documentos. Tem dez mil, com três versões do mesmo contrato, um manual de 2019 que ninguém arquivou, duas políticas que se contradizem porque uma foi atualizada e a outra não, PDFs escaneados sem texto pesquisável, planilhas exportadas como imagem, e e-mails encaminhados que viraram "documentação oficial" por acidente.

Essa distância entre piloto e operação não é uma percepção minha. É a primeira das duas grandes conclusões do trabalho acadêmico de referência sobre o tema. Barnett e colegas, no artigo Seven Failure Points When Engineering a Retrieval Augmented Generation System (arXiv 2401.05856, 2024), conduziram uma investigação empírica com 15.000 documentos e 1.000 perguntas em três domínios distintos (pesquisa, educação e biomedicina). As duas lições centrais do estudo são diretas: primeiro, a validação de um sistema de RAG só é viável durante a operação, não no projeto; segundo, a robustez de um sistema de RAG evolui com o tempo, não é projetada de uma vez no início. Em outras palavras, o que funciona na demo não diz quase nada sobre o que vai funcionar em produção.

O modelo de embedding não tem como saber qual das fontes conflitantes é a verdadeira. Ele foi treinado para medir similaridade semântica, não autoridade documental. Quando você pergunta "qual o prazo de cancelamento", ele recupera com competência os cinco trechos mais parecidos com a pergunta. Se três deles estão errados, desatualizados ou contraditórios, ele vai recuperar os três com a mesma confiança que recuperaria a resposta certa. O problema não é que ele recuperou mal. É que a base continha lixo, e recuperar lixo com precisão continua sendo lixo.

O ponto onde as falhas realmente acontecem

A engenharia de RAG tem uma sequência de estágios: ingestão, parsing, chunking, indexação, recuperação e geração. A intuição da maioria dos times é que a falha está nos estágios finais, na recuperação ou na geração, porque é ali que o erro aparece. A análise de quem estuda o pipeline inteiro diz o contrário.

A Unstructured, empresa especializada em preparação de dados para IA, resume o achado de forma cirúrgica em sua documentação técnica sobre desafios de RAG em produção: a maioria das falhas de RAG parece falha de modelo, mas começa mais cedo no pipeline. Se ingestão, parsing, chunking, indexação ou recuperação estão instáveis, o modelo recebe contexto fraco e produz resposta com alto risco de alucinação. A conclusão deles é a tese deste artigo em uma frase: um RAG é tão forte quanto a camada de dados que monta o contexto, e corrigir a geração primeiro é quase sempre a ordem errada, porque a qualidade da recuperação define o teto.

Quando um RAG corporativo produz respostas não confiáveis, a causa quase sempre está em uma destas quatro origens. Nenhuma delas se resolve no modelo.

1. Duplicação e versionamento invisível

A mesma informação existe em múltiplas versões, e o sistema não tem como saber qual é a vigente. Contrato v1, v2 e v2-final-mesmo coexistem na base. A política de reembolso de janeiro convive com a de julho. Quando o usuário pergunta, o retrieval traz a versão que for semanticamente mais próxima da pergunta, que muitas vezes é a mais antiga, porque foi escrita quando o vocabulário interno ainda era o mesmo que o usuário usa hoje.

Nenhum reranking resolve isso, porque o problema não é ordenação por relevância. Os dois documentos são igualmente relevantes para a pergunta. O problema é que um deles não deveria estar na base.

2. Ausência de metadado de autoridade

Cada trecho recuperado deveria carregar consigo a resposta para três perguntas: de onde veio, quando foi validado pela última vez, e quem é responsável por ele. Na maioria das bases corporativas, essa informação simplesmente não existe. O documento entrou no sistema como texto puro, sem data de vigência, sem dono, sem status.

É exatamente aqui que entra a definição operacional que a Gartner consolidou em fevereiro de 2025 para o conceito de AI-ready data. Dados prontos para IA são dados alinhados a casos de uso específicos, ativamente governados no nível do ativo, sustentados por pipelines automatizados com portões de qualidade, gerenciados através de metadado vivo e continuamente submetidos a controle de qualidade. Repare que a definição é quase inteiramente sobre governança e metadado, não sobre o modelo. Uma base sem metadado de autoridade não consegue nem filtrar o que está velho, nem citar a fonte de forma verificável, nem sinalizar que uma informação expirou. Ela trata um rascunho abandonado e uma norma vigente como cidadãos de igual peso.

3. Chunking que quebra a unidade de sentido

A forma como os documentos são fatiados em pedaços para indexação é tratada como detalhe técnico, quando é decisão de conteúdo com impacto mensurável na qualidade. Cortar um documento a cada quinhentos caracteres, sem respeitar onde termina uma cláusula ou um argumento, produz fragmentos que perdem o contexto que os tornava corretos. Uma exceção que estava três parágrafos abaixo da regra some. Uma condição que qualificava a afirmação principal fica em outro chunk e nunca é recuperada junto.

Isso é quantificável. Análises de benchmark de estratégias de chunking mostram que a diferença de recall entre a melhor e a pior abordagem para um mesmo corpus pode chegar a cerca de 9 pontos percentuais. É a diferença entre um sistema que encontra a informação certa e um que a deixa de fora, decidida antes de qualquer embedding ser gerado. E o custo de errar aqui é alto por um motivo estrutural: o chunking acontece antes da geração dos embeddings, então mudar a estratégia depois exige reprocessar o corpus inteiro.

O resultado de um chunking ruim é um trecho que, isolado, afirma algo que o documento inteiro, lido em contexto, não afirma. O modelo não está alucinando. Ele está reportando fielmente um fragmento que foi cortado no lugar errado.

4. Ingestão sem controle de entrada

A base cresce de forma orgânica e sem porteiro. Qualquer documento que aparece é indexado. Não há critério sobre o que entra, não há revisão sobre o que já está lá, não há processo para remover o que saiu de vigência. A base de conhecimento vira um depósito, e um depósito não é uma fonte de verdade.

Esse é o problema que mais se agrava com o tempo, e por isso o primeiro semestre é o ponto de virada que dá título a este artigo. No começo, a base é pequena e relativamente limpa. Conforme mais áreas despejam documentos nela sem governança, a proporção de ruído sobe, e a confiabilidade do sistema cai na mesma medida. A empresa percebe a queda e conclui que o sistema "piorou", quando na verdade a base é que se degradou. Isso conecta diretamente com o segundo achado de Barnett e colegas: a robustez evolui, para melhor ou para pior, e sem governança de ingestão ela evolui para pior.

Por que trocar o modelo dá a falsa sensação de progresso

Quando o time troca o embedding ou o vector store, geralmente há uma melhora pequena e mensurável em alguma métrica de recuperação. Isso reforça a crença de que o caminho é técnico. Mas essa melhora é marginal e tem teto baixo, porque o gargalo não estava ali.

Há uma forma concreta de diagnosticar isso, e ela vale mais que qualquer intuição. Meça o sistema com uma métrica de recuperação como Recall@K, que verifica se a resposta correta está entre os K primeiros trechos recuperados. Se o Recall já está alto, digamos que a resposta certa aparece entre os vinte primeiros na grande maioria das perguntas de um conjunto de avaliação, então a informação está sendo encontrada. O problema não é busca. Se, com Recall alto, a resposta final ainda é ruim, o problema está em qual trecho, entre os corretos e os incorretos que foram recuperados, o sistema escolheu usar. E isso depende da qualidade e da governança da base, não da capacidade de busca.

Investir mais no modelo quando o Recall já está alto é otimizar a parte que não está quebrada. É o equivalente a comprar uma câmera melhor para fotografar um ambiente mal iluminado. A lente não é o problema. Vale notar que a própria maturidade da tecnologia reforça isso: a diferença de qualidade entre um bom modelo de embedding e um excelente encolheu a ponto de ser pequena para a maioria dos casos de uso corporativos. A diferença entre uma base limpa e uma base caótica não encolheu nada.

O que fazer antes de tocar em qualquer componente técnico

A sequência correta inverte a ordem intuitiva. Antes de escolher modelo, antes de escolher vector store, antes de ajustar prompt, o trabalho é de governança de dados. Na prática, quatro frentes.

Primeiro, auditar a base de origem. Levantar o que existe, identificar duplicatas, versões concorrentes e documentos sem dono. Esse levantamento quase sempre revela que uma parte significativa da base não deveria estar sendo consultada. Remover essa parte melhora o sistema mais do que qualquer troca de modelo, e é a intervenção de maior retorno sobre esforço em todo o projeto.

Segundo, atribuir metadado de autoridade a cada fonte, seguindo o padrão de AI-ready data: data de vigência, responsável, status de validação. Isso permite que o sistema filtre por recência, cite fonte de forma verificável e sinalize quando uma informação expirou. É trabalho de curadoria, não de engenharia de modelo, e é o que separa um sistema auditável de um sistema opaco. Em domínios regulados, onde erro tem consequência jurídica ou financeira, essa camada não é opcional.

Terceiro, definir chunking por unidade de sentido, não por contagem de caracteres. Cortar respeitando a estrutura do documento, onde começa e termina uma cláusula, uma seção, um argumento completo. Uma técnica que resolve boa parte do dilema entre precisão e contexto é o parent-document retrieval: indexar chunks pequenos para o recuperador ter alvos de alta precisão, mas, quando um chunk pequeno é recuperado, entregar ao modelo o trecho pai que o contém, a seção ou o documento inteiro. O recuperador ganha a precisão dos fragmentos pequenos, o gerador ganha o contexto dos grandes. Para documentos longos onde o sentido depende do entorno, contratos, pareceres, normas, isso costuma ser um salto de qualidade sobre qualquer chunking de nível único.

Quarto, instituir um processo de ingestão com porteiro. Critério explícito sobre o que entra, revisão periódica do que já está indexado, e rotina de remoção do que saiu de vigência. A base de conhecimento precisa ser tratada como um sistema vivo que exige manutenção contínua, não como um arquivo morto que se enche indefinidamente.

O reenquadramento que muda o projeto

O erro estratégico que mata o RAG corporativo é enquadrá-lo como um projeto de tecnologia quando ele é, na maior parte, um projeto de governança de informação. A camada de IA é a menor parte do trabalho e a mais fácil de acertar. A camada difícil, a que determina se o sistema vai ser confiável ou não, é a curadoria da base que o alimenta.

Vale notar que esse mesmo princípio aparece nos dados sobre o que distingue os projetos que dão certo. A McKinsey, em sua pesquisa State of AI de 2025, encontrou que organizações que reportam retornos significativos com IA têm cerca do dobro de probabilidade de terem redesenhado os fluxos de trabalho de ponta a ponta antes de escolher a técnica de modelagem. Ou seja, os que ganham tratam o problema de processo e dado antes do problema de modelo. É o mesmo padrão, visto do lado do sucesso.

Isso tem uma implicação prática direta. Se a sua empresa está avaliando um projeto de RAG, ou tem um piloto que travou, a pergunta certa não é "qual modelo devemos usar". A pergunta certa é "quem é o dono da nossa base de conhecimento e qual o processo que garante que ela está limpa e vigente". Se essa pergunta não tem resposta, nenhum modelo vai resolver, e o projeto vai repetir o ciclo de degradação no semestre seguinte, entrando na estatística dos 60% que a Gartner projeta serem abandonados por falta de dados prontos para IA.

O RAG que funciona no segundo ano não é o que tem o melhor embedding. É o que foi construído sobre uma base governada desde o primeiro dia.

Referências

• Barnett, S. et al. Seven Failure Points When Engineering a Retrieval Augmented Generation System. arXiv:2401.05856, 2024. Investigação empírica com 15.000 documentos e 1.000 perguntas em três domínios.
• MIT Project NANDA. The GenAI Divide: State of AI in Business 2025. Julho de 2025. Cobertura de mais de 300 iniciativas e 150 entrevistas com executivos.
• RAND Corporation. Why AI Projects Fail. 2025. Meta-análise de casos documentados de projetos de IA corporativa.
• Gartner. Lack of AI-Ready Data Puts AI Projects at Risk. Fevereiro de 2025, e definição operacional de AI-ready data. Pesquisa com 248 líderes de gestão de dados (Q3 2024).
• Informatica. CDO Insights 2025. Qualidade e prontidão de dados como obstáculo número um à IA.
• McKinsey. The State of AI 2025. Correlação entre redesenho de fluxos e retorno financeiro com IA.
• Unstructured. Common Challenges in RAG and How to Solve Them in Production. Análise de falhas por estágio do pipeline.

As estatísticas de mercado citadas são consolidadas por múltiplas fontes de análise setorial e podem variar conforme metodologia e recorte. Recomenda-se consultar os relatórios originais para os números exatos e suas condições de medição.

Thiago Azeredo Rodrigues é engenheiro e consultor de IA aplicada, especializado em sistemas de RAG em produção, agentes e automações corporativas em domínios regulados. Constrói e avalia pipelines de recuperação com foco em confiabilidade, auditabilidade e operação real.