Request processing method, electronic equipment, storage medium and program product

Abstract

The invention discloses a request processing method, electronic equipment, a storage medium and a program product. The method relates to the technical field of artificial intelligence, and comprises the steps that a to-be-processed request input by a user is received, and the to-be-processed request comprises request content and a request type; a rule set associated with the request type is obtained, one rule set is obtained through analysis of one service decision logic, and the service decision logics corresponding to different rule sets are different; if the number of the rule sets associated with the request type is at least two, generating a decision tree model according to all the rule sets; and inputting the request content into the decision tree model to obtain a first processing result. According to the scheme provided by the invention, the uniqueness of the request processing result can be ensured, and meanwhile, the response timeliness and accuracy are improved.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a request processing method, electronic device, storage medium, and program product. Background Technology

[0002] With the continuous development of artificial intelligence (AI) technology, the financial industry has introduced AI models to handle various business requests (such as credit approvals) and combine them with traditional rule engines to make decisions.

[0003] However, because AI models and rule engines employ two independent decision-making logics and lack a coordinating mechanism at the underlying level, the problem of fragmented decision-making becomes prominent. For example, in a loan approval scenario, a rule engine might directly trigger a rejection instruction due to an applicant's low income, while an AI model might offer approval based on the applicant's high credit score, resulting in contradictory decision outputs. In such cases, existing solutions can only rely on manual review, which is not only inefficient and slow to respond, but also susceptible to human judgment bias. Summary of the Invention

[0004] This invention provides a request processing method, electronic device, storage medium, and program product that can guarantee the uniqueness of request processing results while improving response timeliness and accuracy.

[0005] According to one aspect of the present invention, a request processing method is provided, comprising: receiving a user-inputted request to be processed, wherein the request to be processed includes request content and request type; obtaining a set of rules associated with the request type, wherein a set of rules is obtained by parsing a business decision logic, and the business decision logics corresponding to different set of rules are different from each other; if the number of set of rules associated with the request type is at least two, generating a decision tree model based on all set of rules; and inputting the request content into the decision tree model to obtain a first processing result.

[0006] Optionally, the method further includes: if the number of rule sets associated with the request type is one, then processing the request content based on the business decision logic corresponding to the rule set to obtain a second processing result.

[0007] Optionally, a rule set includes several rules; based on all rule sets, a decision tree model is generated, including: parsing each rule in each rule set to obtain condition nodes and their corresponding action nodes, wherein condition nodes obtained from parsing rules in the same rule set are stored in the same node set; determining whether there are conflicting node pairs between any two node sets, wherein a conflicting node pair includes condition nodes with the same features but different thresholds or operators stored in the two node sets; if there are no conflicting node pairs, a decision tree model is generated based on the condition nodes and their corresponding action nodes stored in all node sets; if there are conflicting node pairs, node fusion is performed on the conflicting node pairs; based on the node fusion result and the other condition nodes and their corresponding action nodes stored in all node sets except for the condition nodes included in the conflicting node pairs, a decision tree model is generated.

[0008] Optionally, node fusion is performed on the conflicting node pairs, including: calculating the node weights of the two conditional nodes included in the conflicting node pair respectively; calculating a reference value based on the node weights; if the reference value is greater than or equal to a preset threshold, deleting the low-weight node in the conflicting node pair; if the reference value is less than the preset threshold, performing threshold fusion or operator fusion on the two conditional nodes included in the conflicting node pair.

[0009] Optionally, for any one of the condition nodes included in the conflict node pair, the node weight of the condition node is calculated, including: obtaining the sample coverage rate and information gain value of the condition node, wherein the sample coverage rate is the proportion of the condition node being triggered in historical data, and the information gain value is used to reflect the condition node's ability to distinguish data decisions; and calculating the node weight of the condition node based on the sample coverage rate and information gain value.

