GraphRAG: Da Sumarização Local à Global Focada em Consultas

O artigo GraphRAG da Microsoft surgiu em abril de 2024 e rapidamente se tornou a referência para quem questiona se gráficos de conhecimento poderiam salvar o RAG de seu modo de falha mais óbvio: perguntas que exigem a síntese de um corpus inteiro em vez da recuperação de uma passagem específica. Estou lendo-o agora porque o registro anterior sobre FinAuditing expôs como os LLMs têm dificuldade com estruturas XBRL multi-documento — e a abordagem de resumo de comunidade do GraphRAG é a resposta existente mais proeminente para exatamente esse tipo de problema de raciocínio global.

O artigo

"From Local to Global: A Graph RAG Approach to Query-Focused Summarization," de Darren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, Dasha Metropolitansky, Robert Osazuwa Ness e Jonathan Larson (Microsoft, arXiv:2404.16130), propõe um pipeline de dois estágios impulsionado por LLM para responder ao que os autores chamam de "perguntas de compreensão global" — consultas como "Quais são os principais temas deste conjunto de dados?" que o RAG vetorial padrão não pode responder porque nenhuma passagem individual contém a resposta.

A abordagem ocorre em duas fases. Durante a indexação, um LLM extrai entidades, relacionamentos e afirmações de cada bloco de texto, monta-os em um gráfico de entidades ponderado e, em seguida, executa a detecção de comunidade de Leiden para particionar o gráfico em uma hierarquia de clusters relacionados, gerando um resumo em linguagem natural para cada comunidade em cada nível. No momento da consulta, cada resumo de comunidade gera independentemente uma resposta parcial (a etapa map), essas respostas parciais são classificadas por pontuação de utilidade e reunidas até o limite da janela de contexto (a etapa reduce), resultando em uma resposta final sintetizada.

Ideias-chave

• A detecção de comunidade hierárquica de Leiden estrutura o corpus em quatro níveis de granularidade (C0–C3), permitindo que os usuários troquem profundidade de resposta por custo de tokens — resumos de nível raiz exigiram 97% menos tokens do que processar o texto de origem diretamente.
• Em dois corpora de teste — transcrições de podcasts (~1M de tokens, 8.564 entidades, 20.691 arestas de relacionamento) e artigos de notícias (~1,7M de tokens, 15.754 entidades, 19.520 arestas) — o GraphRAG alcançou taxas de vitória de abrangência de 72–83% e taxas de vitória de diversidade de 62–82% contra o RAG vetorial em comparações pareadas julgadas por LLM.
• O design map-reduce evita chamadas de LLM de contexto longo no momento da consulta: os resumos de comunidade são pré-computados, então a recuperação torna-se a busca de um resumo em vez do reprocessamento de documentos brutos.
• O artigo avalia seis condições: quatro níveis de hierarquia GraphRAG, sumarização de texto (TS) e busca semântica (SS). As condições globais do GraphRAG superam consistentemente o SS em perguntas de compreensão; o SS tem melhor desempenho em consultas de busca específicas.
• Experimentos de extração de afirmações descobriram que as condições globais extraíram uma média de 31–34 afirmações por resposta, contra 25–26 do RAG vetorial, sugerindo uma cobertura tópica mais ampla independente das preferências de pontuação do juiz LLM.
• O pipeline não requer esquema ou ontologia específica do domínio — a extração de entidades, a rotulagem de relacionamentos e a sumarização de comunidades provêm apenas de inferência via prompts.

O que se sustenta — e o que não

A percepção arquitetônica central está correta: o RAG de similaridade de cosseno não pode responder a perguntas de nível de corpus porque não existe um único bloco que represente o todo. Os resumos de comunidade pré-computados do GraphRAG são uma solução de contorno fundamentada, e a hierarquia baseada em Leiden é uma escolha de design real que permite navegar de resumos globais amplos a resumos de clusters detalhados, dependendo da tolerância ao custo.

