知识图谱是什么：实体、关系与三元组

知识图谱是一种用「图」来组织知识的方式：把现实世界中的事物抽象成节点（实体），把事物之间的联系抽象成边（关系），形成一张可以沿着关系跳转的网。最基本的单元是三元组——「主实体、关系、客实体」，比如（阿里云，旗下产品，通义千问）。一张知识图谱就是海量三元组的集合，而它的价值在于「连接」：两个实体之间可能隔着好几跳关系，用图查询就能把它们串起来。

为什么不用关系数据库存这些？关系表适合「字段固定、行数多」的数据，而图谱天然是「实体可变、关系稀疏」的——每个实体拥有的关系类型和数量都不一样，用表存要么大量空列，要么拆得支离破碎。图数据库按「节点 + 关系」存储，查询沿边遍历，多跳关联查询的表达和性能都远好于 SQL 的多次 JOIN。知识图谱的应用从搜索引擎的知识面板，到企业里的智能问答、风控反欺诈、供应链分析，本质都是「沿着关系找答案」。

知识图谱的核心不是「存了很多实体」，而是「实体之间的连接可以被查询、被推理、被补全」。
本文核心知识点
  • 三元组（实体、关系、实体）是图谱最小的知识单元。
  • 抽取从非结构化文本中用 LLM 抽取实体与关系，是构建主路径。
  • 建模本体设计、实体消歧与合并决定图谱的质量上限。
  • 存储查询Neo4j + Cypher 是多跳关联查询的工程基座。
知识图谱配图：中央核心节点向外辐射连线连接多个彩色节点，左侧文档与放大镜，右侧环形更新箭头，蓝色渐变扁平风格
知识图谱的示意：实体是节点，关系是边，查询沿边跳转。

实体识别与关系抽取：从标注数据到 LLM 抽取

图谱构建的第一步是把非结构化文本变成三元组。传统做法是 NER（命名实体识别）+ 关系分类：先用模型把「阿里云」「通义千问」这样的实体标出来，再判断实体之间是什么关系。这条路需要大量标注数据、且每个领域都要重新训练，成本高、迭代慢。现在的主流做法是用 LLM 做「端到端抽取」：把文本和抽取规则一起给模型，让它直接输出结构化的三元组。

LLM 抽取的关键是定义好「抽取 schema」：要抽哪些类型的实体（公司、产品、人物、技术…）、哪些关系（旗下产品、成立于、位于…）、每个三元组的属性（时间、置信度、来源文本）。schema 定得越清楚，输出越规整。抽取时建议让模型先输出 JSON 再校验，而不是自由文本；一次处理一段文本而不是全文，避免漏抽和上下文混乱。抽取完成后要记录「来源」——每个三元组来自哪句话，这对后面的溯源和质量控制非常重要。

# LLM 三元组抽取（伪代码）
# 1. 定义 schema：实体类型与关系类型白名单
# 2. 对每段文本调用 LLM，要求输出 JSON 三元组列表
# 3. 校验：实体/关系必须在 schema 内，缺失字段补默认值
# 4. 给每个三元组附加来源文本与抽取置信度
# 5. 失败重试：JSON 解析失败时让模型按示例重新输出
{"triples": [
  {"head": "阿里云", "type": "公司", "rel": "旗下产品", "tail": "通义千问", "source": "第 3 段"},
  {"head": "通义千问", "type": "产品", "rel": "基于", "tail": "大模型", "source": "第 5 段"}
]}

图谱建模：本体设计与消歧合并

抽取出来的三元组是一堆散件，直接入库会乱。建图之前先做「本体设计」：定好实体类型层级（比如「公司」是「组织」的子类）、关系类型及方向、属性的类型约束（时间是日期、金额是数字）。本体设计决定图谱能回答什么问题——设计得细，查询就灵活；设计得过粗，后面想查细分维度就得返工。新手常见的错误是「把属性当实体」：比如把「成立年份」当成一个节点，应该做成年份属性挂在公司节点上。

然后是消歧与合并，这是图谱工程里最容易被低估的一环。同一个实体可能有多种写法：「阿里云」「阿里云计算有限公司」「Aliyun」，指的都是同一个实体；不同来源还可能给同一实体不同的属性值。做法是给实体建「规范名 + 别名」映射，按名称相似度、属性相似度、上下文共现做聚类合并，合并时保留高置信度来源的属性、记录合并证据。消歧做不好，图谱里全是重复节点，多跳查询会漏路径——这是图谱「看起来建好了，一查就废」的头号原因。

# 实体消歧合并（伪代码）
# 1. 候选生成：名称归一化 + 模糊匹配 + 别名表召回候选
# 2. 判定：名称相似度 / 属性相似度 / 共现上下文加权打分
# 3. 超过阈值则合并：保留规范名，别名并入，属性取高置信度来源
# 4. 冲突属性（如两个不同成立年份）标记为待人工确认
# 5. 记录合并证据，支持审计与回滚

存储与查询：Neo4j 与 Cypher 入门

图谱建好之后要落到图数据库里。Neo4j 是最常用的选择：节点和关系都支持属性，Cypher 查询语言直观好上手。建库的基本操作是 CREATE 节点、MERGE 关系（存在则复用，避免重复）。查询的核心是 MATCH 模式匹配：描述「沿着哪类关系从哪类节点走到哪类节点」，引擎自动沿边遍历。多跳查询是图谱相对关系数据库最大的优势场景：比如「找出与通义千问同属阿里云旗下、且成立于 2015 年后的所有产品」，一条 Cypher 就写出来。

实际项目里还要注意几个工程细节：批量导入用 LOAD CSV 或驱动批量 API，别一条条 CREATE；给高频查询的标签和关系建索引；实体和关系的属性里存规范名、来源、时间戳，方便审计；图谱规模大时考虑分片或迁移到分布式图数据库。下面是一段建图与查询的 Cypher 示例。

// 建图（节选）
MERGE (a:Company {name: "阿里云"})
MERGE (p:Product {name: "通义千问"})
MERGE (a)-[:HAS_PRODUCT {since: 2023}]->(p)

// 多跳查询：阿里云旗下产品中，与技术“大模型”相关且成立晚于 2020 的
MATCH (c:Company {name: "阿里云"})-[:HAS_PRODUCT]->(prod:Product)
WHERE prod.founded_year > 2020
  AND (prod)-[:RELATED_TO]->(:Tech {name: "大模型"})
RETURN prod.name

图谱更新与质量校验

图谱不是一次建完就完事的资产，它需要持续更新。更新有两类：增量更新——新文档进来，抽取出的新三元组与已有图谱合并；批量重建——数据源大规模变化时，局部子图重建后替换。增量合并时要复用消歧逻辑：新实体会不会和已有节点重复？新关系会不会和已有关系冲突？属性更新要保留版本信息，避免「改坏了回不去」。

质量校验贯穿构建全程，常见指标有四类。一是完整性：覆盖了多少源文档、抽取覆盖率。二是准确性：抽样人工核对三元组正确率。三是一致性：同一个实体的属性是否互相矛盾（比如两个不同的成立年份），关系方向是否统一。四是连通性：孤立节点占比、图谱平均路径长度——孤立节点太多说明抽取或消歧有问题。校验要形成自动化流水线 + 抽样人工复核的组合，而不是上线前一次性检查。

知识图谱的质量问题大多是「构建时欠的债」：本体没设计好、消歧没做透，上线后越用越乱。