[0010] Optionally, after generating the decision tree model, the method further includes: acquiring and parsing the newly added rules to obtain the newly added condition nodes and their corresponding action nodes; determining the position of the parent node in the decision tree model and inserting the newly added condition nodes and their corresponding action nodes into the parent node position; determining whether the newly added condition nodes will form conflicting node pairs with the subtree associated with the parent node position; if no conflicting node pairs are formed, the decision tree model update process ends; if conflicting node pairs are formed, the decision tree model is updated based on the node fusion result after performing node fusion on the conflicting node pairs.

[0011] Optionally, after obtaining the first processing result, the method further includes: generating a decision tracing path corresponding to the request to be processed, wherein the decision tracing path includes the identification information and decision features corresponding to the request to be processed.

[0012] According to another aspect of the present invention, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform a request processing method according to any embodiment of the present invention.

[0013] According to another aspect of the present invention, a computer-readable storage medium is provided, which stores computer instructions for causing a processor to execute and implement the request processing method of any embodiment of the present invention.

[0014] According to another aspect of the present invention, a computer program product is provided, the computer program product including a computer program that, when executed by a processor, implements the request processing method of any embodiment of the present invention.

[0015] The technical solution of this invention involves receiving a user-inputted request including request content and request type; then obtaining a set of rules associated with the request type; and when there are at least two rule sets associated with the request type, generating a decision tree model based on all rule sets; finally, inputting the request content into the decision tree model to obtain a first processing result. Firstly, since the rule set associated with the request type can be determined, the request to be processed is classified and processed. Secondly, when there are at least two rule sets associated with the request type, it indicates that there are at least two business decision logics for that type of request. In this case, generating a decision tree model based on the rule sets parsed from each business decision logic enables the coordination of various business decision logics, thereby avoiding inconsistencies in processing results that may result from different business decision logics. Thirdly, inputting the request content into the decision tree model to obtain the first processing result ensures the uniqueness, timeliness, and accuracy of the request processing result, and eliminates human judgment bias by eliminating the need for manual review.

[0016] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0018] Figure 1 This is a flowchart illustrating a request processing method provided in an embodiment of the present invention;

[0019] Figure 2 This is a flowchart illustrating another request processing method provided in an embodiment of the present invention;

[0020] Figure 3 This is a schematic diagram of the structure of a request processing device provided in an embodiment of the present invention;

[0021] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0022] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] Furthermore, the user-related information involved in the following embodiments of the present invention is information and data authorized by the user or fully authorized by all parties. The collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0025] Figure 1This is a flowchart illustrating a request processing method provided in an embodiment of the present invention. This embodiment is applicable to processing requests to be processed. The method can be executed by a request processing device, which can be implemented in hardware and / or software and can be configured in an electronic device (such as a server, computer equipment, etc.). Figure 1 As shown, the method includes:

[0026] S110. Receive a pending request input by the user, wherein the pending request includes the request content and the request type.

[0027] In this invention, the user can include a very broad range of entities, not limited to natural persons. The pending requests can be various requests related to the financial field. For example, when the user is a natural person, the pending requests they input could be credit approval requests initiated by a credit card user, credit limit increase requests applied for by a credit card user, work orders submitted by employees, etc.; when the user is a company / organization, the pending requests they input could be order review requests initiated by the company, material requests submitted by the organization, etc.

[0028] The request processing device can receive pending requests from users through interfaces such as Application Programming Interfaces (APIs) and microservices. A pending request includes request content and request type. The request content is the specific information or data to be processed, and the request type distinguishes the business category to which the request belongs.

[0029] In one embodiment, the request content and request type can be directly carried in the request to be processed, and the request processing device can read them directly, or they can be obtained by the request processing device after parsing the request to be processed.

[0030] S120. Obtain a set of rules associated with the request type, wherein a set of rules is obtained by parsing a business decision logic, and the business decision logic corresponding to different set of rules is different from each other.

[0031] Since different requests to be processed may belong to different business categories, and different businesses need to be processed using their associated business decision logic, the essence of step S120 is to determine the business decision logic associated with the request type and obtain the set of rules for parsing the above business decision logic.

