Microsoft GraphRAG et Ollama : le RAG par graphes à l'épreuve des modèles locaux

Une analyse détaillée de Microsoft GraphRAG couplé à Ollama et à des LLM locaux vient d'être publiée. L'auteur a vérifié s'il est possible de monter un RAG par graphes sans infrastructure coûteuse, et a fait tourner le système sur la nouvelle « Johnny Mnemonic » de William Gibson afin d'évaluer la qualité des réponses sur un matériau cyberpunk familier.

Comment le test a été monté

L'expérience reposait sur une question pratique : l'approche par graphes peut-elle vraiment remplacer la recherche vectorielle habituelle dans les systèmes RAG d'entreprise ? L'auteur a retenu Microsoft GraphRAG, un lancement local via Ollama et un texte d'environ 38 mille mots. Le résultat n'est pas seulement un index de recherche, mais un graphe de connaissances complet, avec entités, relations et communautés.

La visualisation via Gephi a montré que le système sait construire une structure assez riche à partir d'un seul texte de fiction. Point notable : GraphRAG ne forme pas seulement des liens littéraux entre objets, mais aussi des clusters thématiques. Dans les rapports de communautés, les groupes se sont formés autour des Yakuza, de Johnny, de Molly Millions et d'autres éléments clés de l'intrigue.

Des limites classiques sont aussi apparues : les entités ne fusionnent pas toujours lorsque les noms diffèrent par leur forme, si bien qu'une partie des doublons doit être traitée à part. Pour les réponses en russe, l'auteur a retouché les prompts système, tout en conseillant de poser les questions en anglais, faute de quoi la précision baisse.

«

En bref, ça fonctionne tant bien que mal même sur des modèles 4b ».

Comment le système répond

Le test a comparé plusieurs modes. La recherche globale travaille sur les descriptions des communautés selon une logique MapReduce et convient mieux aux questions portant sur l'ensemble du corpus. La recherche locale mêle les relations du graphe à des fragments du texte source et se révèle plus utile pour analyser un personnage, un objet ou un épisode précis. Il y a aussi BASIC, la recherche classique par chunks, et DRIFT, un mode plus lourd qui rappelle l'expansion de requête et tente d'élargir le contexte.

• La recherche globale a dégagé les grands thèmes cyberpunk du récit : la fusion de la technologie et de la biologie, une ville dystopique, les conflits entre entreprises et les inégalités technologiques.
• La recherche locale a fourni une réponse plus précise sur le personnage de Jones et ses liens avec Johnny, Molly et Yakuza.
• La recherche DRIFT a mis environ quarante minutes sur la même question, sans progrès de qualité sensible 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.

L'auteur en tire une conclusion pratique importante : un produit réel aura besoin d'un agent ou d'un routeur distinct, qui choisira le type de recherche selon la formulation de la question et l'historique de la requête. Sinon, il faudra changer de mode manuellement.

Autre détail : les réponses de GraphRAG renvoient à des human_readable_id issus des fichiers parquet, de sorte que, pour une interface utilisateur, ces références doivent être résolues et traitées séparément. GraphRAG passe ainsi de simple moteur de recherche à une couche qu'il faut adapter à un scénario d'usage réel.

Où les problèmes sont apparus

Avec les modèles locaux, le tableau est inégal. Parmi les exemples trouvés, Mistral 7B n'est pas venu à bout de la recherche globale à cause de problèmes de sortie JSON structurée : les requêtes map plantent tout simplement. Gemma 3, en versions 4B et 12B, a conservé les entités principales mais simplifié le graphe et déformé des faits par endroits, au point que Jones est devenu un humain au lieu d'un dauphin. L'auteur a désigné Qwen3 14B comme l'option la plus exploitable. Pour les embeddings, il a utilisé le modèle user-bge-m3, qui se comporte correctement en russe comme en anglais.

Les subtilités d'infrastructure sont nombreuses aussi. GraphRAG s'appuie sur LiteLLM, et l'auteur met expressément en garde contre toute version supérieure à 1.82.

6, car les versions 1.82.7 et 1.

82.8 ont été compromises. Avec Ollama, une fausse erreur 404 apparaît lors de la requête des paramètres du modèle, et les appels longs peuvent se heurter à des timeouts de file d'attente.

Les embeddings se comportent encore plus mal : bge-m3 via Ollama plante parfois à cause de la sérialisation d'Inf et de NaN, d'où la nécessité de déporter l'embedding vers un proxy distinct sur HuggingFace. Il faut en outre modifier settings.yaml à la main, définir api_base et une taille de vecteur de 1024, et activer graphml pour la visualisation.

Même sur une machine dotée de 16 Go de GPU, l'indexation d'un texte de cette taille prend plus d'une heure.

Ce que cela signifie

La conclusion principale de l'article est que Microsoft GraphRAG ne paraît pas être un remplaçant direct du RAG vectoriel classique. Il est plutôt utile là où la profondeur des liens sémantiques compte plus que la vitesse de réponse : analytique, systèmes experts et corpus documentaires complexes. L'approche dispose déjà d'une API, d'une application de test et d'une voie claire vers un MVP. Mais des réponses plus pertinentes se paient en temps d'indexation, en fragilité du pipeline et en une configuration nettement plus complexe qu'avec une base vectorielle ordinaire.