CN111524008A - 一种规则引擎及其建模方法、建模装置及指令处理方法 - Google Patents

Abstract

本申请公开了一种规则引擎及其建模方法、建模装置及指令处理方法，建模方法包括：逐条分解规则，获得规则要素；根据规则要素确定规则间的依赖关系；根据依赖关系获得规则流。本申请将规则细化成规则要素及规则要素构成的关系式，以此为基础确定不同的规则之间的依赖关系，进而形成粒度很小的规则流，为多条指令的并行处理提供基础，大大提高了业务系统的并行处理能力，时效性大大提升，实现了纳秒量级的处理速度，实现了各类规则的实时检查、实时定价估值、实时清算结算等各种业务处理，业务处理速度的提升使得各种事后处理的过程移到事前或事中处理，实现了全业务流平行实时端到端事务处理。

Description

一种规则引擎及其建模方法、建模装置及指令处理方法

技术领域

本申请涉及规则管理技术领域，具体涉及一种规则引擎及其建模方法、建模装置及指令处理方法。

背景技术

金融业务处理包含了大量业务规则，从国家宪法、监管部门制订的行业规则、公司制定的业务实施规则等，到日常金融业务中的每一笔业务的处理，都包含了大量规则的定义、执行、相关的数据的管理及其与很多周围系统的集成。

以交易业务处理为例，通常分为前台、中台、后台等各个不同的阶段，交易业务的前台主要包括客户订单管理、合规检查和风险管理等交易前的各项检查、交易策略管理、订单路由和执行管理。交易中台的业务处理主要包括获取成交回报、完善、丰富和标准化成交回报记录中的各项内容，定价和估值、风险管控等。交易后台的业务处理主要包括清算结算、交收管理等。目前前台、中台、后台各个层面的大量规则都用软件方法实现，对中台、后台而言，处理容量大，一致性非常重要，表面上时效性似乎不是关键，但实际上是制约处理过程完整性的非常重要的因素之一。对于前台而言，交易的每一步的处理时效更为关键。目前，金融业务处理系统的并行能力不足，交易的时效性难以得到保障。

另外，目前金融业务中大量规则化处理，对日常业务和运营操作十分重要，然而现在的软件技术系统在开发和升级过程中通常会面临很多难题：

1、需求响应时间长：当前采购科技公司的平台产品，业务逻辑和算法基本集成在代码中，核心能力掌控在科技公司手里，新业务或新需求需要业务人员先和科技公司开发人员普及业务知识、讲透功能需求，甚至很多场合，技术团队为了避免业务人员经常修改需求，会要求提供白纸黑字的需求说明书才开始着手开发流程，这违背了很多金融业务随市场多变的行业规律。

2、难以实现定制化：科技公司产品一般提供标准的、通用的批量产品，从开发成本、提高绩效、实施标准化维护达到其自身运维的便利性出发，科技公司更愿意综合多个用户需求，选择一个折中的落地方案实施，金融行业中的各个机构很难得到最适合自己的规则引擎。

3、费用压力大：商用金融业务规则引擎一般初始引入费用较合理，但后期新业务需求或功能变更，时常引起微小增量功能的完善导致大幅成本，造成持续运营成本压力。因为商用系统产品一般小而全，功能冗余，有时候为了小部分业务必需的差异功能需要购买功能稍有差异的多个系统，大量重复功能被浪费了。

4、版本质量不高：现有的系统平台开发模式下，开发人员虽说要求既懂技术又懂业务，但主要还是在技术领域，一些行业经验不足的开发人员在把业务逻辑融入代码时往往顾此失彼，对所开发业务的人、机、物、法、环境理解不透，版本质量低、返工多；

5、依赖外部采购：金融业务用户通常会与科技公司有长期深度的合作，科技公司自己的治理水平和发展对金融业务用户的稳定运营有极大影响。科技公司人员的流动经常会导致响应时间延长、服务质量下降情况。

综上，由于规则化处理依赖于外部技术开发人员的软件编程来完成，对外部技术开发人员的依赖性很强，随之带来了很多问题。

发明内容

本申请的目的在于提供一种规则引擎及其建模方法、建模装置及指令处理方法，大大提高了业务系统的并行处理能力，时效性大大提升。

本申请提供了一种规则引擎的建模方法，包括：逐条分解规则，获得规则要素；根据规则要素确定规则间的依赖关系；根据依赖关系获得规则流。

其中，优选地，还包括：根据规则流编辑现场可编程门阵列芯片。

其中，优选地，还包括将规则和规则流输入人工智能模块进行训练，并根据训练结果更新现场可编程门阵列芯片。

其中，优选地，确定规则间的依赖关系包括：将第一规则与其他规则组成第一分组，根据规则要素确定第一规则与其他规则是否具有依赖关系；若第一规则与至少两个第二规则有依赖关系，则重复如下步骤直至第二分组中不存在有依赖关系的第二规则：将至少两个第二规则组成第二分组，并遍历第二分组，确定两两之间是否具有依赖关系；若第二分组中存在具有至少两个有依赖关系的规则的第二规则，则用该第二规则更新第一规则，用与更新后的第一规则具有依赖关系的第二规则更新第二规则。