[0032] Specifically, a request type can be associated with one or more business decision logics. For example, request type A is associated with business decision logic 1 and business decision logic 2; request type B is associated with business decision logic 3; and request type C is associated with business decision logic 4, business decision logic 5, and business decision logic 6. A business decision logic can be parsed to obtain a set of rules, meaning there is a one-to-one correspondence between a business decision logic and a set of rules. A set of rules can include several rules.

[0033] Taking a credit approval request as an example, there are two related business decision logics: an approval rule engine and an approval model. The approval rule engine, after parsing, yields rule set 1, while the approval model, after parsing, yields rule set 2. Rule set 1 includes rules such as: annual income > X yuan, number of overdue payments > N times, etc.; rule set 2 includes rules such as: annual income > Y yuan, number of overdue payments > N times, credit score > P points, etc.

[0034] In one possible implementation, the rule set can be pre-parsed for each business decision logic, and a mapping relationship exists between the rule set and the business decision logic. When a user input request is received, the request processing device can directly look up the rule set corresponding to the associated business decision logic based on the request type. This improves the speed of rule set retrieval and the efficiency of request processing.

[0035] In another possible implementation, upon receiving a user-inputted request, the request processing device first locates the associated business decision logic based on the request type, and then parses the business decision logic to obtain a set of rules associated with the request type. Compared to the above possible implementations, although it takes some time to parse the business decision logic, it avoids the problem of the business decision logic being updated while the rule set remains unchanged, thus ensuring the accuracy of the rule set and laying the foundation for accurate request processing.

[0036] It should be noted that since different rule sets are obtained by parsing different business decision logics, the business decision logics corresponding to different rule sets are different, thus ensuring that the rule sets are not redundant.

[0037] S130. If the number of rule sets associated with the request type is at least two, then generate a decision tree model based on all rule sets.

[0038] After obtaining the rule set associated with the request type, the first step is to determine whether the number of rule sets associated with the request type is greater than one. If the number of rule sets associated with the request type is one, it means that there is only one business decision logic associated with the request to be processed. This avoids the problem of inconsistent processing results that may be caused by different business decision logics. In this case, the request content can be processed directly based on the business decision logic corresponding to the rule set to obtain the second processing result.

[0039] If there are at least two rule sets associated with the request type, it means that there are at least two business decision logics associated with the request to be processed. In this case, there may be problems with inconsistent processing results caused by different business decision logics. Therefore, a decision tree model is generated based on all rule sets.

[0040] Specifically, the method for generating a decision tree model based on all rule sets can be as follows: analyze each rule in each rule set to eliminate potential conflicts between multiple rules, thereby avoiding decision conflicts in the decision tree model.

[0041] In this way, multiple independent and scattered business decision-making logics can be transformed into a unified decision tree model, which can realize the collaboration of various business decision-making logics and avoid the problem of inconsistent processing results that may be caused by different business decision-making logics.

[0042] S140. Input the request content into the decision tree model to obtain the first processing result.

[0043] After obtaining the decision tree model, input the request content into the decision tree model to obtain the first processing result.

[0044] Optionally, after obtaining the first processing result, the first processing result can be reviewed manually or through human-machine collaboration to ensure its accuracy.

[0045] The technical solution of this invention involves receiving a user-inputted request including request content and request type; then obtaining a set of rules associated with the request type; and when there are at least two rule sets associated with the request type, generating a decision tree model based on all rule sets; finally, inputting the request content into the decision tree model to obtain a first processing result. Firstly, since the rule set associated with the request type can be determined, the request to be processed is classified and processed. Secondly, when there are at least two rule sets associated with the request type, it indicates that there are at least two business decision logics for that type of request. In this case, generating a decision tree model based on the rule sets parsed from each business decision logic enables the coordination of various business decision logics, thereby avoiding inconsistencies in processing results that may result from different business decision logics. Thirdly, inputting the request content into the decision tree model to obtain the first processing result ensures the uniqueness, timeliness, and accuracy of the request processing result, and eliminates human judgment bias by eliminating the need for manual review.

