Microsoft GraphRAG et Ollama : comment le RAG basé sur graphes a performé sur les modèles locaux

Une analyse détaillée de Microsoft GraphRAG en conjonction avec Ollama et les LLMs locaux a émergé. L'auteur a testé s'il est possible d'implémenter un RAG basé sur graphes sans infrastructure coûteuse, et a exécuté le système sur la nouvelle "Johnny Mnemonic" de William Gibson pour évaluer la qualité des réponses en utilisant un matériel cyberpunk familier.

Comment le test a été configuré

L'expérience s'est concentrée sur une question pratique : l'approche basée sur graphes peut-elle réellement remplacer la recherche vectorielle conventionnelle dans les systèmes RAG d'entreprise. Pour vérifier cela, l'auteur a choisi Microsoft GraphRAG, une exécution locale via Ollama, et un texte d'environ 38.000 mots.

Le résultat a été non seulement un index de recherche, mais aussi un graphe de connaissances complet avec des entités, des relations et des communautés. La visualisation via Gephi a montré que le système peut assembler une structure assez riche à partir d'un seul texte de fiction. Il est important de noter que GraphRAG forme non seulement des connexions littérales entre objets, mais aussi des clusters thématiques.

Dans les rapports, les communautés se regroupaient autour de la Yakuza, de Johnny, de Molly Millions et d'autres éléments clés de l'intrigue. Cependant, des limitations typiques ont également émergé : les entités ne fusionnent pas toujours si les noms différent en forme, donc certains doublons doivent être comptabilisés séparément. Pour les réponses en russe, l'auteur a ajusté les invites système, bien qu'il recommande de poser les questions en anglais, sinon la précision diminue.

"En bref, ça marche même sur les modèles 4B, bien qu'imparfaitement."

Comment le système répond

Le test a comparé plusieurs modes. Global search fonctionne sur les descriptions des communautés en utilisant la logique MapReduce et est mieux adapté aux questions sur l'ensemble du corpus. Local search mélange les relations du graphe avec des fragments du texte original et s'avère plus utile lors de l'analyse d'un personnage, d'un objet ou d'un épisode spécifique. Il y a aussi BASIC—une recherche ordinaire basée sur des chunks—et DRIFT, un mode plus intensif en calcul qui ressemble à query expansion et tente d'étendre le contexte.

• Global search a rassemblé les principaux thèmes cyberpunk de l'histoire : fusion de la technologie et de la biologie, ville dystopique, conflits corporatifs et inégalité technologique.
• Local search a fourni une réponse plus détaillée sur le personnage Jones et ses connexions avec Johnny, Molly et la Yakuza.
• DRIFT search sur la même question a pris environ quarante minutes et n'a pas produit un saut de qualité notable par rapport au mode local.
• BASIC reste un point de contrôle utile car la recherche vectorielle ne disparaît pas à l'intérieur de GraphRAG.

De cela, l'auteur tire une conclusion pratique importante : dans un produit réel, un agent séparé ou un routeur serait nécessaire pour sélectionner le type de recherche en fonction de la formulation de la question et de l'historique des demandes. Sinon, tous les modes devraient être basculés manuellement. Un autre détail—les réponses de GraphRAG référencent human_readable_id à partir de fichiers parquet, donc pour une interface utilisateur ces liens doivent être supplémentairement dépliés et traités. Cela transforme GraphRAG de simplement un outil de recherche en une couche qui doit être adaptée aux scénarios d'utilisateur réels.

Où des problèmes se sont produits

Avec les modèles locaux, le tableau s'avérait inégal. Mistral 7B parmi les exemples trouvés ne pouvait pas gérer global search en raison de problèmes de sortie JSON structurée : les requêtes map échouent simplement. Gemma 3 dans les versions 4B et 12B a préservé les entités principales mais a simplifié le graphe et a déformé les faits par endroits, au point que Jones est devenu un humain au lieu d'un dauphin.

L'option la plus viable, selon l'auteur, a été Qwen3 14B. Pour les embeddings, le modèle user-bge-m3 a été utilisé, qui fonctionne bien en russe et en anglais. Il y a aussi de nombreuses nuances d'infrastructure.

GraphRAG s'appuie sur LiteLLM, et l'auteur avertit spécifiquement de ne pas mettre à niveau au-delà de la version 1.82.6, car les versions 1.

82.7 et 1.82.

8 ont été compromises. En combinaison avec Ollama, une erreur 404 fausse se produit lors de la demande de paramètres de modèle, et les appels longs peuvent atteindre les timeouts de file d'attente. Les embeddings se comportent encore pire : bge-m3 via Ollama échoue parfois en raison de la sérialisation de Inf et NaN, donc l'embedding a dû être déplacé vers un proxy séparé sur HuggingFace.

De plus, vous devez éditer manuellement settings.yaml, définir api_base, la taille du vecteur 1024 et activer graphml pour la visualisation. Même sur une machine avec 16 Go de GPU, l'indexation de texte de cette taille prend plus d'une heure.

Ce que cela signifie

La conclusion principale de l'article est que Microsoft GraphRAG ne semble pas être un remplacement direct pour RAG vectoriel conventionnel. Il est plutôt utile là où la profondeur des relations sémantiques compte plus que la vitesse de réponse : en analytique, systèmes experts et collections complexes de documents. Parallèlement, l'approche possède déjà une API, une application test et un chemin clair vers MVP. Mais pour des réponses plus pertinentes, vous devez payer avec le temps d'indexation, la fragilité du pipeline et une configuration notablement plus complexe par rapport à une base de données vectorielle ordinaire.