Agentic SPARQL: Evaluating SPARQL-MCP-powered Intelligent Agents on the Federated KGQA Benchmark

Cet article explore le potentiel des agents intelligents alimentés par le protocole MCP pour faciliter l'interrogation fédérée de graphes de connaissances en étendant un benchmark existant et en évaluant différentes architectures intégrant la découverte de sources, l'exploration de schémas et la formulation de requêtes SPARQL.

L'essentiel

🌍 Le Grand Défi : Trouver l'aiguille dans la botte de foin... mais dans plusieurs granges !

Imaginez que vous voulez répondre à une question complexe, par exemple : "Quelles sont les publications de Tim Berners-Lee qui existent à la fois dans la base de données DBLP et sur Wikidata ?"

Le problème, c'est que les informations ne sont pas toutes dans un seul livre ou un seul site web. Elles sont dispersées dans des milliers de "granges" différentes (des bases de données en ligne appelées endpoints SPARQL). Certaines granges sont ouvertes, d'autres fermées, certaines parlent un dialecte bizarre, et d'autres sont très lentes.

Traditionnellement, un humain (ou un programme rigide) devrait :

1. Savoir exactement où chercher.
2. Savoir comment poser la question dans le langage spécifique de chaque grange.
3. Assembler les réponses manuellement.

C'est fastidieux et souvent impossible si on ne connaît pas toutes les granges à l'avance.

🤖 La Solution : L'Agent Intelligent avec une "Boîte à Outils" (MCP)

Les auteurs de ce papier proposent d'utiliser une Intelligence Artificielle (LLM) qui agit comme un détective très curieux. Mais pour que ce détective puisse travailler, ils lui donnent une Boîte à Outils Standardisée appelée MCP (Model Context Protocol).

Au lieu de coder le détective pour qu'il connaisse chaque grange par cœur, on lui donne des outils génériques :

• Outil "Explorer" : Pour regarder ce qu'il y a dans une grange (quelques échantillons, de quoi ça parle).
• Outil "Demander" : Pour poser une question précise.
• Outil "Fédérer" : Pour demander à plusieurs granges en même temps et assembler les réponses.

L'objectif est de créer un "Agent SPARQL" capable de naviguer seul dans ce monde dispersé.

🧱 Les Obstacles (Les "Murs" du labyrinthe)

Les chercheurs ont identifié 5 gros problèmes qui rendent la tâche difficile pour l'IA :

1. Le Chaos des Portes (Hétérogénéité) : Certaines granges ont une porte simple, d'autres sont des labyrinthes complexes. L'IA doit savoir comment entrer dans chacune.
2. Le Langage Bizarre (Support inégal) : Même si toutes parlent le même langage théorique (SPARQL), certaines ne comprennent pas les mots compliqués (comme les calculs de sommes ou les unions). L'IA doit adapter sa phrase.
3. L'Absence de Carte (Métadonnées) : Souvent, il n'y a pas de catalogue pour dire "Cette grange contient des voitures, celle-là des livres". L'IA doit deviner ou chercher.
4. La Grange Fermée (Latence et Pannes) : Parfois, une grange est en grève (trop de monde) ou fermée pour la nuit. L'IA ne doit pas attendre éternellement.
5. La Question Mal Posée (Formulation) : Si l'IA pose une question mal formulée, elle n'obtient rien. C'est comme demander "Donne-moi le truc rouge" sans dire de quel objet il s'agit.

🛠️ Ce que les chercheurs ont construit

Pour tester leur idée, ils ont fait trois choses principales :

1. Ils ont créé un "Terrain d'Entraînement" (Benchmark FKGQA) :
   Imaginez qu'ils prennent un jeu de données (comme un grand puzzle) et qu'ils le découpent en 118 petits morceaux (shards), puis qu'ils les cachent dans 118 granges différentes. L'IA doit retrouver les pièces du puzzle sans savoir où elles sont. C'est comme si on cachait les pièces d'un puzzle dans différentes maisons et qu'on demandait à l'IA de reconstituer l'image sans carte.

2. Ils ont construit le "Garage" (Serveur SPARQL-MCP) :
   Ils ont créé un serveur qui fait le pont entre l'IA et les granges. Si l'IA veut poser une question à 10 granges en même temps, ce serveur s'occupe de découper la question, de l'envoyer, et de remettre les pièces ensemble.

3. Ils ont fait le Grand Test :
   Ils ont mis en compétition deux types d'IA :

   • Le "Super-Détective" (GPT-5.2) : Un modèle très puissant.
   • Le "Petit Apprenti" (Qwen3-8B) : Un modèle plus petit et moins cher.

🏆 Les Résultats : Qui gagne ?

