1. 知识图谱概述：从词到网的进化
说实话，每次新课开场我都喜欢先聊定义。不是照搬教科书，而是说说我自己对知识图谱的理解。
知识图谱，说白了就是一张「有结构的百科」。它把现实世界中的实体（比如人、公司、电影）和它们之间的关系（比如「主演」、「位于」、「投资」）组织起来，形成一个巨大的网络。这和传统数据库存表格、搜引擎存倒排索引完全不同。
为什么要搞这么复杂？
因为很多问题，表格解决不了。举个例子：你想查「周星驰演过哪些电影，这些电影的导演是谁」。在传统的数据库里得做两次 JOIN，在知识图谱里一次遍历就搞定。这就是结构的力量。
1.1 发展历程：从语义网到大数据
知识图谱不是一天建成的。我大致把它的发展分成三个阶段，你品一下：
| 阶段 | 时间 | 标志性事件 | 我的感受 |
|---|---|---|---|
| 萌芽期 | 2000-2006 | 语义网、RDF、OWL 标准发布 | 那时概念很超前，但落地太难 |
| 成长期 | 2007-2012 | Freebase、DBpedia 出现 | 终于有人开始建大规模知识库了 |
| 爆发期 | 2012 至今 | Google 提出 Knowledge Graph；腾讯、阿里、头条跟进 | 行业一下子从「要不要做」变成「怎么做」 |
我记得 2012 年 Google 发布 Knowledge Graph 时，我还在一家小公司做 NLP。当时大家都很兴奋——原来搜索框右边的「知识卡片」背后，是一张巨大的网络。从那开始，知识图谱这个方向就彻底火了。
1.2 典型应用：我参与过的三个场景
聊理论不如聊实战。我直接说三个我经手过的项目场景，你看对哪个有感觉。
搜索增强
用户搜「北京天气」，直接返回卡片。这背后是「实体链接 + 属性提取」。我在项目中遇到过最大的坑，是实体消歧：用户说「苹果」，到底是水果还是公司？后来我们用上下文特征+图结构信息搞定了。
推荐系统
知道用户看了《盗梦空间》，推荐《星际穿越》。为什么？因为知识图谱里这两部电影的导演都是诺兰。传统的协同过滤方法可能做不到这种跨领域的推理。
风控与反欺诈
这是我最喜欢讲的场景。举个例子：A 和 B 共用同一个手机号，B 和 C 共用同一个 IP，C 又在黑名单里。尽管 A 本人没有任何不良记录，但基于图谱的关联分析，欺诈概率已经很高了。我曾经用这个思路帮一家金融公司把欺诈误报率降低了 40%。
1.3 常见知识图谱架构
项目做了多了，我发现不管什么业务，知识图谱的底层架构大同小异。我一般把它分成四层：
- 数据层：结构化数据库、非结构化文本，甚至日志文件。这块最容易出问题，脏数据进来了后面全白搭。
- 存储层：主流选择是图数据库（Neo4j、NebulaGraph）或 RDF 存储。我个人的习惯是：业务逻辑复杂选图数据库，学术研究或跨系统共享选 RDF。
- 计算层：实体链接、关系抽取、图算法（PageRank、社区发现）。这里是技术力集中的地方。
- 应用层：搜索、推荐、问答、风控规则引擎。
重要原则：每一层都要做校验。数据层的校验在 ETL 阶段；存储层的校验在写入时；计算层的校验在推理后。这是你在后面章节会反复看到的思路。
下面这张图是我自己总结的知识图谱全流程架构，你注意看校验贯穿在所有环节中：
一个经验：项目初期可能只做校验①和②，但随着数据规模增长，校验③和④几乎必加。我见过太多项目在存储层才暴露关系冲突，那时改起来成本太高了。
1.4 我为什么把校验放在本课程最前面？
你可能会问：学知识图谱，不是应该先学怎么建图吗？
嗯，很多人确实这么想。但我自己做项目时发现，80% 的线上问题不是「建不出来」，而是「建错了不知道」。所谓 Garbage In, Garbage Out。知识图谱一旦投用，错误的关联会导致搜索推荐全崩，甚至风控模型给出完全相反的结论。
举个例子你感受一下：假设张三和李四是两个同名的人，实体链接没处理好，结果张三的信用卡逾期记录关联到了李四的个人信息上。后果是什么？李四贷款被拒，张三却毫发无伤。这种事故一旦发生，轻则投诉，重则诉讼。
注意：知识图谱的「关联校验」不是事后补救，而应该嵌入到每一个构建环节中。这是本课程所有案例的核心理念。后面的每一章我都会用一个真实场景来拆解如何做校验，包括代码实现和避坑指南。
好了，第一章的内容就是这些。先把「知识图谱是什么、能做什么、结构怎么搭」这个地基打好。后面每一章我们都将是实打实的实战案例，从数据预处理开始，一步步走到线上部署。准备好了吗？