[0046] Figure 2 This is a flowchart illustrating another request processing method provided in this embodiment of the invention. Based on the above embodiments, this embodiment provides specific methods for generating the decision tree model, updating the decision tree model, and tracing the results. For example... Figure 2 As shown, the method includes:

[0047] S201. Receive a pending request input by the user, wherein the pending request includes the request content and the request type.

[0048] In this invention, the request to be processed can be any type of request related to the financial field. The request processing device can receive the request to be processed from user input via an interface. The request to be processed includes request content and request type. The request content is the specific information or data to be processed, and the request type is used to distinguish the business category to which the request to be processed belongs.

[0049] S202. Obtain the set of rules associated with the request type, wherein a set of rules is obtained by parsing a business decision logic, and the business decision logic corresponding to different set of rules is different.

[0050] In one embodiment, the number of business decision logics associated with a request type can be one or more. A business decision logic can be parsed to obtain a set of rules; that is, there is a one-to-one correspondence between business decision logics and rule sets. A rule set may include several rules.

[0051] In one possible implementation, the rule set can be pre-parsed for each business decision logic, and a mapping relationship exists between the rule set and the business decision logic. When a user input request is received, the request processing device can directly look up the rule set corresponding to the associated business decision logic based on the request type.

[0052] In another possible implementation, upon receiving a user-input request to be processed, the request processing device first looks up the associated business decision logic based on the request type, and then parses the business decision logic to obtain a set of rules associated with the request type.

[0053] It should be noted that since different rule sets are obtained by parsing different business decision logics, the business decision logics corresponding to different rule sets are different, thus ensuring that the rule sets are not redundant.

[0054] S203. Determine whether the number of rule sets associated with the request type is greater than or equal to two. If not, proceed to S204; if yes, proceed to S205.

[0055] S204. Process the request content based on the business decision logic corresponding to the rule set to obtain the second processing result.

[0056] If there is only one rule set associated with the request type, it means that there is only one business decision logic associated with the request to be processed. In this case, there will be no problem of inconsistent processing results that may be caused by different business decision logics. Therefore, the second processing result can be obtained by directly processing the request content based on the business decision logic corresponding to the rule set.

[0057] Optionally, after obtaining the second processing result, feedback can be sent to the user. The specific feedback method can be selected based on user type, request type, system architecture, etc. Furthermore, when sending out the second processing result, the system can ensure the security of the feedback channel through methods such as signature verification and sensitive information anonymization.

[0058] S205. Parse each rule in each rule set to obtain the condition node and its corresponding action node. The condition nodes obtained from parsing rules in the same rule set are stored in the same node set.

[0059] If there are at least two rule sets associated with a request type, it means that there are at least two business decision logics associated with the request to be processed. In this case, there may be problems with inconsistent processing results caused by different business decision logics. Therefore, it is necessary to merge all rule sets to generate a unified decision tree model.

[0060] Specifically, when generating a decision tree model, it is first necessary to parse each rule in each rule set to obtain the condition nodes and their corresponding action nodes. The condition nodes obtained from parsing rules in the same rule set are stored in the same node set.

[0061] Condition nodes correspond to the feature judgment conditions in the rules and are the core building blocks of nodes in the decision tree model. They contain three elements: "feature dimension," "operator," and "threshold." For example, in "monthly income ≥ 50,000," the feature dimension is "monthly income," the operator is "≥," and the threshold is "50,000." Action nodes corresponding to condition nodes refer to the decision results after the feature judgment conditions are met; they are the final actions executed after the rule is triggered. Examples include "Pass," "Reject," and "Manual Review."

[0062] For example, suppose the rule is "IF age>25 AND income>500,000 THEN low risk". After parsing, we get the condition nodes "age>25" and "income>500,000", and the corresponding action node "low risk".

[0063] Condition nodes obtained from the parsing of rules in the same rule set are stored in the same node set. This is to facilitate the subsequent step S206 in finding conflicting node pairs.