其中，优选地，根据依赖关系获得规则流包括：具有依赖关系的两个规则形成串行规则流；不具有依赖关系的两个规则形成并行规则流。

本申请还提供了一种规则引擎的建模装置，包括规则分解模块、依赖关系确定模块、规则流获得模块；其中，规则分解模块逐条分解规则，获得规则要素；依赖关系确定模块根据规则要素确定规则间的依赖关系；规则流获得模块根据依赖关系获得规则流。

其中，优选地，还包括编辑模块，编辑模块根据规则流编辑现场可编程门阵列芯片。

其中，优选地，还包括训练模块，训练模块将规则和规则流输入人工智能模块进行训练，并根据训练结果更新现场可编程门阵列芯片。

其中，优选地，依赖关系确定模块包括第一分组子模块、第二分组子模块以及更新子模块；其中，第一分组子模块将第一规则与其他规则组成第一分组，根据规则要素确定第一规则与其他规则是否具有依赖关系；第二分组子模块与第一分组子模块和更新子模块连接，若第一规则与至少两个第二规则有依赖关系，则第二分组子模块将至少两个第二规则组成第二分组，并遍历第二分组，确定两两之间是否具有依赖关系；更新子模块与第二分组子模块连接，若第二分组中存在具有至少两个有依赖关系的规则的第二规则，则更新子模块用该第二规则更新第一规则，用与更新后的第一规则具有依赖关系的第二规则更新第二规则。

本申请还提供了一种基于规则引擎的指令处理方法，包括：将多条指令输入规则引擎；将每条指令分解为多个参数，根据参数分析多条指令之间的第一依赖关系；将参数及第一依赖关系输入规则引擎模型；规则引擎模型根据第一依赖关系处理多条指令；根据参数分析规则引擎模型输出的多条指令的处理结果之间的第二依赖关系；根据第二依赖关系组合多条指令的处理结果，作为规则引擎的最终输出结果。

其中，优选地，参数包括用户信息、指令对应的规则来源、指令对应的操作对象、指令的输出对象；第一依赖关系包括每两条指令的用户信息之间的依赖关系、每两条指令对应的规则来源之间的依赖关系、每两条指令的操作对象之间的依赖关系。

其中，优选地，参数包括指令的输出对象；第二依赖关系包括每两条指令的输出对象之间的依赖关系。

其中，优选地，若两条指令对应的规则来源相同，则该两条指令对应的规则来源具有第一依赖关系。

其中，优选地，若两条指令的操作对象相同，则该两条指令的操作对象具有第一依赖关系。

其中，优选地，若两条指令的输出对象相同，则该两条指令的输出对象具有第二依赖关系。

其中，优选地，规则引擎模型根据第一依赖关系处理多条指令，具体包括：若两条指令的某一参数的第一依赖关系成立，则规则引擎模型合并执行该两条指令的该参数对应的规则流；否则，规则引擎模型并行执行该两条指令的该参数对应的规则流。

其中，优选地，根据第二依赖关系组合多条指令的处理结果，包括：若两条指令的某一参数的第二依赖关系成立，则将规则引擎模型输出的该两条指令的该参数对应的处理结果进行组合。

本申请还提供一种规则引擎，包括指令预处理模块、规则引擎模型以及处理结果预处理模块；指令预处理模块接收多条指令，并将每条指令分解为多个参数，根据参数分析多条指令之间的第一依赖关系；规则引擎模型与指令预处理模块连接，规则引擎模型接收参数及第一依赖关系，并根据第一依赖关系处理多条指令；处理结果预处理模块根据参数分析多条指令的输出结果之间的第二依赖关系，并根据第二依赖关系组合多条指令的处理结果，作为规则引擎模型的最终输出结果。

其中，优选地，规则引擎模型以规则流的形式处理指令，并且规则引擎模型基于现场可编程门阵列芯片。

其中，优选地，参数包括用户信息、指令对应的规则来源、指令对应的操作对象、指令的输出对象；第一依赖关系包括每两条指令的用户信息之间的依赖关系、每两条指令对应的规则来源之间的依赖关系、每两条指令的操作对象之间的依赖关系。

其中，优选地，参数包括指令的输出对象；第二依赖关系包括每两条指令的输出对象之间的依赖关系。

本申请的技术效果如下：

1、本申请将规则细化成规则要素及规则要素构成的关系式，以此为基础确定不同的规则之间的依赖关系，进而形成粒度很小的规则流，为多条指令的并行处理提供基础，大大提高了业务系统的并行处理能力，时效性大大提升，实现了纳秒量级的处理速度，实现了各类规则的实时检查、实时定价估值、实时清算结算等各种业务处理，业务处理速度的提升使得各种事后处理的过程移到事前或事中处理，实现了平行实时全业务流端到端事务处理。

