Quando o Graph RAG realmente agrega valor? Um experimento prático com 4 arquiteturas

O que um experimento caseiro revela sobre o Graph RAG

O Graph RAG virou presença constante em relatórios de analistas e arquiteturas de referência — knowledge graphs aparecem como ingrediente-chave para que sistemas de IA entendam não apenas informações, mas as relações entre elas. Mas quando, exatamente, adicionar um grafo de conhecimento compensa o esforço extra de engenharia?

Foi essa a pergunta que o engenheiro Arijit Ghoshal resolveu testar na prática. Em um artigo publicado no Towards Data Science, ele construiu quatro arquiteturas de recuperação em um laptop e as comparou usando os mesmos documentos e as mesmas perguntas.

As quatro arquiteturas testadas

Para manter a comparação justa, Ghoshal usou os mesmos componentes de base em todos os sistemas baseados em recuperação: o modelo Phi-4 da Microsoft (14 bilhões de parâmetros), rodando localmente via Ollama, e o modelo de embeddings all-MiniLM-L6-v2 para busca semântica. O grafo de conhecimento foi armazenado no Neo4j. Como referência externa, ele incluiu o Claude Haiku 4.5 recebendo os documentos completos, sem camada de recuperação.

• Sistema A — RAG simples: documentos divididos em blocos, convertidos em vetores; os cinco blocos mais relevantes são enviados ao modelo.
• Sistema B — Só o grafo: extrai triplas (sujeito–relação–objeto) e responde apenas com os conceitos e relações do grafo, sem o texto original.
• Sistema C — Graph RAG: combina os dois anteriores — o modelo recebe os trechos relevantes e as relações do grafo.
• Sistema D — Modelo de fronteira com contexto completo: os dois documentos inteiros vão direto ao Claude Haiku, sem recuperação.

O resultado que surpreendeu

O vencedor geral foi o modelo de fronteira — mas isso não decepcionou o autor. Pelo contrário: quanto mais ele olhava para as saídas, mais interessantes ficavam os trade-offs. O Graph RAG venceu o RAG simples de forma consistente em alguns tipos de pergunta, penou em outros e expôs um ponto muitas vezes esquecido: o valor do grafo depende do problema que você está tentando resolver.

Os três padrões descobertos

A avaliação, feita por um “juiz” LLM (o próprio Claude Haiku) em quatro dimensões — precisão, completude, raciocínio e proveniência — revelou três comportamentos distintos:

1. Raciocínio multi-hop: o Graph RAG teve vantagem clara quando a resposta exigia conectar conceitos entre documentos. O RAG simples recuperou os trechos certos, mas não tinha contexto suficiente e admitiu não saber responder.
2. Completude de recuperação: o Graph RAG ajudou pouco quando o desafio era recuperar todas as informações relevantes. Se os trechos ou nós nunca chegam ao prompt, o grafo não tem sobre o que raciocinar.
3. Proveniência e rastreabilidade: abordagens baseadas em grafo foram surpreendentemente boas para rastrear de onde uma informação veio — chegando perto do modelo de fronteira.

As lições práticas para quem for construir

Ghoshal também detalhou o que faria diferente. Três pontos se destacaram:

• Comece por uma ontologia: a maior fonte de ruído foi a proliferação de tipos de relação. Sem um vocabulário restrito, o modelo criou dezenas de rótulos de uso único, tornando o grafo difícil de consultar.
• Resolução de entidades é crítica: conceitos iguais apareciam como nós diferentes — “prompt injection”, “injection attack” e “prompt injection attack” viraram três nós separados, espalhando o contexto.
• Avaliação frágil leva a conclusões erradas: nos primeiros testes, o script de avaliação truncava os documentos, marcando respostas corretas como “sem suporte”. Uma avaliação ruim invalida qualquer comparação de arquitetura.

O veredito

A conclusão não é que Graph RAG é sempre melhor ou pior que RAG tradicional, mas que diferentes arquiteturas resolvem diferentes problemas. Se a sua aplicação depende de conectar conceitos espalhados por múltiplas fontes, o grafo agrega valor real. Se o gargalo é garantir que toda evidência relevante chegue ao modelo, o grafo não resolve o problema de recuperação — ele adiciona estrutura por cima dele.

O código completo do experimento, incluindo a construção do grafo no Neo4j, os quatro sistemas e a interface Gradio, está disponível no GitHub do autor.