[0064] S206. Determine whether there is a conflicting node pair between any two node sets, wherein a conflicting node pair includes condition nodes that have the same features but different thresholds or operators stored in the two node sets respectively. If not, proceed to S207; if yes, proceed to S208.

[0065] In step S206, the method for determining whether there is a conflicting node pair between any two node sets can be as follows: traverse the two condition nodes between any two node sets and determine whether the two condition nodes have the same features and different thresholds or operators. If so, then the two condition nodes are considered a conflicting node pair; otherwise, the two condition nodes are not a conflicting node pair.

[0066] For example, suppose the node set 1 is denoted as R = {r1, r2, ..., r...} m}, where r i Let S represent the i-th condition node in node set 1, and let S = {s1, s2, ..., s2} be the node set 2. n}, where s j This represents the j-th condition node in node set 2. i and s j If there are cases where features are the same but thresholds or operators are different, then (r i ,s j A () is a pair of conflicting nodes.

[0067] S207. Generate a decision tree model based on the condition nodes and their corresponding action nodes stored in all node sets.

[0068] When there are no conflicting node pairs between any two node sets, it means that there are no decision conflicts among the condition nodes stored in all node sets. In this case, the decision tree model can be generated directly based on the condition nodes and their corresponding action nodes stored in all node sets.

[0069] Specifically, you can first traverse all node sets, summarize the feature dimensions of all condition nodes, and form a global feature list; then assign a priority score to each feature dimension. The priority can be preset by the system (such as financial regulatory requirements) or configured by the user, and can be dynamically adjusted; finally, sort them from high to low according to the priority score to determine the node level of the decision tree, and then construct the structure of the decision tree root node-intermediate node-leaf node.

[0070] S208. Merge conflicting node pairs.

[0071] When there are conflicting node pairs between any two sets of nodes, it is necessary to merge each conflicting node pair.

[0072] Specifically, the method for merging conflicting node pairs can include the following four steps.

[0073] Step 1: Calculate the node weights of the two condition nodes included in each conflict node pair.

[0074] In one embodiment, for any condition node included in a conflict node pair, the method for calculating the node weight of the condition node includes: obtaining the sample coverage rate and information gain value of the condition node, wherein the sample coverage rate is the proportion of the condition node being triggered in historical data, and the information gain value is used to reflect the condition node's ability to distinguish data decisions; and calculating the node weight of the condition node based on the sample coverage rate and information gain value. This can improve the accuracy of weight calculation.

[0075] For example, the node weight W of a condition node is calculated as α × sample coverage of the condition node + β × information gain. α and β are the weights of the sample coverage and information gain of the condition node, respectively, and their values ​​can be set according to actual needs.

[0076] Optional, α=0.6, β=0.4.

[0077] Step 2: Calculate the reference value based on the node weight.

[0078] In one embodiment, the reference value is determined based on the node weights of the conflicting node relative to the two included condition nodes. For example, the reference value is equal to the absolute value of the difference between the node weights of the conflicting node relative to the two included condition nodes.

[0079] Step 3: If the reference value is greater than or equal to the preset threshold, delete the low-weight node in the conflict node pair.

[0080] If the reference value is greater than or equal to the preset threshold, it means that the node weights of the two condition nodes in the conflict node pair are too different. In this case, deleting the low-weight node in the conflict node pair can establish a processing priority for conflict resolution, prioritizing the retention of high-weight nodes and avoiding low-weight nodes from interfering with the core decision path.

[0081] Step 4: If the reference value is less than the preset threshold, then perform threshold fusion or operator fusion on the two condition nodes included in the conflict node pair.

[0082] If the reference value is less than the preset threshold, it means that the node weights of the two condition nodes included in the conflict node are not significantly different. In this case, threshold fusion or operator fusion can be performed on the two condition nodes included in the conflict node to preserve the characteristics of the two condition nodes included in the conflict node.

[0083] Specifically, threshold fusion is applicable to scenarios where the two condition nodes of a conflicting node pair have the same feature dimensions and the same operators but different thresholds, such as condition node 1: "monthly income ≥ 50,000" and condition node 2: "monthly income ≥ 60,000". The fusion threshold is generated by weighted calculation, retaining the core feature constraints of the two condition nodes.

[0084] For example, the logic for threshold fusion can be as follows: assuming the conflicting node pair is node A (threshold T1) and node B (threshold T2), then the fusion threshold T... 融合 The calculation formula is: T 融合 =(T1+T2) / 2.

[0085] Operator fusion is suitable for scenarios where the two condition nodes of a conflicting node pair have the same feature dimensions and thresholds but different operators. For example, condition node 1: "Monthly income > 50,000" and condition node 2: "Monthly income ≥ 50,000". By merging the compatibility of operators, a fusion operator is generated to eliminate decision conflicts caused by operator differences.

[0086] For example, the logic of operator fusion can follow the constraint reinforcement principle, that is, the fused operator takes the type with the stricter constraint among the original operators. For example, > and ≥ are fused into >; < and ≤ are fused into <, but it is not limited to this.

[0087] It should be added that if the thresholds and operators of the two condition nodes included in the conflicting node pair are different, the different thresholds and different operators can be combined to merge them, which will not be elaborated here.

[0088] S209. Based on the node fusion results and all condition nodes stored in all node sets, excluding the condition nodes included in the conflict node pairs, and their corresponding action nodes, generate a decision tree model.

[0089] In one embodiment, the method for generating a decision tree model based on the node fusion result and all condition nodes stored in all node sets, excluding the condition nodes included in the conflict node pairs, and their corresponding action nodes, is similar to step S207, and can be referred to the description of step S207 above.

[0090] S210. Input the request content into the decision tree model to obtain the first processing result.

[0091] After obtaining the decision tree model, input the request content into the decision tree model to obtain the first processing result.

[0092] Optionally, after obtaining the initial processing result, the result can be reviewed manually or through human-machine collaboration to ensure its accuracy. Simultaneously, the initial processing result can be fed back to the user.

[0093] It should be noted that, regardless of whether it is the first or second processing result, the format and channel of the information ultimately fed back to the user should be kept as consistent as possible to facilitate the user's access.

[0094] S211. Generate the decision tracing path corresponding to the request to be processed, wherein the decision tracing path includes the identification information and decision features corresponding to the request to be processed.

[0095] After obtaining the first processing result, the present invention can also generate a decision tracing path corresponding to the request to be processed. The decision tracing path, as an auditable reasoning chain, meets the requirements of financial compliance.

[0096] In one embodiment, the identification information corresponding to the request to be processed can be the root node hash value when the request to be processed is processed, and the decision features include each feature on the decision path and its corresponding feature value.

[0097] Optionally, the decision tree model generated using the scheme provided in the embodiments of the present invention may also have a hot update mechanism.

[0098] Specifically, after generating the decision tree model, the following five steps can be included.

[0099] Step A: Obtain and parse the newly added rule to get the newly added condition node and its corresponding action node.

[0100] Step B: Determine the position of the parent node in the decision tree model, and insert the newly added condition node and its corresponding action node into the position of the parent node.

[0101] Specifically, feature matching can be performed in the decision tree model using the features of the newly added conditional nodes to find a node with the same name as the parent node. If no node with the same name is found, a node with semantic similarity can be selected as the parent node.

[0102] Step C: Determine whether the newly added condition node will form a conflicting node pair with the subtree associated with the parent node's position.

[0103] After inserting the new condition node and its corresponding action node into the parent node position, the newly inserted node may conflict with the existing node, so conflict pre-check is still required.

[0104] Specifically, since the newly added condition node and its corresponding action node have already been inserted into the parent node's position, there is no possibility that other nodes unrelated to the parent node's position will form conflicting node pairs. It is only necessary to determine whether the newly added condition node will form a conflicting node pair with the subtree associated with the parent node's position. This significantly reduces the amount of data required for conflict pre-detection and improves update efficiency.

[0105] Step D: If no conflicting node pairs are formed, the decision tree model update process ends.

[0106] Step E: If conflicting node pairs are formed, then after merging the conflicting node pairs, update the decision tree model based on the node fusion result.

[0107] Specifically, the method for merging conflicting node pairs is similar to step S208 above, and you can refer to the description of step S208 above.

[0108] The technical solution of this invention involves receiving a user-inputted request including request content and request type; then obtaining a set of rules associated with the request type; and when there are at least two rule sets associated with the request type, generating a decision tree model based on all rule sets; finally, inputting the request content into the decision tree model to obtain a first processing result. Firstly, since the rule set associated with the request type can be determined, the request to be processed is classified and processed. Secondly, when there are at least two rule sets associated with the request type, it indicates that there are at least two business decision logics for that type of request. In this case, generating a decision tree model based on the rule sets parsed from each business decision logic enables the coordination of various business decision logics, thereby avoiding inconsistencies in processing results that may result from different business decision logics. Thirdly, inputting the request content into the decision tree model to obtain the first processing result ensures the uniqueness, timeliness, and accuracy of the request processing result, and eliminates human judgment bias by eliminating the need for manual review.

[0109] Figure 3 This is a schematic diagram of the structure of a request processing device provided in an embodiment of the present invention. Figure 3 As shown, the device includes: a request receiving module 301, a rule acquisition module 302, a model generation module 303, and a processing module 304.

[0110] The request receiving module 301 is used to receive user input requests to be processed, wherein the requests to be processed include request content and request type;

[0111] The rule acquisition module 302 is used to acquire a set of rules associated with the request type. Each set of rules is obtained by parsing a business decision logic, and the business decision logic corresponding to different set of rules is different.

[0112] The model generation module 303 is used to generate a decision tree model based on all rule sets if the number of rule sets associated with the request type is at least two.

[0113] The processing module 304 is used to input the request content into the decision tree model and obtain the first processing result.

[0114] Optionally, the processing module 304 is further configured to process the request content based on the business decision logic corresponding to the rule set if the number of rule sets associated with the request type is one, and obtain a second processing result.

[0115] Optionally, a rule set includes several rules; the model generation module 303 is specifically used to parse each rule in each rule set to obtain condition nodes and their corresponding action nodes, wherein the condition nodes obtained from parsing rules in the same rule set are stored in the same node set; determine whether there is a conflicting node pair between any two node sets, wherein a conflicting node pair includes condition nodes with the same features but different thresholds or operators stored in the two node sets respectively; if there is no conflicting node pair, generate a decision tree model based on the condition nodes and their corresponding action nodes stored in all node sets; if there is a conflicting node pair, perform node fusion on the conflicting node pair; generate a decision tree model based on the node fusion result and the other condition nodes and their corresponding action nodes stored in all node sets except for the condition nodes included in the conflicting node pair.

[0116] Optionally, the model generation module 303 is specifically used to calculate the node weights of the two condition nodes included in the conflict node pair respectively; calculate the reference value based on the node weights; if the reference value is greater than or equal to a preset threshold, delete the low-weight node in the conflict node pair; if the reference value is less than the preset threshold, perform threshold fusion or operator fusion on the two condition nodes included in the conflict node pair.

[0117] Optionally, the model generation module 303 is specifically used to obtain the sample coverage rate and information gain value of the condition nodes, wherein the sample coverage rate is the proportion of the condition nodes that are triggered in historical data, and the information gain value is used to reflect the ability of the condition nodes to make data decisions; and the node weights of the condition nodes are calculated based on the sample coverage rate and information gain value.

[0118] Optionally, the model generation module 303 is also used to acquire and parse the newly added rules to obtain the newly added condition nodes and their corresponding action nodes; determine the position of the parent node in the decision tree model and insert the newly added condition nodes and their corresponding action nodes into the parent node position; determine whether the newly added condition nodes will form conflicting node pairs with the subtree associated with the parent node position; if no conflicting node pairs are formed, the decision tree model update process ends; if conflicting node pairs are formed, the decision tree model is updated according to the node fusion result after node fusion of the conflicting node pairs.

[0119] Optionally, the processing module 304 is also used to generate a decision tracing path corresponding to the request to be processed, wherein the decision tracing path includes the identification information and decision features corresponding to the request to be processed.

[0120] The request processing apparatus provided in the embodiments of the present invention can execute the request processing method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0121] Figure 4This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0122] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0123] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0124] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as request processing methods.

