Decision graph map graph data generation method and device, business execution method and device

Abstract

The embodiment of the present specification provides a kind of decision graph atlas graph data generation method and device.The method is executed by computer, comprising: reading first graph data from first storage area, wherein it includes the first node corresponding to the event attribute of first type business event.Several rules scripts are read from second storage area, rule script defines several decision rules, each decision rule includes identification field and expression field;Any variable included in the expression field of any decision rule is one of several event attributes or the identification value of the identification field of other decision rules.Through parsing rule script, determine second graph data, wherein it includes: parsing expression field obtains the dependent relationship between decision rule and event attribute and between each decision rule;Second graph data includes the second node corresponding to several rules, and the connection edge generated according to dependent relationship.Further, based on first graph data and second graph data, generate the graph data of decision graph atlas.

Description

Technical Field

[0001] This specification relates to the field of data processing technology, and in particular to a method and apparatus for generating graph data of a decision graph, and a business execution method and apparatus. Background Technology

[0002] Domain knowledge graphs are essentially semantic networks, primarily storing industry knowledge within a specific domain. In many fields, the goal is to leverage domain knowledge graphs for business decision-making. For example, in the insurance industry, an insurance knowledge graph might be used to determine whether a user qualifies for insurance coverage. Similarly, in the equipment evaluation field, an equipment knowledge graph might be used to determine whether a piece of equipment is ready for deployment.

[0003] Constructing domain knowledge graphs (essentially generating graph data) and utilizing them for business decision-making have become current research hotspots. Therefore, the embodiments in this specification propose a scheme for generating and using graph data for decision-making graphs, which can meet higher requirements in practical applications, such as reducing costs and improving the efficiency and fairness of business decisions, etc. Summary of the Invention

[0004] This specification describes a method and apparatus for generating graph data of a decision graph, as well as a business execution method and apparatus. By customizing decision rules, the method and apparatus automatically generate a knowledge graph (or decision graph) for business decision-making, and display the decision path of event instances to users on the constructed decision graph, thereby effectively reducing the cost of expansion and maintenance, and achieving high efficiency and transparency in business decision-making.

[0005] According to the first aspect, a method for generating graph data for decision graphs is provided, which is executed by a computer. The method includes:

[0006] First graph data is read from a first storage area. This first graph data is labeled with tags representing a first type of business event and includes several first nodes corresponding to several event attributes of the first type of business event. A rule script is read from a second storage area. This rule script defines several decision rules, each including an identifier field and an expression field. Any variable in the expression field of any decision rule is an identifier value of one of the event attributes or the identifier field of another decision rule. Second graph data is determined by parsing the rule script, including parsing the expression field to obtain the dependencies between decision rules and event attributes, as well as between the decision rules themselves. The second graph data includes several second nodes corresponding to the rules, and connection edges generated based on the dependencies. Based on the first and second graph data, graph data for a decision graph is generated.

[0007] In one embodiment, the first graph data further includes an event starting node and a plurality of connecting edges between the event starting node and the plurality of first nodes.

[0008] In one embodiment, determining the second graph data by parsing the rule script further includes: creating the plurality of second nodes according to the parsed decision rules; and creating connection edges between the plurality of first nodes and the plurality of second nodes according to the dependency relationship.

[0009] In one specific embodiment, determining the second graph data by parsing the rule script further includes: parsing out the description content in the description field included in any decision rule, and using the description content as the node description information of the second node corresponding to the decision rule, and incorporating it into the second graph data.

[0010] In one embodiment, the plurality of decision rules include a first decision rule; wherein parsing the expression field to obtain the dependencies between the decision rule and the event attribute, as well as between each decision rule, includes: parsing that the expression field of the first decision rule includes a first variable and a first logical operator; and determining that there is a dependency between the first variable and the first decision rule if the first logical operator belongs to a first type of logical operator.

[0011] In one embodiment, the plurality of decision rules include a second decision rule; wherein parsing the expression field to obtain the dependencies between the decision rule and the event attribute, as well as between each decision rule, includes: parsing that the expression field of the second decision rule includes a second variable and a second logical operator; if the second logical operator belongs to a second type of logical operator, determining that there is a dependency between the second variable and the second logical operator, and that there is a dependency between the second logical operator and the second decision rule; wherein the second graph data also includes a third node corresponding to the second logical operator.

[0012] In one embodiment, the plurality of decision rules include a third decision rule; wherein parsing the expression field to obtain the dependencies between the decision rules and event attributes, as well as between each decision rule, includes: parsing that the third decision rule includes a third variable, a predicate, and a conclusion, wherein the third decision rule indicates that the conclusion is output when the value of the third variable is true; and parsing that the third variable has a dependency relationship with the third decision rule.

[0013] According to the second aspect, a business execution method is provided, executed by a computer. The method includes:

[0014] The system receives an input event instance, which includes attribute values ​​corresponding to at least a portion of several event attributes under its event type. It then invokes a rule script corresponding to the event type, where each defined decision rule includes an identifier field and an expression field; any variable in the expression field of any decision rule is an identifier value of one of the event attributes or the identifier field of another decision rule. The system executes the rule script based on the event instance to obtain matching results against the decision rules. Based on the matching results, it displays a decision path for the event instance using a decision graph corresponding to the event type.

[0015] In one embodiment, the rule script further includes trigger condition rules, which indicate that when the event type of the event instance matches the event type, the matching of each decision rule is triggered.

[0016] In one specific embodiment, based on the matching result, a decision path for the event instance is displayed based on the decision graph corresponding to the event type, including: determining the successfully matched nodes in the decision graph based on the matching result; and highlighting the connection paths between the successfully matched nodes based on the decision graph.

[0017] According to a third aspect, a graph data generation apparatus for decision graphs is provided. The apparatus includes:

[0018] A first reading module is configured to read first graph data from a first storage area. The first graph data is labeled with tags representing a first type of business event and includes several first nodes corresponding to several event attributes of the first type of business event. A second reading module is configured to read a rule script from a second storage area. The rule script defines several decision rules, each including an identifier field and an expression field. Any variable in the expression field of any decision rule is an identifier value of one of the event attributes or the identifier field of another decision rule. A determination module is configured to determine second graph data by parsing the rule script, including: parsing the expression field to obtain the dependencies between decision rules and event attributes, and between the decision rules themselves; the second graph data includes several second nodes corresponding to the several rules, and connection edges generated based on the dependencies. A generation module is configured to generate graph data for a decision graph based on the first and second graph data.

[0019] According to a fourth aspect, a business execution apparatus is provided. The apparatus includes:

[0020] The receiving module is configured to receive an input event instance, wherein the event instance includes attribute values ​​corresponding to at least a portion of several event attributes under its event type. The calling module is configured to call a rule script corresponding to the event type, wherein each defined decision rule includes an identifier field and an expression field; any variable contained in the expression field of any decision rule is an identifier value of one of the several event attributes or the identifier field of another decision rule. The execution module is configured to execute the rule script based on the event instance to obtain matching results that are matched against the various decision rules. The display module is configured to display a decision path for the event instance based on the matching results and the decision graph corresponding to the event type.

[0021] According to a fifth aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of the first or second aspect.

[0022] According to a sixth aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of the first aspect or the second aspect.

[0023] The methods and apparatus described in the embodiments of this specification enable staff to define decision rules conforming to standard paradigms based on ontology knowledge such as concepts and attributes. This allows for the automatic generation of decision graphs based on the defined rules. These decision graphs integrate domain knowledge and decision logic, exhibiting strong scalability. Adjustments to the rules update the knowledge graph accordingly, effectively reducing expansion and maintenance costs. Furthermore, based on the decision rules, decisions can be made for event instances within the target business, and the decision-making process can be navigated within the decision graph, intuitively displaying the decision path to the user. This achieves openness, fairness, and transparency in decision-making, significantly improving the user experience. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This illustrates a subgraph model within a health assessment.

[0026] Figure 2 This demonstrates how to overlay the service layer logic onto... Figure 1 The example of a domain knowledge graph obtained from the subgraph model is shown;

[0027] Figure 3 This diagram illustrates a flowchart of a decision graph data generation method disclosed in an embodiment of this specification.

[0028] Figure 4 This illustrates the first image data generated for a thyroid ultrasound event as disclosed in the embodiments of this specification;

[0029] Figure 5 This document illustrates an example of a decision graph automatically generated based on decision rules, as disclosed in the embodiments of this specification.

[0030] Figure 6 This document illustrates a schematic diagram of the business execution method disclosed in an embodiment of the specification.

[0031] Figure 7 This diagram illustrates the textual conclusions obtained by executing rule scripts based on event instances, as disclosed in the embodiments of this specification.

[0032] Figure 8 This diagram illustrates the decision paths corresponding to event instances displayed on a decision graph, as disclosed in the embodiments of this specification.

[0033] Figure 9 This diagram illustrates the structure of a device for generating graph data of a decision graph, as disclosed in an embodiment of this specification.

[0034] Figure 10 This diagram illustrates the structure of the business execution device disclosed in the embodiments of this specification. Detailed Implementation

[0035] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0036] As mentioned earlier, in many fields, there is a desire to leverage domain knowledge graphs to achieve business decisions. However, in traditional knowledge graphs, the core of the knowledge network is the entity and semantic relationship carried by the SPO triple, where SPO represents subject, predicate, and object. For example, the insurance domain knowledge graph includes the triple (nodule, exists, thyroid).

[0037] Traditional knowledge graphs are very compatible with Natural Language Processing (NLP) for Named Entity Recognition (NER) and chaining, but they fall short in industries that require deep knowledge application, such as insurance. Determining whether a disease meets the criteria for insurance coverage requires multiple criteria and logical calculations to output multiple conclusions. Each criterion needs to reference a large number of entities and semantic relationships, and the logical calculations themselves are often enormous, with a complexity comparable to basic ontology knowledge.

[0038] Therefore, effectively expressing and managing these logics in an orderly manner, and achieving seamless integration with ontology knowledge to enable domain knowledge graphs to have business decision-making capabilities, is an effective direction for thinking.

[0039] Traditional knowledge graphs only store ontology knowledge, including entities and semantic relationships between them. This leads to a proposed technical architecture where the knowledge graph provides the data foundation, while the rules for knowledge usage and the judgment logic are implemented in the technical service layer. This approach works well initially, but as the rules iterate and the upper layers support more and more scenarios, the following problems arise:

[0040] a. The strong coupling between knowledge graphs and the service layer introduces vulnerabilities in the technical architecture. Traditionally, knowledge graphs primarily address cognitive problems, storing ontology-based knowledge. However, in vertical domains, the focus is on solving business-oriented decision-making problems. This requires technical personnel to first understand the knowledge structure and then implement a significant amount of decision-making logic in the service layer. This strong coupling necessitates considering compatibility and collaboration with other scenarios when the knowledge graph serves multiple business scenarios. This hinders knowledge evolution and increases the cost of service integration.

[0041] b. The strong coupling between knowledge graphs and the service layer will inevitably increase the access cost of business applications. Knowledge graphs are easier to understand and use because their data organization format is close to human language models. However, if the service layer needs to implement the knowledge operation logic, then technical personnel must first understand the knowledge network and then learn the industry information behind the operation logic. Obviously, this is very unfriendly to technical personnel, and as business scenarios increase, this part of the logic will be implemented repeatedly.

