Sintesi Tecnica: GPTKB 2.0

Definizione del Problema

La costruzione automatica di basi di conoscenza (AKBC) si è tradizionalmente basata su risorse curate come Wikipedia e Wikidata per la canonicalizzazione delle entità, o sulla clusterizzazione di stringhe superficiali per l'estrazione basata sul testo. Tuttavia, gli approcci recenti che generano basi di conoscenza direttamente dai Large Language Models (LL-LLM) affrontano un limite strutturale critico: gli LLM sono addestrati su stringhe, non su entità. Di conseguenza, trattare le stringhe superficiali come identificatori unici porta a due modalità di fallimento complementari:

1. Omonimia: Entità distinte con etichette identiche (ad esempio, la città di "Monaco" e il film "Monaco") vengono erroneamente fuse.
2. Sinonimia: Entità identiche con etichette diverse (ad esempio, "Île-de-France" e "Île-de-France region") sono trattate come entità distinte.

I metodi di disambiguazione esistenti spesso si affidano a inventari esterni (ad esempio, il collegamento a ID di Wikidata), il che limita l'ambito della costruzione alle risorse preesistenti. Altri utilizzano la clusterizzazione post-hoc, che affronta la sinonimia ma non riesce a risolvere l'omonimia su larga scala. La sfida principale è costruire una base di conoscenza open-domain su larga scala direttamente dai parametri di un LLM, mantenendo una canonicalizzazione interna esplicita di entità, relazioni e classi senza fare affidamento su identificatori esterni.

Metodologia: GPTKB 2.0

Gli autori propongono GPTKB 2.0, una metodologia per la costruzione di basi di conoscenza disambiguate direttamente dagli LLM. Il sistema tratta l'LLM come l'unica fonte di conoscenza, utilizzando una pipeline ricorsiva guidata dal contesto che alterna elicitazione e consolidamento lungo il confine soggetto-oggetto.

Modello dei Dati

La base di conoscenza è definita da un quadruplo $(T, E, R, C)$ contenente triple, entità, relazioni e classi.

• Identificatori Unici: Ogni elemento riceve un ID interno unico, scindendo l'identità dalle etichette superficiali.
• Descrizioni: Ogni elemento include una descrizione testuale generata per supportare la disambiguazione basata sul contesto.
• Alias: Etichette sinonime sono collegate come alias a un singolo ID canonico.
• Gestione dell'Omonimia: Entità distinte che condividono un'etichetta ricevono ID differenti, distinti dalle loro descrizioni uniche.

Pipeline di Costruzione

La pipeline opera attraverso tre fasi principali, espandendo iterativamente la KB a partire da entità seme:

1. Elicitazione: L'LLM viene istruito per generare triple per una data entità. Fondamentalmente, il prompt include la descrizione dell'entità insieme alla sua etichetta. Questo contesto assicura che i fatti elicitati riguardino la specifica entità intesa (ad esempio, distinguere il film "Monaco" dalla città) piuttosto che un'omonima. Il modello riceve anche l'istruzione di generare triple instanceOf per catturare i tipi di entità.
2. Riconoscimento delle Entità Nominate (NER): L'LLM classifica le entità elicitate come letterali o come Entità Nominate (NE). Questo passaggio è guidato dal contesto, utilizzando la triple sorgente per determinare se un oggetto (ad esempio, un codice come "01099") sia un letterale o un'entità.
3. Disambiguazione (NED): Questa è la fase centrale di consolidamento, divisa in due round per bilanciare accuratezza e scalabilità:
   • NED basata sul Contesto della Triple: Per le NE, il sistema recupera i $k$ candidati migliori basandosi sulla somiglianza di embedding delle etichette. L'LLM riceve come input l'etichetta target, la triple sorgente come contesto e le etichette/descrizioni dei candidati. Il modello decide se effettuare un match, selezionare "Nessuno dei precedenti" (nuova entità) o "Non sono sicuro".
   • Generazione della Descrizione: Le entità contrassegnate come "Nessuno dei precedenti" vengono indirizzate a una fase di generazione della descrizione. L'LLM genera una breve descrizione basata sull'etichetta target e sulla triple sorgente. Questa descrizione funge da definizione canonica dell'entità.
   • NED basata sulla Descrizione: Per gli omonimi ad alta densità (ad esempio, "Facoltà di Giurisprudenza" che appare centinaia di volte), l'insieme dei candidati è ristretto alle entità che condividono l'esatta etichetta. L'LLM utilizza quindi la descrizione generata (inveve della triple sorgente) per distinguere tra i candidati in base alla somiglianza semantica.

