Resumo Técnico: GPTKB 2.0

Declaração do Problema

A Construção de Base de Conhecimento Automatizada (AKBC) tradicionalmente dependeu de recursos curados como Wikipedia e Wikidata para a canonicalização de entidades, ou de agrupamento de strings superficiais para extração baseada em texto. No entanto, abordagens recentes que geram bases de conhecimento diretamente de Grandes Modelos de Linguagem (LLMs) enfrentam uma limitação estrutural crítica: os LLMs são treinados em strings, não em entidades. Consequentemente, tratar strings superficiais como identificadores únicos leva a dois modos de falha complementares:

1. Homonímia: Entidades distintas com rótulos idênticos (ex: a cidade "Munique" e o filme "Munique") são incorretamente mescladas.
2. Sinonímia: Entidades idênticas com rótulos diferentes (ex: "Île-de-France" e "Île-de-France region") são tratadas como entidades distintas.

Métodos de desambiguação existentes frequentemente dependem de inventários externos (ex: vinculação a IDs da Wikidata), o que limita o escopo da construção a recursos pré-existentes. Outros utilizam agrupamento post-hoc, que aborda a sinonímia, mas falha em resolver a homonímia em escala. O desafio central é construir uma base de conhecimento de domínio aberto e larga escala diretamente dos parâmetros de um LLM, mantendo a canonicalização interna explícita de entidades, relações e classes sem depender de identificadores externos.

Metodologia: GPTKB 2.0

Os autores propõem o GPTKB 2.0, uma metodologia para construir bases de conhecimento desambiguadas diretamente de LLMs. O sistema trata o LLM como a única fonte de conhecimento, utilizando um pipeline recursivo e guiado por contexto que alterna entre elicitação e consolidação ao longo da fronteira sujeito–objeto.

Modelo de Dados

A base de conhecimento é definida por um quadruplo $(T, E, R, C)$ contendo triplas, entidades, relações e classes.

• Identificadores Únicos: Cada elemento recebe um ID interno único, desacoplando a identidade dos rótulos superficiais.
• Descrições: Cada elemento inclui uma descrição textual gerada para suportar a desambiguação baseada em contexto.
• Aliases: Rótulos sinônimos são anexados como aliases a um único ID canônico.
• Tratamento de Homonímia: Entidades distintas que compartilham um rótulo recebem IDs diferentes, distinguidas por suas descrições únicas.

Pipeline de Construção

O pipeline opera através de três fases principais, expandindo iterativamente a KB a partir de entidades semente:

1. Elicitação: O LLM é instruído a gerar triplas para uma determinada entidade. Crucialmente, o prompt inclui a descrição da entidade junto com seu rótulo. Este contexto garante que os fatos elicitados refiram-se à entidade pretendida específica (ex: distinguindo o filme "Munique" da cidade) em vez de uma homônima. O modelo também é instruído a gerar triplas instanceOf para capturar tipos de entidades.
2. Reconhecimento de Entidade Nomeada (NER): O LLM classifica os objetos elicitados como literais ou Entidades Nomeadas (NEs). Esta etapa é guiada por contexto, utilizando a tripla de origem para determinar se um objeto (ex: um código como "01099") é um literal ou uma entidade.
3. Desambiguação de Entidade Nomeada (NED): Esta é a fase central de consolidação, dividida em duas rodadas para equilibrar precisão e escalabilidade:
   • NED de Contexto de Tripla: Para NEs, o sistema recupera os $k$ melhores candidatos baseados na similaridade de embedding do rótulo. O LLM é instruído com o rótulo alvo, a tripla de origem como contexto, e os rótulos/descrições dos candidatos. O modelo decide entre corresponder (match), selecionar "Nenhum dos acima" (nova entidade) ou "Inseguro".
   • Geração de Descrição: Entidades marcadas como "Nenhum dos acima" são direcionadas para uma etapa de geração de descrição. O LLM gera uma descrição breve baseada no rótulo alvo e na tripla de origem. Esta descrição serve como a definição canônica da entidade.
   • NED de Contexto de Descrição: Para homônimos de alta densidade (ex: "Faculdade de Direito" aparecendo centenas de vezes), o conjunto de candidatos é restrito a entidades que compartilham o rótato exato. O LLM então utiliza a descrição gerada (em vez da tripla de origem) para distinguir entre candidatos com base na similaridade semântica.