2、本申请的规则引擎大量收录规则中的规则要素作为引擎的标准字段，使添加、修改和更新规则的处理简单化，降低了规则引擎的维护和更新困难，解除了软件编程语言对业务人员的限制，实现了业务人员与外部技术开发人员的解耦，也使得

3、本申请利用FPGA芯片可编程、低功耗、低时延的特性实现了规则的灵活设置，实现了业务规则定义参数化、公式化、流程化，规则执行和处理过程事务化、平行化、流水化，在大量新加或修改业务规则时，只要添加或修改规则定义，实现了使用中业务规则定义所需的各种灵活度，发挥了硬件的高速平行处理特点，省去了大量编写软件的工作，降低了对操作人员的专业度，消除和降低了传统技术平台的软件开发和维护及管理成本。同时，FPGA硬件的横向可扩充性使硬件规则引擎几乎不受用户数量限制。

4、对于证券等金融业务平台来说，本申请的FPGA硬件规则引擎还可以与簿记平台对接，FPGA硬件规则引擎提供了全面、集中、统一的自动化合规风控管理体系，使证券公司统一持仓管理，日终上账，日间对账防透支，解决了证券公司因业务条线和平台分割、职能分散、自动化不足等原因造成的操作风险。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的规则引擎的建模方法的流程图；

图2是本申请实施例提供的确定规则间的依赖关系的流程图；

图3是线性规则流的示意图；

图4是星形规则流的示意图；

图5是本申请实施例提供的规则引擎的建模装置的结构图；

图6是本申请实施例提供的基于规则引擎的指令处理方法的流程图；

图7是本申请提供的指令处理方法的应用场景实例的示意图；

图8是本申请实施例提供的规则引擎的结构图。

具体实施方式

下面结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

实施例一

图1是本申请实施例提供的规则引擎的建模方法的流程图。如图1所示，建模方法包括如下步骤：

S110：逐条分解规则，获得规则要素。

每条规则由自然语言表达出来。作为一个实施例，分解规则时，将规则按照自然语言的意思划分意群，然后在意群中，按照执行顺序等划分执行单元，在执行单元中，按照词汇含义划分字段，将字段作为规则要素。具体地，例如，规则中，被检查客体(如用户和账户)、被检查客体的关联客体(如与用户有关联的其他用户、用户的不同账户、账户的关联账户)、被检查客体的属性(如账户所属的地区、级别)、客体应满足的规则要求等均为规则要素。

例如：在特殊的产品系列中，需要检查和防止产生几个关联产品中在交易中形成违规的关联交易时，模型将会把这条规则逐步拆解成如下规则要素：

产品名称、产品代码、交易主账户、关联账户列表、对敲违规、集中度违规、透支违规、禁止买卖违规、有意抬高价格违规、有意压低价格违规等等

可以理解，每条规则可以分解出多个规则要素。

S120：根据规则要素确定规则间的依赖关系。

图2是本申请实施例提供的确定规则间的依赖关系的流程图。本申请中，针对每条规则，均执行图2所示的步骤。依照图2，将每条规则作为第一规则，对该规则与其他规则的依赖关系进行分层分析。

如图2所示，确定规则间的依赖关系包括如下步骤：

S1201：将第一规则与其他规则组成第一分组，根据第一分组中所有规则的规则要素确定第一规则与其他规则是否具有依赖关系。

该步骤中，分析第一规则与其他所有的规则之间的关联关系，确定该规则与其他规则之间的依赖关系，例如：完成某一条规则后才能根据这条规则的某个规则要素的处理结果完成第一规则或完成第一规则后需要根据第一规则的某个规则要素的处理结果完成另一条规则，则这两条规则均与第一规则有依赖关系。

S1202：判断第一规则是否与至少两个第二规则有依赖关系。若是，则执行S1203。否则，说明不存在与第一规则有依赖关系的规则，则执行S1204：输出依赖关系结果。

S1203：将上述至少两个第二规则组成第二分组，并遍历第二分组，确定两两之间是否具有依赖关系。该步骤进一步分析与第一规则有依赖关系的多个规则之间的依赖关系。作为举例，如图4所示，规则1作为第一规则，与其有依赖关系的规则有规则2、3和4。该步骤对规则2、3和4两两之间的依赖关系进行分析。

S1205：判断第二分组中是否存在具有至少两个有依赖关系的规则的第二规则。若是，则执行S1207；否则，说明第二分组中的规则间不存在依赖关系，则执行S1206：输出依赖关系结果。

作为举例，请参见图4，规则3与规则2和4有依赖关系，与规则5没有依赖关系。这种情况下，执行S1207。

S1207：用该第二规则更新第一规则，用与更新后的第一规则具有依赖关系的第二规则更新第二规则，并返回S1203。

作为举例，请参见图4，S1207中，将规则3作为第一规则，规则2和4作为第二规则。返回S1203，规则2和4组成第二分组，分析规则2与规则4之间是否存在依赖关系。