[0042] c. The cost of expanding and maintaining knowledge and computational logic is high. Knowledge and rules are invisible to each other, which makes it difficult to unify expansion and maintenance in knowledge operation. Changes in knowledge or changes in the logic of knowledge application can easily lead to unpredictable results, resulting in financial losses in extreme scenarios of high-intensity iteration.

[0043] d. The reasoning conclusions lack good interpretability. One of the advantages of knowledge graphs is their white-box explanation, but when the rules for using knowledge (metadata of knowledge) are disconnected from the knowledge itself, it is difficult to explain to the user where the current conclusion comes from, or why a conclusion cannot be output at present, or what key inputs are missing.

[0044] The implementation of the above technical architecture will be explained using health assessment in insurance business as an example. Figure 2 This demonstrates how to overlay the service layer logic onto... Figure 1 The example of a domain knowledge graph derived from the shown subgraph model takes as input indicators, indicator values, organs, parts, and tissues, and outputs underwriting approval and underwriting rejection. For service layer developers, this means not only understanding the subgraph structure but also comprehending and implementing complex reasoning logic. While these issues may not be apparent in the early stages of a project, they become a heavy burden as the project enters a fast-paced iteration cycle. Similarly, for knowledge experts, the lack of consistency between rule and knowledge maintenance increases workload. Returning to this example, we can see at least the following logical branches:

[0045] path1: Indicator = calcification, Indicator value in("scattered", "punctate", "single"), Organ = thyroid gland, Location in("left", "right", "bilateral")

[0046] path2: Indicator = Capsule, Indicator value in("scattered", "punctate", "single"), Organ = Thyroid gland, Location in("left", "right", "bilateral")

[0047] path3: Indicator = NULL, Organ = Thyroid, Tissue = Nodule

[0048] It can be seen that such logical judgments undoubtedly pose a huge challenge to the understanding of technical personnel, while at the same time seamlessly binding the service layer and knowledge base together.

[0049] Based on the above observations and analysis, this specification proposes a decision-making scheme that allows staff to define decision rules conforming to standard paradigms based on ontology knowledge such as concepts and attributes. This enables the automatic generation of a decision graph based on the defined rules. This decision graph integrates domain knowledge and decision logic, exhibiting strong scalability. Adjustments to the rules update the knowledge graph accordingly, effectively reducing expansion and maintenance costs. Furthermore, based on the decision rules, decisions can be made for event instances within the target business context, and the decision-making process can be navigated within the decision graph, intuitively displaying the decision path to the user. This achieves openness, fairness, and transparency in decision-making, significantly improving the user experience.

[0050] The implementation steps of the above decision-making scheme will be explained below with reference to the accompanying diagram. Specifically, the method for constructing the decision graph will be introduced first, followed by the method for executing target business based on the decision graph.

[0051] Figure 3 This diagram illustrates a flowchart of a decision graph generation method disclosed in an embodiment of this specification. The method is executed by a computer, which can refer to any device, platform, server, or equipment cluster with computing and processing capabilities. Figure 3 As shown, the method includes the following steps:

[0052] Step S310: Read first graph data from the first storage area. The first graph data is labeled with tags for a first type of business event. The first graph data includes several first nodes corresponding to several event attributes of the first type of business event. Step S320: Read rule script from the second storage area. The rule script defines several decision rules. Each decision rule includes an identifier field and an expression field. Any variable contained in the expression field of any decision rule is the identifier value of one of the several event attributes or the identifier field of another decision rule. Step S330: Determine second graph data by parsing the rule script. This includes: parsing the expression field to obtain the dependency relationships between decision rules and event attributes, as well as between each decision rule. The second graph data includes several second nodes corresponding to the several rules, and connection edges generated according to the dependency relationships. Step S340: Generate a decision graph based on the first graph data and the second graph data.

[0053] The steps above are explained in detail below:

[0054] In step S310, the first image data is read from the first storage area.

[0055] It should be noted that the "first" in "first storage area" and "first graph data," as well as the "second" and similar terms elsewhere in the text, are all used to distinguish similar things and do not have any other limiting function such as sorting.

[0056] The first storage area refers to the area used to store the first graph data. Whether it is temporary storage, such as storage in memory, or persistent storage, such as storage on disk, is not limited in the embodiments of this specification.

[0057] The data in the first graph is labeled with the tag for Category 1 business events, meaning that the data in the first graph is applicable to at least Category 1 business events. For example, in insurance business involving health assessments, a Category 1 business event could be a thyroid ultrasound report. As another example, in the field of equipment testing, a Category 1 business event could be a testing report for a specific piece of equipment. It should be understood that the data in the first graph can also be applicable to other types of business events; that is, the data in the first graph can also be labeled with tags for other types of business events, such as medical examination events other than thyroid ultrasound reports, including breast ultrasound reports, pancreatic ultrasound reports, etc.

[0058] In essence, the first graph data is built upon ontology knowledge, including concepts, attributes, and relationships, abstracted from the first type of business events. Specifically, the first graph data includes at least several first nodes corresponding to several event attributes of the first type of business events. It should be noted that "several" in this text refers to one or more, and a first node can also be called an attribute node. For example, Figure 3 This is the first image of data generated for thyroid ultrasound events. The four attribute nodes shown correspond to four event attributes abstracted from medical examination events such as thyroid ultrasound events: human tissue, indicator value, indicator, and organ.

[0059] In one embodiment, the first graph data further includes an event initiation node and a plurality of first connection edges corresponding to the event initiation node and a plurality of first nodes. Typically, the first connection edges point from the event initiation node to the first nodes. For example, Figure 4 This indicates the starting node of the event, whose description (or node name) indicates the start of the event. However, it can also be other names such as "event start". Figure 4 The image also shows four connecting edges between the event starting node and the four attribute nodes.

