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

Este artigo explora o potencial de agentes inteligentes baseados no Protocolo de Contexto de Modelo (MCP) para facilitar consultas federadas SPARQL, propondo uma extensão de benchmarks de resposta a perguntas em grafos de conhecimento e avaliando diferentes arquiteturas que integram descoberta de endpoints, exploração de esquemas e formulação de consultas.

O essencial

Imagine que você tem um assistente pessoal superinteligente (uma Inteligência Artificial) que adora responder perguntas. O problema é que esse assistente, por mais inteligente que seja, não sabe tudo o que existe no mundo. Ele precisa consultar "bibliotecas" externas para encontrar a resposta.

Este artigo de pesquisa é sobre como ensinar esse assistente a não apenas visitar uma biblioteca, mas a conectar-se a milhares de bibliotecas ao mesmo tempo, sem se perder no caminho.

Aqui está a explicação simplificada, usando analogias do dia a dia:

1. O Cenário: O Assistente e as Bibliotecas

• O Assistente (Agente IA): É como um detetive muito esperto, mas que precisa de ferramentas para trabalhar.
• As Bibliotecas (Endpoints SPARQL): São bases de dados gigantes na internet (como a Wikipedia, dados de navios, publicações científicas, etc.). Cada uma tem suas próprias regras e está em um lugar diferente.
• O Protocolo MCP (Model Context Protocol): Pense no MCP como um universal de chaves ou um adaptador de tomadas. Antes, cada biblioteca exigia uma chave diferente para entrar. O MCP cria um padrão único que permite ao assistente se conectar a qualquer biblioteca de forma fácil e segura.

2. O Grande Desafio: A "Festa" de Dados

O problema é que, às vezes, a resposta para uma pergunta está dividida entre várias bibliotecas.

• Exemplo: "Quero saber todas as publicações de Tim Berners-Lee (o pai da Web) que também estão na Wikipedia."
  • Parte da informação está na DBLP (uma biblioteca de ciência da computação).
  • A outra parte está na Wikidata (a versão estruturada da Wikipedia).

O assistente precisa:

1. Descobrir que essas duas bibliotecas existem.
2. Entender o que cada uma delas contém (o "índice" ou "catálogo").
3. Pedir a informação a ambas e juntar as peças do quebra-cabeça.

Isso é chamado de Consulta Federada. É como se o assistente tivesse que ligar para dez amigos diferentes, pedir pedaços de uma história para cada um e montar o filme completo na hora.

3. O Que os Autores Fizeram (A Solução)

Eles criaram uma ferramenta chamada SPARQL-MCP.

• A Ferramenta: É um "gerente de viagens" para o assistente. Em vez de o assistente tentar adivinhar para onde ir, o gerente diz: "Ei, para essa pergunta, você precisa ir à Biblioteca A e à Biblioteca B. Aqui está o mapa (esquema) delas."
• O Teste (Benchmark FKGQA): Eles criaram um "campo de treinamento" artificial. Pegaram 19 bases de dados reais, quebraram-nas em pedaços menores e espalharam por diferentes servidores. Depois, deram perguntas difíceis para os assistentes tentarem resolver, sem dizerem onde as respostas estavam escondidas.

4. O Que Eles Descobriram (Os Resultados)

Eles testaram dois tipos de assistentes: um "Gênio" (GPT-5.2) e um "Estudante" (Qwen3-8B).

• O Gênio (GPT-5.2):

  • Funcionou muito bem! Ele conseguiu responder cerca de 45% das perguntas complexas corretamente.
  • Como ele agiu: Ele foi explorador. Ele olhou os catálogos, escolheu as bibliotecas certas e fez perguntas diretas. Ele não perdeu tempo visitando bibliotecas que não tinham a resposta.
  • Curiosidade: O assistente se saiu melhor quando recebeu descrições simples (ex: "Esta biblioteca tem carros") do que quando recebeu dados técnicos complexos (catálogos gigantes de metadados). Às vezes, menos informação é mais clara para a IA.

• O Estudante (Qwen3-8B):

  • Teve muita dificuldade. A taxa de acerto foi baixa (cerca de 13%).
  • O Erro: Ele tendia a fazer "perguntas bobas". Em vez de escolher as bibliotecas certas, ele ligava para todas as bibliotecas ao mesmo tempo e tentava juntar tudo. Isso é como tentar achar uma agulha no palheiro ligando para todas as fazendas do mundo ao mesmo tempo. Isso gasta muita energia e tempo.
  • Ele também cometeu muitos erros de "gramática" ao tentar escrever as perguntas técnicas (SPARQL).