[0125] In some embodiments, the request processing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the request processing method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the request processing method by any other suitable means (e.g., by means of firmware).

[0126] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0127] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0128] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0129] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0130] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0131] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0132] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the request processing method provided in any embodiment of this invention.

[0133] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0134] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0135] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A request processing method, characterized in that, include: Receive user input of pending requests, wherein the pending requests include request content and request type; Obtain a set of rules associated with the request type, wherein a set of rules is obtained by parsing a business decision logic, and the business decision logics corresponding to different set of rules are different; If the number of rule sets associated with the request type is at least two, then a decision tree model is generated based on all rule sets. The request content is input into the decision tree model to obtain the first processing result.

2. The request processing method according to claim 1, characterized in that, The method further includes: If the number of rule sets associated with the request type is one, then the request content is processed based on the business decision logic corresponding to the rule set to obtain a second processing result.

3. The request processing method according to claim 1, characterized in that, A set of rules includes several rules; generating a decision tree model based on all the rule sets includes: Each rule in each rule set is parsed to obtain the condition node and its corresponding action node. The condition nodes obtained from the parsing of rules in the same rule set are stored in the same node set. Determine whether there is a conflicting node pair between any two node sets, wherein a conflicting node pair includes condition nodes that have the same features but different thresholds or operators stored in the two node sets respectively; If there are no conflicting node pairs, the decision tree model is generated based on the condition nodes and their corresponding action nodes stored in all node sets. If there are conflicting node pairs, then node fusion is performed on the conflicting node pairs; The decision tree model is generated based on the node fusion results and all condition nodes stored in all node sets, excluding the condition nodes included in the conflict node pairs, and their corresponding action nodes.