[0060] In one embodiment, the first graph data further includes the relationship type of the first connecting edges. For example, the relationship type from the event start node to the attribute node can be set to "owns attribute," as can be seen in [reference needed]. Figure 4 .

[0061] The above describes the first graph data read from the first storage area, labeled with the first type of business event tags.

[0062] In step S320, the rule script corresponding to the first type of business event is read from the second storage area. It should be noted that step S320 can be executed before, after, or simultaneously with step S310; this embodiment of the specification does not limit this.

[0063] The second storage area refers to the area used to store rule scripts. Whether it is temporary or persistent storage is not limited in the embodiments of this specification.

[0064] The rule script includes several decision rules defined by staff. For ease of understanding, an example rule script is shown below:

[0065] A(“Index Value”): mtIndexValue in [“Point-like”, “Scattered”, “Single”]

[0066] B(“Indicator”): mtIndex in [“Calcification”]

[0067] C ("Thyroid gland"): human tissue in the thyroid gland

[0068] D(“lesion site”):organ in [“left side”, “right side”, “bilateral”]

[0069] F(“nodule”): human tissue in [“nodule”]

[0070] R1 (“Thyroid nodule”): (B and C and D) or (C and F)

[0071] E(“calcification”): mtIndex in [“capsule”]

[0072] R2 (“Thyroid Cyst”): E and C and F

[0073] R3 (“High-risk for thyroid nodules”): A and R1

[0074] C1 (“High-risk conclusion for thyroid nodules”) = R3 leadTo “High-risk for thyroid nodules”

[0075] R4 (“Low-risk conclusion for thyroid nodules”) = R1 leadTo “Low-risk thyroid nodules”

[0076] R5 (“Low-risk thyroid cyst”): A and R2

[0077] C2(“Low-risk conclusion for thyroid cysts”): R5 leadTo “Low-risk for thyroid cysts”

[0078] C3 (“Health Declaration Conclusion Approved”) = R4 or R5 leadTo “Underwriting Approved”

[0079] C4 (“Health Declaration Not Approved”) = R3 leadTo “Underwriting Rejection”

[0080] In the rule script example above, each line represents a decision rule. Below, we will use this example to introduce the standard paradigm for decision rules and the composition of a rule script.

[0081] Each decision rule in the rule script conforms to a standard paradigm and includes at least an identifier field and an expression field. The value of the identifier field is used to uniquely identify the decision rule; in this document, the value of the identifier field may be simply referred to as the identifier value. In one embodiment, the identifier value may consist of English letters or numbers. Referring to the rule script example above, the identifier value can be A, B, R1, R2, C1, or C2, etc.

[0082] In the standard paradigm of decision rules, the expression field can be designed to be located to the right of the identifier field and separated by a predetermined symbol. For example, in the rule script example above, the expression field follows the equals sign (=) or colon (:).

[0083] The expression field includes variables, which can be event attributes or rule identifiers. Specifically, any variable included in the expression field of any decision rule is the identifier value of one of the event attributes of the first type of business event mentioned above, or the identifier field of another decision rule. Referring to the rule script example above, the expression field of decision rule A includes the variable mtIndexValue, corresponding to the event attribute "Indicator," and the expression field of decision rule R1 includes variables B, C, D, and F, which are the identifier values ​​of rules B, C, D, and F, respectively.

[0084] The expression field also includes operators. In one embodiment, operators include operators such as arithmetic operators or logical operators. In one specific embodiment, the arithmetic operators could be +, ÷, etc. In another specific embodiment, the logical operators could be in, >, <, ==, >=, <=, and, or, etc. The in field is followed by an array, indicating whether the operand (or the value of the variable) is an item in the array. For example, "abc" in ["abc", "cde", "efg"] results in true.

[0085] In one example, the expression field mtIndexValue in[“point-like”, “scattered”, “single”] in the above decision rule A means to determine whether the variable mtIndexValue matches “point-like”, “scattered”, or “single”. If it matches, the result of the execution of decision rule A is true; otherwise, it is false.

[0086] In another example, the expression field (B and C and D)or(C and F) in the decision rule R1 above represents a logical AND or OR operation based on the execution results of rules B, C, D, and F. For example, if the execution results of rules B, C, and D are all true, then the execution result of decision rule R1 is true; or, if the execution result of rule C is false, then the execution result of rule R1 is false.

[0087] In another embodiment, the operator includes a predicate, with a variable on the left and a conclusion on the right, indicating that the conclusion should be output when the variable's value is true. It should be understood that the notation for this predicate can be arbitrarily set, for example, it can be written as `leadTo`. In one example, the expression field in the decision rule C1 above is `R3 leadTo "High-risk thyroid nodules"`, meaning that if the execution result of decision R3 is true, then "High-risk thyroid nodules" will be output; otherwise, no output will be given.

[0088] In yet another embodiment, the operator includes a function name, such as a date calculation function, used to calculate the number of days between two dates.

[0089] The above describes the identifier field and expression field that are at least included in a decision rule. For example, a decision rule is jj89757:mtIndexValue in[“cough”,“runny nose”,“fever”], where the left side of the colon (:) is the identifier field and the right side is the expression field.

[0090] According to another embodiment, the decision rule also includes a description field. The content of the description field can be used to describe the meaning of the rule and to describe rule nodes in the subsequent decision graph constructed based on the decision rule. For example, the description field of the above decision rule C includes "thyroid," which is used as... Figure 5 The decision graph shown describes the rule nodes corresponding to decision rule C.

[0091] In a specific embodiment, the design in the standard paradigm of decision rules places the description field between the identifier field and the expression field, and the three fields can be separated by preset symbols. For example, the content of the description field is written in parentheses, and the description field and the expression field are separated by an equal sign (=) or a colon (:). See the rule script example above for details.

