GraphRAG: guia prático de 6 padrões arquiteturais avançados

O salto do RAG vetorial para o GraphRAG

O RAG (Retrieval-Augmented Generation) é o caso de uso de LLM mais difundido nas empresas: vetorize documentos e recupere trechos semanticamente similares na hora da consulta para mitigar alucinações e contornar o corte de conhecimento dos modelos. Mas o RAG vetorial padrão tropeça em consultas que exigem contexto global, raciocínio multi-hop ou agregação de números entre documentos. Se você pergunta “como um atraso na entrega da peça A pelo fornecedor B afeta a montagem final do produto C?”, o RAG vetorial recupera trechos desconexos por sobreposição semântica e perde as relações determinísticas que conectam as entidades.

O GraphRAG resolve isso trocando a recuperação de documentos planos pela recuperação de conhecimento estruturado: integra grafos de conhecimento (KGs) — dados armazenados como nós, arestas e propriedades — ao pipeline de RAG, combinando a correspondência semântica difusa dos LLMs com o raciocínio determinístico dos grafos. Neste guia, Partha Sarkar detalha seis padrões arquiteturais distintos de GraphRAG, com prós, contras e casos de uso.

Componentes essenciais de qualquer GraphRAG

• Extração de informação: texto bruto passa por um LLM que faz NER (reconhecimento de entidades) e extração de relações, identificando nós (Empresa, Pessoa) e arestas (TRABALHA_PARA, FORNECE). É computacionalmente caro e exige uma ontologia bem definida.
• Armazenamento em grafo: nós e arestas carregados em um banco de grafos (Neo4j, NebulaGraph, Memgraph), consultados via Cypher. Nós e relações também podem ser embebidos para busca por similaridade.
• Recuperação: o mecanismo pelo qual a consulta do usuário interage com o grafo — é aqui que os padrões divergem.
• Geração: os dados do grafo recuperados entram na janela de contexto do LLM para sintetizar a resposta final.

Padrão 1: Text-to-Cypher

A abordagem mais direta e determinística. O LLM atua como tradutor de consulta, não como buscador semântico: recebe o schema do grafo (rótulos de nós, tipos de arestas e propriedades) no prompt e traduz a linguagem natural para Cypher (ou Gremlin). A consulta é executada direto no banco e o resultado exato é formatado em resposta por um segundo LLM.

Prós: recuperação com zero alucinação (100% determinística, como SQL) e a única que lida nativamente com agregações (contagem, média). Contras: fragilidade — se o usuário diz “desenvolvedor de software” mas a ontologia usa “Engenheiro”, a consulta retorna nulo; e não recupera contexto não estruturado (só o que está modelado como nós e arestas). Quando usar: bases operacionais altamente estruturadas — RH, cadeia de suprimentos, transações financeiras — onde precisão importa e os usuários conhecem o domínio.

Padrão 2: híbrido paralelo (vetor + grafo)

Mantém dois bancos separados — um índice vetorial dos chunks originais e um grafo de conhecimento das entidades extraídas — e consulta ambos simultaneamente. Os resultados das duas correntes são combinados no contexto do LLM.

Prós: alto recall (se a resposta está na nuance de um parágrafo, o vetor acha; se exige conectar dois fatos, o grafo acha) e baixa latência (as buscas rodam em paralelo). Contras: pesado em tokens (muito contexto injetado) e redundância (às vezes uma corrente já bastava). Quando usar: busca empresarial generalizada, quando não dá para prever se a consulta será factual-relacional ou de contexto amplo.

Padrão 3: híbrido sequencial (graph-first)

Usa o resultado de uma recuperação para informar e filtrar a outra. No graph-first, o sistema consulta o grafo primeiro, extrai os source_document_ids das entidades relevantes e os usa como filtro rígido na busca vetorial subsequente — garantindo que só textos dos documentos que mencionam as entidades certas sejam recuperados.

Prós: recuperação ancorada (restringe a busca aos documentos relevantes) e eficiência de tokens. Contras: latência sequencial e dependência estrita (se falta a aresta no grafo, a busca vetorial retorna nada — com fallback para busca global). Quando usar: consultas altamente centradas em entidade, como busca em textos jurídicos ou manuais de fabricação.