重复执行S1203-S1207，直至第二分组中不存在有依赖关系的规则。

图2中，输出的依赖关系结果包括第一规则与所有的其他规则之间的依赖关系，即第一规则与哪些规则具有依赖关系，这些规则之间是否具有依赖关系；以及第一规则与哪些规则不具有依赖关系。

可以理解，本申请中，第一规则与第二规则的依赖关系包括第一规则依赖于第二规则和第二规则依赖于第一规则。

本申请通过规则要素层层分解规则，以便在最小的粒度内分析规则之间的依赖关系。

S130：根据依赖关系获得规则流。具体地，具有依赖关系的两个规则形成串行规则流，不具有依赖关系的两个规则形成并行规则流。

作为举例，如图3所示，规则1与2、规则2与3、规则3与4之间分别存在依赖关系，则规则1与2、规则2与3、规则3与4分别形成了串行规则流，规则1、2、3、4整体形成了一个串行规则流，该规则流中任何规则均没有其他依赖关系的规则，这样的规则流为线性规则流。

作为举例，如图4所示，规则1与2、3、4、5之间存在依赖关系，则规则1与2、规则1与3、规则1与4、规则1与5之间形成串行规则流，规则2、3、4与规则5之间均不存在依赖关系，因此规则2与5、规则3与5、规则4与5分别形成并行规则流。规则6-12之间的规则流也依据相互间的依赖关系确定为串行规则流或并行规则流。由于规则1存在多个并行的下行规则，因此图4所示的规则流称为星形规则流。

优选地，最终形成的规则引擎模型中，线性规则流以矩阵的形式表达。

优选地，本申请还包括S140。

S140：根据规则流编辑现场可编程门阵列芯片。

本申请依托现场可编程门阵列(Field-Programmable Gate Array，FPGA)芯片实现规则引擎的建模。具体地，根据S130获得的规则流编辑FPGA芯片中的门电路，使FPGA芯片按照规则流实现规则的检查。通过配置的FPGA芯片形成规则引擎模型。

FPGA具有硬件可编程、低功耗、低时延的特性，本申请以FPGA芯片硬件作为载体，实现了多个小粒度规则流的平行处理，可并行处理和流水操作，有效发挥平行处理硬件的优势，使得规则引擎模型的处理容量大大增加，几乎不受用户数量限制，同时降低了规则处理的延迟。

本申请中，进一步地，优选地，还执行S150和S160。

S150：将规则和规则流输入人工智能模块进行训练。

S160：根据训练结果更新现场可编程门阵列芯片。

在该优选实施例中，规则引擎包括规则引擎模型和人工智能模块，二者通过TCP/IP或PCIe标准化API模式通信。

本申请通过人工智能模块实现机器学习，指导和优化规则检查的业务配置，使得规则的分解和检查达到最优化。

规则引擎大量收录规则中的规则要素作为引擎的标准之一，也就是说用自然语言(非计算机语言)作为规则引擎的标准词库。在更新、修改和添加的规则时，业务人员可参照模型的标准规则要素将新的规则描述出来输入规则引擎模型，规则引擎模型将规则分解为标准的规则要素，从而形成新的规则流。本申请使新规则的处理简单化，降低了规则引擎的维护和更新困难，解除了软件编程语言对业务人员的限制，实现了业务人员与外部技术开发人员的解耦。

实施例二

本申请还提供了与上述建模方法匹配的建模装置。图5是本申请实施例提供的规则引擎的建模装置的结构图。

如图5所示，建模装置包括规则分解模块510、依赖关系确定模块520以及规则流获得模块530、编辑模块540和训练模块550。

规则分解模块510逐条分解规则，获得规则要素。

每条规则由自然语言表达出来。作为一个实施例，分解规则时，将规则按照自然语言的意思划分意群，然后在意群中，按照执行顺序等划分执行单元，在执行单元中，按照词汇含义划分字段，将字段作为规则要素。具体地，例如，规则中，被检查客体(如用户和账户)、被检查客体的关联的客体(如与用户有关联的其他用户、用户的不同账户、账户的关联账户)、被检查客体的性质(如账户所属的地区、级别)、客体应满足的规则要求等均为规则要素。

可以理解，每条规则可以分解出多个多规则要素。

依赖关系确定模块520与规则分解模块510连接，依赖关系确定模块520根据规则要素确定规则间的依赖关系。

具体地，依赖关系确定模块包括第一分组子模块、第二分组子模块、更新子模块以及输出模块；

其中，第一分组子模块将第一规则与其他规则组成第一分组，根据规则要素确定第一规则与其他规则是否具有依赖关系。

具体地，第一分组子模块分析第一规则与其他所有的规则之间的关联关系，确定该规则与其他规则之间的依赖关系，例如：完成某一条规则后才能根据这条规则的某个规则要素的处理结果完成第一规则或完成第一规则后需要根据第一规则的某个规则要素的处理结果完成另一条规则，则这两条规则均与第一规则有依赖关系。