[0092] It is understandable that the identifier field and expression field, or the identifier field, description field, and expression field in the decision rule, can be arranged in other orders or separated by other symbols; these will not be exhaustively listed here. Furthermore, when several decision rules constitute multiple decision rules, the order of arrangement generally requires that one rule be defined first before it can be referenced in subsequent rules. For example, if decision rule C3 references decision rules R4 and R5, then R3 and R4 must be defined first before C3 can be defined.

[0093] The rule script described above includes decision rules, which can be one or more, but usually more.

[0094] According to another embodiment, the rule script may also include other types of rules besides decision rules, such as trigger condition rules. Trigger condition rules indicate that the matching and execution of the aforementioned decision rules will only be triggered when the event type of the event instance matches a preset event type (such as a first-type business event); otherwise, the decision rules will not be executed.

[0095] For example, the trigger condition rule is: Require(“Trigger Condition”):name == “Thyroid Ultrasound Report”, which indicates that the execution of the decision rule in the rule script will only be triggered when the type of the input event instance is “Thyroid Ultrasound Report”, or in other words, the rule script will be recalled for execution.

[0096] The above describes the rule scripts read from the second storage area that correspond to the first type of business events.

[0097] In step S330, the data for the second graph is determined by parsing the rule script.

[0098] It should be understood that executing the rule script already enables decision-making on target business events and outputs the decision result text. The main purpose of this step is to subsequently generate a decision graph, thereby visualizing the decision path. This allows users to intuitively view the business decision-making process and also facilitates the editing and debugging of the rule script by staff.

[0099] Specifically, this step includes: generating (or creating) several second nodes based on several decision rules parsed from the rule script; and generating (or creating) connection edges between several second nodes and several first nodes contained in the first graph data based on the dependency relationships between the decision rules and event attributes, and between the decision rules themselves, obtained by parsing the expression fields in each decision rule.

[0100] It should be noted that the generation of nodes and edges involved in this step does not necessarily require generating all nodes first and then creating the edges. Node and edge generation can also be performed alternately or simultaneously, as long as the data generation order is logical. For example, the decision rules arranged sequentially in the rule script can be parsed sequentially, generating corresponding node or edge data for each rule parsed, and then incorporated into the data in the second graph mentioned above.

[0101] To facilitate understanding, the generation of the second graph data will be introduced from the perspective of generating corresponding node and edge data for each decision rule in the parsing rule script.

[0102] Let's parse each decision rule in the rule script as the current decision rule. Specifically, for the current decision rule:

[0103] 1) Generate a second node (or rule node) corresponding to the current decision rule and incorporate it into the second graph data.

[0104] Figure 5 The decision graph example shown includes second graph data generated based on the rule script example described above. Assume the current decision rule is decision rule C from the rule script example described above. Figure 5 The rule matching section shows the second node (the second square node from left to right) corresponding to decision rule C.

[0105] In one embodiment, descriptive content can be extracted from the description field of the current decision rule and used as the node name or description information of the current rule node, and this description information can be included in the second graph data. For example, Figure 5 The text displays the description "thyroid" extracted from decision rule C, serving as node description information.

[0106] 2) Parse the expression field in the current decision rule, including the following cases:

[0107] 2.1) Parse out the first logical operators belonging to the first category of logical operators included in the current expression field. It should be understood that the first category of logical operators can be set according to business requirements, such as including in, >, <, ==, >=, and <=.

[0108] Based on this, the dependency relationship between the current variable (there may be one or more current variables) in the current expression field and the current decision rule is further analyzed, and a connection edge is established between the node corresponding to the current variable and the second node corresponding to the current decision rule, which is then incorporated into the second graph data. In one embodiment, the type of this dependency relationship can also be determined, for example, it can be determined as "applies to" or "apply", etc.

[0109] For example, assuming the current decision rule is decision rule C as described above, it can be parsed that the logical operator 'in' included in its expression field belongs to the first type of logical operator. Based on this, it can be parsed that the event attribute "human tissue" corresponding to the current variable humanTissue has a dependency relationship with decision rule C, and thus generate a system based on this dependency relationship. Figure 5 The diagram shows the connecting edges from the "Human Tissue" node to the "Thyroid" node.

[0110] 2.2) Parse out the second logical operators that belong to the second category of logical operators included in the current expression field. It should be understood that the second category of logical operators can also be set according to business requirements, and there is no overlap between them and the first category of logical operators. For example, the second category of logical operators can be configured to include AND, OR, and XOR.

[0111] Based on this, third nodes corresponding to several second logical operators are generated. Furthermore, the dependencies between each second logical operator and the current variable, the current decision rule, or other second logical operators are parsed, and corresponding connection edges are established based on these dependencies, which are then incorporated into the second graph data. In one embodiment, the type of this dependency can also be determined, such as "applies to" or "apply", and incorporated into the second graph data.

[0112] In one embodiment, if the number of second logical operators in the current expression field is 1, then it can be determined that there are dependencies between the second logical operators and the current variable and the current decision rule.

[0113] For example, suppose the current decision rule is decision rule R3 as described above, and its expression field includes the logical operator AND, as well as the current variables A and R1. In this case, as follows... Figure 5 As shown, a third node corresponding to the logical operator AND can be generated. Figure 5 The leftmost diamond-shaped node in the middle logic execution part, and based on the parsed dependencies, establish connection edges from the "index value" node corresponding to the current variable A to the "AND" node, from the "thyroid nodule" node corresponding to the current variable R1 to the "AND" node, and from the "AND" node to the "high-risk thyroid nodule" node.

[0114] In another embodiment, if the operators in the current expression field include multiple second logical operators, the dependency relationship can be determined according to the priority or operation logic of each second logical operator.

