GraphRAG vs RAG: o teste de 7 passos que me fez trocar depois de 3 meses errando
Rodei Vector RAG em produção por três meses achando que ia dar pra puxar na base do jeitinho. Toda vez que quebrava, eu jogava mais um reranker por cima, mexia no top-k, cortava os chunks menor. Voltava a quebrar. E quebrava sempre no mesmo formato de pergunta. Levei umas dez semanas a mais do que devia pra sacar que a forma era a mesma. Minha curva de aprendizado é, digamos, contida.
A forma era essa: sempre que a resposta pedia dois saltos entre documentos, o pipeline devolvia uma coisa errada com muita confiança. Não era “não encontrei”. Era uma resposta plausível, bem formatada e errada. Aquele tipo de resposta em que o stakeholder confia por exatamente uma semana antes do primeiro cliente reclamar.
Esse texto é o teste de sete passos que eu rodo hoje, antes de escrever qualquer linha de embedding, pra decidir se o trabalho precisa de grafo mesmo ou se eu tô a caminho de gastar um trimestre de engenharia contra uma incompatibilidade estrutural.
Onde o Vector RAG realmente para
Deixa eu nomear os três formatos de pergunta que quebravam. Guardo eles num arquivo rag-failures.md e testo qualquer corpus novo contra eles antes de fechar arquitetura.
Formato 1: “como A afeta B?” — A resposta mora na junção de dois documentos que não se citam. Doc A fala de uma mudança de config. Doc B fala de um pico de latência. O elo causal tá num terceiro artefato (thread do Slack, runbook, um ticket antigo do cliente) que menciona os dois. A busca vetorial devolve os documentos que falam de “pico de latência” e os que falam de “mudança de config” separados. O LLM tem que adivinhar a ponte que não tá no contexto. E adivinha errado.
Formato 2: “quais são todas as pessoas ligadas a X, e como?” — A resposta é uma lista de arestas. Vector store devolve documentos, não arestas. Já vi uma consulta cuja resposta correta eram 14 pessoas espalhadas em 40 documentos. O pipeline devolveu os cinco documentos mais similares e o LLM listou seis pessoas com toda a segurança do mundo. Ninguém consegue pegar o erro sem cruzar com ground truth na mão.
Formato 3: “qual é o tema desse corpus inteiro?” — Esse é o exemplo clássico do GraphRAG da Microsoft. Busca vetorial não consegue responder “resuma essa base inteira” porque não existe um chunk que diga “o tema é X”. O tema é uma propriedade estrutural que emerge da clusterização das entidades, não do match de query string. Eu tentei. Perdi um dia escrevendo prompts de resumo cada vez piores.
Se as perguntas centrais do produto caem em algum desses três formatos, tuning de reranker não te salva. Falo isso da posição de quem tunou reranker por três meses.
O que “só empurrar um grafo” não te compra
Antes do teste, um aviso que eu ignorei e paguei pra aprender: adicionar grafo não é subir um Neo4j do lado do teu pgvector. É pagar um custo de construção real toda vez que o corpus muda.
Microsoft GraphRAG num corpus de 500 páginas custa entre USD 50 e 200 pra indexar. Vector RAG no mesmo corpus fica abaixo de USD 5. Multiplicador de 10 a 40 vezes no custo de indexação, e ele compõe com o tamanho do corpus. Em 100 mil documentos, isso vira linha de orçamento. Em 1 milhão, vira decisão de diretoria. Só a extração de entidades consome uns 58% dos tokens de indexação.
Se a resposta do teu time pra “e se o corpus dobrar?” for um encolher de ombros, faz o teste primeiro. Se não fizer, o que sobra no mês quatro é uma demo linda de GraphRAG e um pipeline de ETL que ninguém quer manter.
O teste de 7 passos
Cada passo é sim ou não. Conta os sins.
Passo 1 — 30% ou mais das consultas reais são multi-hop? Multi-hop é quando a resposta pede juntar fatos de duas ou mais fontes que não se citam. Amostra o log real de uma semana. Lê na mão. Se menos de três em dez são relacionamento, provavelmente não precisa de grafo. Se a maioria é, quase certamente precisa.
Passo 2 — Os usuários fazem perguntas de relação ou de similaridade? “Me acha um documento sobre X” é similaridade. “Como X se conecta com Y” é relação. Vector RAG é otimizado arquiteturalmente pro primeiro e sofre estruturalmente com o segundo.
Passo 3 — As entidades têm identidade estável entre documentos? GraphRAG assume que “UserAPI” no doc A e “UserAPI” no doc B viram o mesmo nó. Se as entidades são bagunçadas (nome de cliente com typo, versão de produto com drift, três apelidos pro mesmo time), você vai gastar semanas em resolução de entidade antes do grafo dar retorno.
Passo 4 — Um especialista desenharia a resposta como diagrama? Parece frouxo, mas é o sinal mais confiável que eu conheço. Pede pro especialista do domínio resolver uma pergunta difícil na tua frente. Se ele vai pro quadro branco desenhando nós e setas, o trabalho tem forma de grafo. Se abre o Confluence e dá Ctrl-F, tem forma de documento.
Passo 5 — Você já tá emendando várias buscas dentro do prompt? Se o pipeline atual faz duas buscas por consulta e pede pro LLM reconciliar (“aqui os docs de config, aqui os docs de alerta, vira nas mãos”), você já tá escrevendo query de grafo à mão dentro do prompt. Fazer direito do lado do grafo costuma sair mais barato e mais preciso.
Passo 6 — Você precisa de caminho de raciocínio auditável? Compliance, saúde, jurídico. Muitas vezes a resposta tem que vir com a cadeia de evidência: “concluí X pelas arestas A→B→C”. Vector RAG te dá top-k documentos, não caminho. GraphRAG te dá um subgrafo, que já lê como traço de raciocínio.
Passo 7 — A dor de uma resposta errada é maior que a dor de uma resposta lenta? É aqui que o caso do LinkedIn entra. O artigo do LinkedIn na SIGIR ‘24 reporta -28,6% no tempo mediano de resolução de ticket e +77,6% em MRR depois de trocar pra pipeline aumentada por KG. Essa é a aposta do GraphRAG inteira: indexar mais devagar, mais trabalho de setup, em troca de qualidade de resposta maior nos formatos que importam.
Conta.
- 0 a 2 sins: Fica no Vector RAG. Adiciona reranker, busca híbrida com keyword, ajusta chunking. Vai colher mais do trabalho de qualidade de retrieval do que da troca de arquitetura.
- 3 a 4 sins: Considera híbrido. Um classificador pequeno roteia consulta: pergunta de relação vai pro GraphRAG, pergunta de similaridade fica com vetores. É pra onde os textos recentes de arquitetura tão convergindo como padrão.
- 5 a 7 sins: Você tem workload de grafo. Assume o custo de construção. Se não assumir, vai gastar o mesmo dinheiro em experimento de reranker e prompt hack e vai terminar com um sistema mais lento, mais caro e menos preciso.
O número dos multi-hop, já que prometi
O paper do Microsoft GraphRAG (arXiv
.16130) reporta 55,2 EM / 68,6 F1 no HotpotQA em modo local. Competitivo, mas não é atropelar baseline no dataset multi-hop mais fácil. Onde a diferença abre é no MuSiQue e no 2WikiMultiHopQA, os multi-hop difíceis, e em perguntas que atravessam o corpus inteiro do tipo “resume essa base” que RAG comum não consegue responder por design. Em recuperação multi-hop, retrieval baseado em grafo tá batendo perto de 86% enquanto Vector RAG puro fica na casa dos 30% em benchmarks recentes. Em single-hop, os dois empatam. Essa diferença é o teste de troca inteiro em um número só.Já vi dois times pularem pra GraphRAG na vibração de “multi-hop = número gordo”. Ambos subestimaram o custo de construção. Um subiu assim mesmo e tá funcionando. O outro voltou silenciosamente pra Vector RAG com um bom reranker e também tá funcionando. Os dois estavam certos. A diferença era se o log real de consultas tinha o formato que o grafo é bom em resolver.
A pergunta da stack, rápido
Se você chegou aos 5+ sins, escolher a stack não é a parte difícil. Neo4j é o padrão corporativo com ecossistema Cypher maduro. Kuzu é a opção embarcada, ótima quando você quer o grafo do lado do app. Memgraph fica no slot de análise em tempo real. Pra maior parte dos times a resposta honesta é: Neo4j até você superar ele, e você não supera no primeiro ano. Escolhe um, tira a primeira consulta do papel, e reavalia depois.
O que eu faço hoje antes de trocar qualquer coisa
Uma coisa menos prescritiva que o teste.
O que mais me ajudou no mês quatro foi parar de perguntar “qual arquitetura é melhor” e começar a perguntar “qual é o formato das perguntas que os usuários tão pagando pra responder”. Quando eu li o log de consulta com honestidade, quatro das dez perguntas principais eram formato 1 ou 2 lá de cima. Vector RAG nunca ia responder isso limpo. Eu tava iterando um sistema construído pra outro trabalho.
Se você tá três meses brigando com qualidade de retrieval: lê o log. Não amostra. Lê. Imprime. Marca os multi-hop com marca-texto. Uma tarde. Depois roda o teste de 7 passos. Ele vai te dizer ou “pare de fingir que precisa de grafo” ou “pare de fingir que não precisa”.
Eu me dei essa resposta oito semanas atrasado. Escrever isso limpo agora é meu pedido de desculpas pro meu eu do futuro.
ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews
Este artigo foi útil?