第二分组子模块与第一分组子模块和更新子模块连接，若第一规则与至少两个第二规则有依赖关系，则第二分组子模块将至少两个第二规则组成第二分组，并遍历第二分组，确定两两之间是否具有依赖关系。

第二分组子模块进一步分析与第一规则有依赖关系的多个规则之间的依赖关系。作为举例，如图4所示，规则1作为第一规则，与其有依赖关系的规则有规则2、3和4。该步骤对规则2、3和4两两之间的依赖关系进行分析。

更新子模块与第二分组子模块连接，若第二分组中存在具有至少两个有依赖关系的规则的第二规则，则更新子模块用该第二规则更新第一规则，用与更新后的第一规则具有依赖关系的第二规则更新第二规则。

作为举例，请参见图4，规则3与规则2和4有依赖关系，与规则5没有依赖关系。这种情况下，将规则3作为第一规则，规则2和4作为第二规则，并将该信息传输给第二分组子模块，第二分组子模块将规则2和4组成第二分组，分析规则2与规则4之间是否存在依赖关系。

循环执行第二分组子模块和更新子模块的，直至第二分组中不存在有依赖关系的规则，使得与第一规则有依赖关系的规则逐层细分，逐渐减小有依赖关系的规则的粒度。

输出模块与第一分组子模块和第二分组子模块连接，若第一分组中与第一规则有依赖关系的第二规则不存在或只有一个、或者第二分组中不存在具有至少两个有依赖关系的规则的第二规则，则输出模块输出依赖关系结果。

输出的依赖关系结果包括第一规则与所有的其他规则之间的依赖关系，即第一规则与哪些规则具有依赖关系，这些规则之间是否具有依赖关系；以及第一规则与哪些规则不具有依赖关系。

可以理解，本申请中，第一规则与第二规则的依赖关系包括第一规则依赖于第二规则和第二规则依赖于第一规则。

规则流获得模块530与依赖关系确定模块520连接，规则流获得模块530根据依赖关系获得规则流。

具体地，具有依赖关系的两个规则形成串行规则流，不具有依赖关系的两个规则形成并行规则流。

作为举例，如图3所示，规则1与2、规则2与3、规则3与4之间分别存在依赖关系，则规则1与2、规则2与3、规则3与4分别形成了串行规则流，规则1、2、3、4整体形成了一个串行规则流，该规则流中任何规则均没有其他依赖关系的规则，这样的规则流为线性规则流。

作为举例，如图4所示，规则1与2、3、4、5之间存在依赖关系，则规则1与2、规则1与3、规则1与4、规则1与5之间形成串行规则流，规则2、3、4与规则5之间均不存在依赖关系，因此规则2与5、规则3与5、规则4与5分别形成并行规则流。规则6-12之间的规则流也依据相互间的依赖关系确定为串行规则流或并行规则流。由于规则1存在多个并行的下行规则，因此图4所示的规则流称为星形规则流。

优选地，最终形成的规则引擎模型中，线性规则流以矩阵的形式表达。

编辑模块540与规则流获得模块530连接，编辑模块540根据规则流编辑现场可编程门阵列芯片，通过配置的FPGA芯片形成了规则引擎模型。

具体地，根据规则流获得模块获得的规则流编辑FPGA芯片中的门电路，使FPGA芯片按照规则流实现规则的检查。通过配置的FPGA芯片形成了规则引擎模型。

训练模块550与编辑模块540连接，训练模块550将规则和规则流输入人工智能模块进行训练，并并根据训练结果更新FPGA芯片。

在该优选实施例中，规则引擎包括规则引擎模型和人工智能模块，二者通过TCP/IP或PCIe标准化API模式通信。

本申请通过人工智能模块实现机器学习，指导和优化规则检查的业务配置，使得规则的分解达到最优化。

实施例三

本申请还提供了一种规则引擎。图8是本申请实施例提供的规则引擎的结构图。如图8所示，规则引擎包括指令预处理模块810、规则引擎模型820和处理结果预处理模块830。

指令预处理模块810接收多条指令，并将每条指令分解为多个参数，根据参数分析接收的多条指令之间的第一依赖关系。

具体地，参数包括用户信息、指令对应的规则来源(如合规规则、风控规则)、指令对应的操作对象(如某一支股票)、指令的输出对象(如深交所或上交所)等。

第一依赖关系包括每两条指令的用户信息之间的依赖关系、每两条指令对应的规则来源之间的依赖关系、每两条指令的操作对象之间的依赖关系等。

具体地，例如，若两条指令对应的规则来源相同，则该两条指令对应的规则来源具有第一依赖关系。若两条指令的操作对象相同，则该两条指令的操作对象具有第一依赖关系。

规则引擎模型820与指令预处理模块810连接，规则引擎模型820接收参数及第一依赖关系，并根据第一依赖关系处理接收的多条指令。

优选地，指令以矢量的形式表达。

