📚 课程目录第1章知识图谱概述

一、知识图谱概述：从一张图理解世界

先问大家一个问题。你说，搜索引擎是怎么知道“特朗普”和“美国总统”是同一个东西的？

其实背后的核心技术，就是我这些年一直在打交道的——知识图谱。

我个人习惯把知识图谱看作一张巨大的“概念关系网”。它不是简单的关键词匹配，而是让机器真正理解实体之间的语义关联。2012年Google首次提出这个概念时，整个搜索行业都震动了。

定义很简单：知识图谱是用图结构来描述实体及其关系的技术框架。

技术上讲，它由节点和边组成：

核心公式：知识图谱 = 三元组集合（头实体，关系，尾实体）

例如：（伊马替尼，治疗，慢性粒细胞白血病）就是一条典型的三元组。

说白了一个知识图谱就是一堆“A-B-C”这样的三元组组合在一起。我在项目里通常用RDF或属性图来存储这些东西，不过这是后话了。

知识图谱这玩意儿不是一夜之间冒出来的。我把它分成三个阶段：

阶段	时间	标志性事件	我的看法
萌芽期	2000-2010	语义网、RDF、OWL标准	理论很丰满，落地很骨感
爆发期	2012-2016	Google Knowledge Graph上线	技术开始接地气了
深耕期	2017-至今	医疗、金融、工业垂直应用	我现在就干这个

我记得2012年Google Knowledge Graph刚上线那天，我们团队还在用小规模的本体推理。看到搜索引擎直接给出“实体卡片”而不是一堆链接时，大家都有点懵。嗯，这才知道差距在哪。

最接地气的例子。你搜索“阿司匹林”，右侧会出现药物结构式、适应症、副作用、交互作用等信息卡片。这些数据背后就是一张庞大的药物知识图谱。

Google在2012年发布时只有5.7亿实体、180亿关系。到现在，这个数字翻了不知道多少倍。我个人觉得它最大的贡献是让知识图谱从学术圈走进了普通用户的视野。

这才是我们课程的重点。医疗领域的知识图谱有几个典型方向：

我在项目里做过一个癌症药物知识图谱，里面包含了FDA批准的400多种抗癌药、3000多个基因靶点、200多种癌症亚型以及数万条临床试验结果。单是数据源整合这一步，就花了团队三个月。

一点经验：构建医疗知识图谱，最难的往往不是算法，而是数据清洗和实体对齐。同一药物在不同数据库中可能有七八种不同叫法。

避坑指南：我刚开始做药物图谱时，直接拿PubMed文献抽三元组，结果充满了各种实验条件和矛盾结论。如果你也做类似项目，建议先建立一个高质量的核心知识库，再扩展。

为什么我们要专门讨论“癌症药物知识图谱”？因为癌症本身就是一个极端复杂的疾病系统。

你想想看，一种抗癌药可能有多个靶点，一个靶点可能关联多种肿瘤类型，同一种基因突变在不同癌种中的表现完全不同。传统的二维表格根本装不下这种多维关联。

下面这张图可以帮你快速理解知识图谱在癌症药物领域的核心结构：

这张图展示了我们课程将要构建的图谱的核心骨架。左边是三种主要实体类型，右边是它们之间的典型关系。箭头方向代表了语义方向。

注意那个虚线部分——疾病和靶点之间也存在直接关联，这在实际项目中经常被忽略。我就踩过这个坑，后来不得不重跑数据对齐流程。

我们课程会用到这些工具。先列出来让你有个印象：

环节	常用工具/框架	我们课程选择的
数据存储	Neo4j、JanusGraph、ArangoDB	Neo4j（社区版）
本体建模	Protégé、OWL API、RDF4J	Python + 自定义本体
实体抽取	BERT-BiLSTM-CRF、BioBERT、PubMedBERT	BioBERT + 词典匹配
关系抽取	PCNN、Attention-BiLSTM、预训练模型微调	微调生物医学预训练模型
图谱查询	Cypher、SPARQL、Gremlin	Cypher

这几行表格背后藏着不少坑。比如原型阶段，我用过一段时间的RDF4J，后来发现查询性能在千万级实体时撑不住。换Neo4j之后才稳定下来。我个人建议起步阶段别太纠结技术选型，先让图谱跑起来再说。

关于癌症药物领域的特殊性：这个领域知识更新极快。FDA每天都在批准新药，文献数据库每周增长数千篇。知识图谱必须具备增量更新能力。

我见过不少团队做出来的图谱上线就过时。你得在设计之初就把“持续更新”这个需求考虑进去。

好了，这一章我们聊了：

有一个关键点想让你记住：知识图谱的本质是“先建模，后填充”。我们接下来的所有实战都会围绕这个思路展开。