5. Por que isso importa?

Hoje, a maioria das IAs só sabe olhar para um único lugar ou precisa que um humano diga exatamente onde procurar.

Este trabalho mostra que, com a ferramenta certa (MCP) e um modelo inteligente o suficiente, podemos criar agentes autônomos que:

• Encontram dados em qualquer lugar da internet.
• Juntam informações de fontes diferentes automaticamente.
• Respondem perguntas complexas que exigem conhecimento de várias áreas ao mesmo tempo.

Resumo Final:
O artigo prova que é possível transformar IAs em "detetives de dados" que navegam sozinhos por uma rede mundial de informações. No entanto, para que isso funcione na vida real, precisamos de IAs "mais inteligentes" (modelos maiores) e de mapas (metadados) que sejam fáceis de entender, não apenas técnicos demais. O futuro é ter assistentes que não apenas conversam, mas investigam a internet para você.

Resumo técnico

1. Problema e Motivação

O artigo aborda o desafio de integrar Inteligência Artificial Agêntica (baseada em Grandes Modelos de Linguagem - LLMs) com Consultas Federadas de Grafos de Conhecimento (Knowledge Graphs - KGs). Embora os LLMs tenham capacidades de planejamento avançadas (como o protocolo Reason+Act ou ReAct) e o Protocolo de Contexto de Modelo (MCP) permita a conexão a ferramentas externas, a aplicação dessas tecnologias em ambientes de dados federados (múltiplos endpoints SPARQL distribuídos) ainda é limitada.

Os principais desafios identificados são:

• Heterogeneidade de Interfaces: Endpoints variam desde dumps RDF brutos até interfaces SPARQL completas, com suporte desigual às funcionalidades do padrão SPARQL 1.1 (ex: cláusulas SERVICE, agregações).
• Falta de Metadados: A ausência de catálogos padronizados de metadados dificulta a descoberta de endpoints e a seleção de fontes relevantes, levando a consultas ineficientes.
• Latência e Disponibilidade: Endpoints podem ter tempos de resposta variáveis ou falhar, exigindo estratégias de execução não bloqueantes.
• Formulação de Consultas: A dificuldade de gerar consultas SPARQL sintaticamente corretas e semanticamente precisas em ambientes dinâmicos onde o esquema e os URLs dos endpoints não são conhecidos a priori.

O objetivo é criar um sistema onde agentes autônomos possam descobrir endpoints, explorar esquemas e formular consultas federadas complexas a partir de perguntas em linguagem natural.

2. Metodologia

A. Arquitetura SPARQL-MCP

Os autores desenvolveram o SPARQL-MCP, uma extensão do protocolo MCP projetada especificamente para motores de consulta federada SPARQL.

• Funcionalidades: O servidor MCP expõe ferramentas para:
  1. Execução de Consultas Federadas: Aceita consultas SPARQL com operadores SERVICE. Se a consulta envolve múltiplos endpoints, o servidor atua como um orquestrador (proxy), decompondo a consulta e enviando subconsultas aos endpoints remotos.
  2. Descoberta de Esquema (VoID): Permite aos agentes recuperar descrições VoID (Vocabulary for Interlinking Datasets) dos endpoints para entender o esquema (classes, propriedades) e estatísticas.
  3. Gerenciamento de Bloqueios: Para contornar a política de bloqueio de chamadas SERVICE em endpoints públicos (como Wikidata), o sistema redireciona consultas multi-endpoint para um motor de federação local que gerencia as requisições.

B. Benchmark FKGQA (Federated KGQA)

Para avaliar o sistema, os autores criaram um novo benchmark estendendo o Spider4SPARQL:

• Particionamento de Dados: Os dados de 19 conjuntos de dados RDF foram particionados em 118 "shards" (fragmentos) hospedados em endpoints separados.
• Estratégias de Particionamento: Utilizaram três estratégias para forçar a necessidade de federação:
  1. Vertical (Baseada em Predicados): Separa triples por predicados.
  2. Semântica (Baseada em Classes): Separa triples pelo tipo de sujeito.
  3. Horizontal (Baseada em Hash): Separa instâncias de uma mesma classe em diferentes shards.