若两条指令的某一参数的第一依赖关系成立，则规则引擎模型合并执行该两条指令的该参数对应的规则流；否则，规则引擎模型并行执行该两条指令的该参数对应的规则流。例如，若两条指令对应的操作对象之间存在依赖关系，则合并处理这两条指令。

处理结果预处理模块830与规则引擎模型820连接，处理结果预处理模块830根据参数分析多条指令的输出结果之间的第二依赖关系，并根据第二依赖关系组合多条指令的处理结果，作为规则引擎模型的最终输出结果。

具体地，第二依赖关系包括每两条指令的输出对象之间的依赖关系等。具体地，例如，若两条指令的输出对象相同，则该两条指令的输出对象具有第二依赖关系。

若两条指令的某一参数的第二依赖关系成立，则处理结果预处理模块830将规则引擎模型输出的该两条指令的该参数对应的处理结果组合。

优选地，规则引擎模型为基于现场可编程门阵列(FPGA)芯片的规则引擎模型。具体地，规则引擎模型820为FPGA芯片，根据规则流编辑FPGA芯片中的门电路，使FPGA芯片按照规则流实现规则的检查。

FPGA具有硬件可编程、低功耗、低时延的特性，本申请以FPGA芯片硬件作为载体，实现了多个小粒度规则流的平行处理，可并行处理和流水操作，有效发挥平行处理硬件的优势，使得规则引擎模型的处理容量大大增加，几乎不受用户数量限制，同时降低了规则处理的延迟。

优选地，规则引擎模型820中的线性规则流以矩阵的形式表达。输出结果以矢量的形式表达，具体地，输出结果的矢量由规则引擎模型内的矩阵与输入指令的矢量的乘积决定。

U1、U2、U3为输入数据矢量，即根据输入的所有指令分解成的参数和第一依赖关系确定的矢量。

g11、g12、g13、g21、g22、g23、g31、g32、g33组成的矩阵为规则引擎模型中各条规则组成的矩阵。

R1、R2、R3为规则引擎模型的输出矢量。

进一步地，优选地，本申请还提供了一种规则检查系统，该规则检查系统包括上述的规则引擎，还包括人工智能模块和/或分布式云存储器。

人工智能模块用于训练规则引擎模型，并将训练结果输出给规则引擎模型。具体地，规则引擎模型和人工智能模块通过TCP/IP或PCIe标准化API模式通信。

通过人工智能模块实现机器学习，指导和优化规则检查的业务配置，使得规则的分解和检查达到最优化。

分布式存储器与规则引擎模块无线连接，规则引擎模型把规则流和指令数据传输给分布式存储做备份，借助分布式存储的快速部署和实时承接能力，实现动态伸缩服务资源，应对业务量急速变化带来的大数据，扩充硬件规则引擎的功能。

图7是本申请提供的指令处理方法的应用场景实例的示意图。图7为证券交易的流程示意图。如图7所示，用户在交易柜台中提出交易需求，交易柜台的业务人员给FPGA规则引擎输入订单指令。多个交易柜台同时向FPGA规则引擎输入订单指令，FPGA规则引擎同时并行处理多条订单指令。FPGA规则引擎包括指令预处理模块、规则引擎模型和处理结果预处理模块，规则引擎模型包括合规规则流、风控规则流和异常交易规则流，用于对合规规则、风控规则和异常交易规则进行检查。FPGA规则引擎接收到多条指令后，对于多条指令进行并行检查，并且对于每条指令并行进行合规规则、风控规则检查以及按照需要进行异常交易规则的检查，若规则检查通过，则订单传输至交易中心，交易中心对订单处理后形成成交回报结果，成交回报结果也需要经过FPGA规则引擎的规则检查后才能返回交易柜台。

实施例四

本申请还提供了一种基于实施例三中的规则引擎的指令处理方法。

图6是本申请实施例提供的基于规则引擎的指令处理方法的流程图。如图6所示，基于规则引擎的指令处理方法包括如下步骤：

S610：将多条指令输入规则引擎。

S620：将每条指令分解为多个参数，根据参数分析所述多条指令之间的第一依赖关系。

具体地，参数包括用户信息、指令对应的规则来源、指令对应的操作对象、指令的输出对象等。

第一依赖关系包括每两条指令的用户信息之间的依赖关系、每两条指令对应的规则来源之间的依赖关系、每两条指令的操作对象之间的依赖关系等。

具体地，例如，若两条指令对应的规则来源相同，则该两条指令对应的规则来源具有第一依赖关系。若两条指令的操作对象相同，则该两条指令的操作对象具有第一依赖关系。

S630：将参数及第一依赖关系输入规则引擎模型。

S640：规则引擎模型根据第一依赖关系处理多条指令。

若两条指令的某一参数的第一依赖关系成立，则规则引擎模型合并执行该两条指令的该参数对应的规则流；否则，规则引擎模型并行执行该两条指令的该参数对应的规则流。例如，若两条指令对应的操作对象之间存在依赖关系，则合并处理这两条指令。