[0115] For example, suppose the current decision rule is decision rule R1 as described above, and its expression field includes three logical operators (AND) and one logical operator (OR). In this case, as follows... Figure 5 As shown, one "OR" node and two "AND" nodes (located above the OR node) can be generated according to the operation logic. Based on the parsed dependencies, connection edges are established between the "AND" node and the variable node, between the "AND" node and the "OR" node, and between the "OR" node and the rule node. For details, please refer to [link to documentation]. Figure 5 I won't go into too much detail.

[0116] 2.3) Parse the current expression field to find that it includes the predicates mentioned above, and then parse the dependency relationship between the current variable and the current decision rule. Based on this dependency relationship, establish the corresponding connection edge and incorporate it into the second graph data. In one embodiment, the type of this dependency relationship can also be determined, such as determining it as "causing".

[0117] For example, suppose the current decision rule is decision rule C4 as described above, and its expression field includes the predicate `leadto`. In this case, as... Figure 5 As shown, a connection edge can be established between the "High-risk thyroid nodules" node and the "Not passing health report conclusion" node corresponding to the current variable R3 based on the parsed dependency relationship, and the type of the connection edge is set to cause.

[0118] The above provides an illustrative introduction to the parsing of rule scripts and the generation of second graph data. It should be understood that script parsing and graph data generation can actually be performed alternately, such as generating corresponding graph data after parsing each one or two decision rules, or sequentially, such as completing the parsing of the rule scripts first and then generating all the second graph data based on the parsing results. There is no limitation on which method is used.

[0119] In step S340, graph data for the decision graph is generated based on the first graph data and the second graph data. It should be understood that "graph data for the decision graph" and "decision graph" can be used interchangeably in this text.

[0120] In one embodiment, the first graph data and the second graph data can be directly merged, or in other words, the union can be calculated, and the merged data can be used as the graph data of the decision graph.

[0121] In another embodiment, considering that the first graph data may not only be labeled with tags for the first type of business event, but also with tags for other types of business events, this means that the shared attribute nodes corresponding to the first type of business event and other types of business events included in the first graph data may also include unique attribute nodes corresponding to other types of business events. In this case, it is proposed that, based on the first node involved in the second graph data, the nodes and edge data related to that first node in the first graph data be retained, while others are removed. Then, the remaining first graph data is merged with the second graph data to form the graph data for the decision graph.

[0122] Figure 5 The example decision graph shown is automatically generated based on the rule script instance described above. It should be understood that... Figure 5 The diagram only shows one possible style; in reality, the visual elements can be designed in other ways. For example, circular node icons could be replaced with spherical icons, or the text descriptions for "Event Input," "Rule Matching," "Logic Execution," and "Conclusion Output" could be omitted. Furthermore, Figure 5 The diagram provides a simplified illustration of the relationship types of connecting edges, and does not show all of them. In fact, the relationship types of connecting edges can be hidden or omitted.

[0123] In summary, the decision graph generation method disclosed in the embodiments of the specification allows staff to define decision rules that conform to standard paradigms based on ontology knowledge such as concepts and attributes, forming a programmable expression of computational logic. This enables the automatic generation of decision graphs based on the defined decision rules. The decision graph integrates domain knowledge and decision logic, has strong scalability, and updates accordingly by adjusting the rules, effectively reducing expansion and maintenance costs.

[0124] The above describes the method for generating decision graphs. Next, we will introduce the method for executing target business based on decision graphs. Figure 6 This diagram illustrates a business execution method flow chart disclosed in an embodiment of this specification. The method is executed by a computer, which can refer to any device, platform, server, or equipment cluster with computing and processing capabilities. Figure 6 As shown, the business execution method includes the following steps:

[0125] Step S610: Receive an input event instance, the event instance including attribute values ​​corresponding to at least a portion of several event attributes under its event type; Step S620: Call the rule script corresponding to the event type, wherein each defined decision rule includes an identifier field and an expression field; any variable contained in the expression field of any decision rule is an identifier value of one of the several event attributes or the identifier field of another decision rule; Step S630: Execute the rule script based on the event instance to obtain a matching result matching the various decision rules; Step S640: Based on the matching result, display the decision path for the event instance based on the decision graph corresponding to the event type.

[0126] The steps above are explained in detail below:

[0127] In step S610, an input event instance is received, the event instance including attribute values ​​corresponding to at least a portion of several event attributes under its event type.

[0128] In one embodiment, a thyroid test report uploaded by a user is received through an insurance business processing platform. For example, several event attributes include human tissue, indicator value, indicator, and organ. In this case, the received attribute value might be thyroid, punctate, capsule, right side, etc.

[0129] In another embodiment, a device testing platform accepts device testing reports uploaded by users for a certain type of device.

[0130] It should be noted that the event type corresponding to the event instance can be referred to as the first type of business event mentioned above. Accordingly, for the introduction of the event type and its several event attributes, please refer to the aforementioned introduction of the first type of business event and its several event attributes, which will not be repeated here.

[0131] In step S620, the rule script corresponding to the event type is invoked.

[0132] In one embodiment, the rule script can be read from the aforementioned second storage area.

[0133] In one embodiment, multiple rule scripts corresponding to multiple event types can be obtained first, and then calculations can be performed based on the triggering condition rules defined in the rule scripts. If the triggering condition rule is met, the matching of the decision rule in the rule script is triggered. Alternatively, if no triggering condition rule is defined in the rule script, the execution of the rule script is triggered by default.

[0134] It should be noted that the description of the rule script can be found in the relevant description in the foregoing embodiments, and will not be repeated here.

[0135] In step S630, the rule script is executed based on the event instance to obtain the matching results with each decision rule.

[0136] For example, Figure 7 This diagram illustrates the textual conclusions obtained by executing rule scripts based on event instances, as disclosed in the embodiments of this specification. The conclusions and explanations correspond to decision rules that have been successfully matched (or whose execution results are true).

