知识图谱：三元组、构建流水线与大模型时代

知识图谱实体识别实体链接图数据库

人工智能

发布日期: 2026-10-27

更新日期: 2026-10-27

文章字数: 13.6k

阅读时长: 48 分

阅读次数:

把”姚明效力于休斯敦火箭”写成一条机器可查的数据，中间要跨过实体识别、关系抽取、实体消歧三道坎——每一道都在跟歧义作战。

一、知识图谱是什么

知识图谱用图结构表示知识：节点是实体（人、公司、城市、概念），边是关系（效力于、位于、收购），部分节点和边上还挂属性。最小的知识单元是三元组：

（姚明，效力于，休斯敦火箭）
（休斯敦火箭，位于，休斯敦）
（姚明，身高，2.26 米）

成千上万条三元组连起来，就是一张图。它的价值不在”存了”，而在”连了”：多跳查询可以从”姚明”出发走到”休斯敦火箭”再走到”NBA”再走到其他球队，这种跨实体的关联查询，关系数据库要写多层 JOIN，文档数据库表达不了 schema 之外的关系，文本检索更是只能靠词面匹配。

Google 在 2012 年推出知识图谱时给过一个准确的定位：”things, not strings”——搜索的终点不该是字符串匹配，而应该是字符串背后那个有唯一身份的东西。”苹果”这个词指向的是公司还是水果，取决于它背后连接的实体节点，而不是字符串本身。这句话点出了知识图谱的全部核心：实体要有唯一身份，关系要有明确定义。

和关系数据库对比一句：关系库的 schema 是先定的、强类型的，查询是结构化的；知识图谱的 schema（本体）相对灵活，实体和关系可以增量生长，查询既有结构化语义（图模式匹配）也兼容模糊语义（嵌入相似度）。它不是替代关系数据库，而是解决”关系复杂、语义多样、持续演化”那类问题。

二、标志性工程与数据来源

通用的知识图谱大多从百科起家。

Freebase（SIGMOD 2008）是早期影响最大的尝试：社区协作、以实体为中心组织数据，后来被 Google 收购并成为知识图谱最初的底座，2016 年停止维护后数据迁移给了 Wikidata。DBpedia（ISWC 2007）的思路不同：自动抽取维基百科信息框的结构化内容，证明”从现有百科机械地造图”可行。YAGO（WWW 2007）把维基百科与 WordNet 的类别体系对齐，兼顾了规模与语义层级。Wikidata（CACM 2014）是现在最大的 freely 可编辑知识库：中央化、多语言、带引用来源，数据以 CC0 发布。

领域知识图谱是另一条线：金融（股权、担保、供应链关系）、医疗（疾病、症状、药物、指南）、公安（人、案件、组织）、工业（设备、工艺、故障）。领域图谱的实体规模通常小得多，但 schema 更深、关系类型更专业、对准确率的要求更苛刻——通用图谱可以容忍 5% 的错误，风控图谱里一条错误的股权关系就是真金白银。

三、构建流水线之一：实体抽取

从原始文本到知识图谱，第一站是把文本里的实体提及（mention）找出来——这就是命名实体识别（NER），也叫实体抽取。它通常建模为序列标注任务：给每个 token 打一个标签（B-PER、I-PER、O 这类），标签序列解码出实体的边界和类型。

深度学习时代的标准结构是 BiLSTM 加条件随机场（Lample 与 Devine，NAACL 2016）：BiLSTM 负责上下文表征，CRF 负责标签之间的转移约束（比如 I-PER 不能直接跟在 B-LOC 后面）。BERT 一类的预训练模型出现后，结构简化为”预训练编码器加线性层加 CRF”，主流场景的 F1 能到 90% 以上。

工程上真正难的不是模型，是三件外围的事：领域实体（产品型号、零件编号、疾病名称不在通用预训练的视野里，要么加词典匹配、要么标注微调）；嵌套实体（”北京大学计算机系”里套着”北京大学”，扁平标注范式处理不了，需要嵌套 NER 的专门设计）；边界歧义（”长江大桥”是一个实体还是”长江”加”大桥”两个）。NER 的错误会沿着流水线向下游传播——实体找错了，后面的关系和消歧全部白做，所以构建流水线里它值得最先打磨。

大模型时代 NER 又有了新做法：把实体抽取改写成指令跟随任务（从文本里抽出所有机构名，输出 JSON），少量标注加提示就能到不错的水平，特别适合冷启动；生产上常见的组合是大模型初抽加人工修正，再把修正数据沉淀给小模型。

四、构建流水线之二：关系抽取与事件抽取

实体之间没有关系就成不了图。关系抽取的任务是判断两个实体之间存在什么关系——给定”姚明”和”休斯敦火箭”，输出”效力于”。

有监督关系抽取效果最好，前提是有标注数据。标注成本高，于是有远程监督（Mintz 等，ACL 2009）：用已有的知识图谱反向对齐文本——图里已有（姚明，效力于，休斯敦火箭），就找所有同时包含这两个实体的句子自动打上”效力于”标签。它解决标注成本的方式也埋了雷：对齐到的句子未必真的在表达这个关系（提到姚明和火箭的句子可能在说身高），噪声标注需要专门处理。

OpenIE 一线的信息抽取走的是另一条路：不预定关系类型，直接从句子里抽出（主语，关系短语，宾语）三元组，优点是完全开放、什么都抽，缺点是关系短语没法归一——“效力于””加入””签约”是三个不同的短语，指的可能是同一件事。

大模型时代关系抽取被改写成了指令任务，零样本和小样本能力都不错，尤其在 schema 复杂、类别多的场景。要留意的还是老问题：大模型会”顺理成章地补全”不存在的关系，验证环节不能省。

比关系抽取更上一层的事件抽取：不止抽取二元关系，还要识别”某时某地某人做了某事”这样的事件结构（触发词、论元角色）。金融风控里的担保链、供应链转移这类多主体场景，事件抽取是比关系抽取更贴切的工具。

五、构建流水线之三：实体消歧与实体链接

这是流水线里最容易被低估、也最见功力的一环。实体链接要解决的问题是：文本里提到的那个 mention，对应知识图谱里的哪个实体节点？

难在歧义无处不在，双向都有。一名多实（同名不同物）：文本里的”苹果”可能指公司、水果或电影；”华盛顿”可能是人、城市或州。多实一名（别名问题）：同一个实体有全称、简称、译名、绰号——“腾讯””腾讯控股””鹅厂”都指向一个节点，英文文本里”NYC”和”New York City”也是。

实体链接的流水线通常分三步：候选生成（用别名表、拼写纠错、检索把 mention 映射到一批候选实体）；消歧打分（对每个候选算一个分数——上下文相似度、流行度先验、与已链接实体的连贯性）；决策（取最高分或留给人工）。消歧打分的直觉是看上下文：”苹果发布了新手机”里出现”手机””发布会”，公司实体的得分就压过水果。

消歧错误的代价分布很不均匀。把用户的”苹果”链到水果，搜索结果只是不对；把一条”某公司法人变更”的信息链到同名的无关人员，风控图谱就多了一条假股权线。消歧的置信度阈值必须按业务的错误代价来定，低置信度的链接宁可悬空等人工确认，而不是自动进图。

消歧之后的知识融合还要处理属性冲突和模式对齐：同一实体在两个数据源里的出生日期不一致信谁；A 源的”法人”关系怎么对应 B 源的”legal representative”。多源融合的常规做法是给属性标可信级、保留出处（provenance）、冲突时按规则仲裁——答案不一定要唯一，但每条知识都要能说出”我从哪来”。

六、存储与查询

三元组存下来之后，用什么查、怎么查，决定了图谱好不好用。

一条路线是 RDF 与 SPARQL（W3C 标准）：数据是三元组集合，查询用 SPARQL 写图模式。它的优势是标准化、开放数据生态（Wikidata、DBpedia 都以 RDF 发布）、对分布式数据集成的支持；代价是工程生态相对小众，高性能查询需要对存储引擎的理解。

另一条路线是属性图与图数据库：Neo4j 是代表，节点和关系都可以挂属性，查询语言 Cypher 用 ASCII 箭头描述图模式（(a:Person)-[:WORKS_FOR]->(c:Company)），上手快，可视化工具成熟。生产里的领域图谱大量长在 Neo4j 或国产图数据库上。

选型的实用判断：数据已有关系数据库且查询以多表 JOIN 为主，深度在三四层以内，PostgreSQL 加递归查询往往够用；需要频繁变 schema、多跳遍历、图算法（最短路、社区发现），图数据库才体现出价值；要对接开放数据和语义网标准，选 RDF 栈。也有折中形态：关系数据库里用邻接表存边，配合递归 CTE 做遍历——规模不大时这是运维成本最低的方案。

七、表示学习与推理

图查得到”已有”的知识，推理要回答”没写出来”的知识。表示学习（知识图谱嵌入）的思路：把实体和关系都映射成低维向量，让”头实体加关系应该接近尾实体”在向量空间里成立。TransE（NeurIPS 2013）是开山之作——把关系建模为向量空间里的平移：如果（姚明，效力于，休斯敦火箭）成立，那么”姚明的向量 + 效力于的向量”应该落在”火箭的向量”附近。

后续十年沿着三个方向修补 TransE 的表达力：对称关系（”夫妻”关系正反等价）平移模型处理不好，ComplEx 一线引入复数空间、RotatE（ICLR 2019）把关系建模为复平面上的旋转，对称、反对称、互逆、组合这些关系模式都能表达

RotatE：把关系建模为复平面上的旋转

图源：Sun 等，RotatE: Knowledge Graph Embedding by Relational Rotation in Complex Space（ICLR 2019）论文原图；多关系图上的图神经网络（R-GCN 一线，ESWC 2018）让邻域信息直接参与实体表示；加上文本描述的联合训练（KG-BERT 一线）让模型”读过”实体的文字定义。

这类嵌入的直接用途是链接预测：给定头实体和关系，给所有尾实体打分排序，补全图谱里缺失的边。评估用 MRR（正确答案排名倒数的平均）与 Hits@k（排名前 k 内命中正确答案的比例）——它们回答的是”图谱缺的知识，模型能不能猜回来”，这和业务查询的准确率是两回事，报告时要分开。

八、知识图谱与大模型

大模型与知识图谱的互补关系是目前最清晰的一条线。大模型的知识编码在权重里：不可更新、不可溯源、会幻觉。知识图谱恰好相反：知识显式、可溯源、可增量更新，但表达受限、查询是刚性的。两个方向都在发生。

用图谱增强大模型：检索增强生成里，把知识图谱作为检索源——子图检索（从问题出发在图上走几跳，取回一个子图而不是几个孤立片段）、图增强的上下文组织（按图谱结构组织证据，而不是拍平的文本列表）。GraphRAG（预印本 2024）用社区摘要回答全局性问题——“这批文档主要在讲什么”这类没有单个片段能回答的问题，—
title: 知识图谱：三元组、构建流水线与大模型时代
date: 2026-10-27 09:30:00
tags:
- 知识图谱
- 实体识别
- 实体链接
- 图数据库
categories: 人工智能
summary: 知识图谱回答的是”谁和谁有什么关系”——把世界拆成实体和关系，存成图，再让机器查询和推理。难点从来不在存图，而在把混乱的自然语言变成干净的三元组：实体抽取、关系抽取、实体消歧，每一步都在跟歧义作战

把”姚明效力于休斯敦火箭”写成一条机器可查的数据，中间要跨过实体识别、关系抽取、实体消歧三道坎——每一道都在跟歧义作战。

一、知识图谱是什么

（姚明，效力于，休斯敦火箭）
（休斯敦火箭，位于，休斯敦）
（姚明，身高，2.26 米）

二、标志性工程与数据来源

通用的知识图谱大多从百科起家。

三、构建流水线之一：实体抽取

四、构建流水线之二：关系抽取与事件抽取

实体之间没有关系就成不了图。关系抽取的任务是判断两个实体之间存在什么关系——给定”姚明”和”休斯敦火箭”，输出”效力于”。

五、构建流水线之三：实体消歧与实体链接

这是流水线里最容易被低估、也最见功力的一环。实体链接要解决的问题是：文本里提到的那个 mention，对应知识图谱里的哪个实体节点？

六、存储与查询

三元组存下来之后，用什么查、怎么查，决定了图谱好不好用。

七、表示学习与推理

RotatE：把关系建模为复平面上的旋转

八、知识图谱与大模型

而今天很多系统里图谱参与 RAG 的实际形态是混合检索：先用向量检索从问题找到种子实体或片段，再沿图扩几跳把关联子图取回来——向量的语义召回负责”从哪进图”，图的遍历负责”把相关的结构带全”。纯向量、纯图遍历、混合三种形态的选择，取决于问题偏语义（开放问答）还是偏结构（多跳关系）。

GraphRAG：社区级摘要回答全局性问题的示意

GraphRAG：多跳查询的层次化组织

图源：Edge 等，From Local to Global: A Graph RAG Approach to Query-Focused Summarization（预印本 2024）论文原图图谱还有个隐性价值：给幻觉一个校验器——生成的答案先过一遍图谱核对实体与关系，不一致就拦下。

用大模型增强图谱：第三到五节的构建流水线（实体抽取、关系抽取、实体链接）如今都可以由大模型完成初版，人工只做修正——这反过来降低了构建领域图谱的门槛，让过去”标注成本撑不起”的图谱项目变得可行。

两者的边界也要说清：图谱不解决大模型的推理能力问题，大模型也不自动带来图谱需要的准确性。图谱提供经过治理的事实与关系结构，大模型提供语言理解与生成——把两者当成互补组件来设计，比争论”谁替代谁”有用得多。

九、应用

搜索与问答是最早也最广的落点：实体卡片、多跳问答（”姚明效力的球队的主场在哪个城市”要跨两跳）、对话里的实体跟踪。

金融风控是价值最硬的场景之一：股权穿透（往上找实际控制人）、担保圈识别（循环担保的环检测）、关联方挖掘。图谱的图结构在这里不是锦上添花——循环担保用 SQL 写多层自连接几乎不可维护，图上是一步遍历。这类图谱对关系准确率极度敏感，构建时的消歧阈值与人工审核流程就是核心工程。

医疗：疾病-症状-药品-检查的关联图谱支撑辅助诊断与用药审查，知识来源是指南与文献，对”每条知识带引用”的要求最严格。

推荐：把用户行为与物品属性图谱连接，用图路径解释”为什么推荐这个”——可解释性是图谱推荐相对向量召回的差异化优势。

共同点是：这些场景里图谱都承担”事实与关系的单一可信来源”角色，模型和检索都围着它转。图谱建得乱，上层的智能就无从谈起。

十、工程实践：工具链与代码

先设计 schema，再抽数据

抽三元组之前，先回答”图谱里允许存在什么”——本体（ontology）或 schema 设计。四个决策决定后面所有的返工率。

实体类型怎么定。从业务问题倒推，而不是从数据倒推：风控图谱要回答”实际控制人是谁”，就必须有”自然人/法人/股权”这些类型；问答图谱要回答”怎么配置”，类型就按文档章节走。类型清单要写文档（每个类型的定义、必填属性、与其他类型的关系），这份文档就是后面消歧的判定依据。

关系类型怎么定。每个关系要有方向约定（谁指向谁）与语义定义（”合作”太含糊，要拆成”供货””联合研发”这类可判定关系）。关系类型宜精不宜多——二十个定义清晰的关系，比一百个互相重叠的关系有用得多。

属性挂哪边。同样的信息可以做成属性（节点上的字段）或关系（连到另一个节点），判断标准是”这个信息要不要参与图遍历、要不要挂自己的属性”。会参与遍历的（公司到法人）做成关系；只是描述性的（公司到成立日期）做成属性。

要不要复用现成本体。通用领域有 schema.org、Wikidata 的属性体系可以借用；领域本体（FIBO 之于金融、SNOMED 之于医疗）起步参考结构即可，通常要按业务大幅裁剪。自建本体时，先在纸面用三个真实业务问题做”查询演练”——能用设计好的 schema 表达这三个问题，再动手建库；表达不出来就说明类型设计有缺口。

schema 一定会演化。做法是给 schema 记版本（类型与关系的增删改都留记录）、新增向后兼容（旧数据不改也能查）、废弃先标记后删除——和数据库的 schema 演化是同一套纪律。

工具链全景

环节	常用工具	说明
本体设计	Protégé	schema 先行的项目从这里起步，可视化编辑类与属性
实体抽取	DeepKE、OpenNRE、大模型指令抽取	DeepKE 覆盖 NER/关系/事件抽取，支持低资源场景
知识融合	Dedupe、大模型辅助对齐	实体去重与属性仲裁
存储	Neo4j、NebulaGraph、GraphDB、PostgreSQL 加 Apache AGE	按规模、查询语言与团队生态选
表示学习	PyKEEN、DGL-KE、LibKGE	训练 TransE、RotatE 一族的标准库
可视化	yEd、Gephi、Neo4j Bloom	中小规模图谱的人工检视

选型的主线就一条：先定查询语言，再定存储。团队写 Cypher 顺手就选属性图系，要对接开放数据与 W3C 标准就选 RDF 系——这个决定比具体用哪一家产品重要得多，迁移成本主要在查询语言上。

用 Neo4j 建图与查询

以第一节的三元组为例，Cypher 的建图与查询：

// 建实体与关系
CREATE (y:Person {name: '姚明'})
CREATE (r:Team {name: '休斯敦火箭'})
CREATE (y)-[:WORKS_FOR {since: 2002}]->(r);

// 多跳查询：姚明效力的球队所在联盟里的其他球队
MATCH (p:Person {name: '姚明'})-[:WORKS_FOR]->(t)-[:IN_LEAGUE]->(l)
      <-[:IN_LEAGUE]-(t2)
RETURN t2.name;

这种跨实体的遍历正是图谱相对关系数据库的甜区——同样的查询用 SQL 写多层自连接，每加一跳就多一层 JOIN，图上只是多写一段箭头。

真实业务问题的查询再具体一步——风控里”找出某公司经两层股权控制触及的全部实体，只看持股超过 20% 的路径”：

MATCH path = (a:Company {name: '某公司'})-[c:OWNS*1..2]->(b)
WHERE all(rel IN relationships(path) WHERE rel.share > 0.2)
RETURN b.name, [rel IN relationships(path) | rel.share] AS 持股链;

变长路径（*1..2）、路径级过滤（all）、按业务字段聚合——这类查询是图谱在风控场景里的日常。

用 PyKEEN 训练一个知识图谱嵌入

表示学习的标准库是 PyKEEN，内置数据集、模型与评测，十几行跑通 TransE：

from pykeen.pipeline import pipeline

result = pipeline(
    dataset='Nations',          # 内置小数据集（国家关系），几分钟跑完
    model='TransE',
    training_loop='SLCWA',
    epochs=200,
)
print(result.get_metric('hits@10'))
print(result.get_metric('mean_reciprocal_rank'))

换 RotatE 只改 model 参数，其余不动——这也是同一批嵌入模型被标准化评测的前提。真实项目把 dataset 换成自己的三元组文件（CSV：头实体、关系、尾实体三列），训练前先按第七节的 MRR 与 Hits@k 定出基线。

用大模型做抽取的落地写法

第三到五节的流水线，今天最省力的做法是把抽取交给大模型，但要给足约束。提示词的骨架是”schema 在前、文本在后、输出 JSON”：

从下面的文本中抽取三元组。
实体类型限定为：人物、球队、联盟、城市。
关系类型限定为：效力于、位于、加盟。
文本里没有的信息不要输出，输出 JSON 数组，
每个元素为 {"head": "", "relation": "", "tail": ""}。

文本：姚明在 2002 年以状元身份加入 NBA 的休斯敦火箭队。

拿到输出后必须做三道校验，缺一不可：

schema 校验：头尾实体的类型、关系的名称是否都在限定清单里——大模型会即兴发明关系名
锚定校验：头尾实体是否真的在原文里出现过（防”合理但不存在”的补全）
置信度分级：低置信度的进人工队列，而不是直接进图

三道校验之后的三元组再走第五节的消歧与链接流程，落到图数据库里。这套”大模型初抽、规则校验、人工兜底”的分层，是当前构建领域图谱性价比最高的方式。

上线之后

图谱的更新管道沿用 CDC 的思路：业务库的增删改事件驱动图谱的增量更新，按内容哈希幂等。图谱的 schema 也需要版本管理——关系类型的新增、废弃都要记录，否则下游查询会悄悄失效。权限做到属性级（哪个角色能看到哪些节点的哪些属性），比整库开关更贴近业务，但也要求查询层的每个入口都接入同一套权限判定。

本体设计与 schema 演化

抽三元组之前，先回答”图谱里允许存在什么”——这就是本体（ontology）或 schema 设计。四个决策决定了后面所有的返工率。

属性挂哪边。同样的信息可以做成属性（节点上的字段）或关系（连到另一个节点），判断标准是”这个信息要不要参与图遍历、要不要挂自己的属性”。会参与遍历的（公司→法人）做成关系；只是描述性的（公司→成立日期）做成属性。

图谱质量怎么量

“图谱建得好不好”要有可操作的度量，上线前与上线后都定期跑一遍：

维度	指标	健康信号
消歧准确率	抽样人工核对的链接正确比例	生产级要求 95% 以上，低于就收紧阈值
关系抽取质量	抽样 P/R 按关系类型拆开看	哪类关系低修哪类的数据
schema 覆盖率	实体都有合法类型的比例	接近 100%，有缺口就补类型定义
孤立节点占比	没有任何边的节点	占比高说明抽取漏了关系或数据源没对齐
属性完整率	必填属性的非空比例	按属性逐个看，缺得多的回头改抽取模板
冲突率	多源属性互相矛盾的比例	升高说明数据源质量或仲裁规则出了问题

这张表建议做成流水线的一部分：每次批量入库后自动重算，数字变差就是流水线某环节退化的信号——比等用户投诉再排查早得多。

十一、常见误解

“知识图谱就是把数据存成图。” 存图是最简单的部分。实体消歧、知识融合、质量控制这些让”存进来的每条知识可信”的工程，才是知识图谱的主要成本。

“大模型时代不需要知识图谱了。” 大模型的语言能力和图谱的结构化事实是互补的：一个会说不准，一个准但表达受限。需要溯源、需要增量更新、需要精确关系的场景，图谱不但没被替代，反而因为大模型降低了构建成本而更容易落地。

“实体消歧就是实体链接的同义词。” 链接是完整的流水线（候选生成、消歧、确认），消歧只是其中的打分环节。工程里候选生成漏了正确答案，消歧做得再好也没用。

“有了大模型，抽取就不用标注了。” 大模型把冷启动成本降了一个量级，但领域实体、精确 schema 的生产级抽取，仍然需要标注数据做微调和评测；大模型的输出同样需要验证。

“图谱推理能发现新知识。” 嵌入模型的链接预测是给缺失边打分排序，它的输出是假设，不是事实；进图谱前必须有人工或业务规则的确认。把预测分数当成已验证知识，是图谱质量崩坏的常见起点。

参考

1705.02488 — Knowledge Graphs（Hogan 等，知识图谱系统性综述）— ACM Computing Surveys 2021
10.1145/1376616.1376746 — Freebase: A Collaboratively Created Graph Database for Structuring Human Knowledge — SIGMOD 2008（CCF-A）
DBpedia — DBpedia: A Nucleus for a Web of Open Data — ISWC 2007
10.1145/1242572.1242667 — YAGO: A Core of Semantic Knowledge — WWW 2007
Wikidata — Wikidata: A Free Collaborative Knowledgebase — CACM 2014
1301.3780 — Translating Embeddings for Modeling Multi-relational Data（TransE）— NeurIPS 2013（CCF-A）
1902.10197 — RotatE: Knowledge Graph Embedding by Relational Rotation in Complex Space — ICLR 2019
tkipf/relational-gcn — Modeling Relational Data using Graph Convolutional Networks（R-GCN）— ESWC 2018
1603.01360 — Neural Architectures for Named Entity Recognition（BiLSTM-CRF）— NAACL 2016
P09-1013 — Distant Supervision for Relation Extraction without Labeled Data — ACL 2009（CCF-A）
1911.03814 — Scalable Zero-shot Entity Linking with Dense Entity Retrieval（BLINK）— EMNLP 2020
2404.16130 — From Local to Global: A Graph RAG Approach to Query-Focused Summarization — 预印本 2024
1909.03136 — KG-BERT: BERT for Knowledge Graph Completion — 预印本 2019
things not strings — Google 官方博客：Introducing the Knowledge Graph — 2012
Neo4j 文档 — 属性图模型与 Cypher 查询语言
SPARQL 1.1 规范 — W3C 标准