Mecanismos de Escalabilidade

Para permitir a construção em escala de milhões, os autores introduzem Paralelização Protegida e Cache:

• Paralelização Protegida: Para evitar a criação redundante de entidades duplicadas ao processar solicitações concorrentes para o mesmo rótulo, o sistema agrupa solicitações de NED pendentes por rótulo. Ele processa apenas a instância elicitada mais antiga imediatamente; instâncias subsequentes são adiadas até que a primeira seja resolvida, garantindo que a entidade exista como um candidato para correspondências posteriores.
• Cache: Decisões de desambiguação para pares (relação, objeto) frequentes são armazenadas em cache para evitar chamadas redundantes de NER e NED, reduzindo significativamente os custos de API.

Principais Contribuições

1. Metodologia: Um pipeline paralelizado e guiado por contexto para construção de KB que utiliza um LLM como fonte exclusiva de conhecimento, abordando tanto a sinonímia quanto a homonímia através de desambiguação on-the-fly sem identificadores externos.
2. Escala e Qualidade: A construção de uma KB materializada contendo 38,4 milhões de triplas e 1,6 milhão de entidades desambiguadas. O sistema consolidou 2,3 milhões de rótulos superficiais em 1,6 milhão de entidades canônicas e distinguiu corretamente 131.990 entidades homônimas que compartilhavam 41.275 rótulos.
3. Novidade: A primeira KB de escala de milhões, nativa de LLM, com canonicalização interna explícita fora da esfera Wikimedia. Aproximadamente 36,8% das entidades construídas são inéditas na Wikidata, demonstrando a capacidade de capturar o conhecimento de cauda longa (long-tail).

Resultados e Avaliação

Os autores avaliaram a KB construída usando anotação manual e verificação baseada em agentes automatizados:

• Precisão de Desambiguação:
  • Precisão de Mesclagem (Merge): 98% para homônimos e 91% para sinônimos.
  • Precisão de Divisão (Split): 100% para homônimos (sem falsas divisões na amostra) e 95% para sinônimos.
  • Relações/Classes: Alcançou 89–91% de precisão de mesclagem e 91–94% de precisão de divisão.
• Factualidade:
  • Precisão de Triplas: 94,5% das triplas amostradas manualmente foram verificadas como verdadeiras; 92,8% na avaliação automatizada.
  • Factualidade de Entidade: 96% das entidades amostradas manualmente eram verificáveis como entidades do mundo real.
• Comparação com Baseline: Um baseline utilizando strings superficiais resultou em 2,3 milhões de entidades (vs. 1,6M no GPTKB 2.0) e falhou em distinguir 131.990 entidades homônimas. Em um teste de domínio específico (Antiga Babilônia), o baseline confundiu entidades distintas (ex: diferentes figuras de "Paris"), enquanto o GPTKB 2.0 manteve identidades distintas.

Significância

O artigo afirma que o GPTKB 2.0 representa um afastamento significativo dos trabalhos anteriores centrados na Wikimedia. Ao demonstrar que um repositório de domínio geral, desambiguado e de grande escala pode ser construído diretamente dos parâmetros de um LLM sem ancoragem externa, o trabalho abre a possibilidade de explorar espaços de conhecimento além dos recursos curados. Os autores destacam que KBs derivadas de LLMs são particularmente eficazes em cobrir o "long-tail" do conhecimento (entidades que aparecem infrequentemente), onde os esforços de curadoria são escassos. A KB resultante é disponibilizada para análise estatística agregada, permitindo o estudo de vieses, focos tópicos e consistência lógica em uma escala anteriormente inalcançável para bases de conhecimento nativas de LLM.