[0137] In step S640, based on the matching result, a decision path for the event instance is displayed based on the decision graph corresponding to the event type.

[0138] For example, nodes that have successfully matched in the decision graph can be determined based on the matching results, and then the connection paths between the successfully matched nodes can be highlighted in the decision graph, such as by bolding or highlighting.

[0139] For example, Figure 8 This diagram illustrates the display of decision paths corresponding to event instances on a decision graph, as disclosed in the embodiments of this specification, with the decision paths highlighted in bold. This allows for a visual representation of the decision paths. It should be understood that the decision paths can be displayed statically or dynamically; for example, a dynamic display can be achieved by sequentially illuminating nodes and connecting edges.

[0140] In summary, by adopting the business execution method disclosed in the embodiments of this specification, business decisions can be made based on rule scripts, and the decision-making process can move within the decision graph, intuitively displaying the decision path to the user, thereby achieving openness, fairness and transparency in decision-making and greatly improving the user experience.

[0141] In summary, the decision-making schemes disclosed in the embodiments of this specification have the following beneficial effects:

[0142] 1) The computational logic of knowledge is integrated into the insurance knowledge graph in the form of another knowledge carrier, thereby forming an independent decision-making capability. When using it, the application layer only needs to pass in the information it has in a structured form to obtain a conclusion that it can understand. In this process, the decoupling of the graph and the service is achieved.

[0143] 2) The computational logic converges in the insurance knowledge graph, which on the one hand realizes integrated maintenance; on the other hand, it displays the computational logic and ontology knowledge network in a graphical form through visualization, reducing the understanding cost for users.

[0144] 2) The calculation process of the decision result and the graph walking process are highly coordinated. Therefore, it can not only use the semantic network of the insurance knowledge graph to output the semantic text explanation of the decision result, but also guide the caller to continuously fill in the missing elements in the calculation process to approach the conclusion when there is no decision result. Finally, it can provide graphical explanations at low cost.

[0145] Corresponding to the above-mentioned map generation method and business decision-making method, the embodiments of this specification also disclose related devices.

[0146] Figure 9 This diagram illustrates a structural schematic of a device for generating graph data for a decision graph, as disclosed in an embodiment of this specification. The device can be integrated into a computer, where "computer" refers to any server, platform, or device cluster with computing and processing capabilities. Figure 9 As shown, the device 900 includes:

[0147] The first reading module 910 is configured to read first graph data from a first storage area. The first graph data is labeled with tags for a first type of business event and includes several first nodes corresponding to several event attributes of the first type of business event. The second reading module 920 is configured to read a rule script from a second storage area. The rule script defines several decision rules, each including an identifier field and an expression field. Any variable in the expression field of any decision rule is an identifier value of one of the several event attributes or the identifier field of another decision rule. The determining module 930 is configured to determine second graph data by parsing the rule script, including: parsing the expression field to obtain the dependencies between decision rules and event attributes, and between the decision rules; the second graph data includes several second nodes corresponding to the several rules, and connection edges generated according to the dependencies. The generating module 940 is configured to generate graph data for a decision graph based on the first graph data and the second graph data.

[0148] In one embodiment, the first graph data further includes an event starting node and a plurality of connecting edges between the event starting node and the plurality of first nodes.

[0149] In one embodiment, the determining module 930 is further configured to: create the plurality of second nodes according to the parsed plurality of decision rules; and create connection edges between the plurality of first nodes and the plurality of second nodes according to the dependency relationship.

[0150] In a specific embodiment, the determining module 930 is further configured to: parse out the description content in the description field included in any decision rule, and use the description content as the node description information of the second node corresponding to the decision rule, and incorporate it into the second graph data.

[0151] In one embodiment, the plurality of decision rules include a first decision rule; the determining module 930 is specifically configured to: parse out that the expression field of the first decision rule includes a first variable and a first logical operator; and, if the first logical operator belongs to a first type of logical operator, determine that there is a dependency relationship between the first variable and the first decision rule.

[0152] In one embodiment, the plurality of decision rules include a second decision rule; the determining module 930 is specifically configured to: parse the expression field of the second decision rule to include a second variable and a second logical operator; if the second logical operator belongs to a second type of logical operator, determine that there is a dependency relationship between the second variable and the second logical operator, and that there is a dependency relationship between the second logical operator and the second decision rule; wherein, the second graph data also includes a third node corresponding to the second logical operator.

[0153] In one embodiment, the plurality of decision rules include a third decision rule; the determining module 930 is specifically configured to: parse out that the third decision rule includes a third variable, a predicate, and a conclusion, wherein the third decision rule indicates that the conclusion is output when the value of the third variable is true; and parse out that the third variable has a dependency relationship with the third decision rule.

[0154] Figure 10 This diagram illustrates the structure of the business execution device disclosed in the embodiments of this specification. The device can be integrated into a computer, where "computer" refers to any server, platform, device cluster, etc., with computing and processing capabilities. Figure 10 As shown, the device 1000 includes:

[0155] The receiving module 1010 is configured to receive an input event instance, the event instance including attribute values ​​corresponding to at least a portion of several event attributes under its event type. The calling module 1020 is configured to call a rule script corresponding to the event type, wherein each defined decision rule includes an identifier field and an expression field; any variable included in the expression field of any decision rule is an identifier value of one of the several event attributes or the identifier field of another decision rule. The execution module 1030 is configured to execute the rule script based on the event instance to obtain matching results that match the various decision rules. The display module 1040 is configured to display a decision path for the event instance based on the matching results and the decision graph corresponding to the event type.

[0156] In one embodiment, the rule script further includes trigger condition rules, which indicate that when the event type of the event instance matches the event type, the matching of each decision rule is triggered.