4. The request processing method according to claim 3, characterized in that, The node fusion of the conflicting node pairs includes: Calculate the node weights of the two condition nodes included in the conflict node pair respectively; Calculate the reference value based on the node weights; If the reference value is greater than or equal to a preset threshold, then the low-weight node in the conflict node pair is deleted. If the reference value is less than a preset threshold, then threshold fusion or operator fusion is performed on the two condition nodes included in the conflict node pair.

5. The request processing method according to claim 4, characterized in that, For any condition node included in the conflict node pair, calculate the node weight of the condition node, including: Obtain the sample coverage rate and information gain value of the condition node, wherein the sample coverage rate is the proportion of the condition node being triggered in historical data, and the information gain value is used to reflect the condition node's ability to distinguish data decisions; The node weight of the condition node is calculated based on the sample coverage and the information gain value.

6. The request processing method according to claim 3, characterized in that, After generating the decision tree model, the method further includes: Retrieve and parse the newly added rule to obtain the newly added condition node and its corresponding action node; In the decision tree model, determine the position of the parent node, and insert the newly added condition node and its corresponding action node into the position of the parent node; Determine whether the newly added condition node will form a conflicting node pair with the subtree associated with the parent node's position; If no conflicting node pairs are formed, the decision tree model update process ends. If conflicting node pairs are formed, the decision tree model is updated based on the node fusion result after the conflicting node pairs are fused.

7. The request processing method according to claim 1, characterized in that, After obtaining the first processing result, the method further includes: Generate a decision tracing path corresponding to the request to be processed, wherein the decision tracing path includes the identification information and decision features corresponding to the request to be processed.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to said at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the request processing method according to any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the request processing method according to any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the request processing method according to any one of claims 1-7.

Images