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

Questo articolo esplora il potenziale degli agenti intelligenti basati su SPARQL-MCP per facilitare la federazione di query su grafi della conoscenza, proponendo un benchmark esteso e valutando diverse architetture che integrano la scoperta degli endpoint, l'esplorazione degli schemi e la formulazione delle query.

L'essenziale

Immagina di avere un assistente personale super-intelligente (un'Intelligenza Artificiale) che è bravissimo a rispondere a domande, ma che ha un problema: non sa dove andare a cercare le informazioni quando la risposta non è nella sua "testa" (nel suo addestramento iniziale).

Questo articolo parla di come abbiamo insegnato a questo assistente a diventare un vero esploratore di dati, capace di collegarsi a migliaia di biblioteche digitali sparse per il mondo per trovare la risposta esatta, anche quando deve incrociare informazioni da fonti diverse.

Ecco la spiegazione semplice, passo dopo passo:

1. Il Problema: L'Assistente che si perde

Fino a poco tempo fa, se volevi chiedere all'AI qualcosa su un dato specifico (ad esempio: "Quanti libri ha scritto Tim Berners-Lee e dove sono archiviati?"), l'AI doveva sapere tutto in anticipo o cercare in un unico database.
Ma il mondo dei dati è come un enorme archivio diviso in mille stanze diverse:

• Una stanza contiene i dati di Wikipedia (Wikidata).
• Un'altra contiene i dati delle pubblicazioni scientifiche (DBLP).
• Un'altra ancora ha dati su musei o biblioteche.

Ogni stanza ha un linguaggio diverso (alcune parlano solo italiano, altre solo francese, altre usano codici strani). Se chiedi all'AI di cercare in tutte queste stanze contemporaneamente, spesso si perde, chiede informazioni sbagliate o si blocca.

2. La Soluzione: "Agentic SPARQL" (L'Assistente con la Mappa)

Gli autori di questo studio hanno creato un sistema chiamato Agentic SPARQL.
Immagina di dare al tuo assistente AI:

• Un passaporto universale (MCP): Un protocollo standard che gli permette di aprire la porta di qualsiasi stanza (endpoint) senza impazzire.
• Una mappa dinamica: Invece di darti solo l'indirizzo di una stanza, l'AI impara a scoprire da sola quali stanze esistono, cosa contengono e quali sono le migliori per la tua domanda.
• La capacità di "unire i puntini" (Federazione): Se la risposta richiede informazioni dalla stanza A e dalla stanza B, l'AI sa come chiedere a entrambe e unire i risultati come se fossero un unico puzzle.

3. La Sfida: Costruire la "Palestra" (Il Benchmark)

Per vedere se questo nuovo assistente funziona davvero, gli autori hanno dovuto costruire una palestra di allenamento speciale.
Hanno preso un vecchio set di domande e risposte (chiamato Spider4SPARQL) e l'hanno "frammentato" in modo intelligente:

• Hanno preso i dati e li hanno sparpagliati in 118 stanze diverse (endpoint).
• Hanno creato domande che obbligavano l'AI a saltare da una stanza all'altra per trovare la risposta.
• Hanno reso la vita difficile: alcune stanze erano chiuse, altre parlavano lingue diverse, altre ancora erano lente.

È come se avessero nascosto le risposte a un tesoro in 100 castelli diversi e avessero detto all'AI: "Trova il tesoro, ma devi prima capire quale castello ha la chiave giusta".

4. Il Test: Chi vince la gara?

Hanno fatto gareggiare due tipi di assistenti AI contro questo labirinto:

1. Il "Gigante" (GPT-5.2): Un modello molto grande e potente.
2. Il "Piccolo" (Qwen3-8B): Un modello più leggero e veloce, ma meno esperto.

I risultati sono stati illuminanti:

• Il Gigante ha fatto un lavoro eccellente. È riuscito a trovare le risposte giuste nel 45% dei casi complessi, quasi quanto i migliori sistemi esistenti che non usano agenti autonomi. Ha imparato a scegliere le stanze giuste senza sprecare tempo.
• Il Piccolo ha faticato molto. Ha sbagliato spesso a costruire le domande (come se scrivesse una frase in grammatica sbagliata) e ha cercato in tutte le stanze contemporaneamente invece di scegliere quelle giuste, perdendo tempo e risorse.

5. La Lezione Principale: "La descrizione vale più del manuale tecnico"

C'è un dettaglio curioso emerso dallo studio.
Quando hanno dato all'AI una descrizione semplice e umana della stanza (es: "Qui ci sono i dati sulle auto"), l'AI ha funzionato meglio rispetto a quando le hanno dato un manuale tecnico complesso (dati grezzi sui metadati).
È come se all'AI fosse più utile dire: "Cerca nel garage delle macchine" piuttosto che darle un elenco di 500 numeri di serie e codici di fabbrica. L'AI capisce meglio il "senso" delle cose quando glielo spieghi in modo naturale.

In sintesi

Questo paper ci dice che:

1. È possibile creare assistenti AI che esplorano autonomamente il "Web dei Dati" collegando fonti diverse.
2. Serve un'AI potente: I modelli piccoli e veloci fanno ancora troppi errori quando devono ragionare su strutture complesse.
3. La semplicità aiuta: Dare all'AI descrizioni chiare e semplici funziona meglio che sommergerla di dati tecnici grezzi.

È un passo avanti enorme verso un futuro in cui potremo chiedere all'AI: "Fammi un riassunto di tutte le ricerche mediche su questo virus negli ultimi 5 anni, incrociando i dati di tre ospedali diversi", e lei lo farà da sola, senza che noi dobbiamo sapere come sono organizzati i database di quegli ospedali.

Sommario tecnico

1. Il Problema

Il lavoro affronta la sfida di integrare i Modelli Linguistici su Grande Scala (LLM) con l'accesso federato a dati strutturati distribuiti sul Web (Linked Open Data). Sebbene i protocolli come il Model Context Protocol (MCP) abbiano abilitato agenti AI capaci di utilizzare strumenti esterni, l'applicazione di questi agenti alla Query Federation SPARQL presenta ostacoli significativi che i sistemi attuali non gestiscono adeguatamente:

• Eterogeneità delle Interfacce: Gli endpoint SPARQL variano dal supporto completo SPARQL 1.1 a interfacce limitate (es. dump RDF o triple pattern), rendendo difficile un approccio uniforme.
• Supporto Disomogeneo a SPARQL 1.1: Anche gli endpoint che supportano il protocollo standard variano nel supporto di funzionalità specifiche (aggregazioni, clausole VALUES o SERVICE), richiedendo strategie di federazione su misura.
• Eterogeneità dei Metadati: La mancanza di cataloghi standardizzati e completi rende difficile la scoperta degli endpoint e la selezione delle fonti, portando spesso a esecuzioni lente a causa di una sovrastima delle fonti rilevanti.
• Problemi di Latenza e Disponibilità: Gli endpoint possono essere bloccati, lenti o non disponibili a causa di carichi elevati, influenzando negativamente la pianificazione delle query ("plan-and-execute").
• Formulazione della Query: La difficoltà per gli LLM di generare query SPARQL sintatticamente corrette e semanticamente accurate in ambienti dinamici dove né gli URL degli endpoint né gli schemi sono noti a priori.

L'obiettivo è colmare il divario tra l'agentic AI (capace di pianificazione e ragionamento) e la federazione SPARQL, creando un sistema in grado di scoprire autonomamente le fonti, esplorare gli schemi e formulare query federate.

2. Metodologia

Gli autori hanno sviluppato un approccio basato su tre pilastri principali:

A. SPARQL-MCP (Server e Architettura)

Hanno implementato SPARQL-MCP, un'estensione del protocollo MCP specifica per i motori di federazione SPARQL 1.1.

• Funzionalità: Il server espone strumenti per l'esecuzione di query federate, la scoperta degli endpoint e l'esplorazione degli schemi (tramite retrieval di descrizioni VoID - Vocabulary for Interlinking Datasets).
• Gestione dei Blocchi: Per aggirare le limitazioni di endpoint come Wikidata o DBpedia che bloccano le chiamate SERVICE dirette, il sistema reindirizza le query multi-agente verso un proxy engine di federazione locale. Questo motore scompone la query e inoltra i sottoproblemi agli endpoint remoti.
• Calcolo VoID Dinamico: Il sistema recupera o ricrea dinamicamente le descrizioni VoID (metadati sullo schema e statistiche) per fornire agli agenti il contesto necessario alla pianificazione.

B. FKGQA Benchmark (Federated Knowledge Graph Question Answering)

Poiché non esisteva un benchmark end-to-end per la KGQA federata, gli autori hanno esteso Spider4SPARQL:

• Partizionamento: Hanno creato un ambiente federato partizionando 19 dataset RDF in 118 shard (endpoint) distinti.
• Strategie di Sharding: Hanno utilizzato tre strategie per massimizzare i pattern di federazione:
  1. Verticale (basata sui predicati).
  2. Class-based (basata sui tipi di soggetto).
  3. Orizzontale (basata sull'hash degli istanze).
• Requisito: A differenza dei benchmark precedenti, gli agenti devono scoprire autonomamente gli endpoint rilevanti senza conoscere gli URL in anticipo, simulando scenari reali.

C. Valutazione Sperimentale

Hanno valutato agenti basati su ReAct (Reason+Act) utilizzando due modelli LLM:

• GPT-5.2: Un modello frontier ad alte capacità.
• Qwen3-8B: Un modello open-weight più piccolo e compatto.
• Scenari di Test:
  1. Baseline: L'agente conosce solo gli URL e ha accesso allo strumento di esecuzione query.
  2. High-Level: L'agente riceve descrizioni naturali degli endpoint.
  3. VoID Tool: L'agente ha accesso agli strumenti di recupero metadati VoID per l'esplorazione dello schema.

3. Contributi Chiave

1. Definizione di "Agentic SPARQL": Concettualizzazione e implementazione pratica dell'uso di agenti AI per la federazione di query SPARQL.
2. Nuovo Benchmark (FKGQA): Il primo benchmark che valuta la KGQA federata end-to-end, richiedendo scoperta degli endpoint e formulazione di query complesse su dati partizionati.
3. Implementazione SPARQL-MCP: Un server MCP che integra federazione, scoperta dinamica e esplorazione dello schema, superando le limitazioni degli attuali wrapper MCP (che supportano solo endpoint singoli).
4. Analisi Comparativa: Una valutazione estensiva (5.814 esecuzioni di agenti) che confronta diverse architetture e modelli LLM in scenari di federazione.

4. Risultati

• Performance dei Modelli:
  • GPT-5.2: Ha raggiunto un'accuratezza del 42,1% - 45,4%, paragonabile agli approcci state-of-the-art (45%) su benchmark non federati, dimostrando che gli agenti capaci possono gestire la complessità della federazione.
  • Qwen3-8B: Ha mostrato prestazioni significativamente inferiori (13,1% - 13,8%) e un alto tasso di errori sintattici (fino al 61%), indicando che i modelli più piccoli necessitano di un affinamento specifico per SPARQL.
• Impatto delle Descrizioni: Le descrizioni di alto livello (testuali) degli endpoint si sono rivelate più efficaci dei dettagli tecnici VoID completi per guidare la selezione delle fonti. Hanno ridotto le query "triviali" (che interrogano tutti gli endpoint inutilmente) dal 90,2% all'11,0% per GPT-5.2.
• Comportamento degli Agenti:
  • GPT-5.2 ha mostrato un comportamento esplorativo, cambiando endpoint e riducendo la ridondanza.
  • Qwen3-8B tendeva a interrogare tutti gli endpoint simultaneamente (strategia "brute-force"), generando molte query ridondanti.
• Validità Sintattica: GPT-5.2 ha mantenuto un tasso di validità sintattica delle query SPARQL superiore al 97%, mentre Qwen3-8B ha fallito spesso nella generazione di prefissi corretti o nella sintassi SERVICE.

5. Significatività e Implicazioni

Questo lavoro rappresenta un passo fondamentale verso l'integrazione dell'IA agentic con il Web of Data.

• Fattibilità: Dimostra che è possibile costruire agenti autonomi capaci di navigare, scoprire e interrogare reti di dati distribuiti complessi senza intervento umano.
• Limiti Attuali: Evidenzia che la scalabilità dei modelli è cruciale; i modelli più piccoli faticano ancora con la complessità sintattica e semantica di SPARQL federato.
• Ottimizzazione vs. Esplorazione: Sottolinea che gli agenti LLM attuali mancano della "consapevolezza dei costi" dei tradizionali ottimizzatori di query federate, portando a piani di esecuzione inefficienti (troppi endpoint consultati).
• Futuro: Il lavoro apre la strada a migliori cataloghi di metadati, tecniche di fine-tuning specifiche per SPARQL e strategie di prompting che guidino gli agenti verso una selezione delle fonti più intelligente ed efficiente.

In sintesi, il paper conferma che l'approccio "Agentic" è promettente per la KGQA federata, ma richiede modelli potenti e un'attenta progettazione degli strumenti (tools) e dei metadati per superare le inefficienze attuali.