[0157] In a specific embodiment, the display module 1040 is specifically configured to: determine the successfully matched nodes in the decision graph based on the matching results; and highlight the connection paths between the successfully matched nodes based on the decision graph.

[0158] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform a combination Figure 3 or Figure 6 The method described.

[0159] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements a combination... Figure 3 or Figure 6 The method described.

[0160] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this invention can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0161] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for generating graph data for a decision graph, executed by a computer, comprising: Read the first graph data from the first storage area. The first graph data is labeled with the tags of the first type of business events. The first graph data includes several first nodes corresponding to several event attributes of the first type of business events. Read the rule script from the second storage area. The rule script defines several decision rules, each of which includes an identifier field and an expression field. Any variable contained in the expression field of any decision rule is the identifier value of one of the event attributes or the identifier field of another decision rule; The second graph data is determined by parsing the rule script, including: parsing the expression field to obtain the dependency relationship between decision rules and event attributes, as well as between each decision rule; the second graph data includes a number of second nodes corresponding to the number of decision rules, and connection edges generated according to the dependency relationship, including connection edges created between the number of first nodes and the number of second nodes. The decision graph data is generated by merging the first and second graph data.

2. The method according to claim 1, wherein, The first graph data also includes an event starting node, and several connecting edges between the event starting node and the several first nodes.

3. The method according to claim 1, wherein, The data for the second graph determined by parsing the rule script also includes: Parse the description content in the description field included in any of the decision rules, and use the description content as the node description information of the second node corresponding to the decision rule, and incorporate it into the second graph data.

4. The method according to claim 1, wherein the plurality of decision rules includes a first decision rule; wherein, Parsing the expression fields reveals the dependencies between decision rules and event attributes, as well as between individual decision rules, including: The parsed expression field of the first decision rule includes the first variable and the first logical operator; If the first logical operator belongs to the first type of logical operator, it is determined that there is a dependency relationship between the first variable and the first decision rule.

5. The method according to claim 1, wherein the plurality of decision rules includes a second decision rule; wherein, Parsing the expression fields reveals the dependencies between decision rules and event attributes, as well as between individual decision rules, including: The expression field parsed to reveal the second decision rule includes the second variable and the second logical operator; If the second logical operator belongs to the second type of logical operator, it is determined that there is a dependency relationship between the second variable and the second logical operator, and that there is a dependency relationship between the second logical operator and the second decision rule; The second graph data also includes a third node corresponding to the second logical operator.

6. The method according to claim 1, wherein, The aforementioned decision rules include a third decision rule; wherein, parsing the expression fields yields the dependencies between the decision rules and event attributes, as well as among the individual decision rules, including: The third decision rule is parsed to include a third variable, a predicate, and a conclusion. The third decision rule indicates that the conclusion is output when the value of the third variable is true. The third variable was found to be dependent on the third decision rule.

7. A business execution method, executed by a computer, comprising: Receive an input event instance, the event instance including attribute values ​​corresponding to at least a portion of several event attributes under its event type; Invoke the rule script corresponding to the event type, wherein each decision rule defined includes an identifier field and an expression field; Any variable contained in the expression field of any decision rule is the identifier value of one of the event attributes or the identifier field of another decision rule; The rule script is executed based on the event instance to obtain matching results that are matched against each decision rule; Based on the matching results, a decision path for the event instance is displayed based on the decision graph corresponding to the event type, wherein the graph data of the decision graph is generated using the method described in claim 1.

8. The method according to claim 7, wherein, The rule script also includes trigger condition rules, which indicate that when the event type of the event instance matches the event type, the matching of each decision rule is triggered.

9. The method according to claim 8, wherein, Based on the matching results, a decision path for the event instance is displayed using the decision graph corresponding to the event type, including: Based on the matching results, the nodes that are successfully matched in the decision graph are determined; Based on the decision graph, the connection paths between successfully matched nodes are highlighted.

10. A graph data generation device for a decision graph, comprising: The first reading module is configured to read first graph data from the first storage area. The first graph data is labeled with tags of a first type of business event. The first graph data includes several first nodes corresponding to several event attributes of the first type of business event. The second reading module is configured to read rule scripts from the second storage area. The rule scripts define several decision rules, and each decision rule includes an identifier field and an expression field. Any variable contained in the expression field of any decision rule is the identifier value of one of the event attributes or the identifier field of another decision rule; The determination module is configured to determine the second graph data by parsing the rule script, including: parsing the expression field to obtain the dependency relationship between the decision rules and event attributes, as well as between each decision rule; the second graph data includes a number of second nodes corresponding to the number of decision rules, and connection edges generated according to the dependency relationship, including connection edges created between the number of first nodes and the number of second nodes; The generation module is configured to merge the first graph data and the second graph data to generate graph data for the decision graph.

11. A business execution apparatus, comprising: A receiving module is configured to receive input event instances, wherein the event instance includes attribute values ​​corresponding to at least a portion of several event attributes under its event type; The calling module is configured to call the rule script corresponding to the event type, wherein each defined decision rule includes an identifier field and an expression field; Any variable contained in the expression field of any decision rule is the identifier value of one of the event attributes or the identifier field of another decision rule; The execution module is configured to execute the rule script based on the event instance to obtain matching results that are matched with each decision rule; The display module is configured to display a decision path for the event instance based on the matching result and the decision graph corresponding to the event type, wherein the graph data of the decision graph is generated using the apparatus of claim 10.

12. A computer-readable storage medium having a computer program stored thereon, wherein, When the computer program is executed in the computer, it causes the computer to perform the method of any one of claims 1-9.

13. A computing device comprising a memory and a processor, wherein, The memory stores executable code, and when the processor executes the executable code, it implements the method of any one of claims 1-9.

Images