知识图谱概述：从搜索到推理的进化之路

说起知识图谱，我得先坦白一件事。我入行那会儿，这概念还没这么火。当时大家管它叫“语义网”，说白了就是想让机器能理解数据背后的含义。我刚开始接触时也犯过嘀咕——这不就是个高级数据库吗？直到我亲手搭了一个药物-靶点知识图谱，才发现事情远没那么简单。

知识图谱的发展历程

知识图谱不是凭空冒出来的。它的演变，你可以理解为三个关键阶段。

1. 早期语义网时代（2000-2010） —— 大家开始意识到，光存数据不行，得存“关系”。RDF、OWL这些标准就是那时候定的。我记得第一次看RDF三元组文档，脑子嗡嗡的，什么subject、predicate、object，感觉跟学一门新外语似的。
2. 谷歌推广期（2012-2015） —— 谷歌提出了“知识图谱”这个营销词，瞬间出圈。我在项目中遇到过很多PM跑来问：“咱们也搞个知识图谱吧？” 我当时的回答是：“你先想清楚要存什么关系，别为了图谱而图谱。”
3. 领域深耕期（2016至今） —— 尤其生物医药领域，知识图谱开始真正落地。药物发现、辅助诊断、临床决策支持……这些场景不再只是PPT上的概念。

核心概念：实体、关系、属性

这三者构成了知识图谱的“砖瓦”。不夸张地说，你如果理解了它们，就等于理解了知识图谱的90%。

概念	通俗解释	医药领域举例
实体	现实世界中可区分的事物或概念	阿司匹林、EGFR蛋白、非小细胞肺癌
关系	实体之间的语义连接	“靶向”、“治疗”、“副作用包括”
属性	描述实体的特征或参数	分子量、半数抑制浓度、给药途径

举个例子。我们用三元组的方式记录一条知识，大概是这样的：

实体：阿司匹林
关系：治疗
实体：头痛
属性：{ATC编码: N02BA01, 剂型: 片剂, 最大日剂量: 4000mg}

这看起来很朴素对不对？但我告诉你，真正的生产级知识图谱，可能就是几十亿条这样的三元组。我在搭建药物重定位图谱时，光实体归一化就折腾了两个月——因为同一个药在不同数据库里名字可能不一样。嗯，这里要注意：实体对齐是第一个大坑。

知识图谱的典型应用场景

我们重点聊两个和课程最相关的场景。你想想看，如果没有知识图谱，药物发现和辅助诊断会是什么样？

药物发现

传统药物发现像大海捞针。你得一个一个化合物去试。知识图谱改变了这个逻辑。你可以这么理解：

• 把药物、疾病、靶点、通路、副作用全部变成节点
• 把“激活”、“抑制”、“引起”、“治疗”变成边
• 然后直接在图里做推理，就能发现隐藏的药物-疾病关系

我曾经在项目中用过图算法做药物重定位。当时我们发现某个老药和某个罕见病之间隔着两个通路和一个蛋白质，这条路径在传统数据库里根本查不到。后来验证成功，那感觉，比中了彩票还爽。

一个典型的药物发现查询流程，代码层面可能是这样的：

# 伪代码：查询与特定蛋白相关的所有药物
MATCH (d:Drug)-[:TARGETS]->(p:Protein)
WHERE p.name = "EGFR"
RETURN d.name, d.stage, d.target_affinity
ORDER BY d.target_affinity DESC

这条查询，在关系数据库里可能要连五张表，在图数据库里一句Cypher搞定。为什么？因为图本身就是按关系组织数据的。

辅助诊断

辅助诊断场景更贴近临床。知识图谱在这里扮演的角色是“医生的超级大脑”——它能把患者症状、检验指标、病史、用药记录关联起来，给出诊断建议或者风险预警。

我以前参与过一个项目，用知识图谱做罕见病辅助诊断。罕见病之所以难诊断，是因为单个症状没有特异性。但如果你把症状组合起来，在图里走两步、三步，就能定位到候选疾病。我印象特别深，有位医生第一次用系统时，查到一例他误诊了三年的病例，整个人沉默了有五分钟。

来看一个辅助诊断的简化示例。假设我们有一个患者的症状集，知识图谱可以帮我们发现关联：

患者症状：{干咳持续3周, 夜间盗汗, 体重下降}
图查询路径：
症状-关联->{肺结核, 肺癌, 淋巴瘤}
症状+年龄+体重变化-筛选->{肺结核}
图结构特征：症状共现频繁子图匹配

你看，症结就在这里——不是简单的字符串匹配，而是图结构上的特征发现。

本章知识结构总览

下面这张图，是我对本节内容的一个梳理，方便你建立整体认知。