引言
这一轮 AI 革命, 自从 ChatGPT 出世已经一年多了, 人们从来没有如此一致地认为, AI 就是未来的方向。
但是上一轮 AI 革命的主角之一的知识图谱, 在实践中却很少再被提及, 人们宁愿用更加简单粗暴的搜索结合大模型(RAG), 而不是用精致复杂的知识图谱。甚至有人认为它的位置更加尴尬了 。
本文将结合作者在大厂的工作经验, 聊一聊知识图谱的基本理念, 以及为什么它没有看起来的那么美好。
知识图谱的现状
搜索
知识图谱涉及的技术都是几十年前的老技术了, 谷歌在2012年重新将它们以 “知识图谱” 的概念打包提了出来。
谷歌副总裁阿密特·辛格博士2012年的文章 things, not strings 提出了一个新颖的观点, 搜索应该基于上下文更加丰富的实体概念, 而不是充满歧义的字符串。
当我搜索 “姚明的母亲是谁?”, 传统的搜索引擎会将这句话拆成几个关键字, 比如 “姚明”, “母亲”, 然后去寻找含有关键字的文档。而知识图谱则不然, 先去知识图谱中寻找 “姚明” 这个实体节点, 然后再顺着 “母亲” 这一条边, 也叫 “关系”, 找到要搜索的目标节点, 直接给出答案:
不过, 谷歌的知识图谱只对某几个特定的例子效果比较好, 稍微复杂一点的搜索就无法触发知识图谱了, 这也和知识图谱本身的缺陷有关, 下文会提到。
虽然搜索一直是知识图谱的 “主吹” 方向, 但是究竟有多少落地我是深表怀疑的。毕竟都十多年了, 连谷歌, 百度这样的大厂, 落地场景都很有限。
社交模式检测
知识图谱在工业界大规模落地的主要领域就是社交了, 每个人天生就是图谱中的一个节点, 人与人间的关系构成边。
利用连接预测(Link prediction)算法, 我们就能找到那些相互认识, 但是尚未添加好友的人们, 推荐 “可能认识的人”:
| 算法 | 应用 |
|---|---|
 |
 |
