📚 课程目录第4章规则引擎简介

4. 规则引擎简介：Drools、SHACL、SPARQL 推理

做知识图谱一致性，说白了就是要让机器能自动判断“这条数据对不对”。人工去查？数据量一上来，累死也查不完。这时候就得靠规则引擎。

规则引擎不是啥新东西。我刚开始接触那会儿，还觉得不就是“if…then…”吗？后来项目做深了才发现，这里面门道挺深。Drools、SHACL、SPARQL 推理，这三样儿就是眼下最主流的工具，各有各的脾气，咱们一个一个说清楚。

4.1 Drools — 老牌业务规则引擎

Drools 是 Red Hat 搞的产品。它强在哪？强在 生产规则系统（Production Rule System，也称 PRS）。你给它一堆事实（Fact），再给它一堆规则（Rule），它能高效地匹配、筛选、执行。

我在项目里用它处理过药物相互作用检查。比如“A 药和 B 药同服，会抑制 CYP3A4 代谢”。这种规则用 Drools 写非常顺手。

一个 Drools 规则片段：

rule "CYP3A4 抑制检查"
when
    处方: 处方单(有药品 "阿托伐他汀")
    药品: 药品(名称 == "克拉霉素")
then
    处方.警告("克拉霉素抑制 CYP3A4，增加阿托伐他汀血药浓度");
end

Drools 用的是 RETE 算法。这算法专门优化了模式匹配效率。你想想看，数据量一大，节点索引不索引，命中的效率天差地别。

适用场景：

业务规则频繁变化，需要热更新。
规则条件复杂，有多层次逻辑分支。
需要集成 Java/Spring 生态。

踩坑提醒：Drools 规则多了之后，规则冲突非常头疼。我曾经遇到过，两条规则同时匹配，一个要禁止开药，一个要提示减量，两个结论互相打架。解决办法是设优先级、加规则流（Rule Flow），或者限定条件。

4.2 SHACL — 给 RDF 数据画框框

SHACL（Shapes Constraint Language）是 W3C 标准。它不推理，它只管验证。你给 RDF 数据，它按照“形状图”去检查，看看每个节点、每个属性对不对得上。

拿药物知识图谱来说，我们需要确保“每种药物都有ATC编码”、“剂量属性只能填数值”，这些约束用 SHACL 定义非常标准。

一个 SHACL 形状示例（验证药物必须有 ATC 编码）：

@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix dto: <http://example.org/dto#> .

dto:DrugShape
    a sh:NodeShape ;
    sh:targetClass dto:Drug ;
    sh:property [
        sh:path dto:atcCode ;
        sh:minCount 1 ;
        sh:datatype xsd:string ;
        sh:pattern "^[A-Z]\\d{2}[A-Z0-9]{2}$"
    ] .

注意：SHACL 的验证引擎有很多实现，比如 Apache Jena SHACL、TopQuadrant 的 SHACL 引擎。不同的实现，对 sh:pattern 的正则支持程度有差别。我在迁移项目中就遇到过引擎升级后，正则语法报错的情况。尽量用标准 PCRE 语法，别走偏门。

SHACL 的优势在于：

跟 RDF 标准绑得紧，天然适合 LPG 或图数据库。
约束写在数据外面，不污染本体。
验证报告非常详细，哪条数据哪条属性不通过，一目了然。

劣势呢？它做不了复杂推理。你写“如果患者用过过敏药，则不能开同类药物”这种逻辑，SHACL 搞不定。它只管“这个字段有没有填对格式”。

4.3 SPARQL 推理 — 用查询做逻辑推导

SPARQL 不只是查数据，它还能推理。借助 OWL 推理机（比如 Pellet、Apache Jena 的微推理机），SPARQL 可以查“所有非甾体抗炎药”，哪怕数据里只标了“布洛芬”是 NSAID，“阿司匹林”是 NSAID。推理机自动把“布洛芬 rdfs:subClassOf NSAID”补出来。

但注意，SPARQL 推理分两种：

事前推理（Materialization）：启动时把所有可推导的三元组全算好，存起来。查询快，但占空间、启动慢。
事后推理（Query Rewriting）：查询来了，实时展开。省空间，但查询慢。

我在做药物知识图推理时，两种都用过。一般是事先生成“药物-副作用”补全关系，存好。推理计算量大，但查询响应快。

SPARQL 推理查询示例：

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX drug: <http://example.org/drug#>

SELECT ?drug ?class WHERE {
  ?drug rdfs:subClassOf drug:Antibiotic .
  ?class rdfs:subClassOf drug:Antibiotic .
}

在推理开启时，这条查询能返回所有三级抗生素子类下的具体药，而不需要手动展开。

4.4 三者的对比

大白话总结就是：

Drools：适合做“条件-动作”的判定，逻辑复杂，更新快，业务决策用。
SHACL：适合做“数据是否合格”的检验，结构约束用。
SPARQL 推理：适合做“隐含知识”的挖掘，本体扩展用。

在实际的质控流程里，三个工具往往配合用。我见过的最佳实践是：

先用 SHACL 验证数据格式、必填字段、值域。
再用 SPARQL 推理，补全通用语义关系。
最后用 Drools 做业务规则的精细判断。

一个典型的质控流程：

原始数据 → SHACL 形状验证（清洗） → SPARQL 推理（补全） → Drools 规则引擎（质控决策） → 输出质控报告。

4.5 本章核心逻辑框架图

下面这张图，把三种工具的位置和关系说清楚了。

流程说明：从左到右，数据先过 SHACL 清洗格式，再推 SPARQL 推理，最后进 Drools 做业务决策。三种工具各自管好自己那一块，互不冲撞。

4.6 三个引擎的选择建议

维度	Drools	SHACL	SPARQL 推理
能力方向	业务规则判定	数据形状验证	语义关系推导
执行效率	中（RETE 优化后高）	高（主要是结构匹配）	低（需推理机计算）
规则更新	热加载	重启后重新加载	数据更新后需重算
学习成本	高（DRL 语法）	中（SHACL 本体）	中（SPARQL + OWL）
典型场景	药物相互作用、业务审批	数据质量检查、字段约束	自动补全上位概念、合并知识

我自己做项目，一般先画一个“工具矩阵”：把规则按“结构约束”“语义扩展”“业务决策”筛出来，再分配到三个引擎。如果一条规则横跨两个域——比如“格式错误时还要生成警告”——那就让 SHACL 负责收集错误，Drools 负责生成警告。分工明确，层级清晰，比一个大一统引擎好维护得多。