计算机科学和软件工程技术在近几十年的飞速发展为各行各业注入了新的活力，自动合规审查技术是其中的一个重要体现。自动合规审查技术是一种利用计算机来自动化地检查和验证特定领域中的合规性要求的技术。这项技术通过将自然语言编写的条文转化为计算机可以理解和处理的格式(后文称为计算机规则)，来实现自动化审查的目的。自动合规审查的核心思想是将领域模型信息和条文信息提取为计算机能够理解的形式，并使用计算机对这些提取出的信息进行计算和推理，以进行自动审查。自动合规审查不仅可以提高审查的速度，还能减少人工审查中可能出现的错误。同时，自动合规审查可以在一定程度上避免由于条文的自然语言描述不清晰而产生的二义性问题，保证审查的有效性和准确性。
自动合规审查技术目前已经在建筑、法律、软件工程等领域有了相应的应用。在建筑领域，其被应用于建筑合规审查流程中，确保建筑的设计符合相关规则[1-3]。建筑自动合规审查技术依靠建筑相关的语义信息模型进行审查，建筑的语义信息可以从建筑的BIM模型和二维图纸中提取。BIM模型[4]是一种包含了多种信息的三维模型，在近十几年中发展迅速，得到了广泛应用。基于BIM模型来获取准确且计算机可理解的建筑语义模型让自动合规审查成为了可能[5]。此外也不断有研究者在二维PDF、CAD和像素图纸的自动合规审查技术领域进行探索。通过使用人工智能和计算机视觉相关技术对图纸中的核心构件进行检测和识别来提取图纸的信息[6]，并将这些信息建模为建筑语义模型来支持后续的自动合规审查流程。随后可通过知识图谱[7-8]相关技术在建筑语义模型上进行具体的自动合规审查流程。
从BIM模型或者二维图纸中提取审查所需信息的过程属于这个标准化流程中的第2阶段。此外，第1阶段对于整个自动合规审查流程而言也是至关重要的。如果不能从条文中提取有效信息并转换为计算机能够理解和解释的规则，那么自动合规审查就无从谈起。
如何对条文进行信息提取和转换是一个研究热点，可以细分成2个核心点：1) 设计一个计算机能够理解的规则表示形式。2) 对条文进行信息抽取。许多学者已经对信息抽取进行了充分的探索，目前一个主要研究方向是使用NLP技术进行抽取[12-14]。对于第1个核心点，也已经有许多相关进展。其中的一项研究[15]提出了一种表示规则的4级结构，将建筑规则划分为领域级别、规则级别、规则集级别和管理级别4个层次。此外，基于规则的(rule-based)表示方法[16]也一直是研究的重点，在近几十年来一直被广泛关注。基于规则的表示方法使用IF-THEN结构来表示规则[15]，这种规则表示方法的一个关键优势是可以轻松建立起自然语言编写的条文和计算机能够理解的规则之间的映射，从而让计算机规则的组织形式更加接近自然语言表示的条文。
一个典型的基于规则表示的例子是清华大学软件学院设计的结构化自然语言(structured natural language, SNL)[17-18]，目前已经成为了中国的国家标准[19-21]。SNL并没有采取先前研究中普遍采取的硬编码模式，即直接将条文转化为SPARQL等查询语言的形式，而是采取了一种介于自然语言和SPARQL之间的中间模式。例如，如果想要将“建筑中所有浴室的门的宽度大于0.8 m”表示为计算机规则，则可以使用SNL“如果建筑有房间，并且房间的名称包括浴室，并且房间有门，那么门的宽度≥800 mm”进行描述。SNL审查引擎会将SNL编译为对应的SPARQL查询语句，随后执行SPARQL查询和与之对应的算法来检索出不合规的结果。
SNL使用一种4层结构来对自然语言编写的条文进行计算机规则表示，本文提出的方法也将建立在这个4层结构之上。4层结构中第1层次，也是最低层次的是构件级别，用来表示条文中出现的实体、实体拥有的属性以及实体之间存在的关系。例如SNL中的“建筑”、“房间”和“门”，都被视为构件。每个构件有多个属性，例如“宽度”是“门”的一个属性。此外，构件之间会存在某些特定的关系，例如“房间有门”是“房间”和“门”之间的包含关系；4层结构的第2层次是可执行规则级别，可执行规则是自动合规审查系统读取和处理的最小基本单位。1句SNL语句就是1条可执行规则，SNL审查引擎每次读取1句SNL语句，生成这句SNL对应的审查结果；4层结构的第3层次是可执行规则集级别，对应1条自然语言编写的条文，由不少于1个可执行规则以“并且”的逻辑组合而成。例如《建筑防火通用规范》(GB 55037—2022)[22](后文简称为《防火通规》)中的条文8.3.1可以表示为1个可执行规则集，该可执行规则集由5句SNL规则语句组成，使用SNL审查引擎对这5句SNL语句分别进行审查即可对该条文进行自动合规审查；4层结构的第4层次是规范级别，对应自然语言编写的整本规范，每个规范由多个可执行规则集按照自然语言规范中的树状编排方式组成。例如整本《防火通规》可以视为1个规范。
综上，目前已有许多自动合规审查相关的研究，并已经形成了可靠的理论框架，许多成果已经落地应用。然而，现有的计算机规则表示形式普遍缺少对高层次规则间关系的关注。高层次规则间关系通常不是显性的，它们隐藏在自然语言条文的潜在表述之间，往往需要具有一定经验的领域专家才能识别这些潜在关系。这种潜在性导致现有的规则表示方法往往忽略了这种关系。本文为了解决此问题，提出了一种高层次规则间关系的计算机表示范式。通过将这种关系归纳为“合规级联”、“不合规级联”和“不适用级联”3种模式，该表示范式可以让计算机自动化地处理好这种关系，最终让自动合规审查系统输出更加符合用户直觉和预期的报告。
1 研究背景
条文之间的高层次关系是很常见的。以建筑消防领域为例，《防火通规》中的条文8.3.1规定了哪些建筑需要设置火灾自动报警系统。该条文规定：除散装粮食仓库、原煤仓库可不设置火灾自动报警系统外，下列工业建筑或场所应设置火灾自动报警系统：1) 丙类高层厂房；2) 地下、半地下且建筑面积大于1 000 m2的丙类生产场所；3) 地下、半地下且建筑面积大于1 000 m2的丙类仓库；4) 丙类高层仓库或丙类高架仓库；该条文有一层隐藏的含义：如果某个建筑不是上述列举的应设火灾自动报警系统的4类建筑，或者该建筑是散装粮食仓库或原煤仓库，那么就不对该建筑是否设置火灾自动报警系统作出要求。此时，《消防设施通用规范》(GB 55036—2022)[23](后文简称《设施通规》)的第12章中的有关条文就无须进行审查，因为这一章的内容与火灾自动报警系统各个设备设施的具体设置规范有关。如果建筑无须设置火灾自动报警系统，那么再对具体细节进行审查就没有实际意义了。
另一个例子是，《建筑设计防火规范》(GB 50016—2014)[24](后文简称《建规》)条文5.5.15规定了各种情况下一个房间所拥有的疏散门数量应该满足特定要求，而《建规》条文5.5.17-3规定了一个房间内任意一点到疏散门的最小距离应该满足的要求。如果某个房间不满足条文5.5.15中对疏散门个数的要求，那么条文5.5.17-3中对该房间疏散门距离进行审查的结果就没有实际意义，此时应不对这个房间进行条文5.5.17-3的相应审查。
上述2个具体案例展示了自然语言表示的条文之间隐性的高层次关系，条文和计算机规则之间的对应让这种关系也同样存在于计算机规则中。表 1中列举了更多高层次条文间关系的相关例子，表明了这种关系的普遍性。本文将此关系称为“高层次规则间关系”的原因是，一般的规则通常处于单个自然语言条文内部，而高层次规则间关系则对应不同条文，例如《建规》条文5.5.15和5.5.17-3所对应的规则之间的关系就是高层次规则间关系。它涉及条文之间的隐含逻辑、适用条件的动态判断以及规则之间的优先级和排除关系等，通常隐藏在条文的业务理解中，与领域知识和领域经验紧密结合，需要具有一定的全局业务理解知识才能准确应用。
表 1 高层次条文间关系的例子 |
| 编号 | 条文内容概述 | 高层次条文间关系的自然语言描述 |
| 1 | 《防火通规》条文8.3.1中规定了4类工业建筑或场所应设火灾自动报警系统；《设施通规》第12章具体规定了火灾自动报警系统的具体设置要求 | 如果某建筑不是《防火通规》条文8.3.1中规定的需要设置火灾自动报警系统的建筑，那么就不对该建筑进行《设施通规》第12章中的所有条文的审查 |
| 2 | 《建规》条文5.5.15规定了一个房间内的疏散门数量需要满足指定要求；《建规》条文5.5.17-3规定了房间内任意一点到疏散门的最小距离应该满足的要求 | 如果某房间不符合《建规》条文5.5.15，那么就不对该房间及房间的疏散门进行《建规》条文5.5.17-3关于疏散门距离的审查 |
| 3 | 《建规》条文5.5.8规定了对防火分区内安全出口的数量要求；《建规》条文5.5.9规定了当某些建筑的某些防火分区设置安全出口有困难时采取的特殊要求 | 如果某建筑中的防火分区符合《建规》条文5.5.8，那么就不对这些防火分区进行《建规》条文5.5.9的审查 |
| 4 | 《防火通规》条文10.1.1规定了应按照特级负荷供电的建筑；《防火通规》条文10.1.2和10.1.3分别规定了应按一级负荷和二级负荷供电的建筑 | 如果某建筑不符合《防火通规》条文10.1.1中有关消防用电负荷等级的要求，那么就不对该建筑进行《防火通规》条文10.1.2和10.1.3的审查 |
| 5 | 《防火通规》条文10.1.2规定了应按照一级负荷供电的建筑；《防火通规》条文10.1.3规定了应按二级负荷供电的建筑 | 如果某建筑不符合《防火通规》条文10.1.2中有关消防用电负荷等级的要求，那么就不对该建筑进行《防火通规》条文10.1.3的审查 |
| 6 | 《防火通规》条文5.2.1规定了耐火等级应为一级的建筑；《防火通规》条文5.2.2和5.2.3规定了耐火等级不应低于二级和不应低于三级的建筑 | 如果某建筑的耐火等级不满足《防火通规》条文5.2.1，那么就不对该建筑的耐火等级进行《防火通规》条文5.2.2和5.2.3的审查 |
| 7 | 《防火通规》条文3.4.2规定了一些应至少沿建筑的2条长边设置消防车道的建筑；《防火通规》条文3.4.3规定了另外一些至少沿建筑的2条长边设置消防车道的建筑，同时规定了特定情况下消防车道的设置位置 | 如果某建筑的消防车道设置不符合《防火通规》条文3.4.2，那么就不对该建筑的消防车道进行《防火通规》条文3.4.3的审查 |
| 8 | 《建规》条文5.4.2规定了不应设置生产车间和其他库房的建筑 | 如果某建筑设置了不符合《建规》条文5.4.2的生产车间或库房，那么就不对该生产车间或库房进行整本《建规》其他条文的审查 |
| 9 | 《防火通规》条文10.1.8规定了应该设置灯光疏散指示标志的建筑；《消防应急照明和疏散指示系统技术标准》(GB 51309—2018)[25](后文简称《应急照明规范》)条文3.2.8至3.2.11对灯光疏散指示标志设置做出具体要求 | 如果某建筑未按照《防火通规》条文10.1.8设置灯光疏散指示标志，那么就不对该建筑进行《应急照明规范》条文3.2.8至3.2.11的审查 |
| 10 | 同上 | 如果某建筑不属于《防火通规》条文10.1.8规定的应该设置灯光疏散指示标志的建筑，那么就不对该建筑进行《应急照明规范》条文3.2.8至3.2.11的审查 |
自动合规审查系统的用户主要是特定领域的专家，若系统不能有效表达和处理高层次规则间关系，那么系统最终输出的审查结果对人类专家而言，报告中可能会存在大量不必要报错。例如，对于上文第1个案例，若某建筑不属于《防火通规》中条文8.3.1规定的应设置火灾自动报警系统的4类建筑，那么系统不应对《设施通规》条文12.0.1至12.0.18进行审查。若系统对这些条文进行审查，将在审查结果报告中生成大量《设施通规》条文12.0.1至12.0.18(共18个条文)的误报信息。这些误报是未考虑高层次规则间关联关系的浅层次审查，与专家基于条文关联的全局理解后的预期审查结果不一致，影响系统的可用性。
基于计算机的规则表示形式一直是自动合规审查的研究重点和难点。随着计算机技术的不断进步，该形式也在不断演进。经典的规则表示形式是直接基于计算机编程语言进行编码实现，该方式存在编辑修改难度高、不透明、难重用等问题[26]。芬兰Solibri Model Checker[27]是一款商业BIM审查软件，其使用自定义的模板语言编写规则。该软件提供的自动合规审查能力依赖于领域专家和程序员的协作开发，而且规则并未以标准方式形式化，无法在应用程序外部使用[28-30]。决策表是一类典型的规则表示形式，Fenves[31]于1966年提出了可精确无歧义地进行规则表示的决策表方法，但未考虑规则之间的关系表示[32]。Tan等[33]于2010年提出了一种改进的决策表方法，可表示规则之间的引用关系，但无法有效表示和处理优先级、排除关系等更多类别的高层次规则间关系。
然而，上述提及的规则表示形式主要关注在单个条文内的单条规则的表示，对规则之间的关联关系关注较少。部分研究中涉及规则之间的关联关系，但仍局限于单个条文内规则之间的关系，不能应对表 1中列举的高层次规则间关系。
对这种高层次规则间关系进行计算机表示、把对这种关系的处理加入自动合规审查的标准化流程，将进一步提高自动合规审查结果与实际人工专家审查结果的一致性，也将进一步提高计算机最终输出的审查报告的可读性和逻辑性。
2 高层次规则间关系计算机表示范式
2.1 总体设计
经过对国内常用的建筑规范中的条文及其对应的计算机规则的分析，针对基于规则的自动合规审查系统的特性，本文对高层次规则间关系进行了抽象和总结，并归纳为以下3大类：
1) 如果规则A的审查结果为“合规”，那么规则B就无须进行审查。表 1中编号3所述条文对应的计算机规则之间的关系就是该类的典型例子。
2) 如果规则A的审查结果为“不合规”，那么规则B就无须进行审查。表 1中编号2、编号4、编号5所述条文对应的计算机规则之间的关系就是该类的典型例子。
3) 如果规则A中的“如果”部分不符合要求，那么规则B就无须进行审查。在基于规则的自动合规审查系统中，计算机规则是以一种“如果······那么······”的形式表达的。因此，规则的审查结果除了合规与不合规之外，还有一种被本文称为“不适用”的结果，即不符合规则的“如果”部分。表 1中编号1和编号10所述条文对应的计算机规则之间的关系就是该类的典型例子。
针对这3大类用例，本文提出高层次规则间关系的计算机表示范式。该范式包括“合规级联”、“不合规级联”和“不适用级联”3种模式，分别对上述的3大类情况进行计算机表示。为了执行这些模式所表示的高层次规则间关系，让这些关系作用于自动合规审查系统最终输出的结果，本文以SNL和BIMChecker为例设计了对应的范式执行引擎。
上述范式和范式执行引擎的设计基于模块化思想，并参考了软件工程常用的开闭原则和单一职责原则的核心观念[43]。开闭原则的核心思想是“对扩展开放、对修改封闭”，即在不修改现有代码的情况下，通过添加新代码来增加功能；单一职责原则指单个功能模块只负责一项职责，从而提高代码的可维护性和可读性。这让该表示范式不仅适用于SNL和BIMChecker，也适用于大量基于规则的自动合规审查方案，同时具有扩展到其他并非基于规则的方案中的潜力。
2.2 合规级联模式(CC)
合规级联模式的结构相对简单，该模式是为了描述2.1节中介绍的3大类高层次规则间关系中的第1类，即“如果规则A合规，那么规则B就无须进行审查”。为了描述这种关系，首先需要对规则A和规则B分别进行指定，本文使用一种合规级联规则指示器来实现对规则的指定。
合规级联规则指示器分为2类，分别指示规则A和B，后文简称指示器A和B。指示器A使用三元组IndicatorA=(S, ERS, ER)进行表示，指示器B使用四元组IndicatorB=(S, ERS, ER, C)进行表示。元组中元素的具体含义如表 2所示。合规级联模式中每个指示器A的指示粒度是可执行规则级别，一个指示器A可指示零至多条可执行规则。假设某可执行规则ERk所处的规范为Sk，所处的可执行规则集为ERSk，同时假设一个IndicatorAj=(Sj, ERSj, ERj)。那么ERk是否处于IndicatorAj的指示范围使用公式$ \operatorname{Match}\left( S_k , S_j\right) \wedge \operatorname{Match}\left(\mathrm{ERS}_k, \mathrm{ERS}_j\right) \wedge \operatorname{Match}\left(\mathrm{ER}_k, \mathrm{ER}_j\right) \Rightarrow \operatorname{In}\left(\mathrm{ER}_k, \operatorname{IndicatorA}_j\right)$ 进行判断。其中，Match(a, b)代表a的值符合b的约束，In(c, d)代表可执行规则c在指示器d的指示范围内。需要补充说明的是，指示器A和指示器B中的各个元素并不仅限于对应一个具体的值，也可以是一个如正则表达式的模式或者一个集合。通过这种方式，可实现单个指示器对多个目标的指定。对于合规级联中的指示器B，其指示的粒度为一个可执行规则中的具体被审查构件。假设某可执行规则ERu审查了一个构件Cu，并且ERu所处的规范为Su，所处的可执行规则集是ERSu，同时假设一个IndicatorAq=(Sq, ERSq, ERq, Cq)。那么Cu是否处于IndicatorAq的指示范围使用公式$ \operatorname{Match}\left( S_u , S_q\right) \wedge \operatorname{Match}\left(\mathrm{ERS}_u, \mathrm{ERS}_q\right) \wedge \operatorname{Match}\left(\mathrm{ER}_u, \mathrm{ER}_q\right)\wedge \operatorname{Match}\left(\mathrm{C}_u, \mathrm{C}_q\right) \Rightarrow \operatorname{In}\left(\mathrm{C}_q, \operatorname{IndicatorA}_q\right)$ 进行判断。此时In(e, f)代表被审查的构件e在指示器f的指示范围内。
表 2 合规级联规则指示器中元素的具体含义 |
| 元素符号 | 全称 | 具体含义 |
| S | Standard | 用于指定规范 |
| ERS | Executable Rule Set | 用于指定可执行规则集 |
| ER | Executable Rule | 用于指定可执行规则 |
| C | Component | 用于指定构件 |
一个合规级联模式使用CC=(IndicatorASet, IndicatorBSet, Id)进行表示，其中前2个元素由1个及以上的指示器A和1个及以上的指示器B组成，第3个元素Id用于唯一标识这个合规级联模式。前2个元素的元组表示为IndicatorASet=(IndicatorA1, IndicatorA2, ···, IndicatorAn)和IndicatorBSet=(IndicatorB1, IndicatorB2, ···, IndicatorBm)，其中n为指示器A的数量，m为指示器B的数量，满足n≥1, m≥1。合规级联模式CC的作用方式可用Pass(IndicatorA1)$ \wedge$ Pass(IndicatorA2)$ \wedge$ ···$ \wedge$ Pass(IndicatorAn) $ \Rightarrow$ Ignore(IndicatorB1)$ \wedge$ Ignore(IndicatorB2)$ \wedge$ ···$ \wedge$ Ignore(IndicatorBm)进行表示。其中Pass(IndicatorAg)表示指示器Ag所指向的所有可执行规则为合规状态，Ignore(IndicatorBh)表示不对指示器Bh所指向的所有可执行规则中所有指定的构件进行审查。该作用公式所表示的含义为：如果所有指示器A所指向的所有可执行规则的审查结果为合规，那么对于每一个指示器B，不对该指示器指向的所有可执行规则中的所有指定构件进行审查。
图 1展示了一个合规级联模式的例子，其含义为：如果规范S1中的可执行规则集ERS1中的可执行规则ER1合规，并且规范S2中的可执行规则集ERS2中的可执行规则ER2和ER3合规，那么不对规范S3中的可执行规则集ERS3中的所有可执行规则进行构件C1和构件C2的审查，同时也不对规范S4中的可执行规则集ERS4中的所有可执行规则进行任何构件的审查。特别地，当指示器元组中缺少某个元素时，则默认该缺少的元素的取值为“ALL”，假设该元素的所有可能的取值集合为{V1, V2, ···, Vi}，那么ALL=(V1, V2, ···, Vi)。
2.3 不合规级联模式(NCC)
不合规级联模式是为了对高层次规则间关系的第2类进行描述，即“如果规则A不合规，那么规则B就无须进行审查”。相比于合规级联模式，不合规级联模式的属性设计和执行逻辑更加复杂。不合规级联模式的表示公式为NCC=(IndicatorASet, IndicatorBSet, Id, Rel)。其中的元素IndicatorASet、IndicatorBSet以及Id的定义与2.2节中所介绍的合规级联模式保持一致。
NCC中的元素Rel用于描述规则A中不合规的构件将如何影响规则B的审查，其满足Rel∈{ALL, ROOM, FLOOR, BUILDING, SAME}。在不合规级联模式所表示的高层次规则间关系中，不合规的规则A中会存在不合规的构件，这些不合规的构件有时会影响规则B的审查。例如，如果想要表示“规则A中某一个房间构件报错，那么就不需要对这个报错的房间中的所有窗户构件进行规则B的审查”这一高层次规则间关系，就需要使用额外的元素对“构件处于同一个房间”这一关系进行表述。
Rel的5个取值是经过对条文、条文对应的计算机规则进行了充分分析后确定的，分别代表“所有关系”、“构件处于同一个房间”、“构件处于同一个楼层”、“构件处于同一个建筑”和“同一构件”。后4种关系是建筑自动合规审查中构件之间最普遍存在且对审查影响较大的关系，可以满足不合规级联模式对构件之间互相影响的表述需求；“所有关系”代表不关注规则A中不合规的构件对规则B审查的影响——只要规则A不合规，那么规则B的指定部分就不进行审查。
此外，另一个与合规级联模式的不同点在于，由于规则A的审查结果中存在具体的不合规的构件，不合规级联模式的IndicatorA是一个四元组，以实现对具体的不合规构件的指定。其公式表示为IndicatorA=(S, ERS, ER, C)，与IndicatorB保持一致。同时，不合规级联模式中对某构件是否处于IndicatorA或IndicatorB指示范围的判断方式与合规级联模式中构件是否处于IndicatorB指示范围的判断方式保持一致。
不合规级联模式的整体逻辑设计如下：假设IndicatorASet中IndicatorA的个数为n，首先对于该模式中的每一个指示器IndicatorAl(1≤l≤n)，找出对应的不合规的构件，组成不合规构件的集合NCSl={NCl1, NCl2, ···, NCly}。随后生成集合NCS=NCS1∩NCS2∩···∩NCSn。假设NCS中元素的总个数为r，遍历集合NCS，对于其中的每一个不合规构件NCt(1≤t≤r)，找到所有与NCt满足Rel关系的所有的其他构件，组成集合TCSt={TCt1, TCt2, ···, TCtw}。随后对于集合TCSt中的每一个构件TCtp(1≤p≤w)，如果TCtp在IndicatorBSet中任意一个指示器B所指示的范围内，那么就不对TCtp进行该指示器B所指示的所有可执行规则的审查。
图 3展示了一个不合规级联模式的简单例子，其含义为：对于每一个不符合规范S1中可执行规则集ERS1中可执行规则ER1或者ER2的C1构件，如果某C2构件与该不合规的C1构件处于同一个房间，那么就不对这个C2构件执行规范S2中可执行规则集ERS2里的所有可执行规则的审查。
一个实际的例子是，若要表示表 1中编号5所示的高层次规则间关系，即“如果某建筑不符合《防火通规》条文10.1.2中有关消防用电负荷等级的要求，那么就不对该建筑进行《防火通规》条文10.1.3的审查”，可使用不合规级联模式进行表示。使用不合规级联模式表示该关系将减少自动合规审查系统的无效报错。
经过实际自然语言规范的测试验证，不合规级联模式对国内建筑的消防相关规范具有普遍适用性。该模式的思想也可以进一步推广到其他的自动审查体系和规范体系中。
2.4 不适用级联模式(NAC)
不适用级联模式是针对基于规则的自动合规审查体系设计的一种相对特殊的模式。相比前2种模式，不适用级联模式用于描述高层次规则间关系的第3类。由于基于规则的体系以“如果······那么······”为格式对条文进行计算机规则表达，那么就会出现可执行规则的“如果”部分不满足要求的情况。
例如《防火通规》条文10.1.8对应的一部分可执行规则为“如果建筑是公共建筑，那么建筑有灯光疏散指示标志”，并且某个建筑并不是公共建筑，那么该可执行规则的“如果”部分就不能筛选出待执行“那么”部分审查的“建筑”构件，本文将这种情况定义为规则的“不适用”。当整个条文10.1.8对某个建筑不适用时，该建筑就无须设置灯光疏散指示标志，不需要对该建筑进行《应急照明规范》条文3.2.8至3.2.11对应的规则审查，不适用级联模式就是针对这种情况进行设计的。
不适用级联模式与合规级联模式有着完全相同的表示形式，一个不适用级联模式使用公式NAC=(IndicatorASet, IndicatorBSet, Id)进行表示，其中的每个元素的定义均与合规级联模式保持一致。NAC的作用方式使用公式NA(IndicatorA1)$\wedge$ NA(IndicatorA2)$\wedge$ ···$\wedge$ NA(IndicatorAn) $ \Rightarrow$ Ignore(IndicatorB1)$\wedge$ Ignore(IndicatorB2)$\wedge$ ···$\wedge$ Ignore(IndicatorBm)进行表示。其中NA(IndicatorAx)表示指示器Ax所指向的所有可执行规则均为不适用状态，Ignore(IndicatorBz)表示不对指示器Bz所指向的所有可执行规则中所有指定的构件进行审查。该作用公式所表达的含义为：如果所有指示器A所指向的所有可执行规则的审查结果均为不适用，那么对于每一个指示器B，不对该指示器指向的所有可执行规则中的所有指定构件进行审查。
不适用级联模式的IndicatorA是一个三元组，IndicatorB是一个四元组，这一点与合规级联模式保持一致。同时，对于某个可执行规则是否处于IndicatorA的指示范围的判断以及对于某个构件是否处于IndicatorB的指示范围的判断与合规级联模式保持一致。
除了上述与灯光疏散指示标志审查相关的实例，不适用级联模式的另一个应用案例是用于表示表 1中编号1的高层次规则间关系。该案例中所描述的“某建筑不是《防火通规》条文8.3.1中规定的需设置火灾自动报警系统的建筑”是典型的条件“不适用”情况。
2.5 高层次规则间关系执行引擎的设计
2.2至2.4节详细介绍了本文提出的3种高层次规则间关系的表示模式，这些模式可以将高层次规则间关系表示为计算机能够理解的形式。为了让这种关系作用于自动合规审查系统最终输出的审查报告中，还需要一个相应的高层次规则间关系执行引擎(后文简称为执行引擎)。本节将会以SNL和BIMChecker自动合规审查工具(后文简称为BIMChecker)为例，介绍如何让基于规则的自动合规审查体系拥有完备的高层次规则间关系处理能力。
一个不包含高层次规则间关系处理逻辑的BIMChecker的执行流程框架如图 4所示。
不包含高层次规则间关系处理逻辑的BIMChecker的总体执行流程框架可以分为如下3个主要部分。
1) 规则信息抽取建模和建筑模型信息抽取建模。该部分对应标准化流程中的第1和2步，即“将自然语言条文转化为计算机能够理解的规则”和“将建筑相关信息转化为计算机能够理解的建筑语义模型”。BIMChecker使用SNL作为计算机规则的载体，每条SNL就是一条可执行规则。将条文抽取为SNL的过程可以由领域专家完成，也可以借助基于规则或人工智能的自动化方法进行辅助生成。对于建筑中的信息提取和建模，BIMChecker使用一种名为BCJSON的JSON格式来记录和表示建筑的各个构件的信息以及构件之间的关系信息，由BIM模型生成BCJSON可以借助特定工具完成。
2) 规则的推理和执行。该部分对应标准化流程的第3步，即“在建筑模型上执行规则审查”。BIMChecker会将SNL编译为对应的SPARQL语句，同时将代表建筑信息的BCJSON转化为OWL模型，使用Jena在OWL模型上执行SPARQL查询并获得查询结果。对于一些需要计算或推理的审查需求，BIMChecker会基于查询结果进行进一步的推理和运算，最终得到每条SNL的审查结果。
3) 结果的汇总和输出。BIMChecker会根据每条SNL所对应的条文、条文所对应的规范汇总整理审查结果，输出一个符合自然语言条文组织结构的JSON审查报告。
在高层次规则间关系执行引擎的具体实现中，该执行引擎的输入是BIMChecker输出的审查报告JSON文件以及存储了3类级联模式的JSON配置文件。执行引擎会解析审查报告文件和级联模式配置文件，并按照配置文件中描述的3类级联模式对审查报告中对应的结果进行处理。
例如，对于图 5的不适用级联模式的例子，BIMChecker审查引擎在输出审查报告JSON文件后，会调用执行引擎进行高层次规则间关系的处理。执行引擎会执行如下操作：1) 对JSON配置文件进行读取和解析，获取该不适用级联模式的具体内容。2) 读取审查报告JSON文件，获取审查报告中《防火通规》的可执行规则集8.3.1中所有可执行规则的结果，判断这些可执行规则的审查结果是否均为“不适用”。如果均为“不适用”，则进行下一步操作；否则对该不适用级联模式的执行操作结束。3) 获取审查报告《设施通规》中编号在12.0.1至12.0.18之间的全部可执行规则集，对于每个可执行规则集的每一个可执行规则，移除所有的不合规构件，并对该可执行规则的审查结果进行标记。4) 整理汇总审查结果，重新生成结果统计数据等信息，得到新的审查报告JSON文件。
3 实验和实例展示
3.1 实验
表 3 对高层次规则间关系实例进行表示的结果 |
| 编号 | 级联模式 | IndicatorASet | IndicatorBSet | Rel |
| 1 | NAC | IndicatorA1=(防火通规, 8.3.1, ALL) | IndicatorB1=(设施通规, 12.0.1-12.0.18, ALL, ALL) | — |
| 2 | NCC | IndicatorA1=(建规, 5.5.15, ALL, 房间) | IndicatorB1=(建规, 5.5.17-3, 疏散门距离, ALL) | ROOM |
| 3 | CC | IndicatorA1=(建规, 5.5.8, ALL) | IndicatorB1=(建规, 5.5.9, ALL, 防火分区) | — |
| 4 | NCC | IndicatorA1=(防火通规, 10.1.1, 用电负荷, 建筑) | IndicatorB1=(防火通规, 10.1.2, 用电负荷, 建筑)IndicatorB2=(防火通规, 10.1.3, 用电负荷, 建筑) | ALL |
| 5 | NCC | IndicatorA1=(防火通规, 10.1.2, 用电负荷, 建筑) | IndicatorB1=(防火通规, 10.1.3, 用电负荷, 建筑) | ALL |
| 6 | NCC | IndicatorA1=(防火通规, 5.2.1, 耐火等级, 建筑) | IndicatorB1=(防火通规, 5.2.2, 耐火等级, 建筑)IndicatorB2=(防火通规, 5.2.3, 耐火等级, 建筑) | ALL |
| 7 | NCC | IndicatorA1=(防火通规, 3.4.2, 消防车道, 建筑) | IndicatorB1=(防火通规, 3.4.3, 消防车道, ALL) | ALL |
| 8 | NCC | IndicatorA1=(建规, 5.4.2, ALL, 房间) | IndicatorB1=(建规, ALL, ALL, ALL) | SAME |
| 9 | NCC | IndicatorA1=(防火通规, 10.1.8, 灯光疏散指示标志, 建筑) | IndicatorB1=(应急照明规范, 3.2.8-3.2.11, ALL, ALL) | ALL |
| 10 | NAC | IndicatorA1=(防火通规, 10.1.8, 灯光疏散指示标志) | IndicatorB1=(应急照明规范, 3.2.8-3.2.11, ALL, ALL) | — |
表 4 实际项目上的实验结果 |
| 项目编号 | 项目描述 | 项目面积/m2 | CC生效 | NCC生效 | NAC生效 | 审查耗时/s | 规则间关系耗时/s | 生效模式编号 |
| 1 | 公共建筑，某餐饮管理公司装修项目 | 1 151.9 | T | T | T | 93.5 | 0.94 | 1、2、3 |
| 2 | 公共建筑，某按摩保健公司装修项目 | 786.5 | T | T | T | 48.1 | 0.62 | 1、2、3 |
| 3 | 公共建筑，某文化传播公司装修项目 | 402.0 | F | T | T | 36.2 | 0.67 | 1、2 |
| 4 | 公共建筑，某沐足保健中心装修项目 | 1 207.7 | T | T | T | 23.6 | 0.58 | 1、2、3 |
| 5 | 公共建筑，某酒店管理公司装修项目 | 2 400.0 | F | T | T | 22.7 | 0.71 | 1、2 |
| 6 | 公共建筑，某网吧建设项目 | 287.5 | F | T | T | 17.3 | 0.68 | 1、2、9 |
| 7 | 公共建筑，某游乐有限公司装修项目 | 26 012.3 | F | T | T | 37.2 | 0.73 | 1、2 |
| 8 | 住宅，某高层住宅楼建设项目 | 22 041.8 | F | T | T | 104.6 | 1.07 | 1、8 |
| 9 | 住宅，某住宅楼建设项目 | 8 575.2 | F | F | T | 94.0 | 0.93 | 1、10 |
| 10 | 公共建筑，某休闲中心装修项目 | 1 100.4 | F | T | T | 31.5 | 0.66 | 1、2 |
| 11 | 公共建筑，某餐饮有限公司装修项目 | 516.0 | F | T | T | 21.3 | 0.60 | 1、2、9 |
| 12 | 公共建筑，某快餐餐厅装修项目 | 216.2 | F | T | T | 18.9 | 0.61 | 1、4、5 |
| 13 | 公共建筑，某个体工商户保健馆装修项目 | 1 957.8 | F | F | T | 15.5 | 0.78 | 1、10 |
| 14 | 工业建筑，某厂房建设项目 | 15 385.0 | F | F | T | 66.2 | 0.83 | 1 |
| 15 | 工业建筑，某邮储仓库建设项目 | 12 429.2 | F | T | F | 49.1 | 0.71 | 6、7 |
表 4中的“CC生效”、“NCC生效”和“NAC生效”代表在该项目中，至少存在1个对应种类的级联模式生效。例如，某项目的“NAC生效”为T代表该项目在实验中至少有1个不适用级联模式生效，该模式是表 3中编号1或10对应的不适用级联模式。级联模式生效的定义如下：对于合规级联模式，每一个IndicatorA指向的可执行规则均为合规；对于不适用级联模式，每一个IndicatorA指向的可执行规则均为不适用；对于不合规级联模式，IndicatorA生成的NCS集合不为空(即存在符合IndicatorA指定的预期中的不合规构件)。此外，对于所有模式，生效需要同时满足的另一个条件是级联模式中每个IndicatorB所指向的目标审查结果均被执行引擎符合预期地处理，例如在审查报告中对相应的可执行规则进行标记，或是在审查报告中移除相应可执行规则的目标构件审查结果。
3.2 实例展示
本节将使用“图智”系统结合实际案例对高层次规则间关系的执行效果进行展示。图 7为一个用于展示不合规级联模式的项目中建筑的某层对应的平面图。其中，位于图 7上半部分的办公室不满足《建规》条文5.5.15对疏散门数量的要求。按照该条文，该办公室位于公共建筑中，面积大于50 m2，且疏散门净宽度小于1.4 m，因此该办公室应设置2个疏散门。然而，实际上此办公室只有1个疏散门，因此“图智”系统给出的报告中，该办公室不符合《建规》条文5.5.15，如图 8左边部分所示。同时, 位于图 7上半部分的办公室不满足《建规》条文5.5.17-3对疏散门与房间最远点距离的要求。因此当不考虑高层次规则间关系时，“图智”系统给出的报告中条文5.5.17-3的结果也是不合规，如图 8右边部分所示。
当启用本文中的执行引擎并给定相应的不合规级联模式配置JSON文件时，“图智”输出的审查报告将会考虑到这2个条文对应的高层次规则间关系，并给出符合实际条文审查逻辑的结果。如图 9所示，此时左边的结果栏中条文5.5.15的结果仍为不合规，但右边条文5.5.17-3的结果中与相应的办公室构件有关的审查结果被移除，最终该条文的整体结果为合规，符合实际建筑消防审查中业务专家经过高层次条文理解后给出的审查结果。
4 结论
本文提出了一种面向基于规则的自动合规审查体系的高层次规则间关系的表示方法，通过“合规级联”、“不合规级联”和“不适用级联”3种模式，构建了一种计算机能够理解的高层次规则间关系表示体系。结合相应的执行引擎，让基于规则的自动合规审查系统能够输出更符合人类专家审查思维的审查报告。本文对这3种模式进行了详细介绍，并以SNL和BIMChecker为例子介绍了对应的执行引擎整合方案。同时，本文在设计该表示方法时结合了先进设计原则，使此表示方法及对应的执行引擎可以无侵入式地整合进其他的自动合规审查解决方案中，使本文提出的方法有优异的适用性。
本文主要以建筑领域语义模型审查为切入点，但提出的表示方法的适用范围不仅限于建筑领域。未来的研究方向之一是将该方法推广到例如法律、能源、环境、医疗、制造业等需要自动合规审查体系的行业。本文发现，如果某个领域的规则能够被组织为本文中提到的“规范-可执行规则集-可执行规则-构件”4级结构，并能够以“IF...THEN...”基于规则的表示形式表示可执行规则，那么本文提出的方法就能够顺利且无侵入地在对应的自动合规审查系统中运用。
此外，由于使用基于机器学习的NLP技术自动进行高层次规则间关系的提取通常对数据规模的要求较高，目前本文通过领域专家人工提取的方式来获取此关系。另一个可能的未来研究方向是使用基于机器学习的NLP技术从自然语言规范中提取这种关系，并自动用三种级联模式表达。
