WO2022237334A1 - 一种业务逻辑的知识表示和推演方法及装置 - Google Patents

一种业务逻辑的知识表示和推演方法及装置 Download PDF

Info

Publication number
WO2022237334A1
WO2022237334A1 PCT/CN2022/082473 CN2022082473W WO2022237334A1 WO 2022237334 A1 WO2022237334 A1 WO 2022237334A1 CN 2022082473 W CN2022082473 W CN 2022082473W WO 2022237334 A1 WO2022237334 A1 WO 2022237334A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
nodes
graph
business
logic
Prior art date
Application number
PCT/CN2022/082473
Other languages
English (en)
French (fr)
Inventor
段戎
胡康兴
黄文文
袁媛
彭文
刘春熙
杨钦杰
尹小亮
李姝凡
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP22806304.6A priority Critical patent/EP4325375A1/en
Publication of WO2022237334A1 publication Critical patent/WO2022237334A1/zh
Priority to US18/505,892 priority patent/US20240078441A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G06N5/02—Knowledge representation; Symbolic representation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/36—Creation of semantic tools, e.g. ontology or thesauri
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/33—Querying
    • G06F16/3331—Query processing
    • G06F16/334—Query execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G06N5/02—Knowledge representation; Symbolic representation
    • G06N5/022—Knowledge engineering; Knowledge acquisition

