初识知识图谱：让机器读懂世界的新方式

你有没有过这样的经历：在搜索引擎里输入“周杰伦的妻子生日”，按下回车后，页面最上方不再是一排排需要你自己点进去筛选的网页链接，而是一张清晰的卡片，直接告诉你答案是1993年8月12日，甚至卡片下方还附带了昆凌的代表作品、与周杰伦的相识历程等相关信息？又或者你在使用导航软件时，输入“故宫”，得到的不只是路线，还有开放时间、门票价格、历史介绍、周边景点推荐，甚至实时的人流密度提示？这些看似平常的功能背后，都藏着同一个核心技术——知识图谱。

很多人第一次听到“知识图谱”这个名字，会觉得它是个高大上的学术名词，离普通人的生活很远。但实际上，你每天用的搜索、推荐、智能客服、导航，背后都有它的身影。它就像是为机器搭建的一张“世界知识地图”，让原本只能靠关键词匹配理解信息的机器，第一次有了接近人类的认知能力：不仅能识别信息，还能理解信息之间的关联，甚至能推理出你没直接问但隐含需要的信息。

一、到底什么是知识图谱？拆解两个词就懂了

要理解知识图谱，我们可以把它拆成“知识”和“图谱”两个部分来理解。

首先是“知识”。我们这里说的知识，不是随便的网络信息、碎片化内容，而是经过验证的、具有明确逻辑关联的确定性事实。比如“周杰伦出生于1979年1月18日”“昆凌是周杰伦的妻子”“故宫位于北京市东城区”“红烧肉的主要食材是五花肉和冰糖”，这些不是观点、不是猜测，是被广泛认可的事实，就是知识图谱要存储的核心内容。

然后是“图谱”。顾名思义，就是把这些知识按照关联关系像地图一样排列起来，而不是散乱地堆在一起。比如我们知道“周杰伦”和“昆凌”是夫妻关系，“昆凌”和“1993年8月12日”是出生日期关系，“周杰伦”和《晴天》是代表作关系，《晴天》又和《叶惠美》专辑是所属关系——这些关联就像地图上的道路，把一个个零散的知识点连成了一张网，机器 traversing 这张网的时候，就能快速找到相关联的信息。

这张知识网的最小单元，叫做三元组，也就是“头实体-关系-尾实体”的结构。你可以把它理解为知识世界的“乐高积木”，无数个三元组拼起来，就是一张庞大的知识图谱。我们拿日常熟悉的例子来拆解三元组：

• 头实体：周杰伦，关系：妻子，尾实体：昆凌
• 头实体：昆凌，关系：出生日期，尾实体：1993年8月12日
• 头实体：故宫，关系：位于，尾实体：北京市
• 头实体：红烧肉，关系：主要食材，尾实体：五花肉
• 头实体：红烧肉，关系：主要食材，尾实体：冰糖

这里的“实体”就是知识图谱里的核心对象，可以是具体的人、地点、物品，也可以是抽象的概念、事件、作品；“关系”就是实体之间的关联，比如“出生于”“位于”“的妻子”“的主要食材”等；“属性”可以理解为实体和值之间的特殊关系，比如“周杰伦”的“身高”是175cm，“故宫”的“门票价格”是旺季60元/人。

```json [ { "头实体": "周杰伦", "关系": "妻子", "尾实体": "昆凌" }, { "头实体": "昆凌", "关系": "出生日期", "尾实体": "1993年8月12日" }, { "头实体": "周杰伦", "关系": "代表作", "尾实体": "晴天" }, { "头实体": "晴天", "关系": "所属专辑", "尾实体": "叶惠美" } ] ``` *（以上是JSON格式的三元组示例，也是知识图谱最常用的存储格式之一）*

除了实体、关系、属性这三个核心组成部分，知识图谱还有一个前置的规划层，叫做Schema（模式层），相当于知识图谱的“骨架”，预先定义了可以存储哪些类型的实体、哪些类型的关系、哪些类型的属性，避免知识混乱。比如你建一个美食知识图谱，Schema里可以定义实体类型有“菜品”“食材”“厨师”，关系类型有“的主要食材”“的发明者”“的流行地区”，属性类型有“口味”“烹饪时长”“难度”，所有录入的知识都要符合这个骨架的规则，保证知识的规范性。

> 【电子版侧边栏·互动体验】 > 你可以现在就打开搜索引擎，尝试搜索以下三个问题，观察搜索结果页面的顶部是否出现了直接回答的卡片，这就是知识图谱在发挥作用： > 1. 姚明的女儿叫什么名字？ > 2. 2024年巴黎奥运会首金得主是谁？ > 3. 红烧肉的主要食材有哪些？ > 如果出现了卡片式答案，说明你正在使用知识图谱的能力；如果出来的还是网页链接，说明你使用的搜索引擎还没有覆盖对应的知识。

二、知识图谱和传统技术有什么不一样？

很多人会把知识图谱和传统数据库、百科词条混淆，其实三者的核心定位和技术逻辑完全不同，我们可以通过对比来直观理解。

1. 和传统关系型数据库的差异

传统的关系型数据库（比如MySQL、Oracle）是我们最常用的数据存储工具，它的核心是“表结构”：你要存什么数据，就得提前定义好表的字段，比如要存明星信息，就得建一张“明星表”，字段包括姓名、生日、代表作、身高，要存配偶信息，就得建一张“配偶表”，字段包括明星ID、配偶ID、结婚时间。两张表通过“ID”关联起来，才能查到“周杰伦的妻子是谁”这样的信息。

这种方式的优势是存储和查询效率高，适合存储结构固定的业务数据，但灵活性非常差：如果你想查“周杰伦的妻子的出生日期”，就需要同时关联“明星表”“配偶表”“人员信息表”三张表，写复杂的SQL查询语句；如果你想加一个“周杰伦的母校”的字段，就得修改表结构，重新设计数据库；更麻烦的是，如果你要查“周杰伦的妻子的丈夫是谁”这种反向关联，传统数据库几乎没法直接实现，需要额外的逻辑处理。

而知识图谱是无模式（schema-less）的，只要符合三元组的规则，你可以随时加任何实体、关系、属性，不需要提前预定义结构。比如你要加“周杰伦的母校是淡江中学”这个知识，只要新增一个三元组`周杰伦-母校-淡江中学`就行，不需要修改任何底层结构；你要查“周杰伦的妻子的丈夫是谁”，只要沿着“周杰伦→妻子→昆凌→丈夫→周杰伦”的路径 traversing 图谱就能得到答案，不需要写复杂的关联查询。

举个更直观的例子，用传统SQL查询“周杰伦的妻子的出生日期”，需要写这样的语句： ```sql SELECT s.name, p.birthday FROM star s JOIN spouse sp ON s.id = sp.star_id JOIN person p ON sp.spouse_id = p.id WHERE s.name = '周杰伦'; ``` 而用知识图谱的查询语言（SPARQL），只需要写： ```sparql SELECT ?birthday WHERE { <周杰伦> <妻子> ?spouse . ?spouse <出生日期> ?birthday . } ``` 不仅语句更简洁，而且不需要预先知道数据存在哪些表里，只要三元组存在就能查到，灵活性高得多。

2. 和百科词条的差异

很多人会把知识图谱和百度百科、维基百科搞混，毕竟两者都存储了大量的常识知识。但两者的核心差异是结构化程度：百科词条是典型的非结构化文本，比如维基百科里“周杰伦”的词条是一大段几千字的文字，里面提到了他的生日、妻子、代表作、出道经历等信息，但这些都是混在段落里的，机器要提取这些信息，需要做非常复杂的自然语言处理（NLP）：首先要识别出哪些是实体（周杰伦、昆凌、《晴天》），然后识别出实体之间的关系（妻子、代表作），还要处理歧义（比如“晴天”既是周杰伦的歌名，也是天气现象），整个过程出错率很高，而且成本极高。

而知识图谱存储的是结构化的三元组，机器一看到`<周杰伦> <妻子> <昆凌>`这个三元组，立刻就能知道“周杰伦”和“昆凌”是夫妻关系，不需要任何额外的解析，可读性和可用性高得多。你可以把百科词条理解为“知识的原文”，而知识图谱是“知识的卡片索引”，机器不需要读完整篇文章，只要查索引就能得到需要的信息。

为了更清晰地对比三者的差异，我们可以看下面的表格： | 对比维度 | 传统关系型数据库 | 百科词条（如维基百科） | 知识图谱 | |---------|----------------|----------------------|---------| | 数据形态 | 结构化，预定义表结构 | 非结构化文本 | 半结构化，三元组形式 | | 关联能力 | 需要预先定义表关联，灵活性差 | 无显式关联，依赖人工阅读理解 | 显式关联实体，可灵活扩展 | | 机器可读性 | 高，但需写SQL查询 | 低，需复杂NLP解析 | 极高，可直接语义查询 | | 知识覆盖 | 仅覆盖预定义的业务数据 | 覆盖广泛但无结构化关联 | 可覆盖通用或领域知识，关联清晰 | | 适用场景 | 企业内部业务数据存储 | 人类阅读的知识查阅 | 机器可理解的知识推理与应用 |

###

很多人会问：既然知识图谱这么好，是不是要取代传统数据库和百科词条？其实完全不是——三者是互补关系，而非替代关系。企业的日常业务数据（比如订单、用户信息、交易记录）存在关系型数据库里，查询效率最高；百科词条是知识图谱最重要的非结构化数据来源，知识图谱相当于把百科里的碎片化知识提取成结构化三元组，方便机器使用；而知识图谱的查询结果又可以反过来丰富百科词条的内容，三者是互相促进的关系，而非谁取代谁。

理解了知识图谱的定位，我们再来看看它在实际场景中到底能发挥什么作用。2012年5月，谷歌正式推出全球首个大规模商用的知识图谱产品，这是知识图谱从学术研究走向大众应用的重要里程碑。当时谷歌知识图谱已经包含了超过5亿个实体、35亿条关系，数据来源包括谷歌2010年收购的公开知识库Freebase、维基百科、美国中央情报局公开的《世界概况》数据集，以及数十年积累的用户搜索行为数据^[1]。举个具体的例子：如果你在谷歌搜索“埃隆·马斯克（Elon Musk）”，页面右侧会出现一张结构化的知识卡片，上面不仅列出了他的出生日期、净资产、国籍、教育背景等基础属性，还会自动关联到他创立的公司（特斯拉、SpaceX、X）、关联人物（前妻贾斯汀·马斯克、合伙人杰夫·贝佐斯）、关联事件（收购推特、星舰试飞），甚至可以直接回答“埃隆·马斯克有多少家公司？”“埃隆·马斯克和比尔·盖茨谁更富有？”这类跨实体的关联问题——这些都是传统搜索引擎永远做不到的，传统搜索引擎只能返回包含这些信息的网页链接，需要用户自己点进去筛选、比对信息。

> 【电子版侧边栏·互动体验】 > 你可以尝试在搜索引擎里搜索以下问题，观察结果页是否出现了直接回答的结构化卡片： > 1. 李白是哪个朝代的诗人？ > 2. 2022年北京冬奥会的首金得主是谁？ > 3. 《流浪地球2》的导演是谁？ > 如果出现了直接答案，说明你正在使用知识图谱的能力；如果出来的还是网页链接，说明你使用的搜索引擎还没有覆盖对应的知识。

国内的百度是最早将知识图谱大规模落地应用的互联网公司，2014年百度正式推出国内首个商用知识图谱，最初主要用于优化搜索体验，现在已经覆盖了超过10亿个实体、数百亿条关系，每天响应超过百亿次的查询请求。对普通用户来说，最直观的感受就是搜索“事实类问题”时，不再需要翻N个网页找答案：比如搜索“刘德华的籍贯”，页面顶部会直接告诉你答案是广东江门，同时还会关联到他的出生日期、代表作品、家庭成员、主要成就等信息；如果你问“刘德华的女儿叫什么？”，知识图谱会沿着“刘德华→妻子→朱丽倩→女儿→刘向蕙”的关联路径直接给出答案，不需要你点进任何网页。除了消费级的搜索应用，百度的知识图谱还深度应用于Apollo自动驾驶平台：自动驾驶汽车需要识别道路上的车辆、行人、交通标志、红绿灯等实体，知识图谱则为这些实体提供了预定义的属性和关联规则——比如看到“限速60”的交通标志，知识图谱会告诉汽车“当前路段最高行驶速度为60km/h”；看到“前方有人行横道”的标志，会提示“注意减速避让行人”，相当于给自动驾驶汽车装了一张“道路常识地图”。

三、为什么机器需要知识图谱？它解决了什么核心痛点？

要理解知识图谱的核心价值，我们首先要明白：在知识图谱出现之前，机器对世界的理解非常“浅”，甚至可以用“傻”来形容。比如你问一个传统搜索引擎“苹果多少钱一斤？”，它会返回所有包含“苹果”和“多少钱”的网页，包括卖水果的、卖手机的、甚至讲苹果公司股票的，因为它根本不知道“苹果”到底是指水果还是手机，也不知道“多少钱”是指零售价格还是公司市值——这种“关键词匹配”的方式，本质上是把理解的工作完全推给了用户，用户需要自己筛选信息，效率极低。

而知识图谱的核心价值，就是给机器提供了一张结构化的世界知识地图，让机器第一次有了接近人类的“常识理解能力”，具体可以归纳为三点：

1. 解决语义歧义，让机器真正“读懂”用户的意思

人类交流时很少会有歧义，是因为我们大脑里存了大量的常识：比如你刚和朋友聊完“昨天买的苹果手机卡顿”，再问“苹果怎么解决卡顿？”，朋友立刻知道你说的是苹果手机，而不是水果。但机器没有这些常识，所以需要知识图谱来给它提供背景知识：如果知识图谱里存储了“苹果-类型-粮食”“苹果-类型-科技公司”两个三元组，机器就会结合上下文判断：如果你前面刚搜了“大米”“白面”，那你要的是粮食苹果；如果你前面刚搜了“华为”“iPhone”，那你要的是苹果手机。这种语义理解的能力，是传统关键词匹配永远做不到的。

2. 实现关联推理，让机器能“举一反三”

人类最核心的认知能力之一就是推理：比如你知道“苏轼是北宋的诗人”“北宋1127年灭亡”“苏轼1037年出生”，别人问你“苏轼活了多少岁？”，你不需要去查资料，直接计算1127-1037就能得到答案。传统数据库要实现这种推理，需要写复杂的SQL语句关联多张表，而知识图谱天生就是关联的，只要三元组存在，机器就能沿着关联路径自动推理。比如你问“周杰伦的妻子的丈夫的代表作有哪些？”，机器不需要你直接问“周杰伦的代表作”，只要沿着“周杰伦→妻子→昆凌→丈夫→周杰伦→代表作”的路径遍历图谱，就能直接得到《晴天》《七里香》《稻香》等答案，这种跨实体的关联推理能力，是知识图谱最核心的价值之一。

3. 统一知识表示，降低不同系统之间的沟通成本

现在很多企业都有多个业务系统：搜索系统、推荐系统、客服系统、数据分析系统，以前每个系统都有自己的关键词库，搜索系统里的“苹果”和推荐系统里的“苹果”可能不是同一个意思，经常出现“你搜了苹果手机，客服给你推荐苹果水果”的乌龙。现在用统一的知识图谱作为底层知识库，所有系统都调用同一个知识库，就不会出现这类问题，而且新增业务系统时不需要重新搭建知识库，直接调用知识图谱就行，大幅降低了企业的IT成本。

四、知识图谱也不是万能的：它的局限性你了解吗？

作为一本面向普通读者的科普书，我们不能只讲知识图谱的好处，也要客观讲清楚它的局限性，避免你对这门技术产生不切实际的期待。目前知识图谱的核心痛点主要有三个：

1. 构建和维护成本极高

知识图谱的构建不是一劳永逸的，需要经历“知识抽取→知识融合→知识推理→质量审核”多个环节：首先要从百科、网页、数据库等不同来源抽取知识，然后要把不同来源的知识融合（比如维基百科说周杰伦的妻子是昆凌，百度百科也说是昆凌，就确认这个三元组是正确的；如果某个小网站写错了，就要排除），然后还要用推理规则补全缺失的知识，最后还要有人工审核避免错误。尤其是医疗、法律、金融这类对准确性要求极高的垂直领域，一条错误的知识可能导致严重的后果，所以知识图谱的更新速度很慢，通常以周甚至月为单位更新，无法实时反映新出现的信息——比如刚出炉的奥运会冠军，可能几天后才能查到对应的知识。

2. 知识覆盖度有限

目前主流的知识图谱主要覆盖通用常识和热门领域，冷门领域的知识覆盖度极低。比如你问“清代道光年间广西桂林府临桂县的一位名叫李明德的县令的生平”，大概率不会在任何通用知识图谱里找到答案，因为这类冷门知识没有商业价值，不会有人专门去录入。根据公开数据，目前全球最大的知识图谱（谷歌知识图谱）的实体覆盖度也不到人类常识的10%，大部分细分领域的知识都还没有被结构化。

3. 歧义和错误难以完全避免

虽然知识图谱的Schema层可以预先定义实体类型来减少歧义，但公开数据源里本身存在的错误、不同数据源之间的矛盾，都可能导致知识图谱里的错误。比如很多小网站会把某位明星的生日写错，如果知识图谱的审核规则不够严格，就会把错误的信息录入进去，导致搜索出来的答案是错的。另外，很多抽象概念、主观观点也很难用三元组的形式表示，比如“红烧肉好不好吃？”这种问题，知识图谱就无法回答，因为它存储的是事实，而不是观点。

> 【电子版侧边栏·常见疑问解答】 > 很多人会问：现在大模型这么火，是不是知识图谱要被淘汰了？ > 其实恰恰相反，大模型的知识是“隐式”存储在神经网络参数里的，容易出现“幻觉”问题（比如编造不存在的事实），而知识图谱的知识是“显式”存储的，准确率更高，两者结合是未来的主流方向——大模型负责自然语言理解和生成，知识图谱负责提供准确的 factual 知识，既解决大模型的幻觉问题，又解决知识图谱的灵活性不足问题，我们会在第8章详细讲解这种“知识增强大模型”的技术方案。

五、普通人也能用到的知识图谱应用

很多人觉得知识图谱是互联网公司的技术，和自己没关系，其实你每天的生活都在和知识图谱打交道，只是你没注意到而已：

• 你用的导航软件：不仅能给你规划路线，还能告诉你“故宫的开放时间是旺季8:30-17:00，淡季8:30-16:30，门票价格旺季60元/人”，还能推荐“故宫周边3公里内的热门景点”，背后就是知识图谱在关联“故宫-开放时间-旺季8:30-17:00”“故宫-门票价格-旺季60元”“故宫-周边景点-景山公园”等三元组。
• 你刷的短视频平台：你看了几个“科幻电影解说”的视频，平台就给你推《三体》电视剧、《流浪地球》周边、刘慈欣的采访，背后就是知识图谱在关联“科幻电影-相关作品-《三体》”“科幻电影-相关人物-刘慈欣”等三元组。
• 你打的智能客服电话：你问“我的信用卡账单日是什么时候？”，智能客服不是给你一堆预设的关键词选项，而是直接告诉你“您的信用卡账单日是每月15日”，背后就是知识图谱在关联“你的账户-信用卡-账单日-每月15日”的三元组。
• 你用的外卖平台：你搜“川菜”，平台不仅给你推荐川菜馆，还会推荐“冰粉”“夫妻肺片”“毛血旺”等川菜特色菜，背后就是知识图谱在关联“川菜-特色菜品-冰粉”“川菜-特色菜品-夫妻肺片”等三元组。

六、本章要点总结与下章预告

本章我们初步认识了知识图谱这个让机器读懂世界的核心技术：它用“实体-关系-实体”的三元组作为基本单元，把零散的知识关联成一张结构化的知识网络，既解决了传统数据库灵活性差、关联查询复杂的问题，也解决了百科词条非结构化、机器难以解析的问题。从谷歌的全球搜索到