GraphRAG vs RAG clássico: quando o grafo vale 7x o custo

Aqui vai a parte que a maioria dos posts sobre GraphRAG deixa de fora: em 2 dos 4 projetos onde troquei RAG vetorial por GraphRAG, foi desperdício de tempo e de dinheiro. O problema não estava na implementação. O critério mais comum, “corpus grande + LLM = usar GraphRAG”, está errado em duas direções. GraphRAG custa até 7x mais para construir e não paga esse custo em qualquer corpus grande. Só paga em corpus onde as perguntas atravessam documento, e isso é um subconjunto pequeno do que a gente chama de “corpus grande”.

O que separa os casos não aparece em benchmark: aparece na conta de nuvem. Quatro cenários, quatro decisões diferentes. Escrevo aqui o que descobri, com número, para que quem estiver na frente dessa decisão não passe pelo mesmo aprendizado caro.

Resumo dos 4 casos:

Dois “valeu”, dois “não valeu”. Se você olhar o corpus, os quatro têm entre 2M e 40M de tokens: todos são grandes. Se olhar o número de documentos, todos passam de 300. Pelas heurísticas de blog, todos deveriam usar GraphRAG. Só que quem decide não é o corpus. Quem decide é a forma da pergunta.

O que é GraphRAG, em três frases honestas

Só para todo mundo ficar na mesma página. RAG clássico pega o texto, divide em pedaço, gera embedding, e na hora da consulta busca os pedaços mais próximos por similaridade vetorial e joga tudo no contexto do LLM. GraphRAG, na versão do paper da Microsoft Research (2024), pega o texto, extrai entidade e relação com LLM, monta um grafo, roda clusterização Leiden para descobrir comunidades, gera um resumo por comunidade, e na consulta usa esses resumos como índice. A diferença que importa é: o RAG te devolve “pedaço parecido”, o GraphRAG te devolve “estrutura de tema”.

Isso muda tudo em perguntas de segundo nível (“qual o tema comum entre esses documentos”, “quais desafios se repetem entre empresa A e B”) e quase nada em perguntas de primeiro nível (“onde está o artigo que fala de cache”). Essa é a linha que separa “valeu” de “não valeu”. Não é o tamanho, é o tipo de pergunta.

Projeto A: base de conhecimento pessoal — desperdício

Eu tenho um pipeline que registra artigos que leio, com resumo e nota de confiabilidade. São 300 fontes acumuladas em 3 meses. Perguntas que faço: “aquele texto sobre estratégia de cache”, “quem defendia X sobre agente autônomo”. Isso é 100% recuperação de pedaço. RAG vetorial resolve em milissegundos com embedding de $0,02 por mil documentos.

Testar GraphRAG aqui sai caro sem retorno: só indexar 300 fontes (extração de entidade + comunidade + resumo via LLM), e as respostas ficaram piores. GraphRAG devolve “temas gerais que atravessam o acervo”, quando a pergunta era “onde está aquele artigo específico”. Ferramenta certa para a pergunta errada.

Lição do A: se sua pergunta começa com “onde está…”, RAG clássico ganha. O grafo estorva.

Projeto B: due diligence de M&A — GraphRAG vale 7x

Aqui a coisa mudou. Um cliente pediu análise cruzada de 1200 documentos internos de 12 empresas candidatas a aquisição. Pergunta típica: “quais padrões de risco financeiro aparecem em pelo menos 3 empresas do portfólio?”.

Isso é pergunta de segundo nível. RAG vetorial nem chega perto. Ele me devolve pedaços de risco de uma empresa por vez, e a resposta final é o LLM tentando adivinhar padrão em cima de 40 chunks desconectados. Precisão baixa, alucinação alta.

GraphRAG indexou os 1200 documentos por 720 dólares em API (contra 95 dólares do RAG puro — 7,6x mais caro). A extração de entidade puxou tudo: nomes de empresa, indicador financeiro, cláusula contratual, data. A clusterização Leiden agrupou “empresas com padrão de dívida escondida em subsidiária”, “empresas com concentração de receita em cliente único”, e mais 5 clusters que ninguém tinha nomeado antes. Duas dessas comunidades pegaram um padrão que a equipe de auditoria não tinha notado em 3 semanas de trabalho.

É o caso em que a pergunta “quanto custa manter isso rodando” chega antes de qualquer discussão técnica. Vale 7x quando a pergunta é de segundo nível e a resposta muda uma decisão de dinheiro.

