GPTKB 2.0: Browsing, Querying, and Auditing a Disambiguated LLM-Derived Knowledge Base

# GPTKB 2.0: Browsing, Querying, and Auditing a Disambiguated LLM-Derived Knowledge Base
Source: [https://arxiv.org/html/2608.06992](https://arxiv.org/html/2608.06992)
Yujia Hu1Tuan\-Phong Nguyen2Simon Razniewski1

1ScaDS\.AI Dresden/Leipzig & TU Dresden, Germany 2Institute for AI, VNU University of Engineering and Technology, Hanoi, Vietnam \{yujia\.hu,simon\.razniewski\}@tu\-dresden\.de tuanphong@vnu\.edu\.vn

###### Abstract

We present a web demo for exploring a large\-scale disambiguated knowledge base \(KB\) materialized from a large language model \(LLM\)\. GPTKB 2\.0 contains 38\.4M triples over 1\.6M canonical entities, together with 207\.6K consolidated relations and 66K consolidated classes\. Unlike prior LLM\-derived knowledge bases that largely identify entities by surface strings, GPTKB 2\.0 performs context\-guided disambiguation during recursive KB construction, separating homonyms and merging synonymous mentions as facts are elicited\. The demo makes this process inspectable: users can browse entities, follow links across the KB, and audit the provenance of individual facts, including surface forms, candidate matches, source triples, and disambiguation decisions\. The interface further supports structured SPARQL queries, natural\-language questions translated to SPARQL, and entity linking from user\-provided text to canonical GPTKB 2\.0 entries\. GPTKB 2\.0 is available at[https://gptkb\.org/](https://gptkb.org/), with the full KB downloadable for offline use\.

GPTKB 2\.0: Browsing, Querying, and Auditing a Disambiguated LLM\-Derived Knowledge Base

Yujia Hu1Tuan\-Phong Nguyen2Simon Razniewski11ScaDS\.AI Dresden/Leipzig & TU Dresden, Germany2Institute for AI, VNU University of Engineering and Technology, Hanoi, Vietnam\{yujia\.hu,simon\.razniewski\}@tu\-dresden\.de tuanphong@vnu\.edu\.vn

## 1Introduction

General\-domain KBswikidata;dbpedia;yagoare important and longstanding backbones for AI applications, and entity disambiguation recognized as a core challenge in KB construction\. More recently, large language models \(LLMs\) have emerged as implicit repositories of factual knowledgepetroni\-etal\-2019\-language, inspiring a line of work that constructs knowledge bases directly from LLMs by materializing their parametric knowledge in structured formmango;cohen\-etal\-2023\-crawling;gptkbv1;gptkbv1\.5;parovic\-etal\-2025\-generating\. However, these approaches largely rely on surface strings as entity identifiers\. Yet surface strings are inadequate identifiers, exhibiting two complementary failure modes: without further triple context, they conflate*homonymous*entities that share identical entity label \(e\.g\.,Munichin\[Europe, hasMajorCity, Munich\]vs\.Munichin\[Mathieu Amalric, notableWork, Munich\]\) and fragment*synonymous*strings that denote the same entity \(e\.g\.,New York CityandThe Big Apple\)\.

![Refer to caption](https://arxiv.org/html/2608.06992v1/images/budapest1.png)Figure 1:[![Refer to caption](https://arxiv.org/html/2608.06992v1/x2.png)Budapest](https://gptkb.org/entity/E13406)in GPTKB 2\.0\.We present GPTKB 2\.0, a disambiguated, general\-domain KB built entirely from an LLM, together with a web interface that makes both the knowledge and its provenance explorable\. GPTKB 2\.0 comprises 38\.4M triples over 1\.6M canonicalized entities, 207\.6K consolidated relations, and 66K consolidated classes\. Disambiguation is performed on the fly during construction, driven by a simple observation: the eliciting triple, together with textual descriptions of existing entities, typically provides sufficient context to distinguish new entities from known ones without external resources\.

The demo’s distinguishing feature is transparency\. Through the interface, users can \(i\) browse and query the full KB via SPARQL or natural language; \(ii\) inspect the derivation and consolidation provenance behind any fact: all its trajectories from the seed entity, and the surface forms, candidate matches, and context considered during consolidation, so that both homonymy and synonymy resolution become auditable; and \(iii\) link named entities in their own input text to canonical GPTKB 2\.0 entries\. To our knowledge, GPTKB 2\.0 is the first demo to combine disambiguation provenance, SPARQL, and natural\-language querying over an LLM\-derived KB\.

## 2Construction

GPTKB 2\.0 methodologyhu2026gptkb20directconstructionrepresents entities, relations, and classes as first\-class elements with unique identifiers, so that disambiguation can operate across homonymous and synonymous mentions\. Following curated KBs such as Wikidatawikidata, besides unique ID, each element also carries a textual description, which serves as the context signal for disambiguation\. An example for[![[Uncaptioned image]](https://arxiv.org/html/2608.06992v1/x3.png)Budapest](https://gptkb.org/entity/E13406)is shown in Figure[1](https://arxiv.org/html/2608.06992#S1.F1)\. Starting from a seed entity, GPTKB 2\.0 is built by a recursive, context\-guided pipeline that expands the KB along the subject–object frontier, disambiguating each new mention on the fly\. The pipeline proceeds through four context\-guided steps: elicitation, named entity recognition \(NER\), and disambiguation\.

#### Elicitation and NER

Both steps rest on one principle: a bare label is ambiguous, so we condition the LLM on context\. Given an entity, the LLM is prompted for triples; since facts aboutMunichcould concern the city or the 2005 film, we include the entity’s description so that elicited facts pertain to the intended entity\. Each elicited object is then classified as a literal or a named entity,01099is a literal in\[Neustadt Dresden, postalCode, 01099\]but an entity in\[Frisch, partOfBand, 01099\]—using the source triple as context\.

#### Disambiguation

Named\-entity objects are resolved against the KB to merge synonyms and separate homonyms\. The LLM is prompted with the target entity label, its source triple, and the labels and descriptions of the nearest candidates by embedding similarity; it either matches an existing entity, marks it new, or abstains\. A match inherits the incoming label as an alias\. For instance,[![[Uncaptioned image]](https://arxiv.org/html/2608.06992v1/x4.png)Munich](https://gptkb.org/entity/E21335)\(city\) and[![[Uncaptioned image]](https://arxiv.org/html/2608.06992v1/x5.png)Munich](https://gptkb.org/entity/E854833)\(film\) are kept distinct through their differing source\-triple context;The Big Appleis mapped to[![[Uncaptioned image]](https://arxiv.org/html/2608.06992v1/x6.png)New York](https://gptkb.org/entity/E550)based on the source triple\[Emerald City, contrastsWith, The Big Apple\]\.

Table 1:Overall statistics of GPTKB 2\.0\.![Refer to caption](https://arxiv.org/html/2608.06992v1/x7.png)Figure 2:Hyde Parkin London is recognized as distinct from other synonymous entities\.

## 3Overview

As shown in Table[1](https://arxiv.org/html/2608.06992#S2.T1), GPTKB 2\.0 contains 38\.4M triples and 1\.6M disambiguated entities, together with 207\.6K relations and 66\.5K classes\.

## 4Web Interface

GPTKB v2 is served at[https://gptkb\.org/](https://gptkb.org/), which provides a user interface for keyword\-based entity search and link\-based exploration to discover connected entities\. The interface is built with the Django framework and served via Nginx, with the KB stored in an OpenLink Virtuoso triple store\. To our knowledge, this is the first demo interface to make the consolidation process fully traceable while combining SPARQL querying, natural\-language \(text\-to\-SPARQL\) querying, and entity linking over an LLM\-derived KB\.

### 4\.1Access

Entities can be reached through several routes:

1. 1\.The start page links directly to featured entities such asVannevar BushandSan Francisco\.
2. 2\.A search field in the top\-right corner supports string\-based lookup\.
3. 3\.

### 4\.2Traceable decision\-making

Each entity’s page exposes the disambiguation decisions behind it, making both homonymy and synonymy auditable\. To trace homonymy handling, users can inspect the candidates presented to the LLM when this entity was disambiguated, revealing how it was kept distinct from same\-label candidates and judged new to the KB at the point it first appeared\. As shown in Figure[2](https://arxiv.org/html/2608.06992#S2.F2), clickingShowunderHow this entity was disambiguatedreveals the process by which[![[Uncaptioned image]](https://arxiv.org/html/2608.06992v1/x9.png)Hyde Park](https://gptkb.org/entity/E71303)in London is separated from its homonyms existing in GPTKB 2\.0\. To trace synonymy handling, the surface forms consolidated into this entity are listed as its aliases; clicking one opens the prompt for the corresponding disambiguation step, showing how that form was merged\. As shown in Figure[3](https://arxiv.org/html/2608.06992#S4.F3), the alias list of[![[Uncaptioned image]](https://arxiv.org/html/2608.06992v1/x10.png)New York City](https://gptkb.org/entity/E40)lets users click an alias \(here,The Big Apple\) to reveal the mentions mapped under that label; the info button then opens the prompt used at that step, listing the target entity, its source triple, and the retrieved candidates\.

![Refer to caption](https://arxiv.org/html/2608.06992v1/x11.png)Figure 3:The Big Apple is mapped to existing entityNew York City\.
### 4\.3Entity Linking

Beyond showing how entities within GPTKB v2 were linked during construction, the interface integrates LELAhaffoudhi2026lelallmbasedentitylinking;haffoudhi2026lelallmbasedentitylinking2, an entity\-linking system, over GPTKB v2\. A user enters text and clicksLink entities; LELA detects named\-entity mentions and links each to its corresponding entity in GPTKB v2, or marks itNILwhen no match exists\.![[Uncaptioned image]](https://arxiv.org/html/2608.06992v1/images/entitylinkingwindow.png) Linking is also context\-dependent: in the example, the two occurrences ofMercuryresolve to distinct entities, the planet \([![[Uncaptioned image]](https://arxiv.org/html/2608.06992v1/x12.png)Mercury](https://gptkb.org/entity/E18768)\) and the Roman deity \([![[Uncaptioned image]](https://arxiv.org/html/2608.06992v1/x13.png)Mercury](https://gptkb.org/entity/E397485)\), despite sharing a surface form\.![[Uncaptioned image]](https://arxiv.org/html/2608.06992v1/images/entitylinking_result.png) Each decision is auditable through a disambiguation\-evidence panel that lists every candidate the linker weighed\. Candidates are retrieved in two ways: surface form matches, ranked by how often each entity has been observed under that surface form, and a BM25 text\-relevance fallback that fills the remaining slots\. Notably, context can override raw frequency: although the planet is the most frequent entity linked toMercury\(observed 53 times\), the mythological mention is correctly resolved to the Roman deity \(observed only 16 times\), which the surrounding context favors\. This transparency lets users see not only which entity was chosen but which alternatives were considered and rejected\.![[Uncaptioned image]](https://arxiv.org/html/2608.06992v1/images/entitylinking_evidence1.png) ![[Uncaptioned image]](https://arxiv.org/html/2608.06992v1/images/entitylinking_evidence2.png)

### 4\.4SPARQL Query

Because GPTKB 2\.0 is a fully materialized, structured KB, its contents can be queried directly rather than through repeated prompting of the underlying model\. The KB is stored in an OpenLink Virtuoso triple store and exposed through a SPARQL endpoint at[https://gptkb\.org/query/](https://gptkb.org/query/), supporting structured queries, filtering, and aggregation over all 38\.4M triples\. This turns questions about the model’s knowledge that would otherwise require bespoke, large\-scale prompting \(e\.g\., thousands of templated probesKotek\_2023\) into single declarative queries evaluated with mature database technology\. In the following, we show enabled analyses\.

#### Most frequent classes

The most frequent classes in GPTKB 2\.0 can be queried via:

PREFIXdisamkbp:<https://gptkb\.org/prop/\>

SELECT?o\(COUNT\(\*\)AS?freq\)

WHERE\{

?sdisamkbp:P0?o\.

\}

GROUPBY?o

ORDERBYDESC\(?freq\)

LIMIT20

labelfreq

human166328

municipality66232

touristattraction51891

fictionalbeaver29751

song25408

neighborhood24317

building23436

film23376

#### Entities with most aliases

Entities with most aliases in GPTKB 2\.0 can be queried via:

PREFIXrdfs:<http://www\.w3\.org/2000/01/rdf\-schema

PREFIXskos:<http://www\.w3\.org/2004/02/skos/core

SELECT?e?eLabel\(COUNT\(?form\)AS?nforms\)

WHERE\{

?e\(rdfs:label\|skos:altLabel\)?form

\}

GROUPBY?e?eLabel

ORDERBYDESC\(?nforms\)

LIMIT20

![[Uncaptioned image]](https://arxiv.org/html/2608.06992v1/images/most_aliases_query_results.png)

As shown above, 128 distinct surface labels map to the entityUnited States of America\. This illustrates the value of resolving entities during construction rather than afterward: because each merge is available to subsequent elicitation steps, later facts are gathered against the consolidated entity, avoiding the fragmentation that a post\-hoc pass would first have to detect and then repair\.

### 4\.5Query in Natural Language

For users unfamiliar with SPARQL, the demo integrates GRASPDBLP:conf/semweb/WalterB25, an agent that answers plain\-English questions over GPTKB 2\.0\. Given a question, the agent iteratively explores GPTKB 2\.0 through tool calls, resolving the entities, properties, and classes it needs, then composes and executes a SPARQL query to produce the answer\. For example,“What is Budapest known for?”is resolved by locating theBudapestentity \(E13406\) and thetraditionallyKnownForproperty \(P67817\), yielding a concise list of answers\.![[Uncaptioned image]](https://arxiv.org/html/2608.06992v1/images/grasp1.png) ![[Uncaptioned image]](https://arxiv.org/html/2608.06992v1/images/grasp2.png) Consistent with the rest of the interface, every step is transparent: the demo exposes the agent’s full reasoning trace, the generated SPARQL query \(which users can open in the query editor\), and the KB entries the agent resolved, each linked to its entity page\.

![[Uncaptioned image]](https://arxiv.org/html/2608.06992v1/images/grasp3.png)

## 5Evaluation

### 5\.1Disambiguation

Reliable link\-based exploration depends on correct disambiguation: linked entities must be neither wrongly merged nor wrongly split\. We manually assess both error directions on samples of 100 cases each \(Table[2](https://arxiv.org/html/2608.06992#S5.T2)\)\.Merge precisionmeasures whether entities combined into one are truly the same: 98% of same\-label objects merged into an existing entity are correct \(homonymy\), as are 91% of differently\-labeled aliases resolved to an existing entity \(synonymy\); false merges \(9%\) in the latter are the main error mode\.Split precisionmeasures whether entities kept separate are truly distinct: all 100 same\-label pairs assigned distinct IDs are genuinely different \(homonymy\), and for 95% of entities no synonymous duplicate appears among their top\-20 label\-embedding neighbors \(synonymy; an approximation, since duplicates with dissimilar surface forms may be missed\)\. The pipeline thus handles both homonymy and synonymy reliably in both directions, with false synonym merges the largest residual error\.

Table 2:Manual and automatic evaluation of GPTKB 2\.0\. Human evaluation usesn=400n=400for NED precision andn=200n=200for triple precision and entity factuality; LLM evaluation usesn=1,000n=1\{,\}000\.
### 5\.2Overall Quality of GPTKB 2\.0

Since exhaustive evaluation of a 38M\-triple KB is infeasible, we assess randomly sampled subsets\. Following YAGOyagoand recent factuality metrics such as FactScoremin\-etal\-2023\-factscoreand VeriScoresong\-etal\-2024\-veriscore, we verify samples against web\-retrieved evidence, using two paradigms: 200 items validated by humans and 1,000 items judged by an agentic pipeline\. Precision exceeds 90% for both triples and entities \(Table[2](https://arxiv.org/html/2608.06992#S5.T2)\)\. Fortriples\(labeled true, plausible, implausible, or false\), 94\.5% are true and 2\.0% false on the human sample, and 92\.8% true and 0\.5% false on the automatic sample\. In an ablation where the judge sees each triple without the subject entity’s description, the true rate drops to 80%, underscoring how much descriptions contribute to interpretability\. Forentities\(labeled verifiable, plausible, or unverifiable\), 96% are verifiable on the human sample and 92\.3% on the automatic sample\.

## 6Related Work

#### Disambiguated Knowledge Bases

Managing entity identity is a longstanding challenge in KB construction\. Curated KBs \(DBpediadbpedia, YAGOyago, Wikidatawikidata\) inherit canonicalization from human\-maintained resources, and mention\-grounding methods reuse such inventorieshoffart\-etal\-2011\-robust, but both bound coverage to what those resources contain; text\-based systemsCarlson2010NELLbroaden coverage yet often set consolidation aside\. LLM\-derived KBscohen\-etal\-2023\-crawling;gptkbv1;parovic\-etal\-2025\-generatingare tied to neither a fixed corpus nor a closed schema, but inherit no external identifiers and must disambiguate from scratch\.

#### Traceable KB Interfaces

Public KBs are typically exposed through browsers, entity pages, and SPARQL endpoints that present the KB as a finished artifact showing what it contains, not how each entry arose\. For LLM\-derived KBs, whose entries are generated and consolidated automatically, the provenance behind each fact and disambiguation decision is itself evidence of trustworthiness\. GPTKB 2\.0’s interface makes this process traceable, surfacing for each fact its derivation trajectory, the candidates weighed during disambiguation, and the context behind each decision\.

## 7Conclusion

We presented GPTKB 2\.0, a disambiguated knowledge base materialized entirely from LLM, together with a web interface that makes both its knowledge and the disambiguation decisions behind it explorable\. The KB comprises 38\.4M triples over 1\.6M entities, 207\.6K relations, and 66K classes, all consolidated on the fly during a recursive construction pipeline\. The distinguishing feature of this demo is transparency: every fact carries provenance recording the surface forms, candidate matches, and context behind its disambiguation\. Through the interface, users can browse and trace entities, query the KB in SPARQL or natural language, and link named entities in their own text against it\. By turning an LLM’s latent parametric knowledge into a structured, queryable, and inspectable resource, GPTKB v2 offers both a usable general\-domain KB and a step toward making the knowledge inside LLMs open to scrutiny\.

## References