知识图谱

01

把事实当作一张图

表示方式的转变正是全部的重点。在一张表里，「Acme 公司总部在阿德莱德」是某一行里的一个单元格； 它与「阿德莱德在南澳」之间的连接住在另一张表里，把它们绑在一起意味着一次连接。在一个知识 图谱里，Acme、阿德莱德、南澳全都是节点，由带标签的边直接相连——而从 一家公司沿链条走到它所在的州，不过是走两条边。关系是一等公民的数据，而不是你按需重建的东西。

02

三元组：知识的原子

基本单位是三元组：一个单一的事实，表达为主语 → 谓语 → 宾语。 「Acme → headquartered_in → 阿德莱德。」「阿德莱德 → located_in → 南澳。」「Jane → works_for → Acme。」每个三元组都是两个节点之间的一条边，而一整张知识图谱不过是这些三元组的一大堆—— 数百万乃至数十亿个——编织成一张相互连接的网。

这就是 Wikidata 存储维基百科背后结构化知识的方式，也是谷歌的知识图谱驱动其搜索结果旁那些事实框的方式。三元组很简单，但在规模上它表达力惊人。

03

本体：约定的词汇表

只有当所有人都同意实体和关系类型是什么意思时，一堆三元组才是连贯的。那个约定的词汇表 就是本体（或模式）：它定义了事物的类别（人、组织、地点）以及它们之间有效的关系 （一个人可以 work_for 一个组织；一个组织可以 headquartered_in 一个地点）。 漂亮的说法是：数据 + 一个本体 = 一个知识图谱——本体正是那个告诉机器每个节点和 边实际上是什么的东西，把图从一团字符串提升为一个有意义的结构。

本体也是让你能统一异构来源的东西：把两个不同的数据库映射到同一个共享的词汇表 上，它们的事实就合并成一张相互连接的图，即便它们原本用不同的名字称呼同一样东西。

04

构建图谱：困难的部分

从真实而杂乱的来源构建一个知识图谱，正是真正的困难所在，而它倚靠本板块各处的工具：

• 实体与关系抽取——从非结构化文本里抽出结构化的三元组（一份说「Jane 加入了 Acme」 的报告 → 那个 works_for 三元组）。这是一个NLP 任务，越来越多地用LLM 来做。
• 实体消解——关键所在。「J. Smith」「Jane Smith」和「Smith, J.」可能是一个人、也 可能是三个，而图的好坏只取决于它判断这个的能力。把这个弄错，会把一个实体碎裂成 许多个、或把不同的实体混为一谈——与数据准备页同样的记录链接问题，只是赌注 更高，因为错误会腐蚀整个相互连接的结构。

把抽取与消解做对，图就强大；做错，它就自信地误导人。构建的成本——以及保持它准确——是核心的 实际挑战。

05

查询：表回答不了的问题

回报在于那些查询。图查询语言（用于 RDF 图的 SPARQL、用于属性图的 Cypher）让你能 问那些遍历关系的多跳问题——正是表所吃力的那些问题。「Jane 工作过的那些公司的 供应商里，有哪些设在海外？」是一次自然的图遍历（Jane → 公司 → 它们的供应商 → 按地点过滤），但 在 SQL 里却是一场连接的噩梦。

这才是去拿一个知识图谱的真正理由：当连接本身就是那个问题时。在许多关系上找出链条、 路径、以及间接的链接，正是这个结构所为之而建的——也是网络分析的那些度量（中心性、社区、链接预测）随后可以叠加在上面的地方。

06

知识图谱 + LLM：GraphRAG

知识图谱最新的角色，是为大语言模型提供 锚定。普通的 RAG 取回文本段落，而GraphRAG 从一个知识图谱里取回结构化的事实及其连接，喂给 LLM。因为那些 事实是明确的、带类型的、可追溯的，这能大幅减少幻觉、并回答 LLM 否则会糊弄过去的多跳 问题——图提供可验证的结构，LLM 在其上提供流畅的语言。它是一个迅速兴起的模式，恰恰因为它把每个 系统的长处，去对上另一个的短处。

07

诚实的代价

知识图谱很强大，但远非免费：

08

它在我工作中的体现

09

60 秒回顾

三元组/本体的基础、对实体消解的强调、SPARQL 查询，以及兴起中的 GraphRAG 模式，反映了当前的 知识图谱参考文献以及亲身的实体链接工作。