优选地，规则引擎模型为基于现场可编程门阵列(FPGA)芯片的规则引擎模型。具体地，规则引擎模型820为FPGA芯片，根据规则流编辑FPGA芯片中的门电路，使FPGA芯片按照规则流实现规则的检查。

FPGA具有硬件可编程、低功耗、低时延的特性，本申请以FPGA芯片硬件作为载体，实现了多个小粒度规则流的平行处理，可并行处理和流水操作，有效发挥平行处理硬件的优势，使得规则引擎模型的处理容量大大增加，几乎不受用户数量限制，同时降低了规则处理的延迟。

优选地，规则引擎模型820中的规则流以矩阵的形式表达。输出结果以矢量的形式表达，具体地，输出结果的矢量由规则引擎模型内的矩阵与输入指令的矢量的乘积决定。

S650：根据参数分析规则引擎模型输出的多条指令的处理结果之间的第二依赖关系。

第二依赖关系包括每两条指令的输出对象之间的依赖关系等。具体地，例如，若两条指令的输出对象相同，则该两条指令的输出对象具有第二依赖关系。

若两条指令的某一参数的第二依赖关系成立，则将规则引擎模型输出的该两条指令的该参数对应的处理结果组合。

S660：根据第二依赖关系组合多条指令的处理结果，作为规则引擎的最终输出结果。若两条指令的某一参数的第二依赖关系成立，则将规则引擎模型输出的该两条指令的该参数对应的处理结果组合。

优选地，获得最终输出结果之后，规则引擎还将指令数据和最终输出结果数据上传给分布式存储器，借助分布式存储器的快速部署和实时承接能力，实现动态伸缩服务资源，应对业务量急速变化带来的大数据，扩充硬件规则引擎的功能。

本申请的技术效果如下：

1、本申请将规则细化成规则要素及规则要素构成的关系式，以此为基础确定不同的规则之间的依赖关系，进而形成粒度很小的规则流，为多条指令的并行处理提供基础，大大提高了业务系统的并行处理能力，时效性大大提升，实现了纳秒量级的处理速度，实现了各类规则的实时检查、实时定价估值、实时清算结算等各种业务处理，业务处理速度的提升使得各种事后处理的过程移到事前(或事中)处理，实现了平行实时全业务流端到端事务处理。

2、本申请的规则引擎大量收录规则中的规则要素作为引擎的标准字段，使添加、修改和更新规则的处理简单化，降低了规则引擎的维护和更新困难，解除了软件编程语言对业务人员的限制，实现了业务人员与外部技术开发人员的解耦，也使得

3、本申请利用FPGA芯片可编程、低功耗、低时延的特性实现了规则的灵活设置，实现了业务规则定义参数化、公式化、流程化，规则执行和处理过程事务化、平行化、流水化，在大量新加或修改业务规则时，只要添加或修改规则定义，实现了使用中业务规则定义所需的各种灵活度，发挥了硬件的高速平行处理特点，省去了大量编写软件的工作，降低了对操作人员的专业度，消除和降低了传统技术平台的软件开发和维护及管理成本。同时，FPGA硬件的横向可扩充性使硬件规则引擎几乎不受用户数量限制。

4、对于证券等金融业务平台来说，本申请的FPGA硬件规则引擎还可以与簿记平台对接，FPGA硬件规则引擎提供了全面、集中、统一的自动化合规风控管理体系，使证券公司统一持仓管理，日终上账，日间对账防透支，解决了证券公司因业务条线和平台分割、职能分散、自动化不足等原因造成的操作风险。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (21)

1.一种规则引擎的建模方法，其特征在于，包括：

逐条分解规则，获得规则要素；

根据所述规则要素确定规则间的依赖关系；

根据所述依赖关系获得规则流。

2.如权利要求1所述的建模方法，其特征在于，还包括：

根据所述规则流编辑现场可编程门阵列芯片。

3.如权利要求2所述的建模方法，其特征在于，还包括将所述规则和所述规则流输入人工智能模块进行训练，并根据训练结果更新所述现场可编程门阵列芯片。

4.如权利要求1所述的建模方法，其特征在于，确定规则间的依赖关系包括：

将第一规则与其他规则组成第一分组，根据所述规则要素确定第一规则与其他规则是否具有依赖关系；

若所述第一规则与至少两个第二规则有依赖关系，则重复如下步骤直至第二分组中不存在有依赖关系的第二规则：

将所述至少两个第二规则组成第二分组，并遍历所述第二分组，确定两两之间是否具有依赖关系；

若第二分组中存在具有至少两个有依赖关系的规则的第二规则，则用该第二规则更新第一规则，用与更新后的第一规则具有依赖关系的第二规则更新第二规则。

5.如权利要求4所述的建模方法，其特征在于，根据所述依赖关系获得规则流包括：

具有依赖关系的两个规则形成串行规则流；

不具有依赖关系的两个规则形成并行规则流。