Mas a avaliação tem problemas sérios. Um estudo independente recente (arXiv:2506.06331) auditou a metodologia de LLM como juiz usada pelo GraphRAG e seus sucessores e encontrou três vieses sistemáticos: viés de posição (as taxas de vitória mudam em mais de 30% simplesmente trocando qual resposta aparece primeiro no prompt), viés de comprimento (uma diferença de 25 tokens em uma resposta de 200 tokens cria uma variação de 50 pontos na taxa de vitória) e viés de tentativa (avaliações idênticas produzem resultados contraditórios em diferentes execuções). Após a correção desses fatores, as vantagens de desempenho reivindicadas colapsam — a taxa de vitória relatada do LightRAG de 66,7% sobre o RAG ingênuo corrige-se para 39,06%. Os próprios números de abrangência de 72–83% do GraphRAG quase certamente sofrem da mesma metodologia.

O custo de indexação também é um obstáculo genuíno. Uma análise de praticantes citou custos de construção de índice chegando a $47,90 contra o GPT-4o para corpora de tamanho moderado. A própria variante LazyGraphRAG da Microsoft, lançada posteriormente, reduz isso para 0,1% do custo total do GraphRAG, adiando a extração do gráfico para o momento da consulta — o que é um reconhecimento implícito de que o orçamento de indexação original é impraticável para muitas implementações reais.

Os dois corpora de avaliação também são limitados: dois conjuntos de dados em inglês totalizando entre 1 e 1,7 milhão de tokens cada. Os autores admitem que a generalização para outros domínios e escalas é desconhecida. Para dados estruturados ou semiestruturados — relatórios financeiros, exportações de livros-razão — os prompts de extração de entidades otimizados para texto narrativo podem perder os relacionamentos tabulares e hierárquicos que mais importam na prática.

Por que isso importa para a IA financeira

Um livro-razão Beancount é exatamente o corpus onde surgem naturalmente consultas de compreensão global: "Quais foram as minhas maiores categorias de gastos nos últimos três anos?" ou "Quais contas de fornecedores cresceram mais de 20% em relação ao ano anterior?". O RAG padrão não pode responder a estas porque nenhuma entrada individual contém a resposta — o agente precisa sintetizar através de milhares de transações.

A abordagem de resumo de comunidade do GraphRAG mapeia-se a isso: se os nós do gráfico de conhecimento forem contas, beneficiários e categorias de transação, e as arestas forem coocorrências ou relacionamentos de conta-pai, então os resumos de comunidade tornam-se visualizações agregadas pré-computadas sobre o livro-razão. A hierarquia também reflete como a árvore de contas do Beancount já estrutura os dados — Ativos, Despesas e Receitas decompõem-se recursivamente, o que se ajusta naturalmente ao agrupamento hierárquico no estilo Leiden.

Dito isso, as descobertas sobre o viés de avaliação servem de alerta: as taxas de vitória impressionantes no artigo podem não se sustentar sob testes controlados rigorosos, e o custo de indexação torna esta uma aposta de engenharia mais pesada do que parece. Especificamente para o Beancount, a agregação estruturada — consultas no estilo SQL ou pandas sobre o livro-razão exportado — pode superar a sumarização de comunidade impulsionada por LLM para análises determinísticas. O valor do GraphRAG seria maior para perguntas com carga narrativa, como raciocinar sobre memos de transação e nomes de fornecedores em escala, onde existe uma ambiguidade genuína que as consultas estruturadas não conseguem resolver.

O que ler a seguir

• LazyGraphRAG (Blog da Microsoft Research, 2024) — a variante de custo reduzido da Microsoft que adia a extração do gráfico; diretamente relevante para saber se a abordagem do GraphRAG é implementável em escala real de livro-razão sem custos proibitivos de indexação.
• "How Significant Are the Real Performance Gains? An Unbiased Evaluation Framework for GraphRAG" (arXiv:2506.06331) — a auditoria sistemática de viés; leitura essencial antes de aceitar qualquer número de taxa de vitória de avaliações de métodos de sumarização baseadas em LLM como juiz.
• "Towards Verifiably Safe Tool Use for LLM Agents" (arXiv:2601.08012, ICSE 2026) — o próximo item na lista de leitura; muda o foco da sumarização para a segurança na gravação (write-back), que é o problema não resolvido mais urgente para agentes Beancount.