Meccanismi di Scalabilità

Per consentire la costruzione su scala di milioni, gli autori introducono la Parallelizzazione Protetta e il Caching:

• Parallelizzazione Protetta: Per evitare la creazione ridondante di entità duplicate durante l'elaborazione di richieste concorrenti per la stessa etichetta, il sistema raggruppa le richieste NED in sospeso per etichetta. Elabora solo la prima istanza elicitata immediatamente; le istanze successive sono differite fino a quando la prima non viene risolta, garantendo che l'entità esista come candidato per i match successivi.
• Caching: Le decisioni di disambiguazione per coppie (relazione, oggetto) frequenti vengono memorizzate nella cache per bypassare le chiamate ridondanti a NER e NED, riducendo significativamente i costi delle API.

Contributi Chiave

1. Metodologia: Una pipeline parallelizzata e guidata dal contesto per la costruzione di KB che utilizza un LLM come fonte esclusiva di conoscenza, affrontando sia la sinonimia che l'omonimia attraverso la disambiguazione on-the-fly senza identificatori esterni.
2. Scala e Qualità: La costruzione di una KB materializzata contenente 38,4 milioni di triple e 1,6 milioni di entità disambiguate. Il sistema ha consolidato 2,3 milioni di etichette superficiali in 1,6 milioni di entità canoniche e ha distinto correttamente 131.990 entità omonime che condividevano 41.275 etichette.
3. Novità: La prima KB su scala di milioni, nativa degli LLM, con una canonicalizzazione interna esplicita al di fuori della sfera di Wikimedia. Circa il 36,8% delle entità costruite è nuovo rispetto a Wikidata, dimostrando la capacità di catturare la conoscenza della "coda lunga" (long-tail).

Risultati e Valutazione

Gli autori hanno valutato la KB costruita tramite annotazione manuale e verifica automatizzata tramite agenti:

• Accuratezza della Disambiguazione:
  • Accuratezza del Merge: 98% per gli omonimi e 91% per i sinonimi.
  • Accuratezza dello Split: 100% per gli omonimi (nessun falso split nel campione) e 95% per i sinonimi.
  • Relazioni/Classi: Ha raggiunto un'accuratezza di merge dell'89–91% e un'accuratezza di split del 91–94%.
• Fattualità:
  • Precisione delle Triple: Il 94,5% delle triple campionate manualmente è stato verificato come vero; il 92,8% nella valutazione automatizzata.
  • Fattualità delle Entità: Il 96% delle entità campionate manualmente è stato verificato come entità reali.
• Confronto con il Baseline: Un baseline che utilizzava le stringhe superficiali ha prodotto 2,3 milioni di entità (rispetto a 1,6M di GPTKB 2.0) e non è riuscito a distinguere 131.990 entità omonime. In un test specifico di dominio (Antica Babilonia), il baseline ha confuso entità distinte (ad esempio, diverse figure di "Parigi"), mentre GPTKB 2.0 ha mantenuto identità distinte.

Significato

Il paper sostiene che GPTKB 2.0 rappresenti un distacco significativo dai lavori precedenti incentrati su Wikimedia. Dimostrando che un repository di entità di dominio generale, disambiguato e su larga scala può essere costruito direttamente dai parametri degli LLM senza grounding esterno, il lavoro apre la possibilità di esplorare spazi di conoscenza oltre le risorse curate. Gli autori sottolineano che le KB derivate da LLM sono particolarmente efficaci nel coprire la "coda lunga" della conoscenza (entità che appaiono infrequentemente), dove gli sforzi curati sono scarsi. La KB risultante è resa disponibile per l'analisi statistica aggregata, permettendo lo studio di bias, focus tematici e coerenza logica su una scala precedentemente irraggiungibile per le basi di conoscenza native degli LLM.