• Le Super-Détective (GPT-5.2) : Il est excellent ! Il arrive à trouver les bonnes réponses dans 45% des cas, ce qui est aussi bien que les meilleurs systèmes actuels, même avec la complexité de devoir chercher dans plusieurs granges.

  • Son style : Il explore, teste une grange, puis une autre. Il est intelligent et évite de poser la même question à tout le monde.
  • Le secret : Il fonctionne mieux si on lui donne une description simple de la grange (ex: "C'est une base de données sur les voitures") plutôt qu'une fiche technique trop complexe.

• Le Petit Apprenti (Qwen3-8B) : Il a beaucoup de mal. Il réussit seulement dans 13% des cas.

  • Son style : Il est paniqué. Il pose la même question à toutes les granges en même temps (ce qui est lent et inefficace) et fait beaucoup de fautes de grammaire dans ses questions.

💡 La Conclusion en une phrase

Ce papier prouve que si on donne les bons outils (MCP) et une IA assez intelligente, on peut créer des agents capables de naviguer seuls dans le chaos des données mondiales. Cependant, il faut encore de gros modèles d'IA pour éviter qu'ils ne fassent des erreurs bêtes ou qu'ils ne perdent du temps à tout demander à tout le monde.

C'est comme passer d'un humain qui doit apprendre par cœur chaque bibliothèque du monde, à un robot qui sait lire les étiquettes, choisir la bonne bibliothèque et poser la bonne question, à condition que le robot soit assez "intelligent" pour ne pas se tromper de chemin !

Résumé technique

1. Problématique et Contexte

L'article aborde la convergence entre deux domaines : les agents intelligents basés sur les LLM (Large Language Models) et les requêtes SPARQL fédérées sur des Graphes de Connaissances (KG).

Bien que les protocoles comme le Model Context Protocol (MCP) permettent désormais aux LLMs de se connecter à des outils externes, leur application aux environnements de données distribués (fédérés) reste sous-exploitée. Les défis majeurs identifiés pour intégrer les agents SPARQL dans un contexte fédéré sont :

• Hétérogénéité des interfaces : Les points de terminaison (endpoints) varient du simple dump RDF aux endpoints SPARQL complets.
• Support inégal de SPARQL 1.1 : Certains endpoints ne supportent pas toutes les fonctionnalités (agrégats, clauses SERVICE, VALUES), nécessitant des stratégies de fédération sur mesure.
• Hétérogénéité des métadonnées : L'absence de catalogues standardisés rend la découverte d'endpoints et la sélection de sources difficiles, conduisant souvent à des exécutions lentes.
• Latence et disponibilité : Les endpoints peuvent être bloqués, lents ou indisponibles, ce qui perturbe la planification des requêtes.
• Formulation de requêtes : La difficulté pour les LLMs de générer des requêtes SPARQL syntaxiquement correctes et sémantiquement précises, surtout sans connaître à l'avance les schémas ou les URLs des endpoints pertinents.

L'hypothèse centrale est qu'une approche combinant l'IA agentique (capacité de planification et d'exploration) avec la fédération SPARQL peut surmonter ces obstacles, mais cela nécessite de dépasser les travaux actuels limités à des endpoints uniques.

2. Méthodologie

Les auteurs proposent une approche structurée en trois volets principaux :

A. Architecture SPARQL-MCP

Ils ont développé SPARQL-MCP, une extension du protocole MCP conçue spécifiquement pour les moteurs de fédération SPARQL 1.1.

• Fonctionnalités : Ce serveur expose des outils pour l'exploration de schéma, la découverte d'endpoints et l'exécution de requêtes fédérées.
• Gestion des blocages : Pour contourner les restrictions des grands endpoints (comme Wikidata) qui bloquent les appels SERVICE directs, l'architecture redirige les requêtes multi-endpoints vers un moteur de fédération proxy local. Ce moteur décompose la requête, interroge les endpoints distants et fusionne les résultats.
• Découverte de VoID : Le système inclut un outil pour récupérer ou reconstruire dynamiquement les descriptions VoID (Vocabulary for Interlinking Datasets) des endpoints, fournissant ainsi des métadonnées sur les schémas et les statistiques.

B. Création du Benchmark FKGQA (Federated KGQA)

Pour évaluer ces agents, les auteurs ont étendu le benchmark existant Spider4SPARQL pour créer un benchmark de KGQA Fédéré (FKGQA) :

• Partitionnement : Ils ont appliqué une méthode de partitionnement rigoureuse sur 19 jeux de données (118 shards au total). Les données sont divisées selon trois stratégies :
  1. Verticale (par prédicat) : Séparation basée sur les propriétés.
  2. Sémantique (par classe) : Séparation basée sur les types de sujets (rdf:type).
  3. Horizontale (par instance) : Séparation basée sur les instances d'une classe spécifique.