Um corolário importante é a arquitetura de grafo esparso: como a extração densa com LLM é cara, use NLP determinístico (SpaCy) ou modelos menores para construir um grafo esquelético só com as entidades críticas, deixando os chunks vetoriais preencherem o contexto.

Padrão 4: híbrido sequencial (vector-first)

O inverso do anterior: lança primeiro uma rede semântica ampla, depois usa o grafo para afiar o contexto. Faz a busca vetorial padrão, extrai as entidades-chave dos chunks recuperados e usa essas entidades como sementes para percorrer o grafo, puxando contexto multi-hop mais profundo.

Prós: descobre “desconhecidos desconhecidos” e é robusto a schemas ruins. Contras: latência sequencial e inchaço de contexto (expandir o grafo a partir de várias sementes pode gerar milhares de arestas irrelevantes). Quando usar: consultas amplas e abertas, análise forense, jornalismo investigativo e pesquisa profunda.

Padrão 5: agente roteador adaptativo

Nenhum padrão único é ótimo para toda consulta, então um agente roteador (um LLM rápido ou classificador ajustado) analisa a consulta de entrada — intenção, densidade de entidades e complexidade relacional — e a encaminha pelo caminho ótimo (cypher, vetor, graph-first, vector-first ou híbrido paralelo). O prompt de roteamento instrui o modelo a retornar um JSON com o pipeline escolhido.

Prós: otimização de custo e latência ao mandar consultas simples para caminhos baratos. Contras: overhead do roteador (uma chamada extra de LLM por consulta) e risco de má classificação. Quando usar: chatbots empresariais voltados ao usuário e barras de busca genéricas, onde a estrutura da consulta varia muito.

Padrão 6: GraphRAG agêntico

Em vez de uma única passada de recuperação, agentes autônomos interagem com o grafo dinamicamente: identificam um nó inicial, consultam vizinhos, avaliam o contexto intermediário e decidem se atravessam mais uma aresta ou leem o texto não estruturado no banco vetorial — num laço Reason-Act-Observe (ReAct) com memória de rascunho. Exige frameworks como LangGraph ou AutoGen.

Prós: raciocínio sem limites e autocorreção (se consultar o nó errado, percebe e muda de caminho). Contras: latência alta (5 a 20 chamadas de LLM por resposta, em minutos) e custo de laços potencialmente ilimitados. Quando usar: estritamente para consultas analíticas complexas e offline, não para chatbots em tempo real.

GraphRAG da Microsoft versus arquiteturas próprias

O framework GraphRAG da Microsoft é um paradigma diferente dos padrões de travessia acima: foca em construir uma representação hierárquica do corpus, com detecção de comunidades (algoritmo de Leiden) e relatórios gerados por LLM. O Global Search usa esses relatórios num processo map-reduce para responder “quais são os temas principais deste conjunto de dados?”; o Local Search combina entidades, relações e texto original para consultas específicas; o DRIFT Search mistura os dois. Para perguntas relacionais muito localizadas (“a quem John se reporta?”), um Graph-First ou Text-to-Cypher simples pode ser mais direto e barato. O diferencial da Microsoft é o raciocínio global em nível de corpus e a sumarização hierárquica — não é uma solução universal para todo problema relacional de RAG.

Desafios e boas práticas

• Custo da extração densa: comece com grafo esparso (SpaCy, GLiNER) e reserve a extração densa por LLM só para os documentos de maior valor.
• Deriva de ontologia: trate a ontologia como schema de banco em produção — com versionamento e governança, ontologia mínima e rígida, e saída estruturada (JSON/function calling) para impedir o LLM de inventar rótulos.
• Manutenção e sincronização: cada nó e aresta deve carregar um array source_document_ids; ao excluir um documento, remova o ID e apague o nó só se o array esvaziar.
• Avaliação do caminho de recuperação: frameworks como Ragas avaliam a resposta final, mas no GraphRAG é preciso saber se falhou o vetor, o grafo ou o roteador. Registre a saída de cada passo intermediário e use LLM-as-a-judge para avaliar o Cypher gerado independentemente da resposta.

A conclusão do guia é clara: não há uma única forma de implementar GraphRAG. A escolha já não é se usar grafos, mas qual padrão arquitetural — híbrido paralelo, roteamento adaptativo ou graph-first sequencial — melhor se encaixa nos requisitos de latência, orçamento e caso de uso de cada aplicação.