1. 课程导论：知识图谱与质量规则概述
大家好，我是你们这轮课程的主讲。开始之前，先聊几句实在的——我做了十几年质量工程，前五年基本是在“救火”。线上出故障了，拉着几个开发排查根因，写个临时规则，然后祈祷别再炸。直到有一次，我试着把自己的经验、历史故障记录、业务字段关系，统统整理成了一张知识图谱。嗯，从那以后，质量规则不再是孤立的补丁，而是一套能推理、能自愈的体系。今天的第一章，我们就把这个“起点”讲清楚。
1.1 为什么要用知识图谱驱动质量规则？
传统的质量规则怎么写？你八成见过这样的代码：
if (order.amount > 10000 && order.pay_status == 'unpaid') {
alert('大额未支付订单，请人工审核');
}这种规则直接、好懂，但一旦业务扩张呢？订单有跨境、有分期、有优惠券叠加……if-else 堆到几千行，谁都改不动。我曾经接手过一个遗留系统，光支付风控就有 47 个 if-else 分支，每个分支都是前人“拍脑袋”加的。结果有个场景漏了——跨境订单加优惠券后，大额判定逻辑全乱套。
知识图谱能解决这个问题吗？ 说白了，知识图谱就是把实体（订单、用户、商品）和关系（属于、关联、派生）当成一张网来存。规则不再是“如果金额>阈值”，而是“如果订单金额超过同类商品历史均值的 2 倍，且用户信用分低于600”，前者是静态阈值，后者是带推理的语义规则。你想想看，后者天然能应对变化。
核心观点： 知识图谱驱动的质量规则，本质是用图结构替代硬编码规则树，让规则具备可解释性、可演化性和可复用性。
1.2 课程目标：学完后你能做什么？
我这门课不讲空泛的概念。30 章走完，我希望你具备以下能力：
- 能独立设计质量领域的知识图谱 —— 从业务过程、故障数据、日志中抽取出实体和关系。
- 能编写基于图推理的质量规则 —— 用 SPARQL 或 Cypher 表达“当A且B且非C时触发告警”。
- 能落地一套质量规则管理平台 —— 包含规则版本、测试、生效、反馈闭环。
- 能规避常见坑 —— 图数据膨胀怎么办？规则冲突怎么检测？这些我都会拿真实案例讲。
| 能力维度 | 对应章节 | 我建议投入时间 |
|---|---|---|
| 知识图谱建模 | 第 2-6 章 | 16 小时 |
| 规则表达式与推理 | 第 7-14 章 | 20 小时 |
| 实战落地与工具链 | 第 15-24 章 | 24 小时 |
| 案例+综合项目 | 第 25-30 章 | 12 小时 |
学习建议： 前面建模部分别跳，你后面遇到的 80% 的麻烦都是因为图没建好。我在项目中吃过这个亏——实体类型定义太粗，导致规则根本没法精准匹配。
1.3 学习路径：从零到落地怎么走？
课程分三个阶段，我按我个人习惯画了张图，帮你心里有个谱：
你看，三个阶段不是孤立的，箭头代表走向，最后那条虚线告诉你——学完第三阶段要回到第一阶段去看建模有没有遗漏。这种迭代是我在实际项目中总结出来的，很管用。
1.4 你需要带什么基础来？
- 编程基础： 至少会用 Python 或 Java 写写脚本，课程里大部分示例我用 Python，但核心思想不限制语言。
- 数据库常识： 知道什么是关系型数据库就行，图数据库（Neo4j、NebulaGraph）我们从头教。
- 一点质量工程经验： 如果你做过测试、监控、或者反作弊，那就更好了。没做过也不要紧，我会用电商、金融的通用场景举例。
避坑提示： 我曾经以为“掌握了 SPARQL 就够了”，结果建图时实体定义太粗，导致后续规则需要反复改属性。所以 不要跳过建模，这是整门课的根基。
1.5 本章小节：一张图回顾
这一章我们聊了什么？四个关键词：
- 问题： 传统规则不可维护、不可推理。
- 答案： 知识图谱提供语义底座，让规则“长”在关系上。
- 目标： 你能设计、编写、落地这套体系。
- 路径： 基础 -> 规则 -> 工程，迭代反馈。