Sber : le graphe de connaissances Yago n'a guère aidé la recherche, tandis que LightRAG a ajouté 12 p.p. de précision

Sber a expliqué comment il a tenté d'améliorer la qualité de la recherche interne en utilisant des graphes de connaissances et un RAG hybride. La première tentative avec un graphe universel prêt à l'emploi n'a eu presque aucun effet, mais le passage à LightRAG et son propre corpus de documents a notablement amélioré la précision des réponses.

Pourquoi le graphe n'a pas décollé

Les services de Sber reposaient déjà sur des schémas de recherche vectorielle et hybride, mais l'équipe s'est heurtée aux limitations typiques de cette approche. Un document unique doit être compressé en un vecteur, les nuances se perdent donc; la similarité sémantique ne signifie pas toujours que le document répond réellement à la question; et les requêtes multi-hop, où vous devez traverser plusieurs entités et documents, sont mal gérées par la recherche vectorielle ordinaire. Cela a conduit à une hypothèse: si nous ajoutions un graphe de connaissances comme source séparée de contexte, les réponses seraient plus précises et robustes.

Pour le tester, ils ont pris SimpleQA d'OpenAI (traduit en russe) sur 4.326 questions factuelles et utilisé llm-as-a-judge pour l'évaluation automatique. Le premier prototype a été construit sur Yago 4.

5, l'un des plus grands graphes de connaissances ouverts, qu'ils ont chargé dans Apache Jena Fuseki et ont déployé une API et un agent sur les données. Le pipeline était classique: extraction d'entités de la requête, requête basée sur template à la base de données graphique, classement des nœuds et arêtes trouvés, puis résumé de la réponse via LLM. Sur le papier, tout semblait convaincant, mais les gains se sont avérés faibles.

13 expériences d'affilée

Après les mesures initiales, l'équipe a configuré un banc de test séparé et a exécuté 13 expériences avec 184 mesures. D'abord ils ont testé le graphe pur, puis une combinaison du graphe avec la recherche ordinaire via un reranker, qui rassemblait un ensemble supérieur unique de candidats de réponse. La conclusion de base a été désagréable: sur ruSimpleQA le graphe en isolation n'a donné que +3 points de pourcentage, et combiné avec la recherche existante, le résultat n'a pas dépassé la marge d'erreur.

• Ont ajouté des sources supplémentaires, y compris IMDB, mais sans agrégation complexe de données au niveau de la base de données
• Ont essayé de classer les entités par pertinence, par exemple par le nombre de connexions à un nœud
• Ont modifié les limites de classement pour équilibrer la complétude du contexte et sa taille
• Ont testé la traversée intelligente du graphe à une profondeur de trois niveaux et la recherche en largeur sur un ou deux hops
• Ont ajouté la recherche vectorielle via les embeddings de nœuds et les algorithmes graphiques comme la recherche de chemin entre entités

Les problèmes n'étaient pas seulement dans l'infrastructure, mais aussi dans la nature du graphe lui-même. Pour les embeddings, ils devaient utiliser des descriptions d'entités courtes et éparses, ce qui rendait la recherche vectorielle sur le graphe instable. Yago s'est avéré être trop universel: il couvre bien le monde en général, mais reflète mal les domaines spécifiques et les relations importantes pour les requêtes réelles des utilisateurs. De plus, chaque étape de la chaîne d'agents ajoutait de nouvelles erreurs—de l'extraction d'entités à la résumé final.

Le tournant vers LightRAG

Après cela, l'équipe a changé de stratégie: au lieu d'un graphe universel mondial, ils ont décidé de construire un graphe directement à partir de leurs propres documents. Pour cela, ils ont choisi LightRAG—un framework GraphRAG avec une 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 arêtes du texte, puis les décrit, vectorise les valeurs et stocke le graphe avec les embeddings. Cette approche aide à éviter la perte de contexte entre les chunks et ne force pas le LLM à coller aveuglément des pièces aléatoires de différents documents.

"Des ordures en entrée produisent très probablement des ordures en sortie."

Sber a indexé son corpus de documents via LightRAG, en sélectionnant les documents qui répondaient aux questions que la recherche de produit ne pouvait pas résoudre, et a à nouveau exécuté les benchmarks. L'effet a été notable: LightRAG a fourni des réponses correctes à 74% de plusieurs centaines de questions précédemment non couvertes et a ajouté 12 points de pourcentage à la précision sur l'ensemble complet de 4.326 requêtes. Un plus supplémentaire—efficacité: l'article indique que LightRAG est approximativement 30–40 fois moins cher que Microsoft GraphRAG à l'étape d'indexation avec une qualité comparable. L'étape suivante est de tester sur le trafic de production et d'accélérer l'indexation, qui atteint actuellement un goulet d'étranglement d'environ 200 documents par heure même sur H100.

Ce que cela signifie

L'histoire de Sber démontre une chose simple: un grand graphe de connaissances par lui-même ne rend pas la recherche plus intelligente. Ce qui compte beaucoup plus, c'est à quel point le graphe est lié à votre domaine, comment il se connecte à la recherche vectorielle et sur lesquels les vrais écarts vous le mesurez. Pour les équipes qui construisent la recherche RAG, c'est un bon signal de ne pas poursuivre la belle démo avec un graphe public, mais d'investir dans un corpus de qualité, une récupération hybride et une évaluation honnête sur des scénarios réels.