Resumo Técnico: MuseKG – Um Grafo de Conhecimento Interativo sobre Coleções de Museus

Declaração do Problema

O setor do patrimônio cultural gerou vastos repositórios de dados de coleções de museus por meio de esforços de digitalização. No entanto, esses repositórios são frequentemente fragmentados, consistindo em fontes heterogêneas, como registros de catálogo estruturados, arquivos de imagens e descrições não estruturadas. Os sistemas de informação de museus existentes lutam para integrar essas fontes em uma representação unificada e consultável que suporte a exploração consciente de relações. Os principais obstáculos não são meramente a escala dos dados, mas a desconexão semântica entre descrições de objetos, relações e metadados contextuais. Embora avanços recentes em Modelos de Linguagem de Grande Escala (LLMs) e Grafos de Conhecimento (KGs) ofereçam soluções potenciais, abordagens existentes frequentemente falham em fechar a lacuna entre pipelines de ponta a ponta. Especificamente, esforços centrados em padrões assumem o uso de SPARQL por especialistas, enquanto métodos de construção automatizada frequentemente carecem de experiências de consulta explicáveis para usuários finais. Além disso, técnicas atuais de NL2SPARQL podem ser frágeis sob esquemas complexos, e ferramentas interativas de KG raramente são integradas a artefatos multimodais de museus.

Metodologia

Os autores apresentam o MuseKG, um sistema interativo projetado para organizar dados heterogêneos de museus em um grafo de propriedades tipado e fornecer uma interface de linguagem natural (NL) para consulta e exploração.

1. Arquitetura do Sistema

O MuseKG opera por meio de dois módulos principais:

• Módulo 1: Construtor de KG: Este componente transforma registros brutos de coleções de museus (formato JSON) em um grafo de propriedades tipado $G = (V, E, \tau, \rho, A)$.

  • Processamento de Dados: O sistema ingere registros contendo metadados de objetos (títulos, materiais, datas) e campos relacionais (pessoas, organizações, objetos relacionados, rótulos de imagem).
  • Etapas de Construção:
    1. Normalização: Campos textuais são padronizados (minúsculas, espaços em branco colapsados) para auxiliar na resolução de entidades.
    2. Identificação de Entidades: Nós são criados para IDs de objetos, entidades referenciadas (pessoas, organizações), IDs de imagem e entidades nomeadas extraídas do texto.
    3. Atribuição de Tipos: Nós são atribuídos tipos (por exemplo, objeto, pessoa, imagem, entidade semântica).
    4. Rotulagem de Relações: Identificadores de relacionamento brutos são mapeados para um vocabulário fixo de sete tipos de relação em quatro categorias: proveniência, inter-objeto, visual e semântica.
    5. Deduplicação: Nós e arestas duplicados são mesclados ou removidos com base em identificadores canônicos e triplas.
    6. Validação de Esquema: Atributos são restritos a um esquema predefinido.
  • Saída: O grafo construído liga objetos, pessoas, organizações, imagens, rótulos derivados de imagem e entidades semânticas. Na demonstração, isso resultou em um grafo com 23.263 nós e 75.375 arestas derivados de 15.829 registros de objetos.

• Módulo 2: Interface de Consulta em Linguagem Natural: Este módulo utiliza uma abordagem de Geração Aumentada por Recuperação (RAG) para responder a consultas de usuários.

  • Recuperação de Contexto: Ao receber uma consulta em NL, um LLM extrai entidades-chave. O sistema então recupera um contexto textual do KG, compreendendo os atributos da entidade identificada e seus vizinhos de um salto (relações e nós conectados).
  • Geração de Resposta: O contexto recuperado e a consulta original são alimentados em um LLM, que é instruído a sintetizar uma resposta concisa usando apenas a evidência do KG fornecida. Este design visa mitigar alucinações comuns em sistemas baseados apenas em LLM.

2. Fluxo de Interação

O sistema fornece uma interface visual onde os usuários podem digitar perguntas de forma livre ou selecionar prompts. O sistema:

1. Fundamenta a consulta em menções específicas de entidades.
2. Recupera um bairro compacto do KG como evidência.
3. Visualiza o subgrafo para inspeção.
4. Exibe um cartão de detalhes da entidade com metadados e imagens.
5. Gera uma resposta em linguagem natural fundamentada nos fatos recuperados.

Contribuições Principais

O artigo delineia três contribuições principais:

1. Sistema MuseKG: Um sistema de KG interativo que permite a construção e consulta de coleções de museus via linguagem natural, integrando registros estruturados com rótulos derivados de mídia.
2. Pipeline Leve e Interface: Um pipeline de construção de KG simplificado e interface de consulta em NL que suporta três tarefas específicas: pesquisa de atributos, exploração de relações e recuperação consciente de relações.
3. Demonstração e Benchmark: Uma demonstração em coleções reais de museus mostrando respostas interpretáveis e fundamentadas em evidências, apoiada por um benchmark de 150 perguntas geradas por métodos fundamentados em KG e guiados por LLM.

Resultados e Avaliação

Os autores avaliaram o MuseKG contra várias linhas de base usando um benchmark personalizado de 150 perguntas categorizadas em:

• C1: Pesquisa de atributos (por exemplo, recuperar medidas).
• C2: Exploração de relações (recuperar entidades vinculadas como produtores).
• C3: Recuperação de atributos consciente de relações (travessar uma relação para encontrar um atributo da entidade conectada).

Desempenho Comparativo:
O MuseKG foi comparado a linhas de base apenas de LLM (Zero-shot, Few-shot) e a um pipeline de prompt NL2SPARQL em três LLMs de backbone diferentes (Gemma-3-4B, Gemma-3-12B e gpt-oss-20b).

• Precisão: O MuseKG alcançou consistentemente a maior precisão em todas as categorias e tamanhos de modelo. Por exemplo, no modelo Gemma-3-12B, o MuseKG alcançou 0,84 de precisão em C1, 0,42 em C2 e 0,36 em C3.
• Comparação com Linha de Base: Embora a linha de base NL2SPARQL fosse competitiva na pesquisa de atributos (C1), ela performou significativamente mais fraca em tarefas centradas em relações (C2 e C3). A execução explícita fundamentada em KG do MuseKG proporcionou os maiores ganhos nesses cenários complexos de travessia de relações.
• Prompting: Diferentemente das linhas de base que exigiam engenharia de prompts específica por categoria (few-shot ou prompting SPARQL), o MuseKG utilizou um único prompt genérico KG-RAG, mantendo desempenho superior.

Significado e Alegações

O artigo afirma que o MuseKG conecta com sucesso a lacuna entre registros de museus fragmentados e consultas acessíveis em linguagem natural. Seu significado reside em demonstrar como combinar a precisão estrutural de um grafo de conhecimento com a flexibilidade de LLMs pode fornecer respostas inspecionáveis e fundamentadas em evidências.

Os autores enfatizam que o sistema permite aos usuários verificar a proveniência das respostas inspecionando as estruturas e relações explícitas do grafo usadas para gerá-las. Eles notam que o MuseKG supera as linhas de base especificamente em tarefas centradas em relações, abordando a fragilidade da geração direta de NL para SPARQL em esquemas complexos.

O artigo mantém um escopo modesto, reconhecendo limitações atuais: o sistema atualmente resolve apenas uma entidade principal por consulta, limitando sua capacidade de lidar com perguntas comparativas entre múltiplas entidades ou perguntas abertas sem referências específicas a objetos. Trabalho futuro é proposto para escalar o pipeline para descoberta entre coleções e evoluir o sistema para um framework baseado em agentes para investigação autônoma em redes heterogêneas.