Definitions

  • the present application relates to the technical field of artificial intelligence, in particular to a method and device for knowledge representation and deduction of business logic.
  • business personnel cannot directly configure knowledge, and then use the knowledge calculation results to obtain timely feedback; second, business users are neither visible to the business logic implemented in the IT system, nor can they intervene and adjust the logic. This leads to two consequences: one is that the results lack interpretability, and there is confusion about how the calculated results are obtained; the other is that the logic cannot be dynamically adjusted.
  • Business users often have demands for dynamic logic adjustments during the deduction and analysis process. For example, business logic is estimated based on certain assumptions. It needs to judge whether it meets expectations based on the calculation results of real-time feedback, and then determine whether to do dynamic Adjustment.
  • the traditional deduction system hides the business logic in the IT code, and any logic adjustment will trigger the system development and change process (as described in point 1 above), that is, it cannot support real-time adjustment of logic, and it cannot achieve instant feedback calculated based on the new logic.
  • the concept representation layer and the instance layer of business knowledge are not decoupled, so the system does not have the functions of automatic knowledge management and analysis.
  • the expression related only to business logic is called the concept layer representation
  • the combination of business logic and data structure, which is embodied in the actual operating environment to form executable code logic is called the instance layer expression.
  • the concept layer to the instance layer is the instantiation process, and it is also the process of business knowledge from abstraction to concreteness.
  • the traditional IT system implementation method only retains the logic of the instance layer, but does not express the explicit task of the concept layer, let alone establish a connection.
  • the embodiment of the present application proposes a method and device for knowledge representation and deduction of business logic.
  • the embodiment of the present application proposes a business logic knowledge representation and deduction method, which includes:
  • a semantic graph corresponding to the business logic of the concept layer is generated; wherein, the semantic graph includes one or more types of nodes and edges connecting the one or more types of nodes, and the nodes are at least Nodes that include variable types;
  • the instance graph includes nodes and edges in the semantic graph
  • the executable code determine the data instance corresponding to each node in the instance graph; wherein, according to the data instance of the pre-branch node that the node depends on, it can be Deduce the data instance corresponding to the node.
  • the generation of a semantic graph corresponding to the business logic of the concept layer according to the knowledge representation model includes:
  • the semantic graph is generated according to the nodes and edges corresponding to the business logic of the concept layer.
  • the concept layer business logic includes: operation rule logic, condition judgment logic and/or complex function/model logic.
  • the nodes further include: constant-type nodes, function-type nodes, and/or container-type nodes; wherein, the container-type nodes encapsulate nodes of different types and edges of different types
  • the semantic graph is called by the semantic graph of the upper layer to construct a multi-level semantic graph.
  • the edge includes: an edge of a process control relationship type, an edge of a calculation relationship type, an edge of a logical judgment relationship type, and/or an edge of a logical link relationship type.
  • the generating executable code according to the business logic relationship between the nodes in the instance graph includes:
  • a sub-path that matches the predefined meta-path characteristics is determined, and an executable code is generated according to the type of the node in the path and the semantic meaning corresponding to the edge;
  • the method also includes:
  • the paths where the nodes without data instances in the instance graph are located are eliminated.
  • the method also includes:
  • the method also includes:
  • the performing conflict detection on the semantic graph includes:
  • out-degree of the node If the out-degree of the node is 0, clear the access marks of all nodes in the current connected graph, and take out new nodes from the queue of the front branch node and/or the back branch node, and repeat the above steps, otherwise start from Select a node other than all nodes in the current connected graph, and repeat the above steps.
  • the method also includes:
  • the detection of logical expression ambiguity on the semantic graph includes:
  • the method also includes:
  • the method also includes:
  • the embodiment of the present application proposes a business logic knowledge representation and derivation device, including at least one processor, the processor is used to execute the program stored in the memory, when the program is executed, the device implement:
  • the embodiments of the present application provide a computer program product containing instructions, and when the computer program product is run on a computer, the method as in the first aspect and various possible implementations thereof is executed by the computer.
  • the embodiment of the present application proposes a computer-readable storage medium, on which a computer program is stored.
  • the computer program is executed by a processor, as in the first aspect and its various possible implementations, method is executed.
  • FIG. 1 is a schematic diagram of a system provided by an embodiment of the present application.
  • FIG. 2 is a schematic diagram of a semantic graph corresponding to business logic provided by an embodiment of the present application
  • FIG. 3 is a schematic flow diagram of a business logic knowledge representation and deduction method provided by an embodiment of the present application.
  • FIG. 4 is a schematic diagram of a semantic map provided by an embodiment of the present application.
  • FIG. 5 is a schematic diagram of a user interface provided by an embodiment of the present application.
  • FIG. 6 is a schematic diagram of the business object provided by the embodiment of the present application, and the attributes of the business object are respectively mapped to the physical table and the fields in the physical table;
  • FIG. 7 is a schematic diagram of a data instance corresponding to each element in the attribute of the business object provided by the embodiment of the present application.
  • FIG. 8 is a schematic diagram of an example graph (displaying data instances corresponding to some nodes) provided by the embodiment of the present application.
  • FIG. 9 is a schematic diagram of generating multiple independent and parallel paths according to the dependencies of the nodes in the example graph provided by the embodiment of the present application.
  • FIG. 10 is a schematic diagram of a node calculation logic dictionary provided by an embodiment of the present application.
  • FIG. 11 is a schematic diagram of an example graph (displaying data instances corresponding to all nodes) provided by the embodiment of the present application.
  • FIG. 12 is a schematic diagram of a semantic graph with cyclic dependencies provided by an embodiment of the present application.
  • FIG. 13 is a schematic diagram of a semantic graph with logical expression ambiguity provided by the embodiment of the present application.
  • Fig. 14 is a schematic diagram for characterizing what-if analysis provided by the embodiment of the present application.
  • a business logic code generation method is proposed, and the specific process is as follows: First, the data source, logic operation, and data output channel are packaged into visual data source components, logic operation components, and data output channels in advance. Channel components for users to choose; then, users can set corresponding component parameters for these data source components, logical operation components, and data output channel components according to application scenarios; secondly, users drag and drop the above components to complete the connection between components, forming A flow chart; furthermore, the system converts the flow chart into a corresponding character string; then parses the character string to generate business logic code.
  • the main purpose of the above solution is to improve the efficiency of developers.
  • the commonly used processing methods in the data preprocessing process are written as code functions, and then packaged into visual components for users to use in a drag-and-drop manner to achieve visual programming.
  • the above solution shields the underlying technology, simplifies the development process of big data, and lowers the development threshold, making it easier, controllable and reliable to process most streaming and real-time big data processing application scenarios.
  • the configurable granularity still stays at the level of larger granularity data components, the flexibility is reduced.
  • the influencing factors of its business logic are not explicit, and cannot support subsequent knowledge analysis and quality management.
  • the concept layer of business logic is not separated from the instance layer, it cannot support business personnel configuration.
  • the rules can be executed, but the dependencies between the rules cannot be displayed and expressed, and the results of logical calculations cannot be explained.
  • a business rule processing method configures multiple business rules according to business objectives, and multiple business rules can form a circular directed graph structure according to the execution sequence and dependency configured in the rule configuration information; execute each business rule according to the execution sequence and dependency of each business rule .
  • the above-mentioned technical solution can efficiently and flexibly process the business rules of complex business, so as to support the application scenarios of real-time decision-making such as distributed and high concurrency.
  • the logic management granularity of the above technical solution for business configuration is at the rule level, the dependencies between business logics can only be at the logic unit granularity at the rule level.
  • the rules also contain multiple rule elements, and the rules can only be executed when the rule elements are complete. Therefore, only by expressing the information of these elements can it be intuitively revealed why there is a dependence between the rules. For example, there are often common rule elements among different rules, so these rules are mutually dependent. Another example: the rule elements that rule B depends on can only be obtained from the output of rule A, so it can be seen that there is a dependency relationship between rules A and B.
  • the invention nor the existing rule engines on the market can explicitly express the rule elements in the business rules, so the above-mentioned limitations inevitably arise.
  • Fig. 1 is a schematic diagram of a system applicable to the embodiment of the present application. As shown in Figure 1, the whole system includes three modules, business logic configuration module, heterogeneous graph-based knowledge generation and code translation module, and knowledge calculation module.
  • the first module is the business logic configuration module, where the user mainly enters the business logic in an interface-friendly way such as near natural language or tables, including business object definition, business logic configuration, and mapping between business objects and physical tables.
  • the physical table to which the business object (group profit and loss object) is mapped is GRP_IS.
  • the second module is the knowledge generation and code translation module based on the heterogeneous graph.
  • This application transforms the business logic into an easy-to-understand model, and the machine can perform knowledge calculations.
  • the execution process can be visualized to support the interpretability of the results and explicitly express the business elements. , supporting the correlation impact analysis between various business elements.
  • This part mainly completes the abstraction of business logic and provides targeted knowledge representation, so that the knowledge expression space can cover the space of business logic description.
  • the knowledge representation model in the embodiment of this application bears the expression of business logic to complete this part of the functions.
  • the semantic graph generation of business logic is mainly based on the knowledge representation model, which transforms various business logics into a unified semantic expression of business logic based on the heterogeneous graph model.
  • Semantic graph to executable code mechanism module mainly through the semantic layer of business logic represented by heterogeneous graph, plus the physical table corresponding to the business object specified by the user, specifying a specific execution environment, and completing the automation of code logic from semantic logic to execution translate. Therefore, this module includes the semantic graph generation of business logic, the translation mechanism between semantic graph and executable code, and the construction of knowledge representation model based on heterogeneous graph.
  • a semantic graph corresponding to the business logic is generated according to the above knowledge representation model.
  • Generate an instance diagram based on the semantic diagram and the physical tables to which the business objects in the business logic are mapped. Translate the instance graph into executable code according to the business logic relationship between the nodes in the instance graph.
  • the third module is the knowledge calculation module, including knowledge calculation and execution status management and knowledge quality management and analysis.
  • Knowledge computing and execution status management completes the execution of executable codes in the computing environment, and determines the running status and running progress.
  • Knowledge quality management and analysis mainly uses the business logic represented by the semantic graph to check whether there are conflicts and contradictions between them, and supports correlation analysis, including conflict detection and logical expression ambiguity detection on the semantic graph.
  • Conditional judgment logic (If...then%), this kind of business logic is mainly used in slightly complex business scenarios, where the operational relationship between business elements needs to rely on certain preconditions; or through the relationship between business elements Whether it is established and whether it exceeds the threshold is used as a standard to split the sub-scenario, and then define the operational relationship between business elements in each sub-scenario. For example, in the business scenario of project revenue and expenditure risk deterioration judgment,
  • customer solvency rating customer solvency rating model (earnings before interest and taxes in the past year, debt growth rate, turnover rate, operating efficiency, ).
  • the above business logic has its own characteristics. Specifically, the business logic includes multiple business elements, and there are a large number of quantitative relationships between the business elements. This is the main logical expression in the process of business analysis and deduction. The quantitative relationship between business elements does not exist constantly, and needs to be judged in combination with certain scenarios. For more complex scenarios, there are different quantitative relationships corresponding to different conditions. Although the business logic subject is expressed in a way that the business understands itself, it also introduces some external capability assistance. These functions internally provide the results of quantitative data for the business in a black-box manner. It can be introduced as a function node in business knowledge representation.
  • nodes represent the business elements contained in the business logic.
  • nodes can be divided into different types. See Table 1 for different node types; edges represent the operational relationship between nodes, and the same relationship After abstraction, they are divided into different types according to the differences in their characteristics. See Table 2 for different edge types.
  • Logic 1 The calculation logic of risk deterioration value, specifically, when the project risk probe is greater than a certain threshold, it is confirmed that there is risk deterioration, and the risk deterioration score is calculated. Sort out the business logic and express it as
  • the project risk probe is related to four key business elements, namely:
  • the project type is complex X1, the customer interface assumption does not fall into the bidding document X2, the customer interface assumption does not fall into the contract X3, and a large proportion of new additions occur during the execution process X4.
  • Each of these four business elements has a quantitative value. If the total value of these four business elements is greater than a certain threshold Threshold, the business judgment project may have a risk of deterioration.
  • Project risk probe score X1+X2+X3+X4.
  • business elements of business logic are represented by nodes of variable type
  • the judgment logic is represented by nodes of type Intra_Judge_FUN
  • the custom logic is represented by nodes of type Intra_PreDEF_FUN.
  • Business logic based on heterogeneous graph representation, namely
  • the construction of the business logic knowledge representation model is the primary problem to be solved.
  • Build a knowledge representation model based on the above types of business logic.
  • the constructed knowledge representation model is ⁇ Profit node, income node, cost node, expense node, other expenditure node, order node, order-to-receipt ratio node, CBG node, glory node, Huawei node, global node, China node, overseas node, edge Part Of, edge Not_Part Of , edge FactOf ⁇ .
  • Fig. 3 shows a schematic flowchart of a method for knowledge representation and deduction of business logic proposed by the embodiment of the present application, and the schematic flowchart includes S302-S308.
  • a business logic knowledge representation and deduction method as shown in FIG. 3 provided in the embodiment of the present application is described in detail below.
  • the knowledge representation and deduction method of the business logic provided by the embodiment of the present application is implemented through the following steps:
  • the business object is a group profit and loss object
  • the attributes of the business object are profit and loss indicators, products and regions
  • the elements in the profit and loss indicators are profit, income, cost, expense, order, order-to-receipt ratio
  • the elements in the product are CBG, Honor and Huawei
  • the elements in the region are global, China and overseas.
  • the nodes and edges corresponding to the business logic of the concept layer are obtained from the knowledge representation model.
  • users can also enter business logic in the user interface based on a similar formalized natural language method, such as determining that the name of the business element needs to be defined uniformly, and the business element must be determined by adding the qualifier ⁇ >; the scene judgment should use standardized if, then keywords .
  • a similar formalized natural language method such as determining that the name of the business element needs to be defined uniformly, and the business element must be determined by adding the qualifier ⁇ >; the scene judgment should use standardized if, then keywords .
  • Entering business logic includes the entry of each business element of business logic, and also includes the definition of business objects, business logic configuration, and the mapping between business objects and physical tables.
  • the user can also use the second natural language expression as the basis, but instead of directly inputting text strings, the user is presented with a guided input interface for inputting information on various business elements.
  • the business logic is transformed into a semantic graph, and the business logic has been expressed in detail at the conceptual level, but it has not yet been specific to the extent that it can be executed at the data level.
  • Business logic can be visualized and displayed friendly. The benefit of business logic visualization allows users to directly adjust and configure the business logic.
  • the semantic diagram corresponding to the business logic of the above concept layer is shown in Figure 4. It can support complex business logic representation; Business personnel; able to abstract and structure the business logic enough to support the subsequent work of automatically converting logic into machine-executed code; clearly express the relationship between all elements of business logic, and support subsequent automatic knowledge management and analysis.
  • the above user interface is shown in FIG. 5 .
  • S304 Generate an instance graph according to the semantic graph and the physical table to which the business object is mapped; wherein, the instance graph includes nodes and edges in the semantic graph.
  • Fig. 6 in Fig. 6, the group profit and loss object is mapped to the physical table GRP_IS, the attribute (profit and loss indicator) of the group profit and loss object is mapped to the field RPT_ITEM, the attribute (product) of the group profit and loss object is mapped to the field PROD, and the attribute (region ) is mapped to the field REGION.
  • Figure 7 shows the data examples corresponding to the elements order, order-to-receipt ratio, cost, expense and other expenditures in the attribute (profit and loss index) of the group profit and loss object.
  • the instance graph shown in FIG. 8 is generated.
  • Figure 8 shows the data examples corresponding to the order node, order-to-receipt ratio node, cost node, expense node and other expenditure nodes, specific to the extent that the data level can be executed.
  • a node with an in-degree of 0 in the instance graph is used as the starting node to perform local breadth-first traversal, and multiple independent and parallelizable The path to run, such as path1 and path2 in Figure 9.
  • Each independent path can be split into multiple single steps.
  • path1 can be split into p11, p12, and p13 as shown in Figure 9, and path2 can be split into p21, p22, and p23.
  • a sub-path that matches the predefined meta-path characteristics is determined, and an executable code is generated according to the type of the node in the path and the semantic meaning corresponding to the edge.
  • a container-type node If a container-type node is found during the traversal process, open the lower-layer subgraph logic encapsulated by the container-type node, traverse the subgraph according to the same logic, complete the executable code generation in the subgraph, and then return to the upper-level instance graph to continue to complete subsequent operations .
  • the edge is part of, parent ⁇ -child node2
  • the edge is part of, (where parent and child are variable types, representing business elements)
  • S306 supports translation of business logic into executable codes.
  • SQL SQL as "Select order * ord rev R AS rev from GRP_IS”.
  • the business logic is decoupled from the implementation logic, and the implementation logic can be automatically transformed through the business logic.
  • the business logic of business staffing supports visual representation, which is easy to understand.
  • the code logic that needs to be transformed is completely decoupled. That is to say, the business logic describes the essential things of the business, and is not bound to the physical implementation of the background.
  • the business logic can be executed in real time after instantiation, giving real-time feedback to the user.
  • the executable code SQL corresponding to "Select order*ord rev R AS rev from GRP_IS” can obtain income
  • the data instance corresponding to the node is 30.
  • the executable code corresponding to business logic profit income-cost-expense-other expenditure, the corresponding profit node can be obtained
  • the data instance for is 5.
  • Figure 11 shows the data instances corresponding to all nodes. That is to say, the income node depends on two pre-branch nodes, namely the order node and the order-to-receipt ratio node. According to the data instances corresponding to the order node and the order-to-receipt ratio node, the data instance corresponding to the revenue node can be deduced, and the deduction results can be interpreted.
  • this application supports automatic management of knowledge.
  • knowledge calculation and management can also be performed, including knowledge calculation and execution state management, and knowledge quality management and analysis.
  • knowledge computing and execution status management complete the execution of executable codes in the computing environment, and determine the running status and running progress.
  • Knowledge quality management and analysis mainly uses the business logic represented by the semantic graph to check whether there are conflicts and contradictions between them, and supports correlation analysis, including conflict detection and logical expression ambiguity detection on the semantic graph.
  • Conflict detection on the semantic graph mainly detects the existence of loop dependencies among business elements. If there are cycles in the semantic graph, it means there is a circular dependency. The circular dependency will fall into an infinite loop in the program scheduling, which generally originates from user input errors during the business logic configuration process. The system searches for errors through loop detection and then feeds back to the user for modification.
  • the conflict detection steps are as follows:
  • the out-degree of the node is 0, the access marks of all nodes in the current connected graph are cleared, and a new node is taken out from the queue of the front branch node and/or the rear branch node, and the above steps are repeated, Otherwise, select a node out of all the nodes in the current connected graph, and repeat the above steps.
  • To detect the ambiguity of logical expression on the semantic graph specifically means that in the semantic graph, when the assumption of the business logic of the concept layer expressed by if-then is established, if there are at least two processing methods, it is determined that there is a logical expression in the semantic graph Ambiguity. Specifically, when expressing business logic for if-then, is there any logical inconsistency. As shown in Figure 13, IF_FUN judges whether the external scene is satisfied. If it is satisfied, two processing methods (infer relationship) can be derived and assigned to Y, which leads to the problem of inconsistency in logical expression.
  • Convenient correlation impact analysis and whatif analysis Perform association impact analysis on the dependencies between nodes in the instance graph and perform what-if analysis based on the adjusted data instance; where the what-if analysis is used to characterize the impact of the adjusted data instance on subsequent dependent nodes.
  • the data instance corresponding to the order node is 50% higher than the data instance corresponding to the order node in Figure 11, and the data instance corresponding to the income node is improved compared to the data instance corresponding to the income node in Figure 11 50%, the data instance corresponding to the profit node is 300% higher than the data instance corresponding to the profit node in Figure 11.
  • this application supports business interactive analysis, can dynamically adjust the logic, and generates results in near real time, and the results can be interpreted. If the data instance corresponding to the node determined in S208 does not meet business expectations, you can return to the user interface shown in Figure 5 to modify business logic, or adjust parameter variables, and execute again. According to the knowledge representation model, the semantic graph corresponding to the modified concept layer business logic is regenerated.
  • Business knowledge configuration can be split into two phases. Both are done visually. For different roles, the first stage is the business logic layer configuration for business personnel, and the second stage is for IT personnel to specify the actual physical data objects to which business objects are mapped.
  • nodes in the embodiment of the present application include variable type nodes, and may also include constant type nodes, function type nodes and/or container type nodes, and the types of nodes are not specified in the embodiment of this application limited.
  • Different businesses have different requirements for the level of detail of business logic.
  • semantic graphs of different levels can be constructed through container nodes to provide multi-level business logic expressions to meet Businesses with different perspectives and different levels of detail requirements.
  • the embodiment of the present application provides a knowledge representation and deduction device for business logic, including at least one processor, and the processor is used to execute the instructions stored in the memory, so that the knowledge representation and deduction of business logic as shown in Figure 3 The various steps of the method are performed.
  • An embodiment of the present application provides a computer-readable storage medium.
  • a computer program is stored on the above-mentioned computer-readable storage medium.
  • the knowledge representation and derivation method of business logic as shown in FIG. 3 Various steps are performed.
  • the embodiment of the present application also provides a computer program product including instructions, when the computer program product is run on a computer, it makes the computer execute the knowledge of the business logic shown in Figure 3 Represent and deduce the individual steps of the method.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Evolutionary Computation (AREA)
  • Artificial Intelligence (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Databases & Information Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Machine Translation (AREA)

Abstract

本申请实施例公开了一种业务逻辑的知识表示和推演方法及装置，方法包括：根据知识表示模型，生成与概念层业务逻辑对应的语义图；其中，语义图包括一种或多种类型的节点和连接一种或多种类型的节点的边，节点至少包括变量类型的节点；根据语义图和业务对象映射到的物理表，生成实例图；其中，实例图包括语义图中的节点和边；根据实例图中的节点之间的业务逻辑关系，生成可执行代码；根据实例图中入度为0的节点对应的数据实例和可执行代码，确定实例图中各个节点对应的数据实例；其中，根据节点依赖的前置分支节点的数据实例可以推演出该节点对应的数据实例。

Description

一种业务逻辑的知识表示和推演方法及装置
本申请要求于2021年05月12日提交中国国家知识产权局、申请号为202110519283.0、申请名称为“一种业务逻辑的知识表示和推演方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及人工智能技术领域，尤其涉及一种业务逻辑的知识表示和推演方法及装置。
背景技术
当前企业各业务领域存在许多专业知识没有被显性表达出来。业务分析时，用户需要在***外将这些知识梳理为具体的业务逻辑，作用在数据上获得分析结果。由于业务逻辑未被显性化表示出来，分析过程中往往需要IT人员去找业务人员了解需求，然后转化为计算机代码固化在IT***中。数据集通过代码运行后输出的结果，最后才能反馈到业务面前。这样带来了诸多不便之处：第一，从专业知识到计算结果反馈的链条较长，涉及到IT对业务需求理解及分析，模块设计，代码开发测试等多个环节，因而周期相对较长。业务人员无法直接配置知识，然后利用知识计算结果及时获得反馈；第二，业务用户对IT***中实现的业务逻辑既不可视，也对逻辑无法做干预和调整。这样导致两个后果：一是结果缺乏可解释性,对于计算出来的结果是如何得来的比较困惑；二是逻辑无法动态调整。而业务用户在做推演分析过程中往往是有动态调整逻辑的诉求，例如业务逻辑是基于某些假设而做出的估计，需要依据即时反馈的计算结果，判断是否符合预期，再确定是否做动态调整。但是传统推演***将业务逻辑隐藏在IT代码中，任何逻辑调整都会触发***开发变更流程(如上文1点中描述)，即无法支持实时调整逻辑，更无法做到即时反馈依据新逻辑计算后的结果；第三，业务知识的概念表示层与实例层未能解耦，因而***不具备知识自动化管理和分析功能。
这里将仅与业务逻辑相关的表达称为概念层表示，而业务逻辑与数据结构相结合，具化到实际运行环境中形成可执行的代码逻辑称为实例层表达。二者紧密联系，概念层到实例层是实例化过程，也是业务知识从抽象到具体过程。传统的IT***实现方式仅保留了实例层的逻辑，而对概念层没有任务显性化的表达，更没有建立连接。这样存在诸多局限：第一，因为概念层没有表达和抽象出来，不具备知识管理和知识推理功能，也无法做逻辑要素之间的关联影响分析；第二，因为实例层逻辑未能与数据结果建立连接，无法支撑whatif分析；第三，因为概念层逻辑与实例层逻辑未建立连接，无法实现用户录入业务逻辑后的自动的代码生成。
面对着上述数据分析过程中的逻辑不可视，分析结果无法解释，当前业界技术状态是：存在一些业务逻辑配置工具，只是将IT实现程序代码的过程通过配置化方式实现，虽然实现IT逻辑可查看，且可即时反馈计算结果，但是没有业务逻辑概念层的表 达，结果对于业务依然不可解释，业务也无法根据计算结果即时动态调整逻辑；存在类似规则引擎的一些工具(如drools，旗正)及发明，虽然以rule方式存储业务逻辑，实现了业务逻辑与数据的分离，但这类工具，业务逻辑概念层表达不够，体现在规则要素没显性表达出来，这样无法支撑后续的知识自动化管理，无法做要素间的关联影响分析。
发明内容
本申请实施例提出一种业务逻辑的知识表示和推演方法及装置。
第一方面，本申请实施例提出一种业务逻辑的知识表示和推演方法，该方法包括：
根据知识表示模型，生成与概念层业务逻辑对应的语义图；其中，所述语义图包括一种或多种类型的节点和连接所述一种或多种类型的节点的边，所述节点至少包括变量类型的节点；
根据所述语义图和业务对象映射到的物理表，生成实例图；其中，所述实例图包括所述语义图中的节点和边；
根据所述实例图中的节点之间的业务逻辑关系，生成可执行代码；
根据所述实例图中入度为0的节点对应的数据实例和所述可执行代码，确定所述实例图中各个节点对应的数据实例；其中，根据节点依赖的前置分支节点的数据实例可以推演出该节点对应的数据实例。
一种可能的实现中，所述根据知识表示模型，生成与概念层业务逻辑对应的语义图，包括：
从所述知识表示模型中获取与所述概念层业务逻辑对应的节点和边；
根据所述与所述概念层业务逻辑对应的节点和边，生成所述语义图。
一种可能的实现中，所述概念层业务逻辑包括：运算规则型逻辑、条件判断型逻辑和/或复杂函数/模型类型逻辑。
一种可能的实现中，所述节点还包括：常量类型的节点、函数类型的节点和/或容器类型的节点；其中，所述容器类型的节点封装包括不同类型的节点和不同类型的边的语义图且被上一层的语义图调用，以用于构建多层级的语义图。
一种可能的实现中，所述边包括：流程控制关系类型的边、计算关系类型的边、逻辑判断关系类型的边和/或逻辑链接关系类型的边。
一种可能的实现中，所述根据所述实例图中的节点之间的业务逻辑关系，生成可执行代码，包括：
以所述实例图中的入度为0的节点为起始节点，进行局部广度优先遍历，根据实例图中节点的依赖关系生成多条独立可并行运行的路径；
遍历过程中确定出与预定义的元路径特征匹配的子路径，根据该路径中节点的类型及边对应的语义含义，生成可执行代码；
若遍历过程中发现容器类型的节点，则打开容器节点封装的下层子图逻辑，按照同样逻辑遍历子图，完成子图中可执行代码生成，然后再返回上层实例图，继续完成后续操作。
一种可能的实现中，所述方法还包括：
根据预定义的元路径特征，剔除所述实例图中没有数据实例的节点所在的路径。
一种可能的实现中，所述方法还包括：
确定所述可执行代码在计算环境中的运行状态及运行进度。
一种可能的实现中，所述方法还包括：
对所述语义图进行冲突检测。
一种可能的实现中，所述对所述语义图进行冲突检测，包括：
确定起始检测到的节点不在当前的连通图的节点集合中，则从起始检测到的节点开始做深度优先遍历；
每遍历到一个节点，若该节点无访问标记，则打上访问标记，将该节点加入到当前的连通图的节点集合中，并继续往下遍历，否则确定发现有向环，并输出所有带有访问标记的节点组成的路径信息；其中，若该节点的出度大于1和/或入度大于1，则将其未遍历到的前置分支节点和/或后置分支节点存入队列；
若该节点出度为0，则将当前的连通图中的所有节点的访问标记清空，并从前置分支节点和/或后置分支节点的队列中取出新的节点，重复上述步骤，否则从当前的连通图的所有节点之外，选择一个节点，重复上述步骤。
一种可能的实现中，所述方法还包括：
对所述语义图进行逻辑表达歧义性检测。
一种可能的实现中，所述对所述语义图进行逻辑表达歧义性检测，包括：
在所述语义图中，当if-then表达的概念层业务逻辑的假设条件成立时，若出现至少两种处理方式，则确定出所述语义图存在逻辑表达歧义。
一种可能的实现中，所述方法还包括：
对所述实例图中节点之间的依赖关系进行关联影响分析并基于调整后的数据实例进行what-if分析；其中，所述what-if分析用于表征调整后的数据实例对后续依赖的节点产生的影响。
一种可能的实现中，所述方法还包括：
若所述实例图中的节点对应的数据实例不符合业务预期，则根据所述知识表示模型，重新生成与修改后的概念层业务逻辑对应的语义图。
第二方面，本申请实施例提出一种业务逻辑的知识表示和推演装置，包括至少一个处理器，所述处理器用于执行存储器中存储的程序，当所述程序被执行时，使得所述装置执行：
如第一方面及其各种可能的实现中的方法。
第三方面，本申请实施例提出一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得如第一方面及其各种可能的实现中的方法被该计算机执行。
第四方面，本申请实施例提出一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时，如第一方面及其各种可能的实 现中的方法被执行。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对实施例所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些图获得其他的附图。
图1为本申请实施例提供的一种***的示意图；
图2为本申请实施例提供的一种业务逻辑对应的语义图的示意图；
图3为本申请实施例提供的一种业务逻辑的知识表示和推演方法的流程示意图；
图4为本申请实施例提供的语义图的示意图；
图5为本申请实施例提供的用户界面的示意图；
图6为本申请实施例提供的业务对象、业务对象的属性分别映射到物理表及物理表中的字段的示意图；
图7为本申请实施例提供的业务对象的属性中的各个元素对应的数据实例的示意图；
图8为本申请实施例提供的实例图(显示部分节点对应的数据实例)的示意图；
图9为本申请实施例提供的根据实例图中节点的依赖关系生成多条独立可并行运行的路径的示意图；
图10为本申请实施例提供的节点计算逻辑字典的示意图；
图11为本申请实施例提供的实例图(显示所有节点对应的数据实例)的示意图；
图12为本申请实施例提供的存在环路依赖的语义图的示意图；
图13为本申请实施例提供的存在逻辑表达歧义性的语义图的示意图；
图14为本申请实施例提供的用于表征what-if分析的示意图。
具体实施方式
为了使本申请实施例的目的、技术方案和优点更加清楚，下面结合附图对本申请实施例具体实施方式做详细描述。
需要说明的是，本申请中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。在本申请实施例中，“示例性的”、“举例来说”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”、“举例来说”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。
在一种可能的实现中，提出了一种业务逻辑代码生成方法，具体过程如下：首先，预先将数据源、逻辑运算、数据输出通道分别封装成可视化的数据源组件、逻辑运算组件、数据输出通道组件以供用户选择；然后，用户可以根据应用场景对这些数据源 组件、逻辑运算组件、数据输出通道组件设置相应的组件参数；其次，用户拖拽上述组件，完成组件之间的连接，形成流程图；再者，***将所述流程图转化为与其对应的字符串；进而解析所述字符串生成业务逻辑代码。上述方案主要目的还是在于提升开发人员的效率，将数据预处理过程常用的处理方式写成代码函数，然后封装成可视化组件，提供用户以托拉拽的方式使用，以此实现可视化的编程。上述方案屏蔽了底层技术，简化了大数据的开发过程，降低了开发门槛，使得在处理大部分流式，实时大数据处理应用场景变得更加轻松容易、可控可靠。但是由于可配置粒度依然停留在较大颗粒度的数据组件层面，灵活性有所降低。同时由于颗粒度较大，其业务逻辑的影响因素没有显性化出来，无法支持后面做知识的分析与质量管理。另外由于业务逻辑的概念层与实例层未做分离，无法支持业务人员配置。规则可执行，但是无法显示表达规则间依赖关系，且逻辑计算出来的结果不可解释。
在另一种可能的实现中，提出了一种业务规则处理方法、装置、设备、***及存储介质。该方法根据业务目标配置多个业务规则，多个业务规则能够按照规则配置信息中配置的执行顺序以及依赖关系形成环形有向图结构；根据各个业务规则的执行顺序以及依赖关系，执行各个业务规则。上述技术方案，能够高效灵活地处理复杂业务的业务规则，从而能够支持分布式和高并发等实时性决策的应用场景。但是由于上述技术方案对业务配置完成的逻辑管理粒度在规则层级，所以业务逻辑之间的依赖关系只能在规则级的逻辑单元粒度。实际业务逻辑中，规则内部还包含多个规则要素，规则只有在规则要素完备的情况下才能执行。因而只有把这些要素信息也显示表达出来，才能直观揭示出规则之间为何存在依赖。比如：不同规则之间往往存在共同的规则要素，那这些规则之间就共同依赖。又如：B规则所依赖的规则要素是要从A规则输出才能获得的，故可知A,B规则之间存在依赖关系。而该发明以及当前市场上已有的规则引擎，都无法将业务规则中的规则要素显性表达，故不可避免产生如上所述的局限性。
图1为适用于本申请实施例的一种***的示意图。如图1所示，整个***包括三大模块，业务逻辑配置模块、基于异质图的知识生成及代码翻译模块和知识计算模块。
第一模块是业务逻辑配置模块，主要由用户以近自然语言或表格等界面友好方式录入业务逻辑，包括业务对象定义、业务逻辑配置和业务对象与物理表映射。在一个例子中，定义业务对象为集团损益对象。配置业务逻辑为利润＝收入-成本-费用-其他支出，收入＝订货*订收比。业务对象(集团损益对象)映射到的物理表为GRP_IS。
第二模块是基于异质图的知识生成及代码翻译模块，本申请将业务逻辑转为人易于理解，且机器能够执行知识计算，执行过程可视以支撑结果可解释，显性化表达出业务要素，支撑各业务要素之间的关联影响分析。这部分主要完成业务逻辑抽象，提供针对性的知识表示方式，使得知识表达空间能覆盖业务逻辑描述的空间。本申请实施例中的知识表示模型承载业务逻辑的表达，完成这部分功能。业务逻辑的语义图生成主要是以知识表示模型为基础，将各种不同的业务逻辑基于异构图模型转化为统一的业务逻辑的语义表达。这里表达的业务逻辑还是概念性质的，还没具体的在数据层面可执行的程度。语义图到可执行代码机制模块，主要通过用异质图表示的业务逻辑语义层，加上用户指定业务对象对应的物理表，指定特定的执行环境，完成从语义逻 辑到执行的代码逻辑的自动化翻译。因此该模块包括业务逻辑的语义图生成、语义图与可执行代码翻译机制和基于异质图的知识表示模型构建。根据上述知识表示模型生成与业务逻辑对应的语义图。根据语义图和业务逻辑中的业务对象映射到的物理表，生成实例图。根据实例图中的节点之间的业务逻辑关系，将实例图翻译为可执行代码。
第三模块是知识计算模块，包括知识计算与执行状态管理和知识质量管理与分析。知识计算与执行状态管理完成可执行代码在计算环境中运行，并且确定运行状态及运行进度。知识质量管理与分析主要利用语义图表示的业务逻辑检查彼此之间是否有冲突，矛盾，并支持做关联分析，具体包括对语义图进行冲突检测和逻辑表达歧义性检测。
在本申请实施例中，根据业务场景分析与收集，主要有以下几类业务逻辑的表达方式：
1)运算规则型逻辑：业务要素之间存在着某种确定性的数量关系，可以通过公式的方式定义出来。例如，收入＝订货*订收比
2)条件判断型逻辑(If…then…),这种业务逻辑主要用于稍微复杂业务场景中，业务要素之间的运算关系需要依赖一定的前置条件；或需要通过业务要素之间的关系是否成立，是否超出阈值的情况作为标准来拆分子场景，然后再在每个子场景中定义业务要素之间的运算关系。例如，在项目收支风险恶化判定的业务场景中，
如果：年度预测-年度预算<-5M，或者全生命周期预测-全生命周期预算<-5M，其中，M为Million(百万)
那么:预测较预算贡毛恶化标识＝True
3)复杂函数/模型类逻辑：前两者是用户易理解的业务逻辑，通过以白盒方式描述业务逻辑的细节。但是有些场景，是用户依赖于外部功能模块或者函数实现的，用户将其具体实现当做黑盒，无需理解内部的细节逻辑。这个时候，我们在描述这部分业务逻辑时，只需要黑盒的需要输入的业务要素，黑盒能够实现的业务功能，黑盒输出的业务结果描述即可。
例如：客户偿债能力等级评估，是将有交易的客户清单历表现送入机器学习模型通过复杂算法获得的。对于用户来说，只需要知道要获得客户偿债能力等级需要输入的业务要素有哪些就能获得想要的结果。例如，客户偿债能力等级＝客户偿债能力等级模型(过去一年息税前利润,债务增长率，流动率，运营效率,…)。
上述业务逻辑有其特点。具体来说，业务逻辑包含多个业务要素，业务要素之间存在大量的数量关系。这个是业务分析和推演过程中主要逻辑表达方式。业务要素之间的量化关系，不是恒定存在，需要结合一定的场景进行判断，更复杂的场景，还存在不同条件下，对应不同的量化关系。业务逻辑主体虽然是业务以自身理解的方式表达，但同时也会引入一些外部能力辅助。这些功能内部以黑盒的方式为业务提供量化数据的结果。在业务知识表示上可以作为函数节点引入。
基于以上特点，提出了基于异质图的业务知识表示方式。对应异质图的两个最基本元素：节点和边。具体来说，节点代表业务逻辑中包含的业务要素，根据业务要素抽象后的特点不同，又可以将节点分为不同类型，不同节点类型参见表1；边代表节点之间的运算关系，同样关系抽象后根据其特点存在的差异分为不同类型，不同边类 型参见表2。
表1
Figure PCTCN2022082473-appb-000001
表2
Figure PCTCN2022082473-appb-000002
Figure PCTCN2022082473-appb-000003
基于以上的异质图设计，可以支撑数据分析推演场景的业务逻辑表示。例如，当需要表述风控场景的如下业务逻辑:
逻辑1：风险恶化值计算逻辑，具体为当项目风险探针大于某个阈值时，则确认存在风险恶化，并计算风险恶化得分。梳理下业务逻辑表示为
如果：项目风险探针得分>阈值Threshold     (式1)
那么：计算风险恶化得分
其中项目风险探针与四个关键业务要素相关，分别是:
项目类型复杂X1，客户界面假设未落入标书X2，客户界面假设未落入合同X3，在执行过程中出现大比例新增X4。这四个业务要素分别有一个量化值，如果这四个业务要素值合计起来大于某个阈值Threshold时，则业务判断项目存在风险恶化的可能。项目风险探针得分＝X1+X2+X3+X4。
风险恶化的大小量化值与三个业务要素相关：项目类型复杂X1，项目变更比率X5，超期闭环率X6。风险恶化值＝X1*X5*X6。
这样业务逻辑的业务要素分别用variable类型的节点表示，判断逻辑用Intra_Judge_FUN类型的节点表示，自定义的逻辑用Intra_PreDEF_FUN类型的节点表示。基于异质图表示的业务逻辑，即
如果：项目风险判断逻辑IF1(x1,x2,x3,x4)
那么：x7＝项目风险恶化值THEN1(x1,x5,x6)
如果：[(成本跳变判断逻辑IF2(x8,x9)and外部风险恶化判断IF3(x9)]or项目应付恶化判断IF4(x7,x8)
那么：x12＝最终项目风险综合值THEN2(x10,x11)
如图2所示。
需要说明的是，在本申请中，业务逻辑的知识表示模型的构建是需要解决的首要问题。基于以上几类业务逻辑构建知识表示模型。示例性的，根据概念层业务逻辑，即利润＝收入-成本-费用-其他支出，收入＝订货*订收比，CBG＝荣耀+华为，全球＝中国区+海外，构建的知识表示模型为{利润节点、收入节点、成本节点、费用节点、其他支出节点、订货节点、订收比节点、CBG节点、荣耀节点、华为节点、全球节点、中国区节点、海外节点、边Part Of、边Not_Part Of、边FactOf}。
图3示出了本申请实施例提出的一种业务逻辑的知识表示和推演方法的流程示意图，该流程示意图包括S302-S308。
下面对本申请实施例提供的如图3所示的一种业务逻辑的知识表示和推演方法进行详细介绍。
在一种可能的实现中，通过以下步骤实现本申请实施例提供的业务逻辑的知识表示和推演方法：
需要说明的是，在本申请实施例中，业务对象为集团损益对象，业务对象的属性为损益指标、产品和区域，损益指标中的元素为利润、收入、成本、费用、订货、订收比和其他支出，产品中的元素为CBG、荣耀和华为，区域中的元素为全球、中国区和海外。上述业务对象、业务对象的属性和业务对象的属性中的各个元素统称为业务要素。下面以概念层业务逻辑为利润＝收入-成本-费用-其他支出，收入＝订货*订收比为例，对业务逻辑的知识表示和推演方法进行说明。
S302，根据知识表示模型，生成与概念层业务逻辑对应的语义图；其中，所述语义图包括一种或多种类型的节点和连接所述一种或多种类型的节点的边，所述节点至少包括变量类型的节点。
在一种可能的实现中，从知识表示模型中获取与概念层业务逻辑对应的节点和边，具体地，用户可以通过拖拽前述知识表示模型中的利润节点、收入节点、成本节点、费用节点、其他支出节点、订货节点、订收比节点、边Part Of、边Not_Part Of、边FactOf完成业务逻辑拼装，形成一个与概念层业务逻辑，即利润＝收入-成本-费用-其他支出，收入＝订货*订收比对应的语义图。另外，用户也可以基于类似形式化的自然语言方式在用户界面录入业务逻辑，比如确定业务要素名称需要定义统一，业务要素要加限定符<>确定；场景判断要采用标准化的如果，那么关键词。通过识别用自然语言方式描述的业务逻辑中的业务要素和业务要素之间的关系，生成与概念层业务逻辑，即利润＝收入-成本-费用-其他支出，收入＝订货*订收比对应的语义图。录入业务逻辑包括业务逻辑的各个业务要素的录入，还包括业务对象的定义，业务逻辑配置，业务对象与物理表的映射。此外，用户还可以以第二种类自然语言表述为基础，但是呈现给用户的不是直接输入文本字符串，而是引导式的输入界面，输入各个业务要素信息。通过识别用第二种类自然语言方式描述的业务逻辑中的业务要素和业务要素之间的关系，生成与概念层业务逻辑，即利润＝收入-成本-费用-其他支出，收入＝订货*订收比对应的语义图。将业务逻辑转化为语义图，在概念层面详尽地表达完了业务逻辑，但还没具体到数据层面可执行的程度。业务逻辑能可视化友好展示。业务逻辑可视的好处使得用户可以直接对业务逻辑做调整和配置。上述概念层业务逻辑对应的语义图如图4所示，能够支持复杂的业务逻辑表示；支持业务逻辑可视；既能以显性易懂的方式承载业务逻辑，便于人机交互，这里人指业务人员；能将业务逻辑足够抽象与结构化，支撑后续的由逻辑自动转化为机器执行代码的工作；清晰表达业务逻辑所有要素的关联关系,支撑后续的知识自动化管理及分析。上述用户界面如图5所示。
S304，根据所述语义图和业务对象映射到的物理表，生成实例图；其中，所述实例图包括所述语义图中的节点和边。
参见图4，图4为概念层业务逻辑，即利润＝收入-成本-费用-其他支出，收入＝订货*订收比对应的语义图。参见图6，图6中集团损益对象映射到物理表GRP_IS、集团损益对象的属性(损益指标)映射到字段RPT_ITEM，集团损益对象的属性(产品)映射到字段PROD，集团损益对象的属性(区域)映射到字段REGION。集团损益对象的属性(损益指标)中的元素订货、订收比、成本、费用和其他支出对应的数据实例如图7所示。根据图4所示的语义图和映射到的物理表GRP_IS，生成了如图8所示的实例图。参见图8，在图8中显示出了订货节点、订收比节点、成本节点、费用节点和其 他支出节点对应的数据实例，具体到了数据层面可执行的程度。
需要说明的是，如果针对同一个业务逻辑，需要对应到不同物理环境，只需要改变映射到的物理表即可。
S306，根据所述实例图中的节点之间的业务逻辑关系，生成可执行代码。
在本申请实施例中，生成实例图后，以所述实例图中的入度为0的节点为起始节点，进行局部广度优先遍历，根据实例图中节点的依赖关系生成多条独立可并行运行的路径，如图9中的path1，path2。每个独立路径可拆分成多个单步。如path1可拆分为如图9中所示p11,p12,p13，path2可拆分为p21,p22,p23。每个单步利用字典方式存储节点间的依赖关系，如图10所示，在整体语义图某个path中，利润与收入，成本，费用，其他支出构成的单步，根据单步中元路径特征，解析出利润与收入，成本，费用，其他支出存在的逻辑关系：利润＝收入-成本-费用-其他支出的运算逻辑，然后存储在字典的数据结构中。遍历过程中确定出与预定义的元路径特征匹配的子路径，根据该路径中节点的类型及边对应的语义含义，生成可执行代码。若遍历过程中发现容器类型的节点，则打开容器类型的节点封装的下层子图逻辑，按照同样逻辑遍历子图，完成子图中可执行代码生成，然后再返回上层实例图，继续完成后续操作。具体地，通过语义图中节点间的预定义的元路径特征分析，对应不同业务逻辑语义表达，如遇到如下元路径parent<-child node1,边为part of，parent<-child node2,边为part of，(此处parent，child为variable类型，表示业务要素)，则翻译为parent＝child node1+child node2，完成基于语义图元路径特点翻译为可执行代码。
在本申请实施例中，S306支持将业务逻辑翻译成可执行代码，例如，可以将业务逻辑，即收入＝订货*订收比翻译成SQL为“Select order*ord rev R AS rev from GRP_IS”。
在S304和S306中，业务逻辑与实现逻辑解耦，实现逻辑可以通过业务逻辑自动转化。前面提到业务人员配置的业务逻辑支撑可视化表示，易于理解。且要其转化的代码逻辑完全解耦。也就是说业务逻辑描述业务本质东西，不与后台物理实现绑定。当业务逻辑做实例化动作时，即指定计算的物理数据对象，可自动转化为实现逻辑---即可执行代码。
S308，根据所述实例图中入度为0的节点对应的数据实例和所述可执行代码，确定所述实例图中各个节点对应的数据实例；其中，根据节点依赖的前置分支节点的数据实例可以推演出该节点对应的数据实例。
在本申请实施例中，业务逻辑实例化后即可实时执行，给用户实时反馈。根据订货节点和订收比节点对应的数据实例分别为100和0.3以及业务逻辑收入＝订货*订收比对应的可执行代码SQL为“Select order*ord rev R AS rev from GRP_IS”，可以获得收入节点对应的数据实例为30。根据收入节点、成本节点、费用节点和其他支出节点对应的数据实例分别为30、15、5和5以及业务逻辑利润＝收入-成本-费用-其他支出对应的可执行代码，可以获得利润节点对应的数据实例为5。执行可执行代码后的实例图如图11所示，该实例图显示出了所有节点对应的数据实例。也即收入节点依赖两个前置分支节点，即订货节点和订收比节点。根据订货节点和订收比节点分别对应的数据实例可以推演出收入节点对应的数据实例，推演结果可解释。
需要说明的是，在本申请实施例中，可以根据预定义的元路径特征，剔除实例图 中没有数据实例的节点所在的路径。
还需要说明的是，本申请支持知识的自动化管理。可执行代码生成之后，还可以进行知识的计算与管理，包括知识计算与执行状态管理和知识质量管理与分析。其中，知识计算与执行状态管理完成可执行代码在计算环境中运行，并且确定运行状态及运行进度。知识质量管理与分析主要利用语义图表示的业务逻辑检查彼此之间是否有冲突，矛盾，并支持做关联分析，具体包括对语义图进行冲突检测和逻辑表达歧义性检测。
对语义图进行冲突检测主要检测业务要素之间存在环路依赖。如果语义图中存在环路，则意味着存在循环依赖。而循环依赖在程序调度中会陷入死循环，一般起源于业务逻辑配置过程中用户输入的错误。***通过环路检测搜寻错误后反馈给用户修改。冲突检测步骤如下：
首先，确定起始检测到的节点不在当前的连通图的节点集合中，则从起始检测到的节点开始做深度优先遍历；
然后，每遍历到一个节点，若该节点无访问标记，则打上访问标记，将该节点加入到当前的连通图的节点集合中，并继续往下遍历，否则确定发现有向环，如图12所示，并输出所有带有访问标记的节点组成的路径信息；其中，若该节点的出度大于1和/或入度大于1，则将其未遍历到的前置分支节点和/或后置分支节点存入队列；
最后，若该节点出度为0，则将当前的连通图中的所有节点的访问标记清空，并从前置分支节点和/或后置分支节点的队列中取出新的节点，重复上述步骤，否则从当前的连通图的所有节点之外，选择一个节点，重复上述步骤。
对语义图进行逻辑表达歧义性检测具体是指，在语义图中，当if-then表达的概念层业务逻辑的假设条件成立时，若出现至少两种处理方式，则确定出语义图存在逻辑表达歧义。具体地，针对if-then表达业务逻辑时，是否存在逻辑上不一致性。如图13所示，由IF_FUN判断外部场景是否满足，同为满足情况下可以推导出(infer关系)两种处理方式，并赋值给Y，这就出现了逻辑表达不一致性的问题。
便捷的关联影响分析和whatif分析。对实例图中节点之间的依赖关系进行关联影响分析并基于调整后的数据实例进行what-if分析；其中，what-if分析用于表征调整后的数据实例对后续依赖的节点产生的影响。示例性的，如图14所示，订货节点对应的数据实例较图11中订货节点对应的数据实例提升了50％，则收入节点对应的数据实例较图11中收入节点对应的数据实例提升了50％，利润节点对应的数据实例较图11中利润节点对应的数据实例提升了300％。由上述分析可知，业务逻辑与实现逻辑可扩展，可复用。新的业务需求可以通过配置好的业务逻辑，追踪出新需求的影响，充分利用已有的实现逻辑。
还需要说明的是，本申请支撑业务交互式分析，可动态调整逻辑，近实时产生结果，且结果可解释。在S208中确定出的节点对应的数据实例如果不符合业务预期，可以返回如图5所示的用户界面修改业务逻辑，或者调整参数变量，重新执行。根据知识表示模型，重新生成与修改后的概念层业务逻辑对应的语义图。业务知识配置可以拆分为两个阶段。二者都以可视化方式进行。面向不同角色，第一阶段是面向业务人员的业务逻辑层配置，第二阶段是面向IT人员指定业务对象映射到的实际物理数据对 象。
还需要说明的是，本申请实施例中的节点包括变量类型节点，还可以包括常量类型的节点、函数类型的节点和/或容器类型的节点，节点的类型在本申请实施例中不做具体限定。对于不同的业务其对业务逻辑的详细程度需求是不同的，在以详细规则为基础的异质图的基础上，通过容器节点可以构建不同层级的语义图，提供多层次的业务逻辑表达以满足不同视角，不同详细程度需求的业务。
本申请实施例提供了一种业务逻辑的知识表示和推演装置，包括至少一个处理器，所述处理器用于执行存储器中存储的指令，以使得如图3所示的业务逻辑的知识表示和推演方法的各个步骤被执行。
本申请实施例提供了一种计算机可读存储介质，上述计算机可读存储介质上存储有计算机程序，上述计算机程序被处理器执行时，如图3所示的业务逻辑的知识表示和推演方法的各个步骤被执行。
基于与上述方法实施例相同构思，本申请实施例还提供了一种包括指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得这个计算机执行如图3所示的业务逻辑的知识表示和推演方法的各个步骤。
应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (17)

  1. 一种业务逻辑的知识表示和推演方法，其特征在于，所述方法包括：
    根据知识表示模型，生成与概念层业务逻辑对应的语义图；其中，所述语义图包括一种或多种类型的节点和连接所述一种或多种类型的节点的边，所述节点至少包括变量类型的节点；
    根据所述语义图和业务对象映射到的物理表，生成实例图；其中，所述实例图包括所述语义图中的节点和边；
    根据所述实例图中的节点之间的业务逻辑关系，生成可执行代码；
    根据所述实例图中入度为0的节点对应的数据实例和所述可执行代码，确定所述实例图中各个节点对应的数据实例；其中，根据节点依赖的前置分支节点的数据实例可以推演出该节点对应的数据实例。
  2. 根据权利要求1所述的方法，其特征在于，所述根据知识表示模型，生成与概念层业务逻辑对应的语义图，包括：
    从所述知识表示模型中获取与所述概念层业务逻辑对应的节点和边；
    根据所述与所述概念层业务逻辑对应的节点和边，生成所述语义图。
  3. 根据权利要求1所述的方法，其特征在于，所述概念层业务逻辑包括：运算规则型逻辑、条件判断型逻辑和/或复杂函数/模型类型逻辑。
  4. 根据权利要求1所述的方法，其特征在于，所述节点还包括：常量类型的节点、函数类型的节点和/或容器类型的节点；其中，所述容器类型的节点封装包括不同类型的节点和不同类型的边的语义图且被上一层的语义图调用，以用于构建多层级的语义图。
  5. 根据权利要求1所述的方法，其特征在于，所述边包括：流程控制关系类型的边、计算关系类型的边、逻辑判断关系类型的边和/或逻辑链接关系类型的边。
  6. 根据权利要求2所述的方法，其特征在于，所述根据所述实例图中的节点之间的业务逻辑关系，生成可执行代码，包括：
    以所述实例图中的入度为0的节点为起始节点，进行局部广度优先遍历，根据实例图中节点的依赖关系生成多条独立可并行运行的路径；
    遍历过程中确定出与预定义的元路径特征匹配的子路径，根据该路径中节点的类型及边对应的语义含义，生成可执行代码。
    若遍历过程中发现容器类型的节点，则打开容器节点封装的下层子图逻辑，按照同样逻辑遍历子图，完成子图中可执行代码生成，然后再返回上层实例图，继续完成后续操作；
  7. 根据权利要求6所述的方法，其特征在于，所述方法还包括：
    根据预定义的元路径特征，剔除所述实例图中没有数据实例的节点所在的路径。
  8. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    确定所述可执行代码在计算环境中的运行状态及运行进度。
  9. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    对所述语义图进行冲突检测。
  10. 根据权利要求9所述的方法，其特征在于，所述对所述语义图进行冲突检测， 包括：
    确定起始检测到的节点不在当前的连通图的节点集合中，则从起始检测到的节点开始做深度优先遍历；
    每遍历到一个节点，若该节点无访问标记，则打上访问标记，将该节点加入到当前的连通图的节点集合中，并继续往下遍历，否则确定发现有向环，并输出所有带有访问标记的节点组成的路径信息；其中，若该节点的出度大于1和/或入度大于1，则将其未遍历到的前置分支节点和/或后置分支节点存入队列；
    若该节点出度为0，则将当前的连通图中的所有节点的访问标记清空，并从前置分支节点和/或后置分支节点的队列中取出新的节点，重复上述步骤，否则从当前的连通图的所有节点之外，选择一个节点，重复上述步骤。
  11. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    对所述语义图进行逻辑表达歧义性检测。
  12. 根据权利要求11所述的方法，其特征在于，所述对所述语义图进行逻辑表达歧义性检测，包括：
    在所述语义图中，当if-then表达的概念层业务逻辑的假设条件成立时，若出现至少两种处理方式，则确定出所述语义图存在逻辑表达歧义。
  13. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    对所述实例图中节点之间的依赖关系进行关联影响分析并基于调整后的数据实例进行what-if分析；其中，所述what-if分析用于表征调整后的数据实例对后续依赖的节点产生的影响。
  14. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    若所述实例图中的节点对应的数据实例不符合业务预期，则根据所述知识表示模型，重新生成与修改后的概念层业务逻辑对应的语义图。
  15. 一种业务逻辑的知识表示和推演装置，其特征在于，包括至少一个处理器，所述处理器用于执行存储器中存储的指令，以使得如权利要求1-14任一所述的方法被执行。
  16. 一种包含指令的计算机程序产品，其特征在于，当所述计算机程序产品在计算机上运行时，使得如权利要求1-14任一所述的方法被所述计算机执行。
  17. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时，
    如权利要求1-14任一所述的方法被执行。
PCT/CN2022/082473 2021-05-12 2022-03-23 一种业务逻辑的知识表示和推演方法及装置 WO2022237334A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP22806304.6A EP4325375A1 (en) 2021-05-12 2022-03-23 Knowledge representation and deduction method and apparatus for service logic
US18/505,892 US20240078441A1 (en) 2021-05-12 2023-11-09 Method and apparatus for knowledge representation and deduction of service logic

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110519283.0A CN115344663A (zh) 2021-05-12 2021-05-12 一种业务逻辑的知识表示和推演方法及装置
CN202110519283.0 2021-05-12

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/505,892 Continuation US20240078441A1 (en) 2021-05-12 2023-11-09 Method and apparatus for knowledge representation and deduction of service logic

Publications (1)

Publication Number Publication Date
WO2022237334A1 true WO2022237334A1 (zh) 2022-11-17

Family

ID=83946660

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/082473 WO2022237334A1 (zh) 2021-05-12 2022-03-23 一种业务逻辑的知识表示和推演方法及装置

Country Status (4)

Country Link
US (1) US20240078441A1 (zh)
EP (1) EP4325375A1 (zh)
CN (1) CN115344663A (zh)
WO (1) WO2022237334A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117611095A (zh) * 2023-12-06 2024-02-27 阿帕数字科技有限公司 应用于供应链的多功能组合搭配***的设计方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103942055A (zh) * 2014-04-30 2014-07-23 北京邮电大学 面向融合网络混合服务流程编制语言的开发***及方法
US20190087731A1 (en) * 2017-09-15 2019-03-21 International Business Machines Corporation Cognitive process code generation
CN110692050A (zh) * 2017-06-26 2020-01-14 国际商业机器公司 语义图中元关系的自适应评估
CN112579797A (zh) * 2021-02-20 2021-03-30 支付宝(杭州)信息技术有限公司 针对知识图谱的业务处理方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103942055A (zh) * 2014-04-30 2014-07-23 北京邮电大学 面向融合网络混合服务流程编制语言的开发***及方法
CN110692050A (zh) * 2017-06-26 2020-01-14 国际商业机器公司 语义图中元关系的自适应评估
US20190087731A1 (en) * 2017-09-15 2019-03-21 International Business Machines Corporation Cognitive process code generation
CN112579797A (zh) * 2021-02-20 2021-03-30 支付宝(杭州)信息技术有限公司 针对知识图谱的业务处理方法及装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117611095A (zh) * 2023-12-06 2024-02-27 阿帕数字科技有限公司 应用于供应链的多功能组合搭配***的设计方法
CN117611095B (zh) * 2023-12-06 2024-04-26 阿帕数字科技有限公司 应用于供应链的多功能组合搭配***的设计方法

Also Published As

Publication number Publication date
CN115344663A (zh) 2022-11-15
EP4325375A1 (en) 2024-02-21
US20240078441A1 (en) 2024-03-07

Similar Documents

Publication Publication Date Title
CN112394922B (zh) 决策配置方法、业务决策方法和决策引擎***
Reijers et al. Human and automatic modularizations of process models to enhance their comprehension
Barba-González et al. BIGOWL: Knowledge centered big data analytics
JP2016505953A (ja) ルールベースのデータ処理システムと方法
US11226794B2 (en) Relational logic integration
JP2015502620A (ja) 矛盾するルールを伴うケースの検出
US20080184231A1 (en) Method and system for analyzing process models
US20110004834A1 (en) Intuitive visualization of boolean expressions using flows
US20240078441A1 (en) Method and apparatus for knowledge representation and deduction of service logic
Adams et al. A framework for extracting and encoding features from object-centric event data
Ognjanović et al. A stratified framework for handling conditional preferences: an extension of the analytic hierarchy process
US11669753B1 (en) Artificial intelligence system providing interactive model interpretation and enhancement tools
US20160292305A1 (en) System, method, and program for storing and analysing a data graph
Fill et al. A knowledge perspective on big data by joining enterprise modeling and data analyses
Yerashenia et al. Computational modelling for bankruptcy prediction: Semantic data analysis integrating graph database and financial ontology
Curty et al. Design of blockchain-based applications using model-driven engineering and low-code/no-code platforms: a structured literature review
Fill An approach for analyzing the effects of risks on business processes using semantic annotations
US8862457B2 (en) Method and system for smart mark-up of natural language business rules
Calvanese et al. Semantic DMN: formalizing and reasoning about decisions in the presence of background knowledge
Ostermayer et al. Knowledge engineering for business rules in prolog
Sadowska Quality of business models expressed in BPMN
De Leenheer et al. Ontological representation and governance of business semantics in compliant service networks
Koch et al. Assessment of effort reduction due to model-to-model transformations in the web domain
Duan et al. Service value broker patterns: Towards the foundation
Smith et al. Ontology-based representation and reasoning on process models: A logic programming approach

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22806304

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022806304

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2022806304

Country of ref document: EP

Effective date: 20231114

NENP Non-entry into the national phase

Ref country code: DE