Sber : le graphe de connaissances Yago n'a presque pas aidé la recherche, LightRAG a ajouté 12 points de précision

Sber a raconté comment il a tenté d'améliorer la qualité de sa recherche interne grâce à un graphe de connaissances et à un RAG hybride. Le premier essai, avec un graphe universel prêt à l'emploi, n'a presque rien donné. Le passage à LightRAG et à un corpus de documents propre a en revanche nettement relevé la précision des réponses.

Pourquoi le graphe n'a pas décollé

La recherche de certains services de Sber reposait déjà sur des schémas vectoriels et hybrides, mais l'équipe s'est heurtée aux limites classiques de cette approche. Un document doit être compressé en un seul vecteur, ce qui fait perdre des nuances ; la proximité sémantique ne signifie pas toujours que le document répond réellement à la question ; et les requêtes multi-hop, qui obligent à passer par plusieurs entités et documents, sont mal traitées par la recherche vectorielle classique. D'où l'hypothèse : si l'on ajoute un graphe de connaissances comme source de contexte distincte, les réponses seront plus précises et plus stables.

Pour la vérifier, l'équipe a utilisé SimpleQA d'OpenAI traduit en russe, soit 4326 questions factuelles, avec un dispositif llm-as-a-judge pour l'évaluation automatique. Le premier prototype reposait sur Yago 4.5, l'un des plus grands graphes de connaissances ouverts, chargé dans Apache Jena Fuseki, avec une API et un agent construits au-dessus des données. Le pipeline était classique : extraction des entités de la requête, requête à gabarit sur la base de graphes, classement des nœuds et des relations trouvés, puis synthèse de la réponse par un LLM. Sur le papier, tout semblait convaincant, mais dans les chiffres le gain s'est révélé faible.

13 expériences d'affilée

Après les premières mesures, l'équipe a monté un banc d'essai distinct et mené 13 expériences, soit 184 mesures. Elle a d'abord testé le graphe seul, puis le graphe associé à la recherche habituelle via un reranker qui constituait un top unique de candidats pour la réponse. Le constat de base a été désagréable : sur ruSimpleQA, le graphe isolé n'a donné que +3 points, et combiné à la recherche existante, le résultat n'est pas sorti de la marge d'erreur statistique.

• Ils ont branché des sources supplémentaires, dont IMDB, mais sans agrégation complexe des données au niveau de la base
• Ils ont essayé de classer les entités par pertinence, par exemple selon le nombre de liens d'un nœud
• Ils ont modifié les limites après le classement pour équilibrer l'exhaustivité du contexte et sa taille
• Ils ont testé un parcours intelligent du graphe jusqu'à trois niveaux de profondeur et une recherche en largeur sur un ou deux sauts
• Ils ont ajouté une recherche vectorielle sur les embeddings des nœuds et des algorithmes de graphes, comme la recherche d'un chemin entre entités

Les problèmes ne tenaient pas seulement à l'infrastructure, mais à la nature même du graphe. Pour les embeddings, il fallait utiliser des descriptions d'entités courtes et pauvres, si bien que la recherche vectorielle sur le graphe était elle-même instable. Yago s'est révélé trop universel : il couvre bien le monde en général, mais reflète mal les thématiques précises et les relations qui comptent dans les vraies requêtes des utilisateurs. De plus, chaque étape de la chaîne d'agents ajoutait une nouvelle erreur, de l'extraction de l'entité à la synthèse finale.

Le virage vers LightRAG

L'équipe a alors changé de stratégie : au lieu d'un graphe universel du monde, elle a décidé de construire le graphe directement à partir de ses propres documents. Elle a choisi LightRAG, un framework GraphRAG à recherche à deux niveaux, qui combine les relations locales entre entités et une vue thématique plus large. Le système extrait d'abord les nœuds et les relations du texte, puis les décrit, vectorise les valeurs et stocke le graphe avec les embeddings. Cette approche aide à ne pas perdre le contexte entre les chunks et n'oblige pas le LLM à recoller à l'aveugle des morceaux aléatoires de documents différents.

«

Des déchets en entrée donneront très probablement des déchets en sortie. »

Sber a indexé avec LightRAG un corpus de documents choisi pour les questions auxquelles la recherche en production ne répondait pas, puis a relancé les benchmarks. Cette fois, l'effet a été net : LightRAG a donné des réponses correctes à 74 % de plusieurs centaines de questions jusque-là non couvertes et a ajouté 12 points de précision sur l'ensemble complet de 4326 requêtes. Autre avantage, le coût : l'article indique que LightRAG est environ 30–40 fois moins cher que Microsoft GraphRAG à l'étape d'indexation, pour une qualité comparable.

La prochaine étape consiste à tester sur du trafic de production et à accélérer l'indexation, qui plafonne pour l'instant à environ 200 documents par heure, même sur un H100.

Ce que cela signifie

L'expérience de Sber montre une chose simple : un grand graphe de connaissances ne rend pas, à lui seul, la recherche plus intelligente. Ce qui compte bien davantage, c'est le degré d'ancrage du graphe dans votre domaine, son articulation avec la recherche vectorielle et les échecs réels sur lesquels vous le mesurez.

Pour les équipes qui construisent une recherche RAG, c'est un bon signal : mieux vaut ne pas courir après une belle démo avec un graphe public, et investir dans un corpus de qualité, un retrieval hybride et une évaluation honnête sur des scénarios réels.