Projeto C: FAQ de produto SaaS — desperdício

500 artigos de ajuda de um produto SaaS. Perguntas de cliente: “como faço para exportar meu histórico?”, “por que meu login está falhando?”. Isso é primeiro nível puro. RAG vetorial com embedding barato resolve. Precisão de 89% no teste, latência de 300 milissegundos.

GraphRAG costuma ser testado aqui por pressão externa, não por necessidade técnica. Indexação custou 180 dólares, a precisão subiu para 91% — dois pontinhos. A latência foi para 2 segundos porque o retrieval agora envolve buscar comunidade + resumo + entidade. Trocamos velocidade por dois pontos de precisão que o cliente nem notou. Voltamos para RAG clássico na semana seguinte.

Lição do C: se a maioria das perguntas de usuário é “como faço X?”, RAG clássico basta. Comunidade e clusterização são luxo desnecessário.

Projeto D: análise de contratos jurídicos — GraphRAG vale ~4x

800 contratos de compra com 40 fornecedores. Perguntas do time jurídico: “quais cláusulas de rescisão aparecem em contratos com fornecedores do setor logístico?”, “onde estão as cláusulas de exclusividade em cascata entre fornecedores subcontratados?”.

Segundo nível, mas menos dramático que o projeto B. GraphRAG indexou os 800 contratos por 260 dólares (contra 65 do RAG — 4x). A extração de entidade puxou fornecedor, cláusula, valor, data, subcontratado. Os grafos de subcontratação foram o valor: com RAG vetorial, cláusulas encadeadas entre fornecedor A → subcontratado B → subcontratado C ficavam invisíveis. Com GraphRAG, apareciam em uma query.

O jurídico economizou umas 30 horas por trimestre. Pagou o 4x em três meses.

O que decide de verdade

Depois desses 4 projetos, minha heurística mudou. Não é mais “corpus grande = GraphRAG”. Passou a ser três perguntas antes de escolher.

1. A pergunta atravessa documento? Se sim, GraphRAG. Se é sempre “aquele texto onde…”, RAG. 2. A resposta muda uma decisão cara? Se sim, o 4x-7x é justificável. Se é FAQ interna, não é. 3. A estrutura entre entidades já é clara para o time? Se o time humano já sabe “esses três fornecedores têm cláusula cruzada”, GraphRAG só automatiza o que eles já viam. Se ninguém tem visibilidade dessa estrutura, GraphRAG é útil de verdade.

Se as três respostas forem sim, o custo se paga. Se qualquer uma for não, provavelmente vale RAG puro com bons embeddings.

O paper original da Microsoft (2024) sugere isso implicitamente, mas o discurso público simplificou e virou “corpus grande = GraphRAG”. A conta do Projeto A me lembrou que corpus grande com pergunta rasa é o pior caso: você paga 7x mais para receber resposta pior.

O que eu ainda não sei

Duas coisas que ficaram em aberto e eu escrevo aqui para não fingir que sei.

Primeiro, GraphRAG híbrido. Alguns projetos rodam GraphRAG só nas perguntas de segundo nível e RAG puro nas perguntas de primeiro nível, com um classificador entre os dois. Não testei em produção. No papel resolve o problema do Projeto A, na prática o classificador vira o gargalo. Vou testar no próximo trimestre.

Segundo, atualização incremental. Reindexar 1200 documentos toda vez que muda um contrato é caro. Existe trabalho recente sobre atualização incremental de comunidades Leiden, mas ainda é experimental. Nos meus projetos B e D, eu reindexo semanalmente e absorvo o custo. Se sua base muda diariamente, essa conta muda.

Fechamento honesto

GraphRAG não substitui o RAG. É uma ferramenta com forma de pergunta específica. Em 2 dos 4 cenários, muda o jogo. Nos outros 2, sai caro e pior. A diferença entre os dois grupos não estava no tamanho do corpus, estava no tipo de pergunta que o usuário final ia fazer.

Se você está prestes a começar um projeto de GraphRAG, vale sentar 30 minutos e listar as 20 perguntas mais comuns que seu usuário vai fazer. Se pelo menos 60% delas atravessam documento, siga. Se menos, fique no RAG vetorial e economize o 7x.

A versão completa deste material está no meu livro Manual completo de Knowledge Graph, que cobre de RDF vs Property Graph até GraphRAG em produção.

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews