Microsoft GraphRAG e Ollama: como o RAG baseado em grafo se saiu em modelos locais

Surgiu uma análise detalhada do Microsoft GraphRAG em conjunto com Ollama e LLMs locais. O autor testou se é possível implementar RAG baseado em grafos sem infraestrutura cara, e executou o sistema no conto "Johnny Mnemonic" de William Gibson para avaliar a qualidade das respostas usando material cyberpunk familiar.

Como o teste foi configurado

O experimento centrou-se em uma questão prática: a abordagem baseada em grafos pode realmente substituir a busca vetorial convencional em sistemas RAG corporativos. Para verificar isso, o autor escolheu Microsoft GraphRAG, execução local via Ollama, e um texto de aproximadamente 38.000 palavras.

O resultado foi não apenas um índice para busca, mas também um grafo de conhecimento completo com entidades, relações e comunidades. A visualização através do Gephi mostrou que o sistema consegue montar uma estrutura bastante rica a partir de um único texto de ficção. Importante notar que GraphRAG forma não apenas conexões literais entre objetos, mas também clusters temáticos.

Nos relatórios, as comunidades foram agrupadas em torno da Yakuza, Johnny, Molly Millions e outros elementos-chave da trama. No entanto, limitações típicas também surgiram: entidades nem sempre se mesclam se os nomes diferem em forma, então alguns duplicados precisam ser contabilizados separadamente. Para respostas em russo, o autor ajustou prompts do sistema, embora recomende fazer perguntas em inglês, caso contrário a precisão cai.

"Em resumo, funciona até em modelos 4B, embora imperfeitamente."

Como o sistema responde

O teste comparou vários modos. Global search funciona em descrições de comunidades usando lógica MapReduce e é mais adequado para perguntas sobre todo o corpus. Local search mistura relações do grafo com fragmentos do texto original e prova ser mais útil ao analisar um personagem, objeto ou episódio específico. Há também BASIC—busca baseada em chunks comum—e DRIFT, um modo mais intensivo em computação que se assemelha a query expansion e tenta expandir o contexto.

• Global search coletou os principais temas cyberpunk da história: fusão de tecnologia e biologia, cidade distópica, conflitos corporativos e desigualdade tecnológica.
• Local search forneceu uma resposta mais detalhada sobre o personagem Jones e suas conexões com Johnny, Molly e a Yakuza.
• DRIFT search na mesma pergunta levou cerca de quarenta minutos e não produziu um salto notável de qualidade comparado ao modo local.
• BASIC permanece um ponto de controle útil porque busca vetorial não desaparece dentro do GraphRAG.

Disso o autor tira uma conclusão prática importante: em um produto real, seria necessário um agente separado ou roteador para selecionar o tipo de busca baseado na formulação da pergunta e histórico de requisição. Caso contrário, todos os modos teriam que ser alternados manualmente. Outro detalhe—respostas do GraphRAG referenciam human_readable_id de arquivos parquet, então para uma interface de usuário esses links precisam ser adicionalmente desempacotados e processados. Isso transforma GraphRAG de simplesmente uma ferramenta de busca em uma camada que deve ser adaptada a cenários de usuário reais.

Onde surgiram problemas

Com modelos locais, o quadro se mostrou desigual. Mistral 7B dos exemplos encontrados não conseguia lidar com global search devido a problemas de saída JSON estruturada: map queries simplesmente falham. Gemma 3 nas versões 4B e 12B preservou as principais entidades mas simplificou o grafo e distorceu fatos em alguns lugares, ao ponto de Jones se tornar um humano em vez de um golfinho.

A opção mais viável, segundo o autor, foi Qwen3 14B. Para embeddings, foi utilizado o modelo user-bge-m3, que funciona bem tanto em russo quanto em inglês. Há também muitas nuances de infraestrutura.

GraphRAG depende de LiteLLM, e o autor especificamente avisa contra atualizar além da versão 1.82.6, porque 1.

82.7 e 1.82.

8 foram comprometidas. Em combinação com Ollama, um erro 404 falso ocorre ao solicitar parâmetros de modelo, e chamadas longas podem atingir timeouts de fila. Embeddings comportam-se ainda pior: bge-m3 através do Ollama às vezes falha devido à serialização de Inf e NaN, então embedding teve que ser movido para um proxy separado no HuggingFace.

Além disso você precisa editar manualmente settings.yaml, definir api_base, tamanho de vetor 1024 e habilitar graphml para visualização. Mesmo em uma máquina com 16 GB de GPU, indexar texto deste tamanho leva mais de uma hora.

O que isso significa

O principal aprendizado do artigo é que Microsoft GraphRAG não parece ser um substituto direto para RAG vetorial convencional. É mais útil onde a profundidade das relações semânticas importa mais do que a velocidade de resposta: em análises, sistemas especialistas e coleções complexas de documentos. Ao mesmo tempo, a abordagem já possui uma API, um aplicativo de teste e um caminho claro para MVP. Mas para respostas mais relevantes, você tem que pagar com tempo de indexação, fragilidade do pipeline e configuração notavelmente mais complexa em comparação com uma base de dados vetorial comum.