• Requisito do Agente: Diferente de benchmarks anteriores que fornecem os URLs, este exige que o agente descubra quais endpoints contêm os dados relevantes para responder à pergunta.

C. Configuração Experimental

• Agentes: Utilizaram um agente no estilo ReAct alternando chamadas de LLM e ferramentas.
• Modelos: Compararam um modelo de ponta (GPT-5.2) com um modelo de código aberto compacto (Qwen3-8B).
• Cenários de Avaliação:
  1. Baseline: Apenas URLs dos endpoints e ferramenta de execução.
  2. High-Level: URLs + descrições naturais de alto nível dos endpoints.
  3. VoID Tool: URLs + acesso à ferramenta de recuperação de metadados VoID para exploração de esquema.

3. Contribuições Principais

1. Definição de "Agentic SPARQL": Formalização da combinação de agentes de IA com capacidades de consulta federada SPARQL via MCP.
2. Benchmark FKGQA: O primeiro benchmark de ponta a ponta para avaliar a capacidade de agentes de realizar KGQA federada, incluindo descoberta de endpoints e seleção de fontes.
3. Implementação SPARQL-MCP: Uma infraestrutura funcional que integra a descoberta dinâmica de esquemas (via VoID) e a execução de consultas federadas em um protocolo padrão para LLMs.
4. Avaliação Abrangente: Análise de mais de 5.800 execuções de agentes, cobrindo validação sintática, precisão da resposta, eficiência na seleção de endpoints e padrões comportamentais.

4. Resultados

• Desempenho do Modelo (Precisão):
  • GPT-5.2: Alcançou taxas de precisão de 42,1% a 45,4%, comparáveis aos melhores métodos existentes no benchmark original Spider4SPARQL (45%), demonstrando viabilidade para modelos grandes.
  • Qwen3-8B: Apresentou desempenho significativamente inferior (13,1% a 13,8%), com altas taxas de erro sintático (41,5% a 61,1% das consultas falharam na geração).
• Seleção de Endpoints:
  • O uso de descrições de alto nível (cenário "High-Level") foi mais eficaz do que a recuperação detalhada de metadados VoID para guiar a seleção de fontes.
  • No cenário "High-Level", o GPT-5.2 reduziu drasticamente consultas "triviais" (que consultam todos os endpoints desnecessariamente) de ~90% para ~11%.
  • O modelo menor (Qwen) tendeu a consultar todos os endpoints simultaneamente em quase todos os casos, indicando falta de estratégia de exploração seletiva.
• Comportamento dos Agentes:
  • O GPT-5.2 exibiu comportamento de exploração gradual, alternando entre endpoints e refinando consultas.
  • O Qwen3-8B mostrou pouca exploração, tentando consultar tudo de uma vez, resultando em maior redundância e tempo de execução.
• Validade Sintática: O GPT-5.2 manteve uma taxa de sucesso sintático de ~97-98%, enquanto o Qwen3-8B lutou com a sintaxe complexa do SPARQL federado.

5. Significado e Conclusão

O trabalho demonstra que a consulta federada de SPARQL agêntica é viável para modelos de IA suficientemente capazes, permitindo que agentes acessem a "Web de Dados" de forma autônoma.

Implicações Chave:

• Importância da Escala do Modelo: A capacidade de gerar consultas SPARQL corretas e planejar a federação depende criticamente da capacidade do LLM. Modelos menores exigem ajustes finos específicos ou pipelines de geração mais estruturados.
• Eficiência na Descoberta: Metadados simples e descritivos (descrições de alto nível) podem ser mais úteis para agentes do que metadados técnicos complexos (VoID), sugerindo uma nova direção para o design de catálogos de dados.
• Futuro: O trabalho aponta para a necessidade de melhorar a capacidade sintática dos modelos menores, desenvolver estratégias de exploração de esquema mais robustas para agentes e criar repositórios de endpoints atualizados e confiáveis para lidar com latência e indisponibilidade.

Em resumo, o artigo estabelece as bases para uma nova geração de sistemas de perguntas e respostas que não apenas consultam um único banco de dados, mas navegam dinamicamente por uma rede global de dados interligados.