GPTKB 2.0：浏览、查询和审计去歧义的 LLM 派生知识库

# GPTKB 2.0：浏览、查询与审计一个消歧后的大语言模型派生知识库

来源：https://arxiv.org/html/2608.06992

Yujia Hu¹  
Tuan\-Phong Nguyen²  
Simon Razniewski¹  

¹ScaDS.AI Dresden/Leipzig & TU Dresden, Germany  
²Institute for AI, VNU University of Engineering and Technology, Hanoi, Vietnam  

\{yujia.hu, simon.razniewski\}@tu-dresden.de  
[email protected]  

###### 摘要

我们展示了一个用于探索从大语言模型（LLM）物化的大规模消歧知识库（KB）的 Web 演示。GPTKB 2.0 包含 3840 万个三元组，覆盖 160 万个规范化实体，以及 207.6K 个合并后的关系和 66K 个合并后的类。与先前主要用表面字符串识别实体的 LLM 派生知识库不同，GPTKB 2.0 在递归构建知识库的过程中执行上下文引导的消歧，在事实抽取的同时分离同音异义实体并合并同义提及。该演示使得这一过程可检查：用户可以浏览实体、沿着知识库中的链接导航，并审计单个事实的溯源信息，包括表面形式、候选匹配、源三元组和消歧决策。该界面还支持结构化 SPARQL 查询、将自然语言问题转换为 SPARQL，以及将用户提供的文本中的实体链接到规范的 GPTKB 2.0 条目。GPTKB 2.0 可在 https://gptkb.org/ 获取，完整知识库可下载离线使用。

# GPTKB 2.0：浏览、查询与审计一个消歧后的大语言模型派生知识库

Yujia Hu¹  
Tuan\-Phong Nguyen²  
Simon Razniewski¹  

¹ScaDS.AI Dresden/Leipzig & TU Dresden, Germany  
²Institute for AI, VNU University of Engineering and Technology, Hanoi, Vietnam  

\{yujia.hu, simon.razniewski\}@tu-dresden.de  
[email protected]  

## 1 引言

通用领域知识库（Wikidata、DBpedia、YAGO）是人工智能应用的重要且长期存在的支柱，实体消歧被认为是知识库构建中的核心挑战。最近，大语言模型（LLM）已成为事实知识的隐式存储库 petroni-etal-2019-language，激发了一系列直接从 LLM 构建知识库的工作，通过以结构化形式物化其参数化知识 mango;cohen-etal-2023-crawling;gptkbv1;gptkbv1.5;parovic-etal-2025-generating。然而，这些方法主要依赖表面字符串作为实体标识符。但表面字符串并不是合适的标识符，并表现出两种互补的失效模式：在没有进一步三元组上下文的情况下，它们会混淆共享相同实体标签的同音异义实体（例如，[Europe, hasMajorCity, Munich] 中的 Munich 与 [Mathieu Amalric, notableWork, Munich] 中的 Munich），并割裂表示同一实体的同义字符串（例如，New York City 和 The Big Apple）。我们提出 GPTKB 2.0，这是一个完全由 LLM 构建的消歧后的通用领域知识库，并配有一个 Web 界面，使知识和其溯源信息都可探索。GPTKB 2.0 包含 3840 万个三元组，覆盖 160 万个规范化实体、207.6K 个合并后的关系和 66K 个合并后的类。消歧在构建过程中即时执行，由一个简单观察驱动：抽取谓词的三元组加上已有实体的文本描述，通常足以在无需外部资源的情况下将新实体与已知实体区分开。该演示的显著特点是透明性。通过该界面，用户可以（i）通过 SPARQL 或自然语言浏览和查询整个知识库；（ii）检查任何事实背后的推导和合并溯源：从种子实体出发的所有轨迹，以及合并过程中考虑的表面形式、候选匹配和上下文，从而使同音异义和同义解析都可审计；（iii）将用户输入文本中的命名实体链接到规范的 GPTKB 2.0 条目。据我们所知，GPTKB 2.0 是首个将消歧溯源、SPARQL 和自然语言查询结合在 LLM 派生知识库上的演示。