• Objectif : Chaque partitionnement est conçu pour forcer l'agent à utiliser la fédération (requêtes conjonctives ou disjonctives) et à découvrir les endpoints pertinents sans connaître leurs URLs à l'avance.
• Métadonnées : Des descriptions VoID et des descriptions de haut niveau (résumés naturels) sont générées pour chaque endpoint.

C. Évaluation Expérimentale

L'évaluation utilise un agent de type ReAct (Reason + Act) interagissant avec le serveur SPARQL-MCP.

• Modèles testés :
  • GPT-5.2 (modèle frontier à haute capacité).
  • Qwen3-8B (modèle open-weight plus compact).
• Scénarios d'évaluation :
  1. Baseline : L'agent connaît les URLs et a accès à l'outil d'exécution.
  2. Haut niveau : Ajout de descriptions textuelles courtes des endpoints.
  3. Outil VoID : Ajout de l'accès aux descriptions techniques VoID complètes.
• Métriques : Validité syntaxique, précision du pipeline global, exactitude de la sélection d'endpoints, et analyse comportementale (exploration vs redondance).

3. Contributions Clés

1. SPARQL-MCP : Une implémentation open-source d'un serveur MCP capable de gérer la fédération SPARQL, la découverte dynamique d'endpoints et l'exploration de schéma via des outils standardisés.
2. Benchmark FKGQA : Le premier benchmark généraliste évaluant la capacité des agents à effectuer des questions-réponses sur des graphes de connaissances fédérés, incluant la découverte de sources et la formulation de requêtes distribuées.
3. Analyse Comparative : Une évaluation à grande échelle (5 814 exécutions d'agents) comparant les performances de modèles LLM de différentes tailles dans des environnements fédérés complexes.

4. Résultats

• Performance Globale :
  • GPT-5.2 a atteint des taux de précision de 42,1 % à 45,4 %, ce qui est comparable aux approches de l'état de l'art sur le benchmark Spider4SPARQL original (45 %), malgré la complexité ajoutée de la fédération.
  • Qwen3-8B a montré des performances nettement inférieures (13,1 % à 13,8 %), avec un taux d'erreurs syntaxiques élevé (41,5 % à 61,1 %).
• Impact des Métadonnées :
  • L'utilisation de descriptions de haut niveau (résumés naturels) s'est révélée plus efficace que les descriptions techniques VoID détaillées pour guider la sélection des sources.
  • Pour GPT-5.2, l'ajout de descriptions a réduit drastiquement les requêtes "triviales" (interrogeant tous les endpoints inutilement) de 90,2 % à 11,0 %, tout en améliorant la précision.
• Comportement des Agents :
  • GPT-5.2 adopte une stratégie d'exploration : il change fréquemment d'endpoints, minimise la redondance et découvre progressivement les sources pertinentes.
  • Qwen3-8B montre peu d'exploration, interrogeant souvent tous les endpoints simultanément (approche "brute force"), ce qui génère une forte redondance et des coûts de calcul inutiles.
• Efficacité : Le modèle plus grand (GPT-5.2) est plus rapide (16,3 s médian par exécution) et réalise moins d'appels LLM/SPARQL inutiles que le modèle plus petit.

5. Signification et Conclusion

Cet article démontre que l'approche "Agentic SPARQL" est viable pour des modèles suffisamment capables, permettant de transformer des questions en langage naturel en requêtes SPARQL fédérées complexes sans intervention humaine.

Points forts et implications :

• La combinaison de l'IA agentique et des standards du Web Sémantique (SPARQL, MCP) ouvre la voie à une intégration fluide de données distribuées.
• La qualité du modèle LLM est un facteur critique : les petits modèles peinent encore avec la syntaxe complexe de SPARQL et la logique de fédération.
• La simplicité des métadonnées (descriptions naturelles) peut parfois surpasser la complexité des métadonnées techniques (VoID) pour les agents, suggérant un nouveau paradigme pour la conception de catalogues de données destinés aux IA.

Limites et travaux futurs :

• Nécessité d'un meilleur fine-tuning des modèles pour la syntaxe SPARQL.
• Besoin de catalogues de métadonnées plus riches et accessibles pour gérer la disponibilité et la latence des endpoints réels.
• L'optimisation des plans de requêtes par les agents (éviter les plans "triviaux") reste un défi à relever, car les LLMs manquent souvent de conscience des coûts d'exécution comparée aux optimiseurs de requêtes traditionnels.

En résumé, ce travail pose les fondations pour une nouvelle génération d'agents intelligents capables de naviguer et d'interroger le "Web of Data" de manière autonome et fédérée.