6.一种规则引擎的建模装置，其特征在于，包括规则分解模块、依赖关系确定模块、规则流获得模块；

其中，所述规则分解模块逐条分解规则，获得规则要素；

所述依赖关系确定模块根据所述规则要素确定规则间的依赖关系；

所述规则流获得模块根据所述依赖关系获得规则流。

7.如权利要求6所述的建模装置，其特征在于，还包括编辑模块，所述编辑模块根据所述规则流编辑现场可编程门阵列芯片。

8.如权利要求6或7所述的建模装置，其特征在于，还包括训练模块，所述训练模块将所述规则和所述规则流输入人工智能模块进行训练，并根据训练结果更新所述现场可编程门阵列芯片。

9.如权利要求6所述的建模装置，其特征在于，依赖关系确定模块包括第一分组子模块、第二分组子模块以及更新子模块；

其中，所述第一分组子模块将第一规则与其他规则组成第一分组，根据所述规则要素确定第一规则与其他规则是否具有依赖关系；

所述第二分组子模块与所述第一分组子模块和更新子模块连接，若所述第一规则与至少两个第二规则有依赖关系，则所述第二分组子模块将所述至少两个第二规则组成第二分组，并遍历所述第二分组，确定两两之间是否具有依赖关系；

所述更新子模块与所述第二分组子模块连接，若第二分组中存在具有至少两个有依赖关系的规则的第二规则，则所述更新子模块用该第二规则更新第一规则，用与更新后的第一规则具有依赖关系的第二规则更新第二规则。

10.一种基于规则引擎的指令处理方法，其特征在于，包括：

将多条指令输入规则引擎；

将每条指令分解为多个参数，根据参数分析所述多条指令之间的第一依赖关系；

将所述参数及所述第一依赖关系输入规则引擎模型；

所述规则引擎模型根据所述第一依赖关系处理所述多条指令；

根据参数分析所述规则引擎模型输出的多条指令的处理结果之间的第二依赖关系；

根据所述第二依赖关系组合所述多条指令的处理结果，作为所述规则引擎的最终输出结果。

11.如权利要求10所述的指令处理方法，其特征在于，所述参数包括用户信息、指令对应的规则来源、指令对应的操作对象、指令的输出对象；

所述第一依赖关系包括每两条指令的用户信息之间的依赖关系、每两条指令对应的规则来源之间的依赖关系、每两条指令的操作对象之间的依赖关系。

12.如权利要求10或11所述的指令处理方法，其特征在于，所述参数包括指令的输出对象；

所述第二依赖关系包括每两条指令的输出对象之间的依赖关系。

13.如权利要求11所述的指令处理方法，其特征在于，若两条指令对应的规则来源相同，则该两条指令对应的规则来源具有第一依赖关系。

14.如权利要求11所述的指令处理方法，其特征在于，若两条指令的操作对象相同，则该两条指令的操作对象具有第一依赖关系。

15.如权利要求12所述的指令处理方法，其特征在于，若两条指令的输出对象相同，则该两条指令的输出对象具有第二依赖关系。

16.如权利要求10所述的指令处理方法，其特征在于，所述规则引擎模型根据所述第一依赖关系处理所述多条指令，具体包括：

若两条指令的某一参数的第一依赖关系成立，则规则引擎模型合并执行该两条指令的该参数对应的规则流；

否则，规则引擎模型并行执行该两条指令的该参数对应的规则流。

17.如权利要求10所述的指令处理方法，其特征在于，根据所述第二依赖关系组合所述多条指令的处理结果，包括：

若两条指令的某一参数的第二依赖关系成立，则将规则引擎模型输出的该两条指令的该参数对应的处理结果进行组合。

18.一种规则引擎，包括指令预处理模块、规则引擎模型以及处理结果预处理模块；

所述指令预处理模块接收多条指令，并将每条指令分解为多个参数，根据参数分析所述多条指令之间的第一依赖关系；

所述规则引擎模型与所述指令预处理模块连接，所述规则引擎模型接收所述参数及所述第一依赖关系，并根据所述第一依赖关系处理所述多条指令；

所述处理结果预处理模块根据参数分析所述多条指令的输出结果之间的第二依赖关系，并根据所述第二依赖关系组合所述多条指令的处理结果，作为所述规则引擎模型的最终输出结果。

19.如权利要求18所述的规则引擎，其特征在于，所述规则引擎模型以规则流的形式处理指令，并且所述规则引擎模型基于现场可编程门阵列芯片。

20.如权利要求18或19所述的规则引擎，其特征在于，所述参数包括用户信息、指令对应的规则来源、指令对应的操作对象、指令的输出对象；

所述第一依赖关系包括每两条指令的用户信息之间的依赖关系、每两条指令对应的规则来源之间的依赖关系、每两条指令的操作对象之间的依赖关系。

21.如权利要求20所述的指令处理方法，其特征在于，所述参数包括指令的输出对象；

所述第二依赖关系包括每两条指令的输出对象之间的依赖关系。

Images