80% dos POCs de GraphRAG na empresa morrem: os 3 padrões que sobrevivem (dados de 12 projetos)
Vou dizer o que 12 POCs de GraphRAG me ensinaram e o que a maioria dos posts de LinkedIn continua deixando de fora: grafo em cima de dado ruim continua sendo dado ruim, só que 7x mais caro para operar.
Nos últimos oito meses eu ajudei ou acompanhei 12 POCs de GraphRAG em empresas — cinco no Brasil, sete na Europa (Portugal, Alemanha, Holanda). Nove morreram até o mês 3. Três sobreviveram e viraram sistema em produção. A taxa bate quase exatamente com o que o Gartner vem dizendo sobre GenAI em geral: mais de 30% dos POCs de GenAI abandonados até o fim de 2025, e a leitura interna de várias consultorias põe o número em 60-80% para projetos que dependem de dado não pronto.
Não é sobre o Microsoft GraphRAG estar errado. O paper original é sólido, a implementação faz o que promete. O problema está sempre antes do grafo, e o padrão de sobrevivência dos três casos que deram certo é a peça que ninguém quer contar porque não vende consultoria.
Os 12 POCs em uma tabela
Anonimizei setor e volume porque alguns clientes eram nervosos com pontos de vírgula, mas as métricas de morte estão intactas.
| # | Setor | Corpus | Custo indexação | Mês do óbito | Causa dominante |
|---|---|---|---|---|---|
| 1 | Financeiro BR | 1.500 docs | US$ 4.200 | Mês 2 | Dado sem taxonomia |
| 2 | Farmacêutico EU | 8.000 docs | US$ 21.000 | Mês 3 | Governança bloqueou |
| 3 | Seguros BR | 3.400 docs | US$ 9.100 | Mês 2 | Extração de entidade < 60% precisão |
| 4 | Manufatura EU | 12.000 docs | US$ 33.000 | Mês 3 | Custo mensal > ROI esperado |
| 5 | Varejo BR | 900 docs | US$ 2.800 | Mês 1 | Não achou pergunta de segundo nível real |
| 6 | Telecom EU | 5.500 docs | US$ 14.500 | Sobreviveu | ver §“Padrão 1” |
| 7 | Jurídico BR | 2.800 docs | US$ 7.400 | Sobreviveu | ver §“Padrão 2” |
| 8 | Logística EU | 6.200 docs | US$ 16.000 | Mês 3 | Extração de relação inconsistente |
| 9 | Saúde BR | 4.100 docs | US$ 11.000 | Mês 2 | LGPD travou envio para LLM |
| 10 | Energia EU | 9.000 docs | US$ 24.000 | Mês 3 | Time descontinuou por reorg |
| 11 | Fintech BR | 1.200 docs | US$ 3.400 | Mês 2 | Vetorial resolvia 92% das perguntas |
| 12 | Editorial EU | 4.500 docs | US$ 12.000 | Sobreviveu | ver §“Padrão 3” |
Nove óbitos, três sobreviventes. O que os três que sobreviveram tinham em comum eu conto no fim, porque essa é a parte que muda decisão. Mas primeiro, o retrato do óbito.
O padrão dos 9 mortos: o grafo não criou estrutura, expôs a bagunça
Se eu olho POC por POC, cada um morreu por um motivo diferente na superfície. Governança, custo, precisão de extração, LGPD, reorg. Se eu junto os nove, o motivo é o mesmo: o time acreditou que o LLM ia extrair uma estrutura semântica de um corpus que nunca teve uma.
O ciclo é sempre igual. O time carrega documentos internos que ninguém arrumou em 5 anos. Roda o pipeline de extração de entidade com GPT-4 ou Claude. Recebe um grafo com 40 mil nós e 180 mil arestas, do qual 30% são duplicatas com grafia diferente, 20% são conceitos que ninguém no negócio reconhece, e 15% são relações que o LLM inventou porque o texto era ambíguo. Faz a demo com uma pergunta bonita (“mostre as conexões entre esses fornecedores”), a resposta parece impressionante, o C-level aprova a Fase 2. Três meses depois, a Fase 2 mostra que só 40% das relações são realmente confiáveis, e o custo de curar manualmente empurra o ROI para o próximo trimestre. Fim.
O caso #3 (seguros) é o retrato clássico. Extração de entidade com precisão de 58% em cima de laudos internos escritos por 40 peritos diferentes, cada um com convenção própria. “Sinistro” virou 4 entidades separadas (“SINISTRO”, “sinistro”, “Sinistro Nº”, “S.”). O grafo funcionou, no sentido de que existia. Só não representava a realidade que o time do negócio carregava na cabeça. Curar isso ia custar mais que o próprio POC.
O caso #4 (manufatura EU) morreu diferente e me marcou: precisão era razoável (78%), o grafo era útil, mas o cliente calculou o custo de manutenção mensal para atualizar em cima de 12 mil documentos entrando por mês e chegou em US$ 8.000/mês de API só para reindexar. Comparou com o que o time humano ganhava de produtividade e o número não fechou. É o problema que a Microsoft descreveu no blog do Azure sobre custo de GraphRAG: indexar é 10-40x mais caro que RAG vetorial, e isso não some quando o volume cresce.
O caso #9 (saúde BR) merece nota especial: o POC funcionou, o grafo era ótimo, e morreu por causa de LGPD. Enviar prontuário para LLM externo, mesmo com máscara, não passou no jurídico. O time chegou a testar Azure OpenAI com contrato de não-treinamento, mas o custo triplicou e o compliance ainda pediu on-premises. Não é falha do GraphRAG. É falha de assumir que dado sensível ia ser resolvido no meio do POC.
Os 3 padrões que sobreviveram
Agora a parte útil. Os três POCs que viraram sistema em produção (6, 7 e 12) parecem diferentes por fora. Telecom, jurídico e editorial. Corpus de tamanho diferente. Times de composição diferente. Mas se você olha o que estava antes do grafo entrar, os três têm a mesma característica.
Padrão 1 (POC #6, Telecom EU): já existia uma ontologia funcionando
O time de rede da telecom tinha uma taxonomia interna de tipos de incidente, tipos de equipamento, e relação entre eles, mantida há 6 anos em uma planilha compartilhada. Não era formal. Não era RDF. Mas era uma ontologia funcional que 40 engenheiros usavam todos os dias.
GraphRAG não teve que descobrir a estrutura. Ele materializou o que já existia. O prompt de extração de entidade recebia a lista de tipos possíveis, o LLM só precisava alocar cada trecho de documento nessa taxonomia. Precisão de extração pulou de “não sei” (o que veio no primeiro teste sem taxonomia) para 87% (com taxonomia guiando).
Isso é o que o capítulo 6 do livro que escrevi sobre KG chama de abordagem “conceito primeiro”: quando o domínio já tem uma lista de entidades conhecidas, extrai as entidades primeiro e amarra as relações depois. O trabalho da equipe da telecom em 6 anos foi o que fez o GraphRAG funcionar em 6 semanas.
Padrão 2 (POC #7, Jurídico BR): a pergunta de segundo nível era um caso de uso real e recorrente
O escritório jurídico tinha uma pergunta que aparecia toda semana: “quais cláusulas de exclusividade em cascata existem entre nossos fornecedores subcontratados?”. Não era caso de demo. Era caso operacional, com prazo, com valor de contrato.
Isso é o que separa GraphRAG útil de GraphRAG bonito. RAG vetorial não consegue responder “atravesse 3 documentos e me diga se essa cláusula reaparece”: ele pega chunks parecidos, não estrutura. E a estrutura da resposta importava tanto que pagava o custo extra sem discussão.
Os POCs que morreram por causa disso foram #5 e #11 no meu grupo. O time construiu o grafo e depois foi procurar pergunta de segundo nível. Achou 3, mas nenhuma era recorrente o suficiente para pagar a operação. Ordem invertida: primeiro a pergunta, depois o grafo.
Padrão 3 (POC #12, Editorial EU): o dado já estava semi-estruturado antes
A editora acadêmica europeia tinha 4.500 artigos com metadados sólidos: DOI, autores, keywords do MeSH, referências cruzadas. O grafo não teve que sair de texto puro. Ele partiu de dado que já era quase um grafo. A extração de entidade foi mais validação do que descoberta.
Isso baixou o custo de indexação para 1/3 do esperado (US$ 12.000 contra os US$ 33.000 do caso comparável na manufatura), porque o LLM foi usado só para preencher lacunas, não para gerar tudo. Custo de indexação e precisão de extração andam juntos: quando o dado já vem estruturado, o LLM alucina menos e trabalha menos.
A coisa em comum que quase ninguém está falando
Se você põe os três padrões em cima da mesa, o que aparece é: a estrutura semântica já existia antes do GraphRAG entrar. Numa taxonomia mantida à mão, numa pergunta operacional recorrente, ou num metadado já limpo.
GraphRAG não cria estrutura. Ele acelera estrutura que já existe. Os POCs que morreram foram os que apostaram no LLM para gerar a semântica que o negócio nunca tinha construído. Os que sobreviveram usaram o LLM para amarrar semântica que a equipe humana já mantinha.
Isso muda o critério de decisão inteiro. A pergunta certa não é sobre volume de corpus ou vontade de usar IA. Antes de gastar em API, o time precisa responder: existe uma taxonomia, uma pergunta recorrente, ou um metadado já limpo que o GraphRAG possa acelerar? Se a resposta for não para todas as três, o POC vai morrer no mês 3 e você vai pagar US$ 15.000-30.000 para descobrir isso.
Também bate com um resultado interessante do GraphRAG-Bench aceito no ICLR 2026: em relevância de contexto, métodos GraphRAG marcaram 36-55% contra 63% do RAG vanilla em corpus generalista. Ou seja, na média, GraphRAG perde. Só ganha em condições específicas — e essas condições são exatamente as três acima.
O que eu recomendo antes do próximo POC
Uma pergunta única, antes de gastar em API: quem no time do negócio já mantém uma lista, uma taxonomia, ou uma pergunta cruzada há mais de 6 meses? Se ninguém: adia o GraphRAG, monta a estrutura à mão primeiro, faz RAG vetorial em cima, e reavalia em 3 meses. Se alguém: começa o POC amarrado nessa lista, não em cima do corpus inteiro.
Nove POCs mortos me convenceram que o erro comum não é técnico. É de sequência. Primeiro a estrutura semântica (do humano). Depois o grafo (do LLM). Fazer na ordem contrária custa entre US$ 3.000 e US$ 33.000, e três meses do time inteiro parecendo que está indo bem até parar.
Se ficar em dúvida sobre onde entrar, começa pelas duas perguntas que decidiram o critério nos meus casos: (1) a pergunta atravessa 3 documentos ou mais? (2) alguém já mantém uma lista sobre isso à mão? Se as duas forem sim, GraphRAG paga. Se qualquer uma for não, RAG vetorial faz o trabalho por menos.
ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews
Este artigo foi útil?