💬 NLP

GPTKB 2.0: Direct Construction of Disambiguated Knowledge Bases from Large Language Models

Das Papier stellt GPTKB 2.0 vor, eine skalierbare Methodik, die durch die Implementierung einer On-the-fly-Kanonisierung von Entitäten, Relationen und Klassen zur Überwindung nativer Repräsentationsbeschränkungen eine Millionen-Skala umfassende, disambiguierte Wissensbasis direkt aus großen Sprachmodellen konstruiert.

Ursprüngliche Autoren: Yujia Hu, Tuan-Phong Nguyen, Simon Razniewski

Veröffentlicht 2026-08-05

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Yujia Hu, Tuan-Phong Nguyen, Simon Razniewski

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie versuchen, die ultimative Bibliothek von allem zu bauen, was auf der Welt existiert. Seit Jahrzehnten versuchen Bibliothekare (Informatiker), dies zu tun, indem sie Bücher und Webseiten lesen, Fakten ausschneiden und sie auf ordentliche Karten kleben. Aber es gibt ein kniffliges Problem: Namen sind chaotisch. Das Wort „München“ könnte eine Stadt in Deutschland oder ein Film über Spione sein. Die Phrase „Île-de-France“ und „Île-de-France Region“ klingen vielleicht unterschiedlich, bedeuten aber exakt dasselbe. Wenn Ihre Bibliothek nicht vorsichtig ist, endet sie mit zwei verschiedenen Karten für dasselbe Objekt oder sie klebt versehentlich zwei verschiedene Dinge zusammen, weil sie denselben Namen teilen.

Vor kurzem ist eine neue Art von „Superhirn“ namens Large Language Model (LLM) aufgetaucht. Diese Modelle haben so viel im Internet gelesen, dass sie Fakten zu kennen scheinen, ohne ein physisches Buch zu benötigen. Einige Forscher dachten: „Warum lassen wir das Superhirn die Bibliothek nicht einfach für uns bauen?“ Aber hier ist der Haken: Das Superhirn besitzt eigentlich keine Liste mit eindeutigen ID-Karten für Dinge. Es kennt nur Wörter. Wenn Sie das Superhirn bitten, Fakten aufzulisten, erstellt es versehentlich einen doppelten Eintrag für „München der Stadt“ und „München der Film“, weil es sie als dasselbe Wort behandelt – oder es vergisst, dass „Île-de-France“ und „Île-de-France Region“ derselbe Ort sind. Dieses Papier stellt eine clevere neue Methode vor, um dieses Chaos zu beheben, indem es die wortreichen Antworten des Superhirns in eine saubere, organisierte und massive Bibliothek verwandelt, in der jedes einzelne Ding seine eigene eindeutige ID-Karte besitzt, selbst wenn es denselben Namen teilt.

Das Paper: GPTKB 2.0

Die Forscher hinter dieser Arbeit, Yujia Hu, Tuan-Phong Nguyen und Simon Raznevski, gehen eine große Herausforderung in der Welt der Künstlichen Intelligenz an. Sie wollten sehen, ob sie direkt aus einem Large Language Model (LLM) eine riesige, organisierte Wissensbasis aufbauen können, ohne dabei auf bestehende Datenbanken wie Wikipedia zurückzugreifen, um ihnen zu sagen, was was ist.

Das Problem: Das Chaos des „Namen-Spiels“
Stellen Sie sich ein LLM wie einen sehr gesprächigen Freund vor, der eine Million Fakten kennt, aber eine schreckliche Handschrift und kein Ablagesystem hat. Wenn Sie diesen Freund bitten, Fakten über „München“ aufzuschreiben, schreibt er vielleicht:

„München ist eine Stadt in Deutschland.“
„Mischchen ist ein Film über Spione.“

Wenn Sie diese einfach so aufschreiben, wie sie kommen, erhalten Sie zwei verschiedene Einträge für „München“, die identisch aussehen. Oder wenn Ihr Freund „Île-de-France“ und „Île-de-France Region“ sagt, könnten Sie denken, dass dies zwei verschiedene Orte sind, und zwei separate Karten erstellen. Dies wird als das Problem der Homonymie (gleicher Name, verschiedene Dinge) und der Synonymie (verschiedene Namen, dasselbe Ding) bezeichnet. Frühere Versuche, diese Bibliotheken aus LLMs aufzubauen, nutzten meist einfach die Wörter so, wie sie waren, was zu einer unordentlichen, voller Duplikate befindlichen Datenbank führte.

Die Lösung: Der „Kontext-Detektiv“
Das Team entwickelte ein neues System namens GPTKB 2.0. Anstatt das LLM nur nach Fakten zu fragen, bauten sie eine intelligente Pipeline, die wie ein Detektiv arbeitet. So funktioniert es, Schritt für Schritt:

Der Samen (The Seed): Sie beginnen mit einem einzigen Entität, wie einem Samen, der in den Boden gepflanzt wird (sie verwendeten „Vannevar Bush“ als Ausgangspunkt).
Die Abfrage (Elicitation): Sie fragen das LLM: „Erzähl mir Fakten über [Seed].“ Aber sie fragen nicht nur nach dem Namen; sie fragen auch nach der Beschreibung. Wenn der Samen also „München (die Stadt)“ ist, weiß das LLM, dass es nur über die Stadt sprechen soll, nicht über den Film.
Die Detektivarbeit (Disambiguation): Wenn das LLM einen neuen Fakt liefert, prüft das System: „Warte, haben wir diesen Namen schon einmal gesehen?“
- Wenn der Name „München“ ist, betrachtet das System den Kontext (den Satz, aus dem er stammt). Wenn der Satz sagt „München ist eine Hauptstadt“, ordnet es ihn der Karte der Stadt zu. Wenn er sagt „München ist ein Film“, erstellt es eine ganz neue Karte für den Film.
- Wenn der Name „Île-de-France Region“ ist, erkennt das System, dass dies nur eine schickere Art ist, „Île-de-France“ zu sagen, und führt sie zu einer Karte zusammen.
Das bewachte Parallel-Verfahren (Guarded Parallel): Dies alles nacheinander zu tun, ist langsam. Alles auf einmal zu tun, ist riskant (man könnte zwei „München“-Karten erstellen, bevor man merkt, dass sie dieselben sind). Das Team erfand eine „bewachte“ Methode, um viele Prüfungen gleichzeitig durchzuführen, wobei sichergestellt wird, dass nicht versehentlich Duplikate erstellt werden, während man noch dabei ist, die Dinge zu verstehen.

Das große Ergebnis
Das Team führte dieses System in einem massiven Maßstab durch. Sie erstellten nicht nur eine kleine Liste; sie bauten eine Bibliothek, die Folgendes enthält:

38,4 Millionen Fakten (genannt „Triples“).
1,6 Millionen eindeutige, disambiguierte Entitäten (Dinge wie Personen, Orte und Filme).
207.633 Relationen (wie Dinge miteinander verbunden sind) und 66.523 Klassen (Arten von Dingen).

Was dieses Projekt besonders macht, ist, dass 36,8 % dieser Entitäten neu sind. Sie existieren nicht in der berühmten Wikidata-Datenbank. Das bedeutet, das LLM hat Dinge gefunden, die menschlich kuratierte Bibliotheken übersehen haben, insbesondere im „Long Tail“ (dem langen Ende) von obskuren oder weniger bekannten Themen.

Hat es funktioniert?
Die Forscher testeten ihre Bibliothek, um zu sehen, wie genau sie ist.

Zusammenführung (Merging): Wenn sie versuchten, Dinge zusammenzuführen, die dasselbe sein sollten (Synonyme), hatten sie in 91 % der Fälle recht.
Trennung (Splitting): Wenn sie versuchten, verschiedene Dinge getrennt zu halten (Homonyme), waren sie in ihren Testproben zu 100 % korrekt.
Faktenprüfung (Fact-Checking): Sie überprüften zufällige Fakten gegen das Web. Etwa 94,5 % der Fakten wurden als wahr bestätigt, und nur 2 % waren falsch.

Warum das wichtig ist
Vor diesem Zeitpunkt verließen sich die meisten großen Wissensbasen auf Menschen oder bestehende Datenbanken wie Wikipedia, um sie organisiert zu halten. Dieses Paper zeigt, dass man direkt aus dem „Gehirn“ eines KI-Modells eine massive, saubere Wissensbasis aufbauen kann, ohne eine bereits existierende Landkarte zu benötigen. Es beweist, dass man mit den richtigen „Detektiv-Werkzeugen“ eine KI in der Lage ist, ihr eigenes Wissen zu organisieren, einzigartige Dinge zu finden und verwirrende Namen zu sortieren, wodurch eine Bibliothek entsteht, die größer und detaillierter ist als alles, was wir bisher aufgebaut haben.

Das System steht nun jedem zur Verfügung, um es zu erkunden, und zeigt uns, dass wir endlich das chaotische, wortreiche Wissen der KI in eine strukturierte, zuverlässige Landkarte der Welt verwandeln können.

Technisches Resümee: GPTKB 2.0

Problemstellung

Die automatisierte Konstruktion von Wissensdatenbanken (Automated Knowledge Base Construction, AKKB) stützte sich traditionell auf kuratierte Ressourcen wie Wikipedia und Wikidata zur Entitätskanonisierung oder auf oberflächenbasierte String-Clusterung für die textbasierte Extraktion. Neuere Ansätze, die Wissensdatenbanken direkt aus Large Language Models (LLs) generieren, stehen jedoch vor einer kritischen strukturellen Einschränkung: LLMs sind auf Strings trainiert, nicht auf Entitäten. Folglich führt die Behandlung von Oberflächenstrings als eindeutige Identifikatoren zu zwei komplementären Fehlermodi:

Homonymie: Verschiedene Entitäten mit identischen Bezeichnungen (z. B. die Stadt „München“ und der Film „München“) werden fälschlicherweise zusammengeführt.
Synonymie: Identische Entitäten mit unterschiedlichen Bezeichnungen (z. B. „Île-de-France“ und „Île-de-France region“) werden als verschiedene Entitäten behandelt.

Bestehende Disambiguierungsmethoden verlassen sich oft auf externe Inventare (z. B. die Verknüpfung mit Wikidata-IDs), was den Umfang der Konstruktion auf bereits existierende Ressourcen beschränkt. Andere nutzen Post-hoc-Clusterung, die zwar das Problem der Synonymie adressiert, aber die Homonymie nicht in großem Maßstab lösen kann. Die Kernherausforderung besteht darin, eine groß angelegte, Open-Domain-Wissensdatenbank direkt aus den Parametern eines LLM zu konstruieren und dabei eine explizite interne Kanonisierung von Entitäten, Relationen und Klassen ohne Rückgriff auf externe Identifikatoren aufrechtzuerhalten.

Methodik: GPTKB 2.0

Die Autoren schlagen GPTKB 2.0 vor, eine Methodik zur Konstruktion disambiguierter Wissensdatenbanken direkt aus LLMs. Das System nutzt das LLM als einzige Wissensquelle und verwendet eine rekursive, kontextgesteuerte Pipeline, die zwischen Elicitation (Abfrage) und Konsolidierung entlang der Subjekt-Objekt-Grenze alterniert.

Datenmodell

Die Wissensdatenbank ist als Quadrupel $(T, E, R, C)$ definiert, bestehend aus Triples, Entitäten, Relationen und Klassen.

Eindeutige Identifikatoren: Jedes Element wird einer eindeutigen internen ID zugewiesen, wodurch die Identität von den Oberflächenbezeichnungen entkoppelt wird.
Beschreibungen: Jedes Element enthält eine generierte Textbeschreibung, um die kontextbasierte Disambiguierung zu unterstützen.
Aliase: Synonyme Bezeichnungen werden als Aliase an eine einzige kanonische ID angehängt.
Umgang mit Homonymie: Verschiedene Entitäten, die dieselbe Bezeichnung teilen, erhalten unterschiedliche IDs, die durch ihre einzigartigen Beschreibungen unterschieden werden.

Konstruktions-Pipeline

Die Pipeline operiert durch drei Kernphasen, die die Wissensdatenbank iterativ von Seed-Entitäten aus erweitern:

Elicitation (Abfrage): Das LLM wird angewiesen, Triples für eine gegebte Entität zu generieren. Entscheidend ist, dass der Prompt neben dem Label auch die Beschreibung der Entität enthält. Dieser Kontext stellt sicher, dass die abgerufenen Fakten sich auf die spezifisch beabsichtigte Entität beziehen (z. B. die Unterscheidung zwischen dem Film „München“ und der Stadt „München“) und nicht auf eine homonyme Entität. Das Modell wird zudem angewiesen, instanceOf-Triples zu generieren, um Entitätstypen zu erfassen.
Named Entity Recognition (NER): Das LLM klassifiziert abgerufene Objekte entweder als Literale oder als benannte Entitäten (Named Entities, NEs). Dieser Schritt ist kontextgesteuert und nutzt das Quell-Triple, um zu bestimmen, ob ein Objekt (z. B. der Code „01099“) ein Literal oder eine Entität ist.
Disambiguierung (NED): Dies ist die zentrale Konsolidierungsphase, die in zwei Runden unterteilt ist, um ein Gleichgewicht zwischen Genauigkeit und Skalierbarkeit zu finden:
- Triple-Kontext NED: Für NEs ruft das System Top- $k$ -Kandidaten basierend auf der Ähnlichkeit der Label-Embeddings ab. Das LLM wird mit dem Ziel-Label, dem Quell-Triple als Kontext sowie den Labels/Beschreibungen der Kandidaten gepromptet. Das Modell entscheidet über einen Match, die Auswahl von „Keines der oben genannten“ (neue Entität) oder „Unsicher“.
- Beschreibungsgenerierung: Entitäten, die als „Keines der oben genannten“ markiert wurden, werden einem Schritt zur Beschreibungsgenerierung zugeführt. Das LLM generiert eine kurze Beschreibung basierend auf dem Ziel-Label und dem Quell-Triple. Diese Beschreibung dient als kanonische Definition der Entität.
- Beschreibungs-Kontext NED: Für hochverdichtete Homonyme (z. B. „Philosophische Fakultät“, das hundertfach vorkommt) wird der Kandidatensatz auf Entitäten beschränkt, die exakt dasselbe Label teilen. Das LLM nutzt dann die generierte Beschreibung (statt des Quell-Triples), um zwischen Kandidaten bassierend auf der semantischen Ähnlichkeit zu unterscheiden.

Skalierbarkeitsmechanismen

Um eine Konstruktion im Millionenmaßstab zu ermöglichen, führen die Autoren Guarded Parallelization (geschützte Parallelisierung) und Caching ein:

Guarded Parallelization: Um die redundante Erstellung von Duplikaten bei der gleichzeitigen Verarbeitung desselben Labels zu verhindern, gruppiert das System ausstehende NED-Anfragen nach Label. Es verarbeitet nur die zuerst abgerufene Instanz sofort; nachfolgende Instanzen werden aufgeschoben, bis die erste aufgelöst ist, um sicherzustellen, dass die Entität als Kandidat für spätere Matches existiert.
Caching: Disambiguierungsentscheidungen für häufig vorkommende (Relation, Objekt)-Paare werden gecacht, um redundante NER- und NED-Aufrufe zu vermeiden, was die API-Kosten erheblich senkt.

Zentrale Beiträge

Methodik: Eine parallelisierte, kontextgesteuerte Pipeline zur Wissensdatenbank-Konstruktion, die ein LLM als exklusive Wissensquelle nutzt und sowohl Synonymie als auch Homonymie durch On-the-fly-Disambiguierung ohne externe Identifikatoren adressiert.
Skalierung und Qualität: Die Konstruktion einer materialisierten Wissensdatenbank mit 38,4 Millionen Triples und 1,6 Millionen disambiguierter Entitäten. Das System hat 2,3 Millionen Oberflächenlabels zu 1,6 Millionen kanonischen Entitäten konsolidiert und 131.990 homonyme Entitäten korrekt unterschieden, die 41.275 Labels teilten.
Neuheit: Die erste millionen-skalierte, LLM-native Wissensdatenbank mit expliziter interner Kanonisierung außerhalb des Wikimedia-Sphäre. Etwa 36,8 % der konstruierten Entitäten sind neuartig gegenüber Wikidata, was die Fäh Fähigkeit demonstriert, Long-Tail-Wissen zu erfassen.

Ergebnisse und Evaluierung

Die Autoren haben die konstruierte Wissensdatenbank mittels manueller Annotation und automatisierter agentenbasierter Verifizierung evaluiert:

Disambiguierungsgenauigkeit:
- Merge-Genauigkeit (Zusammenführung): 98 % für Homonyme und 91 % für Synonyme.
- Split-Genauigkeit (Trennung): 100 % für Homonyme (keine falschen Trennungen in der Stichprobe) und 95 % für Synonyme.
- Relationen/Klassen: Erreichten 89–91 % Merge-Genauigkeit und 91–94 % Split-Genauigkeit.
Faktizität:
- Triple-Präzision: 94,5 % der manuell gesampelten Triples wurden als wahr verifiziert; 92,8 % in der automatisierten Evaluierung.
- Entitäten-Faktizität: 96 % der manuell gesampelten Entitäten waren als reale Entitäten verifizierbar.
Vergleich zur Baseline: Eine Baseline, die auf Oberflächenstrings basierte, ergab 2,3 Millionen Entitäten (gegenüber 1,6 Mio. bei GPTKB 2.0) und scheiterte daran, 131.990 homonyme Entitäten zu unterscheiden. In einem domänenspezifischen Test (Altes Babylon) vermischte die Baseline verschiedene Entitäten (z. B. unterschiedliche „Paris“-Figuren), während GPTKB 2.0 distinkte Identitäten beibehielt.

Bedeutung

Das Paper behauptet, dass GPTKB 2.0 eine signifikante Abkehr von bisherigen Wikimedia-zentrierten Arbeiten darstellt. Durch den Nachweis, dass ein groß angelegtes, disambiguierbares, General-Domain-Entitätenregister direkt aus LLM-Parametern ohne externe Erdung konstruiert werden kann, eröffnet die Arbeit die Möglichkeit, Wissensräume jenseits kuratierter Ressourcen zu explorieren. Die Autoren betonen, dass LLM-abgeleitete Wissensdatenbanken besonders effektiv bei der Abdeckung des „Long-Tail“ des Wissens (Entitäten, die selten vorkommen) sind, wo kuratierte Bemühungen spärlich sind. Die resultierende Wissensdatenbank wird für aggregierte statistische Analysen zur Verfügung gestellt, was die Untersuchung von Biases, thematischen Schwerpunkten und logischer Konsistenz in einem Ausmaß ermöglicht, das für LLM-native Wissensdatenbanken bisher unerreichbar war.