利用图的 路径相似度算法, 我们可以发现同一个人的很多 “小号”。
结合大模型
在大模型展现出超强的能力后, 抱着 “打不过就加入的心态”, 知识图谱也可以考虑成为大模型的一个挂件。
大模型虽然很强, 但是劣势就是可能存在幻觉(Hallucination)。目前我见到的所有落地的解决方案都是 RAG(Retrieval-Augmented Generation, 搜索增强生成), 就是在把问题交给大模型之前,先走一下搜索引擎, 找到相关的文档后, 再加上这些文档中的知识一并交给大模型。一方面解决模型超长记忆的问题, 另一方面保证模型答有所依。
在 RecallM 这篇论文中, 作者提出了用知识图谱代替文档数据库, 作为大模型长期记忆的方法。
文档不再是被”堆”放在文档数据库中, 而是先用传统 NLP 方法抽取出其中的实体概念, 然后将其放在知识图谱中, 相关概念的节点属性里:
当用户提问的时候, 则先从用户的提问中抽取出实体, 在知识图谱中定位到它, 再向周围搜寻某个固定深度(比如 2)的所有节点, 将这些节点中所有片段作为背景知识, 在 Prompt 中输入给大模型, 得到最终结果。
其实这跟 RAG 也没有本质的区别, 知识图谱就相当于文档数据库的一个索引, 我们通过知识图谱从文档库中索引检索到所有相关的文档, 再交给大模型。
传统 RAG 一般使用大模型的 Embedding 能力, 通过向量相似度索引到相关的文档。
问题来了, 知识图谱当索引真的就能比大模型 Embedding 要好吗? 从 RecallM 论文的结果看, 可能还不如, 在都没有经过微调的情况下, 还是传统的做法更好:
下图截取自 RecallM 论文, VectorDB 就是传统 RAG 向量检索的做法, 可以看到, 基于知识图谱的 RecallM 和 Hybrid-RecallM 方法要明显低于它。 Hybrid-RecallM Maximum 是作者根据任务专门微调过的模型, 虽然它最高, 但是个人认为没有可比性
在大厂的实际落地方面, 我听说的所有 AI 落地, 都是采用 RAG 注入领域知识。原因为何? 无它, 唯简单粗暴尔。知识图谱看起来精致, 但是造成的额外复杂度, 能带来多少好处? 没人能说清楚。 还不如先用简单的方案上线。纵观历史, 这也是计算机技术的一个特点, 越是简单粗暴的做法, 越是容易被广泛采用, 而越精致的做法, 反而更加小众, 就像 C 语言和 lisp 语言的结局一样。
另外, 也有观点认为, 大模型内部已经蕴含了某种知识图谱, 其本身具有的推理能力就是一个例证, 没必要再外置一个显示的知识图谱帮助推理。 (参考 [3])
深入理解知识图谱: 理想与落地的鸿沟
逻辑结构: 人类对自身认知的过度美化
以下是一张典型的知识图谱的逻辑结构(某家电商的客户行为与喜好图谱):
“张三在 2024 年 4 月 1 日购买了小米手机” , 翻译到图中, 就变成了一个张三节点, 一个小米手机节点, 以及一条 “购买” 边, 我们可以把购买时间备注在边的 time 属性上。
这就是 属性图模型, 可以通过 Label 标注节点的类型, 比如张三节点的 Label 就是 “消费者”, 小米手机的 Label 就是 “产品”。其他额外的信息可以通过属性附加在节点上, 比如产品名称 name, 产品的制造商 mfr 等等。
为了解客户喜好的产品类型, 我们继续在知识图谱中标注了每个产品所属的类型, 产品类型又进一步延伸出父类型, 通过推导这个知识图谱, 我们可以知道张三和王二都是电子产品的爱好者。
这个知识图谱中, 产品和消费者是主角, 产品类型只是进一步标注了产品的元信息, 所以在图中我单独框了出来, 这一部分有一个术语, 叫做 Ontology。在某些领域中, 有公开的行业通用的 Ontology, 比如用于临床文档和报告的 SNOMED CT。
乍看之下, 是不是非常符合人类对世界的认知? 比关系型数据库中那一行行的表要好看多了。但是仔细想想, 人们对世界的认知真的有这么简单吗? 有没有可能只是人类对自身认知的一种美化呢?
相比漂亮精确的知识图谱实体, 人类对世界的认知其实是模糊的。在 Word2Vector 或者 大模型的 Embedding 中, 都是多维度的向量来表示一个概念, 虽然看起来丑陋, 但更加符合实际情况。所以现在也有论文提出用 Embedding 代替实体节点, 不过这也破坏了知识图谱可解释性强的优势, 没见过厂里有实际落地。(参考 [4])
知识图谱的另一个宣言的优势是 Smart Data。所谓 Smart Data, 就是将业务逻辑编码进了数据中, 这样业务人员不需要看应用程序代码, 也能理解数据的含义, 也方便数据的复用与迁移。比如上图中, 从数据里就可以看出, 小米手机的产品类型是手机, 并且它是电子产品的子类。而不需要再去翻 Java 代码才知道小米手机的类型是手机, 然后继承了电子产品。而且知识图谱中的数据结构和 Java 中类和对象概念也更加接近, 没有烦人的关系对象阻抗阻抗, 不需要使用ORM框架再转一层。
但是回过头来, 看看自己应用里的屎山代码, 以及产品多变的业务逻辑, 将它们编码到数据中的真的好吗? 一旦有变化, 数据的订正也非常麻烦。如果只放了核心数据, 跟普通的关系型数据库又没有什么区别。还不如将数据的解释权交给应用, 改起来也方便。
物理结构: 图数据库真的必要吗?
知识图谱一般采用图数据库进行存储, Neo4j 是当前最流行的图数据库, 其宣扬的优势有两个:
- Cypher 语言 相比 SQL, 进行图查询更加直观方便
- 无索引邻接(index-free adjacency) 技术使得图遍历更加高效
这两个优势都是对比关系型数据库而言的, 假设我们要用关系型数据库存储图数据的话, 只能在每一条记录里存储边的起始节点与到达节点:
为了能够从 A 出发找到 C, SQL 中只能去写自关联, 去找到和 A 相邻两条边的节点:
SELECT r2.target FROM relations r1
-- 自关联
JOIN relations r2
ON r1.target=r2.source
WHERE r1.source='A'
如果要找和 A 相邻三条边的节点, 则又需要再加一次自关联:
SELECT r3.target FROM relations r1
-- 自关联
JOIN relations r2
ON r1.target=r2.source
-- 再加一次自关联
JOIN relations r3
ON r2.target=r3.source
WHERE r1.source='A'
如果我要找到和 A 任意深度连接的所有节点呢? 那 SQl 简直没法写了, 因为我不可能写无限个自关联, 但是 Cypher 却很容易写出来:
// 查询和 A 连通的所有节点
Match (a {name: 'A'})-[*]->(n)
RETURN n
// 查询和 A 相邻两条边的节点
Match (a {name: 'A'})-[*2..2]->(n)
RETURN n
自关联除了不好写之外, 还存在性能问题。想象一下关系型数据库中, 找到下一个节点需要多少个步骤: 首先通过 source 的索引找到主, 然后回表通过主键找到记录, 再记录中抽取出 target 字段。这还只是逻辑上的步骤, 物理上通过 B+ 树的跳转则更加复杂。
而图数据库 Neo4j 物理上将节点(nodestore), 边(relationstore)和属性(propertystore)分别存储, 节点和边都是由定长记录构成, 通过 id*记录长度 就能快速定位节点的位置, 从一个节点到下一个节点只需要两次非常简单的计算:
这种技术被业界称为 无索引邻接(index-free adjacency)。(参考 [6])
有网友测试过, 深度为 5 时, Neo4j 就比 MySQL 要快 1322 倍, 随着深度和数据量增加, 差距还会进一步扩大(参考 [5])。
从这两点上讲, 图数据库确实颇有优势, 但个人认为, 并非不可替代。
如果要查询任意深度的图节点, 完全可以在应用程序中写一个 while 循环, 每轮循环访问一个节点来实现。这样还更加灵活。据我所知, 大厂里很多类似的图遍历场景都是这么做的。至于性能问题嘛, 只要合理地进行分库分表, 我见过很多应用承接上千 QPS 都没有问题。
如果是离线分析场景, 除了社交之外, 很少会有任意深度遍历的场景, 用 SQL 写几个自关联也能够糊弄过关。离线分析场景, 性能也没那么重要。如果真的在乎性能的话, 可能就上 MPP 数据库了。
不断萎缩的目标
知识图谱的前身其实是早在 1999 年就提出的语义网(Semantic Web)。
它的提出有着非常宏大的目标, 想要将整个互联网的内容组织成一张大的图谱, 让原本割裂的数据互联互通。在20世纪初, Web3.0 就是指的语义网。
因为上述知识图谱技术的种种缺陷, 语义网做到现在基本是 “黄了”。随着语义网热度的不断降低, 现在再提 Web3.0, 只会让人想到代指区块链相关技术的 Web3。从下图中可以看到语义网热度的急剧衰退:
10 年以后, 趁着 AI 的热度, 这些技术重新被打包成 “知识图谱” 的概念卷土重来。这一次大家不再敢提过于宏大的设想了, 目标就缩小成了企业内部的知识管理。还模仿 “数据湖”, 提出了 “知识湖”(knowledge lake)的概念。
十年来具体落地几何, 大家看看目前自己企业知识管理的现状, 也就知道了。
大模型出来后, 不仅语言能力强, 也拥有很强的推理能力, 知识图谱就更尴尬了, 只期望能成为大模型的一个挂件而不被淘汰。
在本文的参考 [3] 中, 清华的研究者们也倡导大家, 更加重视 “知识” 本身, 而不是 “图” 的表现形式。
我们自己平时学习, 画思维导图能够帮助知识的理解。这是因为人脑更擅长模糊概念的理解, 而实体关系图的形式, 能够弥补人脑精确性的不足。
但是机器和人相反, 更擅长精确的计算, 程序员编写的一行行 if else 逻辑代码, 也可以理解为机器处理业务的知识图谱。而 Embeding 这种相对含糊的东西, 才能够进一步帮助机器像人一样理解概念。
参考
[1]things, not strings[2]大语言模型的检索增强生成 (RAG) 方法[3]5 Reasons Knowledge Graph will never bloom[4]Knowledge graph embedding[5]Neo4j性能评测[6]The Graph Traversal Pattern[7]The Semantic Web is Dead
End
关注我, 用技术i人的眼光看世界
