Technische Samenvatting: GPTKB 2.0

Probleemstelling

Geautomatiseerde kennisbankconstructie (Automated Knowledge Base Construction, AKBC) heeft traditioneel vertrouwd op gecureerde bronnen zoals Wikipedia en Wikidata voor entiteits-canonicalisering, of op tekstgebaseerde extractie via oppervlaktestring-clustering. Recente benaderingen die kennisbanken direct uit Large Language Models (LLM's) genereren, kampen echter met een cruciale structurele beperking: LLM's zijn getraind op strings, niet op entiteiten. Het behandelen van oppervlaktestrings als unieke identificatoren leidt daarom tot twee complementaire foutmodi:

1. Homonymie: Verschillende entiteiten met identieke labels (bijv. de stad "Munchen" en de film "Munchen") worden onjuist samengevoegd.
2. Synonymie: Identieke entiteiten met verschillende labels (bijv. "Île-de-France" en "Île-de-France regio") worden als afzonderlijke entiteiten behandeld.

Bestaande disambiguatiemethoden vertrouwen vaak op externe inventarissen (bijv. koppeling aan Wikidata-ID's), wat de reikwijdte van de constructie beperkt tot reeds bestaande bronnen. Andere methoden gebruiken post-hoc clustering, wat synonymie aanpakt maar homonymie niet op schaal kan oplossen. De kernuitdaging is het construeren van een grootschalige, open-domein kennisbank direct uit de parameters van een LLM, waarbij een expliciete interne canonicalisering van entiteiten, relaties en klassen wordt behouden zonder afhankelijk te zijn van externe identificatoren.

Methodologie: GPTKB 2.0

De auteurs stellen GPTKB 2.0 voor, een methodologie voor het construeren van gedisambiguëerde kennisbanken direct uit LLM's. Het systeem behandelt het LLM als de enige kennisbron en maakt gebruik van een recursieve, contextgestuurde pipeline die afwisselt tussen elicitatie en consolidatie langs de subject–object-grens.

Datamodel

De kennisbank wordt gedefinieerd als een quadruppel $(T, E, R, C)$ bestaande uit triples, entiteiten, relaties en klassen.

• Unieke Identificatoren: Elk element krijgt een unieke interne ID, waardoor identiteit wordt losgekoppeld van oppervlaktelabel.
• Beschrijvingen: Elk element bevat een gegenereerde tekstuele beschrijving om contextgebaseerde disambiguatie te ondersteunen.
• Aliassen: Synonieme labels worden als aliassen aan een enkel canoniek ID gekoppeld.
• Omgang met Homonymie: Verschillende entiteiten die hetzelfde label delen, krijgen verschillende ID's, die worden onderscheiden door hun unieke beschrijvingen.

Constructie-pipeline

De pipeline werkt via drie kernfasen en breidt de KB iteratief uit vanaf zaadentiteiten (seed entities):

1. Elicitatie: Het LLM wordt geprompt om triples te genereren voor een gegeven entiteit. Cruciaal is dat de prompt naast de entiteit ook de beschrijving van de entiteit bevat. Deze context zorgt ervoor dat de geëliciteerde feiten betrekking hebben op de specifieke beoogde entiteit (bijv. het onderscheid maken tussen de film "Munchen" en de stad) in plaats van op een homoniem exemplaar. Het model krijgt ook de instructie om instanceOf-triples te genereren om entiteitstypen vast te leggen.
2. Named Entity Recognition (NER): Het LLM classificeert geëliciteerde objecten als ofwel literals of als Named Entities (NEs). Deze stap is contextgestuurd, waarbij de bron-triple wordt gebruikt om te bepalen of een object (bijv. een code zoals "01099") een literal of een entiteit is.
3. Disambiguatie (NED): Dit is de kernfase van consolidatie, verdeeld in twee ronden om een balans te vinden tussen nauwkeurigheid en schaalbaarheid:
   • Triple-Context NED: Voor NE's haalt het systeem top-$k$ kandidaten op op basis van label-embedding-gelijkenis. Het LLM wordt geprompt met het doel-label, de bron-triple als context, en de labels/beschrijvingen van de kandidaten. Het model beslist of het een match is, kiest voor "Geen van de bovenstaande" (nieuwe entiteit), of "Onzeker".
   • Beschrijvinggeneratie: Entiteiten die als "Geen van de bovenstaande" zijn gemarkeerd, worden doorgeleid naar een stap voor beschrijvinggeneratie. Het LLM genereert een korte beschrijving op basis van het doel-label en de bron-triple. Deze beschrijving dient als de canonieke definitie van de entiteit.
   • Description-Context NED: Voor homoniemen met een hoge dichtheid (bijv. "Faculteit der Rechten" dat honderden keren voorkomt) wordt de kandidaatset beperkt tot entiteiten die exact hetzelfde label delen. Het LLM gebruikt vervolgens de gegenereerde beschrijving (in plaats van de bron-triple) om kandidaten te onderscheiden op basis van semantische gelijkenis.

Schaalbaarheidsmechanismen

Om constructie op miljoenschaal mogelijk te maken, introduceren de auteurs Guarded Parallelization en Caching:

• Guarded Parallelization: Om redundante creatie van duplicaatentiteiten te voorkomen bij het gelijktijdig verwerken van verzoeken voor hetzelfde label, clustert het systeem lopende NED-verzoeken op label. Het verwerkt alleen het eerst geëliciteerde exemplaar onmiddellijk; daaropvolgende instanties worden uitgesteld totdat de eerste is opgelost, zodat de entiteit als kandidaat beschikbaar is voor latere matches.
• Caching: Beslissingen voor disambiguatie van veelvoorkomende (relatie, object)-paren worden gecached om redundante NER- en NED-oproepen te omzeilen, wat de API-kosten aanzienlijk verlaagt.

Belangrijkste Bijdragen

1. Methodologie: Een geparallelliseerde, contextgestuurde pipeline voor KB-constructie die een LLM als exclusieve kennisbron gebruikt en zowel synonymie als homonymie aanpakt via on-the-fly disambiguatie zonder externe identificatoren.
2. Schaal en Kwaliteit: De constructie van een gematerialiseerde KB met 38,4 miljoen triples en 1,6 miljoen gedisambiguëerde entiteiten. Het systeem consolideerde 2,3 miljoen oppervlaktestrings tot 1,6 miljoen canonieke entiteiten en onderscheidde correct 131.990 homonieme entiteiten die 41.275 labels deelden.
3. Nieuwigheid: De eerste miljoenschaal, LLM-native KB met expliciete interne canonicalisering buiten de Wikimedia-sfeer. Ongeveer 36,8% van de geconstrueerde entiteiten is nieuw voor Wikidata, wat het vermogen aantoont om de "long-tail" aan kennis te vatten.

Resultaten en Evaluatie

De auteurs evalueerden de geconstrueerde KB middels handmatige annotatie en geautomatiseerde agent-gebaseerde verificatie:

• Disambiguatienauwkeurigheid:
  • Merge Accuracy: 98% voor homoniemen en 91% voor synoniemen.
  • Split Accuracy: 100% voor homoniemen (geen valse splits in de steekproef) en 95% voor synoniemen.
  • Relaties/Klassen: Behaalde 89–91% merge-nauwkeurigheid en 91–94% split-nauwkeurigheid.
• Feitelijkheid:
  • Triple Precisie: 94,5% van de handmatig gesamplede triples werd geverifieerd als waar; 92,8% in automatische evaluatie.
  • Entiteitsfeitelijkheid: 96% van de handmatig gesamplede entiteiten was verifieerbaar als reële entiteiten.
• Vergelijking met Baseline: Een baseline die oppervlaktestrings gebruikte, resulteerde in 2,3 miljoen entiteiten (tegenover 1,6M in GPTKB 2.0) en slaagde er niet in om 131.990 homonieme entiteiten te onderscheiden. In een domeinspecifieke test (Oud-Babylon) verwarde de baseline verschillende entiteiten (bijv. verschillende "Paris"-figuren), terwijl GPTKB 2.0 de onderscheidende identiteiten behield.

Betekenis

Het artikel stelt dat GPTKB 2.0 een significante afwijking vormt van eerdere Wikimedia-gecentreerde werken. Door aan te tonen dat een grote, gedisambiguëerde, algemene entiteitenrepository direct uit LLM-parameters kan worden geconstrueerd zonder externe gronding, opent dit werk de mogelijkheid om kennissystemen te verkennen die verder gaan dan gecureerde bronnen. De auteurs benadrukken dat LLM-afgeleide KBs bijzonder effectief zijn in het dekken van de "long-tail" van kennis (entiteiten die zelden voorkomen), waar gecureerde inspanningen schaars zijn. De resulterende KB wordt beschikbaar gesteld voor aggregatieve statistische analyse, wat de studie van biases, topische focus en logische consistentie op een schaal mogelijk maakt die voorheen onbereikbaar was voor LLM-native kennisbanken.