参见图1：GPTKB 2.0 中的 Budapest (https://gptkb.org/entity/E13406)。

## 2 构建

GPTKB 2.0 方法论 hu2026gptkb20directconstruction 将实体、关系和类表示为具有唯一标识符的一等元素，从而可以在同音异义和同义提及之间进行消歧。遵循 Wikidata 等人工策展知识库 wikidata，除了唯一 ID，每个元素还携带文本描述，作为消歧的上下文信号。图1 中展示了 Budapest (https://gptkb.org/entity/E13406) 的一个示例。从一个种子实体开始，GPTKB 2.0 通过一个递归的、上下文引导的流水线构建，该流水线沿着主语–宾语边界扩展知识库，并对每个新提及即时消歧。该流水线包含四个上下文引导步骤：抽取、命名实体识别（NER）和消歧。

#### 抽取与 NER

两个步骤都基于一个原则：单独的标签是有歧义的，因此我们以上下文为条件来提示 LLM。给定一个实体，提示 LLM 生成三元组；由于关于 Munich 的事实可能涉及城市或 2005 年的电影，我们加入实体的描述，使抽取的事实属于预期实体。然后，每个抽取出的宾语被分类为字面量或命名实体——01099 在 [Neustadt Dresden, postalCode, 01099] 中是字面量，但在 [Frisch, partOfBand, 01099] 中是实体——使用源三元组作为上下文。

#### 消歧

命名实体宾语会与知识库进行解析，以合并同义词并分离同音异义词。提示 LLM 时，会给出目标实体标签、其源三元组，以及通过嵌入相似性得到的最近候选的标签和描述；它要么匹配现有实体，要么将其标记为新实体，要么放弃。匹配时会将传入的标签继承为别名。例如，Munich（城市）和 Munich（电影）通过其不同的源三元组上下文而保持区分；The Big Apple 基于源三元组 [Emerald City, contrastsWith, The Big Apple] 被映射到 New York。

表 1：GPTKB 2.0 的总体统计。

参见图2：伦敦的 Hyde Park 被识别为与其它同义实体不同的实体。

## 3 概览

如表 1 所示，GPTKB 2.0 包含 3840 万个三元组和 160 万个消歧后的实体，以及 207.6K 个关系和 66.5K 个类。

## 4 Web 界面

GPTKB v2 在 https://gptkb.org/ 上提供服务，其用户界面支持基于关键词的实体搜索和基于链接的探索，以发现相关联的实体。该界面使用 Django 框架构建，并通过 Nginx 提供服务，知识库存储在 OpenLink Virtuoso 三元组存储中。据我们所知，这是首个将合并过程完全可追踪，并同时结合 SPARQL 查询、自然语言（文本转 SPARQL）查询和实体链接的 LLM 派生知识库演示界面。

### 4.1 访问实体

可以通过多种途径访问实体：

1. 起始页直接链接到精选实体，例如 Vannevar Bush 和 San Francisco。
2. 右上角的搜索字段支持基于字符串的查找。
3. 

### 4.2 可追踪的决策过程

每个实体的页面都展示其背后的消歧决策，使同音异义和同义解析都可审计。为了追踪同音异义的处理，用户可以检查该实体被消歧时呈现给 LLM 的候选，从而揭示它如何与同标签候选保持区分，并在首次出现时被判定为知识库中的新实体。如图 2 所示，点击 “How this entity was disambiguated” 下的 Show，会揭示伦敦的 Hyde Park 是如何与 GPTKB 2.0 中已有的同音异义实体分离的。为了追踪同义处理，合并到该实体的表面形式会作为其别名列出；点击某个别名会打开对应消歧步骤的提示，显示该形式是如何被合并的。如图 3 所示，New York City 的别名列表让用户点击某个别名（此处为 The Big Apple），以揭示在该标签下映射的提及；信息按钮随后会打开该步骤使用的提示，列出目标实体、其源三元组和检索到的候选。

参见图3：The Big Apple 被映射到已有实体 New York City。

### 4.3 实体链接

除了展示 GPTKB v2 中的实体在构建时是如何链接的之外，该界面还在 GPTKB v2 上集成了实体链接系统 LELA haffoudhi2026lelallmbasedentitylinking;haffoudhi2026lelallmbasedentitylinking2。用户输入文本并点击 “Link entities”；LELA 检测命名实体提及，并将每个提及链接到 GPTKB v2 中对应的实体；如果没有匹配，则标记为 NIL。

![[未配图题图像]](https://arxiv.org/html/2608.06992v1/images/entitylinkingwindow.png)

链接也是依赖上下文的：在示例中，Mercury 的两次出现被解析为不同的实体——行星（Mercury）和罗马神祇（Mercury），尽管它们共享相同的表面形式。

![[未配图题图像]](https://arxiv.org/html/2608.06992v1/images/entitylinking_result.png)

每个决策都可通过消歧证据面板进行审计，该面板列出链接器权衡过的每个候选。候选通过两种方式检索：表面形式匹配（按每个实体在该表面形式下被观察到的频率排序），以及用于填充剩余槽位的 BM25 文本相关性回退。值得注意的是，上下文可以覆盖原始频率：尽管行星是与 Mercury 链接的最频繁实体（观察到 53 次），但神话中的提及被正确解析为罗马神祇（仅观察到 16 次），因为周围上下文更倾向于后者。这种透明性使用户不仅能看到选择了哪个实体，还能看到哪些备选方案被考虑过并拒绝。

![[未配图题图像]](https://arxiv.org/html/2608.06992v1/images/entitylinking_evidence1.png)

![[未配图题图像]](https://arxiv.org/html/2608.06992v1/images/entitylinking_evidence2.png)

### 4.4 SPARQL 查询

由于 GPTKB 2.0 是一个完全物化的结构化知识库，其内容可以直接查询，而不必反复提示底层模型。知识库存储在 OpenLink Virtuoso 三元组存储中，并通过 https://gptkb.org/query/ 上的 SPARQL 端点暴露，支持对全部 3840 万个三元组进行结构化查询、过滤和聚合。这将关于模型知识的问题——否则需要定制的、大规模提示（例如，数千个模板化探针 Kotek_2023）——转化为用成熟数据库技术求值的单个声明式查询。下面，我们展示由此支持的分析。

#### 最常见的类

GPTKB 2.0 中最常见的类可以通过以下方式查询：

```
PREFIX disamkbp: 
SELECT ?o (COUNT(*) AS ?freq) WHERE { ?s disamkbp:P0 ?o . }
GROUP BY ?o ORDER BY DESC(?freq) LIMIT 20
```

label freq  
human 166328  
municipality 66232  
touristattraction 51891  
fictionalbeaver 29751  
song 25408  
neighborhood 24317  
building 23436  
film 23376  

#### 别名最多的实体

GPTKB 2.0 中别名最多的实体可以通过以下方式查询：

```
PREFIX rdfs:
```