Multivariate decision processing

Abstract

Disclosed in the present description are a multivariate decision processing method and apparatus, a storage medium, and an electronic device. The method comprises: acquiring an initial multivariate decision rule system configured by a user end on the basis of standard DSL grammar rule information, wherein the standard DSL grammar rule information is DSL grammar rule information preset for a multivariate transaction decision development scenario; determining all multivariate decision rule combinations corresponding to the initial multivariate decision rule system, and determining reference transaction workflows corresponding to the multivariate decision rule combinations; constructing a multivariate combination instance library for the initial multivariate decision rule system, and on the basis of the multivariate combination instance library, performing engineering language conflict detection processing on the initial multivariate decision rule system, so as to obtain a target multivariate decision rule system after conflict detection; and using the target multivariate decision rule system to perform transaction workflow decision processing on transaction data.

Description

Multivariate decision processing Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a multivariate decision processing method, apparatus, storage medium, and electronic device. Background Technology

[0002] With the rapid development of computer technology, transactional scenarios such as financial credit decisions, insurance underwriting and claims, risk management and anti-fraud detection, service recommendations and e-commerce recommendations often involve multivariate decision-making. Each decision in a transactional scenario is affected by multiple variables, and there may be complex logical relationships or correlations between the variables. Therefore, multivariate decision-making is needed to support transactional systems and help them make accurate decisions quickly under different conditions. Summary of the Invention

[0003] This specification provides a multivariate decision processing method, apparatus, storage medium, and electronic device, the technical solution of which is as follows.

[0004] Firstly, this specification provides a multivariate decision processing method, the method comprising: acquiring an initial multivariate decision rule system configured by a user terminal based on standard DSL syntax rule information, wherein the standard DSL syntax rule information is DSL syntax rule information preset for a multivariate transaction decision development scenario; determining all multivariate decision rule combinations corresponding to the initial multivariate decision rule system, and determining a reference transaction operation flow corresponding to the multivariate decision rule combination; constructing a multivariate combination instance library for the initial multivariate decision rule system, performing engineering language conflict detection processing on the initial multivariate decision rule system based on the multivariate combination instance library, and obtaining a target multivariate decision rule system after conflict detection; and using the target multivariate decision rule system to perform transaction operation flow decision processing on transaction data.

[0005] Secondly, this specification provides a multivariate decision processing device, comprising: a rule configuration module for acquiring an initial multivariate decision rule system configured by a user terminal based on standard DSL syntax rule information, wherein the standard DSL syntax rule information is preset DSL syntax rule information for a multivariate transaction decision development scenario; a job annotation module for determining all multivariate decision rule combinations corresponding to the initial multivariate decision rule system and determining a reference transaction job flow corresponding to the multivariate decision rule combination; a conflict detection module for constructing a multivariate combination instance library for the initial multivariate decision rule system, performing engineering language conflict detection processing on the initial multivariate decision rule system based on the multivariate combination instance library, and obtaining a target multivariate decision rule system after conflict detection; and a decision application module for using the target multivariate decision rule system to perform transaction job flow decision processing on transaction data.

[0006] Thirdly, this specification provides a computer storage medium storing at least one instruction adapted for loading by a processor and executing method steps of one or more embodiments of this specification.

[0007] Fourthly, this specification provides a computer program product storing at least one instruction adapted to be loaded by a processor and to execute the method steps of one or more embodiments of this specification.

[0008] Fifthly, this specification provides an electronic device that may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the method steps of one or more embodiments of this specification.

[0009] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following: In one or more embodiments of this specification, the electronic device acquires an initial multivariate decision rule system configured by the user terminal based on standard DSL syntax rule information, wherein the standard DSL syntax rule information is preset DSL syntax rule information for multivariate transaction decision development scenarios; determines all multivariate decision rule combinations corresponding to the initial multivariate decision rule system; determines the reference transaction operation flow corresponding to the multivariate decision rule combination; constructs a multivariate combination instance library for the initial multivariate decision rule system; performs engineering language conflict detection processing on the initial multivariate decision rule system based on the multivariate combination instance library; obtains a target multivariate decision rule system after conflict detection; and uses the target multivariate decision rule system to perform transaction operation flow decision processing on transaction data. Through standard DSL syntax rule information, the multivariate decision rule system achieves consistency and structure, eliminating the complexity of traditional if-else logic. By leveraging a multivariate combination instance library and an engineered conflict detection mechanism, all possible combinations of multivariate rule conditions can be comprehensively covered, ensuring that the rule logic is conflict-free and easy to maintain. Ultimately, through automated decision-making process execution, the system not only significantly improves its accuracy and stability in complex decision-making scenarios, but also enhances the scalability of rules and the efficiency of decision processing. Attached Figure Description

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

[0011] Figure 1 is a schematic diagram of a multivariate decision processing system provided in this specification.

[0012] Figure 2 is a flowchart of a multivariate decision processing method provided in this specification.

[0013] Figure 3 is a schematic diagram of a scenario for defining DSL syntax rule information provided in this specification.

[0014] Figure 4 is a schematic diagram of a DSL syntax rule definition provided in this specification.

[0015] Figure 5 is a flowchart illustrating a multivariate decision rule configuration provided in this manual.

[0016] Figure 6 is a schematic diagram of a scenario for writing decision rules provided in this manual.

[0017] Figure 7 is a flowchart illustrating one type of work process labeling provided in this manual.

[0018] Figure 8 is a schematic diagram of a scenario for annotating a transaction operation process as provided in this manual.

[0019] Figure 9 is a schematic diagram of a conflict detection process provided in this specification.

[0020] Figure 10 is a schematic diagram of a conflict detection scenario provided in this specification.

[0021] Figure 11 is a flowchart illustrating a multivariate decision-making application provided in this specification.

[0022] Figure 12 is a schematic diagram of the structure of a multivariate decision processing device provided in this specification.

[0023] Figure 13 is a schematic diagram of the structure of an electronic device provided in this specification. Detailed Implementation

[0024] The technical solutions in this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0025] In the description of this specification, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. In the description of this specification, it should be noted that, unless otherwise expressly specified and limited, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. Those skilled in the art can understand the specific meaning of the above terms in this specification based on the specific circumstances. Furthermore, in the description of this specification, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0026] In related technologies, multivariate decision-making typically relies on complex if-else statements, rule engines, or experience-based human judgment. While these multivariate decision-making methods can achieve conditional judgment and decision support to some extent, they often suffer from problems such as maintenance difficulties, poor scalability, error susceptibility, and lack of standardization and consistency when dealing with complex conditions involving multiple variables.

[0027] Complex if-else branches or static rule engines not only result in lengthy and easily confused rules, but also lead to high maintenance costs. For example, when the number of variables increases or transaction logic is adjusted, a large amount of rule logic needs to be manually modified, making system maintenance extremely complex. Furthermore, if-else statements and static rule engines lack flexibility and scalability when faced with diverse variable combinations and complex decision-making needs. When new variables are added or transaction logic needs adjustment, the existing rule structure cannot adapt quickly, requiring the transaction system to rewrite and adjust a large amount of logic, leading to longer development cycles, poor scalability, and difficulty in adapting to rapidly changing transaction requirements.

[0028] Furthermore, since decision-making logic in traditional methods is typically implemented through manually written rules, the relationships between these rules are complex, easily leading to decision conflicts and inconsistencies. When there are many variable values ​​and complex combinations, there may be contradictions or incomplete coverage between conditions, potentially causing the system to make incorrect decisions.

[0029] For example, in financial lending scenarios, different credit scores and risk factors may have overlapping conditions, which could lead to users being misclassified and resulting in misjudgments in credit granting. Traditional decision-making rules often lack standardized definitions, and different transaction needs generate different rule logic formats, making rule management difficult and prone to inconsistencies. Different transaction modules may generate conflicting decision rules due to inconsistent standards, affecting the accuracy and reliability of decisions. For instance, in the financial lending field, to achieve refined credit management, the system needs to comprehensively assess a customer's risk based on multiple attributes (such as credit score, income, loan history, etc.) to determine whether they meet the credit criteria for a particular loan product. However, multivariate decision-making under traditional methods often struggles to handle complex logical relationships, easily leading to duplicated, missed, or contradictory decision rules. The complex writing and maintenance of rules not only increases the system's burden but also fails to effectively meet the refined and real-time requirements of financial transactions, making it difficult to support rapidly changing transaction needs and market risk environments.

[0030] The present specification will now be described in detail with reference to specific embodiments.

[0031] The following provides definitions for all or part of the technical terms used in one or more embodiments of this specification. For technical terms not covered herein, please refer to the descriptions in the corresponding embodiments of this specification, as follows.

[0032] Decision matching: refers to comparing input variables with corresponding decisions based on defined rules and conditions in order to make a reasonable decision.

[0033] Conflict detection mechanism: An automated system function used to identify and report contradictions or inconsistencies between decision rules and decision labels.

[0034] Multivariate decision-making: a decision-making process involving multiple different decision variables, each of which may have different values, forming a complex decision-making scenario.

[0035] Rule parsers describe the structure of a language by defining grammatical rules, enabling users to define, build, and implement domain-specific languages ​​(DSLs) for easier parsing of input data and rules. Common parsers include ANTLR4, flex / bison, and lex / yacc.

[0036] DSL (Domain-Specific Language): A programming language customized for a specific industry or application scenario, used here to define the syntax and format of decision rules.

[0037] Decision rules: A set of user-defined logical expressions, usually formatted as "variable operator specific values", used to guide the decision-making process.

[0038] Variables: Elements in decision rules that represent quantities that can have different values, such as "credit score" or "income level".

[0039] Operators: Symbols used to connect variables and specific values, indicating the type of relationship, such as ">", "<", "=", etc.

[0040] Decision labeling: Manually created labels for rules and processes that conform to specific business scenarios, to facilitate their reference during decision execution.

[0041] Logical expression: An expression form used to describe decision conditions, which typically includes multiple variables and operators.

[0042] Decision-making process: The complete process from data input to rule application and final decision formation, including all relevant steps and operations.

[0043] Rule set: A set of interrelated decision rules, usually managed and used in a uniform format and structure.

[0044] Transaction processing: A series of activities and decisions undertaken by an enterprise or organization to achieve specific transactional goals, mainly covering data analysis, decision-making, and implementation.

[0045] Please refer to Figure 1, which is a schematic diagram of a multivariate decision processing system provided in this specification. As shown in Figure 1, the multivariate decision processing system may include at least a client cluster and a service platform 100.

[0046] The client cluster may include at least one client, as shown in Figure 1, specifically including client 1 corresponding to user 1, client 2 corresponding to user 2, ..., client n corresponding to user n, where n is an integer greater than 0.

[0047] Each client in a client cluster can be an electronic device with communication capabilities, including but not limited to: wearable devices, handheld devices, personal computers, tablets, in-vehicle devices, smartphones, computing devices, or other processing devices connected to a wireless modem. Electronic devices may have different names in different networks, such as: user equipment, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, electronic device, wireless communication device, user agent or user device, cellular phone, cordless phone, personal digital assistant (PDA), and electronic devices in 5G networks or future evolved networks.

[0048] The service platform 100 can be a standalone server device, such as a rack-mount, blade, tower, or cabinet-type server device, or a workstation, mainframe, or other hardware device with strong computing power; or it can be a server cluster composed of multiple servers. The servers in the service cluster can be composed in a symmetrical manner, wherein each server is functionally and hierarchically equivalent in the transaction chain, and each server can provide services independently. The independent provision of services can be understood as not requiring the assistance of other servers.

[0049] In one or more embodiments of this specification, the service platform 100 may establish a communication connection with at least one client in the client cluster, and complete the data interaction in the multivariate decision processing process based on the communication connection.

[0050] It should be noted that the service platform 100 establishes a communication connection with at least one client in the client cluster via a network for interactive communication. This network can be a wireless network or a wired network. Wireless networks include, but are not limited to, cellular networks, wireless LANs, infrared networks, or Bluetooth networks. Wired networks include, but are not limited to, Ethernet, Universal Serial Bus (USB), or Controller Area Network (CAN). In one or more embodiments of the specification, technologies and / or formats including HyperText Markup Language (HTML), Extensible Markup Language (XML), etc., are used to represent data exchanged over the network (such as target compressed packets). Furthermore, conventional encryption technologies such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), and Internet Protocol Security (IPsec) can be used to encrypt all or some links. In other embodiments, customized and / or dedicated data communication technologies can be used to replace or supplement the aforementioned data communication technologies.

[0051] The multivariate decision processing system embodiments provided in this specification and the multivariate decision processing methods described in one or more embodiments belong to the same concept. The execution entity corresponding to the multivariate decision processing method involved in one or more embodiments of this specification can be the aforementioned service platform 100; the execution entity corresponding to the multivariate decision processing method involved in one or more embodiments of this specification can also be the electronic device corresponding to the client, specifically determined based on the actual application environment. The implementation process of the multivariate decision processing system embodiments can be detailed in the following method embodiments, and will not be repeated here.

[0052] Based on the scenario diagram shown in Figure 1, the multivariate decision processing method provided by one or more embodiments of this specification will be described in detail below.

[0053] As an illustration, multivariate decision-making is typically applied to business scenarios that require comprehensive consideration, analysis, and judgment of multiple factors. The following explains some business scenarios involved in multivariate decision-making.

[0054] Financial lending decisions: When assessing a borrower's credit risk, lending institutions typically consider multiple variables, including the user's credit score, income level, repayment history, debt situation, and job stability, to determine whether to grant credit, the credit limit, and the interest rate. This type of transaction requires the development of precise decision-making rules based on different combinations of customer attributes to mitigate risk.

[0055] Insurance Underwriting and Claims: In the insurance industry, insurance companies need to consider a variety of factors when underwriting and settling claims, such as the insured's age, health condition, occupational risk, sum insured, and historical claims record. Each variable affects risk assessment and compensation standards, thereby influencing premium pricing and claims decisions.

[0056] Risk management and fraud detection: When detecting transaction risks and preventing fraud, banks, payment platforms and e-commerce platforms combine multiple variables such as transaction amount, transaction frequency, transaction device, geographical location, and historical behavior patterns to quickly determine whether a transaction has fraud risks or needs further verification in order to reduce losses.

[0057] Intelligent routing and network management: In network communication, routing algorithms need to select the best route based on multiple factors such as bandwidth, latency, network load, and packet loss rate to ensure fast data transmission and network stability.

[0058] Intelligent manufacturing and process control: In intelligent manufacturing, optimizing production process parameters requires consideration of multiple variables, such as temperature, humidity, pressure, and material properties. Multivariate decision-making can help factories optimize production efficiency, improve product quality, and reduce energy consumption.

[0059] Temperature and pressure related industrial control: In temperature and pressure industrial control scenarios, parameter optimization needs to consider multiple decision variables, such as temperature, pressure, flow rate (gas, liquid, etc.), concentration, pH range, stirring speed, etc. These multivariate decision controls also play an important role in production processes and product quality, enabling more precise optimization of production processes, improving product quality consistency, reducing resource waste, and lowering energy consumption.

[0060] In wet pressure-related industrial control, optimizing production process parameters also requires consideration of multiple decision variables. These variables include humidity, pressure, temperature, gas or liquid flow rate, pH value, and solution concentration. Through multivariate decision control, the system can precisely adjust the wet pressure conditions in the production environment to improve product quality consistency, optimize production processes, and reduce energy consumption and resource waste.

[0061] In vehicle manufacturing control, multivariate decision control is widely used in various stages such as body welding, painting, assembly, and molding. The automotive manufacturing process is complex, involves many variables, and requires high precision and consistency. Therefore, multivariate control can significantly improve production efficiency, product quality, and overall resource utilization efficiency. Decision variables commonly involved in multivariate decision control include, but are not limited to, temperature, pressure, humidity, vibration, positional accuracy, material properties, torque, and angle.

[0062] The common characteristics of the above-mentioned transaction scenarios involving multivariate decision-making are that each decision outcome is affected by multiple variables, and there may be complex logical relationships or correlations between the variables. Therefore, a multivariate decision support system is needed to help make accurate decisions quickly under different conditions.

[0063] Please refer to Figure 2, which is a flowchart illustrating a multivariate decision processing method provided by one or more embodiments of this specification. This method can be implemented using a computer program and can run on a multivariate decision processing device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone tool application. The multivariate decision processing device can be an electronic device.

[0064] Specifically, this multivariate decision processing method includes the following steps.

[0065] S102: Obtain the initial multivariate decision rule system configured by the user terminal based on the standard DSL syntax rule information, wherein the standard DSL syntax rule information is the DSL syntax rule information preset for the multivariate transaction decision development scenario.

[0066] Before the user-side configures the initial multivariate decision rule system based on standard DSL syntax rule information, the electronic device can pre-define DSL syntax rule information for the multivariate transaction decision development scenario. During the DSL (Domain-Specific Language) syntax rule information definition phase, the electronic device establishes a framework for rule expression through predefined syntax and structure, providing a standardized language foundation for subsequent decision logic. Figure 3 illustrates a scenario for defining DSL syntax rule information. Defining DSL syntax rule information includes, but is not limited to, the following parts.

[0067] 1) Variable value type definitions in standard DSL syntax rules information

[0068] Variable value type definition is the core of DSL languages ​​in multivariate transaction decision-making development scenarios, determining the types of variable data the system can recognize. Common data types include numeric and symbolic. Numeric variables, such as age and earnings, allow for comparisons of ranges and magnitudes; symbolic variables, such as customer type and risk level, support judgments on specific discrete values.

[0069] Variable value type definitions also include a bounded variable table, which restricts the range of available variables and the set of legal values. This is particularly important in financial decision-making, as different customer groups may have different applicable rules. For example, a consumer finance system may divide users into different credit ratings, each corresponding to different credit granting standards.

[0070] 2) Operator definitions in the standard DSL syntax rules information

[0071] Operator definitions are the foundation for constructing the logical expression (formula) of variable decision rules in a DSL. A series of operators (such as >, <, AND, OR, !) are used to express the logical relationships between the conditions of the variable decision rules. These operators allow users to make conditional judgments and combinations on variables.

[0072] For example, "isOverSea[TRUE]AND isForbiddenUsr[Y]" means that the user needs to meet both the conditions of "overseas" and "disabled user".

[0073] Optionally, operators can be used only for logical combinations of variables within an expression, and not directly in a bounded variable list. This is because the bounded variable list only represents the valid range of variable values, while operators are used for dynamic evaluation and the construction of logical conditions.

[0074] 3) The compiled DSL syntax tree definition in the standard DSL syntax rule information

[0075] Compiling the DSL syntax tree is a crucial step in the DSL definition phase, transforming the user-input rule expressions into a syntax tree structure. The purpose of the DSL syntax tree is to decompose complex rule logic into a hierarchical expression, facilitating system understanding and processing.

[0076] For example, the rule combination "isOverSea[TRUE]AND(isForbiddenUsr[Y]OR isOverLimit[FALSE])" typically includes variable types (such as numeric and Boolean), logical operators (such as AND, OR, NOT), and constraints in DSL syntax rules. The structured logical operators are "AND" and "OR," and the relevant decision variable rules are "isOverSea[TRUE]" and "isForbiddenUsr[Y]OR isOverLimit[FALSE]." This structured expression facilitates subsequent decision logic calculations, improving the efficiency and accuracy of the system's rule parsing.

[0077] As illustrated in Figure 4, this diagram illustrates a DSL syntax rule definition that involves variable table qualifiers, logical expressions, operators, data types, etc.

[0078] In Figure 4, “grammar DecisionRule” is the name of the defined grammar, “DecisionRule”, indicating that the grammar is used to define decision rules.

[0079] In Figure 4, "expr_start" is the starting rule for the entire decision logic expression, defining two starting expressions: "logical_expr EOF": allows the decision logic expression (logical_expr) to end with EOF (end-of-file marker), indicating that it is a complete decision expression. 'ALL'EOF: allows the use of the keyword ALL to indicate selecting all. This part of the DSL syntax rules ensures that the expression can accept a single decision logic expression or a global "ALL" multivariate decision expression.

[0080] In Figure 4, "logical_expr" is the core part of the decision logic expression, supporting various logical combinations. For example, logical operators and logical operation expressions; by combining different logical operators, rules can be constructed with complex logical conditions. In Figure 4, "STRING" represents a string value, and "CHAR" represents the character =, typically including letters, numbers, and some specific characters. "fragment CHAR" in Figure 4 represents the specific definition of the character, including the range: "az,AZ,0-9: supports uppercase and lowercase English letters and numbers," "_: allows the use of underscores," and "\u4e00-\u9feF: supports Chinese characters." In Figure 4, "Whitespace and Newline" define how spaces and newlines are handled. Whitespace defines a space or tab (\t) and sets it to channel(HIDDEN), indicating that these characters will be ignored. Newline defines a newline character (\r\n) and also sets it to channel(HIDDEN), indicating that newlines will not affect expression parsing.

[0081] Figure 4 illustrates the DSL syntax rule definition, which provides a standardized way to express rules for multivariate decision systems. This DSL syntax rule definition enables the parsing of complex multivariate logical conditions, supports multiple variable types, and ensures the flexibility and accuracy of rule expression.

[0082] DSL syntax rules typically include variable types (such as numeric and Boolean), logical operators (such as AND, OR, NOT), and restrictions.

[0083] For example, a user configures a multivariate decision system to a service platform using DSL syntax rules via a client. First, the set of multivariate decision rules required by the multivariate decision system is defined. Then, the service platform obtains these multivariate decision rules based on DSL syntax from the client, standardizes them using engineering language, and obtains the initial multivariate decision system.

[0084] For example, in practical applications, users on the client side input one or more multivariate decision rules in a certain format ([variable][operator][specific value]), which involves three steps.

[0085] 1) On the user side, the user writes multivariate decision rules and performs syntax checks to verify whether the rules compiled by the user satisfy the aforementioned DSL definition. After completion, a set (combination) of multivariate decision rules is obtained.

[0086] For example: Variable decision rule one: isOverSea[TRUE], variable decision rule two: isForbiddenUsr[Y], etc. From a transactional perspective, the rule combination: [Rule one, Rule two] precisely expresses a specific work process.

[0087] 2) Translate the set (combination) of multivariate decision rules, and translate the variable decision rule expressions in the combination of multivariate decision rules into variable decision logic language, such as: set, array, open and closed interval.

[0088] 3) Translate the above variable decision logic language expression into a preset computer language (such as Java, Csharp, etc.) to obtain the initial multivariate decision rule system.

[0089] For example, in a financial transaction scenario, a user can configure a set of rules for credit granting decisions based on multiple decision variables. These variables can be occupation type (discrete categories: civil servant / public institution employee, corporate employee, freelancer, student, unemployed or without fixed employment) and residential area (discrete categories: first-tier city, second-tier city, third-tier and below city, rural area). Rule 1: If the occupation type is "civil servant / public institution employee" and the residential area is "first-tier city" or "second-tier city," then execute the "credit approval process." Rule 2: If the occupation type is "freelancer" and the residential area is "third-tier and below city" or "rural area," then execute the "manual review process." Rule 3: If the occupation type is "student" or "unemployed," then execute the "credit rejection process." The set (combination) of the written multivariate decision rules is converted into a multivariate decision logic language, and then these multivariate decision logic language expressions are converted into a preset computer language to determine whether the customer meets the credit conditions and execute the credit granting process. Users write a set (combination) of multivariate decision rules using DSL syntax, and then the engineering process transforms it into an initial multivariate decision system, forming a set of standardized variable decision rules.

[0090] S104: Determine all combinations of multivariate decision rules corresponding to the initial multivariate decision rule system, and determine the reference transaction operation process corresponding to the combination of multivariate decision rules.

[0091] Multivariate decision rule combination: A decision rule composed of multiple variable decision conditions, representing the multivariate decision transaction logic triggered under certain combinations of conditions.

[0092] Reference transaction workflow: The transaction operation workflow corresponding to a specific combination of decision rules (such as a combination of multivariate decision rules), indicating the specific transaction processing logic that should be executed when a certain combination of decision rules is met. For example, in a financial transaction scenario, the specific credit granting transaction processing logic that should be executed when a certain combination of credit granting decision rules is met.

[0093] This example illustrates how all rules in an initial multivariate decision system are parsed to generate all possible combinations of decision rules. For each rule combination, the system determines its corresponding task flow, that is, it determines which task flow should be executed based on the conditions set by the rule. This mapping relationship allows the system to execute corresponding task flows based on different combinations of variables, improving the accuracy and automation of decision-making.

[0094] S106: Construct a multivariate combination instance library for the initial multivariate decision rule system, and perform engineering language conflict detection processing on the initial multivariate decision rule system based on the multivariate combination instance library to obtain the target multivariate decision rule system after conflict detection.

[0095] Multivariate Combination Instance Library: A collection of combination instances consisting of all decision variables and their possible value ranges in the initial multivariate decision rule system. This library contains all possible combinations of conditions to cover all potential decision scenarios.

[0096] Engineering language conflict detection: used to identify conflicts or logical inconsistencies in the combination of multivariate decision rules in the initial multivariate decision rule system, so as to ensure the integrity and consistency of multivariate decision rules.

[0097] In one optional implementation, constructing a multivariate combination instance library for the initial multivariate decision rule system includes: determining the range of discrete values ​​of the decision variables of the initial multivariate decision rule system, and constructing a multivariate combination instance library based on the range of discrete values ​​of the variables.

[0098] This example demonstrates the construction of an instance library covering all possible combinations of variables, and the use of this library to perform conflict detection on combinations of multivariate decision rules in the initial multivariate decision rule system. Conflict detection aims to identify contradictions or logical errors in the rule system, ensuring that each combination of multivariate decision rules can be correctly processed by the system in actual transaction processing.

[0099] Specifically, based on the range of values ​​for the decision variables, all possible combinations of variables are generated, forming a multivariate combination instance library. For example, if the initial multivariate decision rule system has two variables, "credit score" and "income level," the system will list all combinations of these two variables within their respective ranges, thus obtaining the listed combination instances.

[0100] Then, the initial multivariate decision rule system is tested using a multivariate combination instance library to check for conflicts. Conflict scenarios include, but are not limited to, the following.

[0101] Logical contradiction: For example, the conditional parts of two rules are mutually exclusive, but they are mapped to the same transaction process.

[0102] Incomplete coverage: This means that certain combinations of conditions lack corresponding rules or procedures, which may cause errors when the system processes certain transaction data.

[0103] Condition duplication: The same combination of conditions is defined as different rules or mapped to different transaction processes, which may lead to inconsistent decisions.

[0104] After conflict detection, a target multivariate decision rule system is output: After conflict detection and error correction, a conflict-free, multivariate combination-complete target multivariate decision rule system is obtained. The target multivariate decision rule can ensure correct decision-making under various variable combinations.

[0105] For example, in a credit scoring system, suppose the range of the "credit score" variable is 0 to 850, and the range of the "income level" variable is 0 to 100,000. The "credit score" can be divided into three intervals (0-600, 601-700, 701-850), and the "income level" can be divided into three intervals (0-5000, 5001-10000, 10001 and above). A multivariate combination instance library is constructed to cover all nine combination instances. Then, conflict detection is performed on the multivariate decision rule combinations in the initial multivariate decision rule system using each combination instance. For example, if a conflict is detected between the conditions of multivariate decision rule combination 1 and multivariate decision rule combination 2 (e.g., a combination is assigned two different processing flows), the conflict can be marked and adjustments made.

[0106] If a combination of multivariate decision rules has no corresponding rules or process mappings, a message can be displayed indicating that the multivariate decision rule combination is incomplete and a request for supplementation can be made.

[0107] The target multivariate decision rule system, after testing, will have a conflict-free and comprehensive rule set, providing a foundation for the next step of transaction decision-making application processing.

[0108] S108: The target multivariate decision rule system is used to process transaction operation flow decisions on transaction data.

[0109] Transaction data: refers to specific data information flowing in a transaction (platform) system, such as a user's credit score, income, and loan history, which is used as a basis for decision-making.

[0110] Transaction workflow: The target multivariate decision rule system selects the transaction workflow or operation path for transaction data according to specific rules, such as the "credit approval process" or "credit rejection process" mentioned in the example above.

[0111] To illustrate, the service platform monitors a set of transaction data, including the specific values ​​of each decision variable. It then matches the variable values ​​of the transaction data with the rule combinations in the target multivariate decision rule system. After finding a multivariate decision rule combination that meets the conditions, the service platform determines the transaction operation process corresponding to the multivariate decision rule group and executes the transaction operation process.

[0112] Example: In a credit approval system, suppose we monitor a set of transaction data: a user's credit score is 720, monthly income is 8000, and there are no overdue records.

[0113] The service platform inputs this transaction data into the target multivariate decision rule system for rule combination matching. It finds that this group of transactions matches the multivariate decision rule combination of "credit score of 720 and monthly income of 8000," which is then mapped to the "credit approval process." The service platform then initiates the credit approval process, approving the user's loan application. Finally, the service platform feeds back the "credit approval" result to the transaction system, completing this multivariate transaction decision.

[0114] In one or more embodiments of this specification, the electronic device acquires an initial multivariate decision rule system configured by the user terminal based on standard DSL syntax rule information. The standard DSL syntax rule information is preset DSL syntax rule information for multivariate transaction decision development scenarios. It determines all multivariate decision rule combinations corresponding to the initial multivariate decision rule system, determines the reference transaction workflow corresponding to the multivariate decision rule combinations, constructs a multivariate combination instance library for the initial multivariate decision rule system, performs engineering language conflict detection processing on the initial multivariate decision rule system based on the multivariate combination instance library, obtains a conflict-detected target multivariate decision rule system, and uses the target multivariate decision rule system to perform transaction workflow decision processing on transaction data. By using standard DSL syntax rule information, the multivariate decision rule system achieves consistency and structure, eliminating the complexity of traditional if-else logic. Utilizing the multivariate combination instance library and the engineering-based conflict detection mechanism, all possible multivariate rule condition combinations can be comprehensively covered, ensuring that the rule logic is conflict-free and easy to maintain. Finally, through automated decision process execution, it not only significantly improves the accuracy and stability of the system in complex decision scenarios but also enhances the rule scalability and decision processing efficiency.

[0115] Please refer to Figure 5, which is a flowchart illustrating the configuration of multivariate decision rules according to one or more embodiments of this specification. The following implementation method can be used to specifically execute the initial multivariate decision rule system configured by obtaining user-side information based on standard DSL syntax rules.

[0116] S202: Obtain the set of target multivariate decision rules developed by the user terminal based on standard DSL syntax rules information.

[0117] According to some embodiments, the user configures a multivariate decision system to the service platform using DSL syntax rules via the user terminal. First, the user defines the set of multivariate decision rules required by the multivariate decision system, and then the service platform obtains these target multivariate decision rule sets based on DSL syntax from the user terminal.

[0118] S204: Based on the target multivariate decision rule set, perform engineering transformation processing to obtain the initial multivariate decision rule system.

[0119] As an illustration, the service platform then performs engineering language standardization on the target multivariate decision rule set to obtain the initial multivariate decision system.

[0120] In one feasible implementation, the process of converting the target multivariate decision rule set into engineering language to obtain the initial multivariate decision rule system can be described in the following embodiments.

[0121] A2: Combine the multivariate decision rules in the target multivariate decision rule set to obtain multiple multivariate decision rule combinations.

[0122] A4: The multivariate decision rule combination is translated into a decision rule logic language structure data by using a preset rule logic language.

[0123] A6: The initial multivariate decision rule system is obtained by converting the logical language structure data of the decision rules into engineering code language.

[0124] For example, in practical applications, users on the user end input one or more multivariate decision rules in a certain format (such as [variable][operator][specific value]) to obtain the target multivariate decision rule set. Please refer to Figure 6, which is a schematic diagram of a scenario for writing decision rules involved in this specification, as follows.

[0125] 1) On the user side, the user writes one or more multivariate decision rules (combinations) to form the target multivariate decision rule set and performs a syntax check. The rules in the target multivariate decision rule set compiled by the user are checked to see if they meet the standard DSL syntax rule information defined above. After the syntax check is completed, it is determined to be the target multivariate decision rule set (combination).

[0126] For example: Variable decision rule one: isOverSea[TRUE], variable decision rule two: isForbiddenUsr[Y], etc. In business terms, a combination of multi-variable decision rules—[Rule One, Rule Two]—precisely expresses a specific work process.

[0127] 2) Translate the set (combination) of multivariate decision rules. Translate the variable decision rule expressions in the combination of multivariate decision rules into variable decision logic language to obtain decision rule logic language structure data, such as: set, array, open and closed interval.

[0128] 3) Convert the above decision rule logic language structure data into engineering code language according to a preset computer language (such as Java, Csharp, etc.) to obtain the initial multivariate decision rule system.

[0129] For example, in the financial sector, a user can configure a set of rules for credit decisions based on multiple variables, such as "isOverSea[TRUE]AND isForbiddenUsr[Y]", to determine whether a customer meets the credit conditions and execute the credit granting process. Users write a set (combination) of multivariate decision rules using DSL syntax, and then engineer them to obtain an initial multivariate decision system, forming a standardized set of variable decision rules.

[0130] In one or more embodiments of this specification, the above-described method effectively standardizes and structures the rule definitions on the user side, ensuring the uniformity and maintainability of the rule set. Through the target rule set obtained via DSL syntax standardization and subsequent engineering conversion processing, the system achieves a seamless transition from high-level rule description to engineering implementation. This process not only improves the management efficiency of multivariate decision rules but also reduces the possibility of rule conflicts and logical errors, ensuring the accuracy and consistency of the decision-making process and significantly enhancing the system's adaptability and scalability in complex decision-making scenarios.

[0131] Please refer to Figure 7, which is a flowchart illustrating a workflow annotation proposed in one or more embodiments of this specification. Specifically, the process of determining all combinations of multivariate decision rules corresponding to the initial multivariate decision rule system and determining the reference transaction workflow corresponding to the multivariate decision rule combinations can be performed as follows.

[0132] S3002: Determine all combinations of multivariate decision rules corresponding to the initial multivariate decision rule system.

[0133] Multivariate decision rule combination: A decision rule composed of multiple variable decision conditions, representing the multivariate decision transaction logic triggered under certain combinations of conditions.

[0134] Indicatively, all rules in the initial multivariate decision system are parsed to generate all possible combinations of decision rules.

[0135] S3004: Obtain multiple transaction job processes, perform job process matching on the multivariate decision rule combination based on the transaction job processes, and obtain the reference transaction job process matched by each multivariate decision rule combination.

[0136] This example illustrates how the system parses all decision rules in the initial multivariate decision system to generate all possible combinations of multivariate decision rules. For each combination of multivariate decision rules, the system combines multiple transaction processes to determine its corresponding transaction process; that is, based on the conditional semantics set by the combination of multivariate decision rules, it determines which transaction process should be executed. This mapping relationship allows the system to execute corresponding processes based on different combinations of variables, improving the accuracy and automation of decision-making.

[0137] S3006: Mark the rule and process mapping relationship between the combination of multivariate decision rules and the reference transaction operation process.

[0138] Example: In a credit granting decision scenario, assume the system has the following combination of rules.

[0139] Rule combination 1: isOverSea[TRUE]AND isForbiddenUsr[Y], indicating the reference transaction workflow as "credit approval process".

[0140] Rule combination 2: isOverSea[FALSE]OR isForbiddenUsr[N], which marks the reference transaction operation process as "rejection of credit process".

[0141] Figure 8 illustrates a scenario for transaction workflow annotation. For each multivariate decision rule combination (e.g., rule combination 1, rule combination 2, ..., rule combination n), the service platform explicitly maps the multivariate decision rule combination to the corresponding reference transaction workflow, annotating each multivariate decision rule combination and its corresponding reference transaction workflow to establish a mapping relationship between rules and workflows. This rule-to-workflow mapping relationship serves as the execution basis for the decision-making system, ensuring that the system can automatically select the correct transaction workflow during decision-making. As shown in Figure 8, rule combination 1 is mapped to annotation value workflow 1, rule combination 2 to annotation value workflow 2, and rule combination n to annotation value workflow n. For example, if the customer is an "overseas user" (isOverSea is TRUE) and "user is disabled" (isForbiddenUsr is Y), the system will directly include the customer in the "credit approval process"; while if the customer is a "non-overseas user" (isOverSea is FALSE) or "user is not disabled" (isForbiddenUsr is N), the system will enter the "credit rejection process".

[0142] In one or more embodiments of this specification, the above-described method enables the systematic identification of all combinations of multivariate decision rules and the matching of the most suitable transaction workflow for each rule combination. Simultaneously, the mapping relationship between rules and workflows provides the system with a clear rule execution path, ensuring consistent decision logic in complex scenarios with multiple conditions and processes. This process allows electronic devices to efficiently and automatically invoke appropriate transaction workflows based on conditions during actual operation, significantly improving the accuracy of decision-making and the automation level of transaction workflows.

[0143] Please refer to Figure 9, which is a schematic diagram of a conflict detection process proposed in one or more embodiments of this specification. Specifically, the following method can be used to construct a multivariate combination instance library for the initial multivariate decision rule system, and to perform engineering language conflict detection processing on the initial multivariate decision rule system based on the multivariate combination instance library to obtain the conflict-detected target multivariate decision rule system.

[0144] S4002: Obtain all decision variables corresponding to the initial multivariate decision rule system, and determine the range of discrete values ​​of each decision variable.

[0145] Decision variables: Conditional variables used for rule-based judgment in a decision-making system, such as credit scores and income levels.

[0146] Range of discrete values ​​for a variable: All discrete values ​​or the range of discrete values ​​for each decision variable. The division of the range of discrete values ​​for a variable can be flexibly set according to the actual needs of the transaction to cover all decision conditions.

[0147] S4004: Based on the range of discrete values ​​of each decision variable, determine the multivariate decision rule combination instance corresponding to the multivariate decision variable combination type.

[0148] Decision variable combination type: The type formed by the cross-combination of the discrete value ranges of different decision variables, representing various possible combinations of variable values.

[0149] Examples of multivariate decision rule combinations: Each example of a decision variable combination type represents the specific combination of discrete values ​​of each variable in a real-world scenario.

[0150] Specifically, please refer to Figure 10, which is a schematic diagram of a conflict detection scenario. In Figure 10, all possible combinations of variables are first generated based on the value range (i.e., discrete value range) of the decision variables, forming a multivariate combination instance library (the use case library shown in Figure 10). For example, if the initial multivariate decision rule system has two variables, "credit score" and "income level", the system will list all combinations of these two variables within their respective ranges, thus obtaining the listed combination instances.

[0151] For example, in a credit scoring system, suppose the range of the "credit score" variable is 0 to 850, and the range of the "income level" variable is 0 to 100,000. The "credit score" variable can be divided into three intervals (0-600, 601-700, 701-850), and the "income level" variable can be divided into three intervals (0-5000, 5001-10000, 10001 and above). A multivariate combination instance library can be built to cover all nine combination instances.

[0152] S4006: Construct a multivariate combination instance library based on all the multivariate decision rule combination instances.

[0153] Multivariate combination instance library: This is a collection of all variable combination instances, ensuring that the system can cover all possible decision scenarios. The instance library is the basic data instance verification library for the multivariate rule decision system.

[0154] This example illustrates how all decision variable combination instances generated in S4004 are compiled into a complete multivariate combination instance library. This library contains all possible combinations of variable values, providing fundamental data support for subsequent steps. The construction of this instance library ensures that the system can achieve comprehensive decision coverage under different conditions, avoiding the omission of any important decision scenarios.

[0155] For example, in the example of a credit approval system, the instance library will contain all generated variable combination types, such as combination 1, combination 2, combination 3, etc. These instances constitute a complete set of conditions that the system can refer to during the decision-making process.

[0156] S4008: Perform engineering language expression conversion processing on each multivariate decision rule combination instance in the multivariate combination instance library to obtain the reference multivariate decision rule logic language.

[0157] Engineering language expression: Representing instances of multivariate decision rule combinations using computer programming languages.

[0158] Refer to the multivariate decision rule logic language: express the data of multivariate decision rule combination instances in an engineering logic language for subsequent conflict detection.

[0159] S4010: Perform conflict detection processing on all the aforementioned reference multivariate decision rule logic languages ​​to obtain conflict detection results.

[0160] Conflict detection: This checks for contradictions or overlaps in the rules expressed in the logical expression to ensure that each combined instance can uniquely determine its processing flow in the decision-making system. For example, as shown in Figure 10, it checks whether all reference multivariate decision rule logical languages ​​in the engineering language are labeled, and determines whether there is any overlap between the reference multivariate decision rule logical languages ​​in the engineering language.

[0161] Conflict detection results: Detection reports containing conflict instances or annotations, which can be used to suggest adjustments to rules.

[0162] For example, the system autonomously implements a decision conflict detection mechanism that can detect the following two types of conflicts.

[0163] a. The decision rule is satisfied, but the decision labeling process is not labeled: The system identifies rules that satisfy the defined rules but are not labeled in any transaction processing process, indicating potential rule missing or error.

[0164] b. Decisions that meet the decision rules but are incorrectly labeled: The system identifies rules that meet the rules but whose labeled transaction processes do not match expectations, and prompts potential labeling errors.

[0165] Conflicting decision rules will not be considered to conform to transaction semantics and will not be applied by the transaction.

[0166] In one optional implementation, the conflict detection processing of all the reference multivariate decision rule logic languages ​​to obtain conflict detection results includes the following.

[0167] B2: Obtain the rule-process mapping relationship corresponding to the initial multivariate decision rule system. The rule-process mapping relationship is the mapping relationship between the multivariate decision rule combination of the initial multivariate decision rule system and the reference transaction operation process.

[0168] Rule-process mapping: This refers to the mapping relationship between the combination of multivariate decision rules in the initial multivariate decision rule system and the transaction job process. Each combination of multivariate decision rules corresponds to a specific transaction process, and this mapping relationship determines the process to be executed under specific conditions.

[0169] Multivariate decision rule combination: A combination of conditions consisting of multiple decision variables and their values, used to determine which transaction process to execute.

[0170] Reference transaction workflow: The transaction operation process that the system should trigger when certain decision conditions are met, such as "credit approval process" or "credit rejection process".

[0171] Indicatively, the rule-process mapping relationship of all rules and processes is extracted from the initial multivariate decision rule system. Each multivariate decision rule combination is mapped to a specific reference transaction operation process according to its condition characteristics. This rule-process mapping relationship is used to check for missing rule annotations and content conflicts in subsequent conflict detection.

[0172] Example: In a credit decision-making system, assume the following rule-process mapping relationship exists.

[0173] Rule combination 1 (isOverSea[TRUE]AND isForbiddenUsr[Y]) -> "Credit Approval Process".

[0174] The mapping relationship between rule combination 2 (isOverSea[FALSE] OR isForbiddenUsr[N]) -> “Credit Deny Process” ensures that the system selects the correct process under different combinations of conditions.

[0175] B4: Based on the rule-process mapping relationship, perform rule annotation missing detection processing on the reference multivariate decision rule combination corresponding to the reference multivariate decision rule logic language to obtain the rule annotation missing detection result.

[0176] Rule labeling missing detection: Based on the reference multivariate decision rule logic language, this function detects whether there are any incorrectly labeled processes in the combination of reference multivariate decision rules. Missing labels may result in no matching transaction processes under certain conditions, affecting the completeness of the decision.

[0177] Rule annotation missing detection results: All detected missing annotation information, recording which rule combinations were not correctly mapped to the corresponding transaction processes.

[0178] For each combination of reference multivariate decision rules, missing data is checked to ensure that each combination has a clear process mapping.

[0179] For illustrative purposes, if a combination of reference multivariate decision rules corresponding to a certain reference multivariate decision rule logic language lacks a corresponding transaction process in the mapping relationship, the system will record it as missing and indicate it in the detection results.

[0180] Missing rule combinations may prevent the decision-making system from executing appropriate transaction processes under certain conditions, so these missing annotations need to be added in subsequent steps.

[0181] Example: In a credit decision-making system, suppose a certain combination of rules is not mapped to any transaction process. During rule missing detection, the system will mark this combination as missing for later correction.

[0182] B6: Based on the aforementioned rule-process mapping relationship, perform annotation content conflict detection processing on all reference multivariate decision rule combinations of the aforementioned reference multivariate decision rule logic language to obtain annotation content conflict detection results.

[0183] Content conflict detection: Detects whether there are logical conflicts in the mapping relationship between rules and processes, such as the same combination of conditions mapping to different processes, or the combination of mutually exclusive rules mapping to the same process.

[0184] Annotation content conflict detection results: All detected annotation logical conflict information, recording each logically conflicting rule combination and its corresponding process mapping problem.

[0185] This example illustrates how to perform content conflict detection on each reference multivariate decision rule combination to check for logical conflicts. If a rule combination maps to multiple different transaction flows, or if mutually exclusive rule combinations map to the same flow, the system marks it as a logical (content) conflict. Marking logical (content) conflicts can lead to inconsistent flow choices during system execution, affecting the accuracy of decisions, thus requiring further adjustments.

[0186] Example: In a credit decision-making system, suppose a certain combination of rules is mapped to "credit approval process" and "manual review process". During the content conflict detection, the system will mark this combination as a logical conflict so that the mapping relationship can be further corrected to ensure uniqueness.

[0187] This specification demonstrates how the above methods effectively obtain the mapping relationship between rules and processes, and detect missing annotations and content conflicts. Missing rule annotation detection ensures that all rule combinations have a clear transaction process mapping, avoiding omissions. Conflict annotation detection ensures the logical consistency of rule mappings, avoiding contradictions in condition combination mappings. Based on these detection results, the rule-process mapping relationship can be further adjusted, ensuring that the decision-making system can automatically select the correct transaction operation process under different conditions, improving the system's decision-making accuracy and reliability.

[0188] S4012: Based on the conflict detection results, adjust the rules of the initial multivariate decision rule system to obtain the target multivariate decision rule system after rule adjustment.

[0189] Rule adjustment: Optimize or modify the decision rules based on the conflict detection results to eliminate logical conflicts.

[0190] Objective multivariate decision rule system: The adjusted decision system has consistent and conflict-free decision logic.

[0191] As an illustration, the system adjusts conflicting rules based on the conflict detection results of S4010 to eliminate logical contradictions or duplicate annotations, ultimately obtaining a conflict-free target multivariate decision rule system.

[0192] Optionally, rule adjustments include, but are not limited to, deleting redundant rules, merging conditions, and refining rules to ensure that each combination of conditions has a unique and correct transaction process mapping.

[0193] Example: During the adjustment process, if it is detected that "isOverSea[FALSE]OR isForbiddenUsr[N]" points to both "Credit Approval Process" and "Manual Review Process", one of the processes will be selected as the final mapping, or the conditions will be further refined to eliminate the conflict.

[0194] In one optional implementation, the step of adjusting the rules of the initial multivariate decision rule system based on the conflict detection results to obtain the adjusted target multivariate decision rule system includes the following.

[0195] C2: Based on the conflict detection results, determine the combination of abnormal multivariate decision rules for the conflict detection type.

[0196] Conflict detection results: The results generated during the previous process of missing annotations and content conflict detection, including all detected rule conflicts and annotation anomalies.

[0197] Conflict detection types: Different conflict types, such as missing annotations, content conflicts, or duplicate annotations. These types help the system classify anomalies so that appropriate adjustment methods can be selected.

[0198] Abnormal multivariate decision rule combinations: Rule combinations that are detected as having conflicts or missing annotations. The conditions and process mappings of these combinations do not meet the consistency requirements of the system and require further adjustment.

[0199] The system reads the previously generated conflict detection results and identifies all rule combinations that are conflicting or missing.

[0200] As an illustration, based on different types of detection results (such as missing annotations or content conflicts), the service platform categorizes various anomalies into combinations of multivariate decision rules. This categorization provides a basis for subsequent adjustment steps, ensuring that the system can handle different types of anomalies in a targeted manner.

[0201] Example: Using the above example as an explanation, suppose the rule combination "isOverSea[FALSE]OR isForbiddenUsr[N]" is mapped to both "Credit Approval Process" and "Manual Review Process" simultaneously. This is a content conflict type anomaly. Furthermore, if "isOverSea[TRUE]AND isForbiddenUsr[Y]" lacks a process mapping, it belongs to the annotation missing type anomaly. These two cases can be categorized as content conflict and annotation missing types respectively for subsequent processing.

[0202] C4: Adjust the abnormal multivariate decision rule combination in the initial multivariate decision rule system to obtain the target multivariate decision rule system after rule adjustment.

[0203] As an example, the service platform makes targeted adjustments to the combination of abnormal multivariate decision rules based on different conflict detection types.

[0204] For exceptions with missing annotations, the system will supplement the missing process mapping to ensure that each rule combination has a clear execution path.

[0205] For exceptions involving content conflicts, the system will select the appropriate process mapping based on the transaction logic and delete duplicate or conflicting mappings.

[0206] Furthermore, after the adjustment is completed, the system re-examines the corrected rule combination to ensure the accuracy and consistency of the rule adjustment. The final target multivariate decision rule system contains a combination of rules without conflicts or omissions, forming a standardized decision system.

[0207] In one or more embodiments of this specification, the above-described method enables the standardized construction of a multivariate combination instance library, transforming all rule instances into engineering language expressions. Through conflict detection and adjustment, a conflict-free target multivariate decision rule system is obtained. This process ensures that the system's decision logic is comprehensive, clearly expressed, and efficiently executed, providing reliable support for complex multivariate decision-making needs and improving the system's stability and decision accuracy.

[0208] Please refer to Figure 11. Figure 11 is a flowchart illustrating a multivariate decision application proposed in one or more embodiments of this specification. Specifically, the process of using the target multivariate decision rule system to perform transaction operation process decision processing on transaction data can be carried out in the following ways.

[0209] S5002: The target multivariate decision rule system is used to monitor transaction data for the reference transaction operation process.

[0210] Objective multivariate decision rule system: An adjusted, conflict-free, multivariate decision rule system with consistency and accuracy, used to guide decision-making in business processes.

[0211] Transaction data: The specific data that needs to be processed in a transaction system, such as a customer's credit score, income information, and loan records.

[0212] Reference transaction workflow: Workflows triggered by different conditions, such as "credit approval process" and "credit rejection process".

[0213] This illustration demonstrates how a multivariate decision rule system can monitor transaction data in real time to determine if the data meets certain decision conditions. By monitoring transaction data, the system can identify specific transaction scenarios and determine whether there are corresponding rule combinations that satisfy these conditions. This ensures continuous tracking of transaction data, enabling a rapid response and triggering of the corresponding transaction workflow when conditions are met.

[0214] Example: In a credit approval system, transaction data might include "credit score 720" and "monthly income 8000," etc. The system monitors this data and matches it against rule combinations in the target multivariate decision rule system to determine if a matching decision rule combination exists.

[0215] S5004: Determine all target decision rules satisfied by the transaction data, and detect whether there is an actual multivariate decision rule combination in the multivariate decision rule combination, wherein the actual decision rule combination includes at least two of the target decision rules.

[0216] Target decision rule: A specific combination of conditions defined in a multivariate decision system, used to determine whether specific transaction data meets the conditions.

[0217] Actual multivariate decision rule combination: a composite rule combination consisting of multiple objective decision rules, that is, a combination formed when transaction data simultaneously satisfies two or more rules.

[0218] This method illustratively identifies all target decision rules satisfied by transaction data and records each satisfied rule. It examines combinations of multivariate decision rules to determine if an "actual multivariate decision rule combination" exists, i.e., whether at least two target decision rules are satisfied. This can be used to determine whether transaction data conforms to complex combinations of conditions, so as to determine the transaction operation process based on these combinations.

[0219] Example: Suppose in a credit approval system, the transaction data is "Credit score 720, monthly income 5000". If the system has rule A (credit score = 720) and rule B (income = 5000), then the transaction data satisfies rule A and rule B, forming a practical multivariate decision rule combination.

[0220] S5006: If the actual multivariate decision rule combination exists in the multivariate decision rule combination, then the target transaction operation process corresponding to the actual multivariate decision rule combination is determined from the target multivariate decision rule system, and the target transaction operation process is executed.

[0221] Target transaction workflow: The transaction workflow mapped by the actual combination of multivariate decision rules is the specific workflow that the system should execute when a complex combination of conditions is met, such as "credit approval workflow" or "manual review workflow".

[0222] For example, based on the actual combination of multivariate decision rules, the corresponding target transaction workflow is determined from the target multivariate decision rule system. After the workflow is confirmed, the system automatically executes the workflow in response to transaction data that meets the conditions. This ensures that when transaction data meets the conditions, the system can efficiently trigger and execute the corresponding transaction workflow.

[0223] S5008: If the actual multivariate decision rule combination does not exist in the multivariate decision rule combination, then the transaction is ignored.

[0224] Transaction Ignore Handling: When no matching rule combination exists in the multivariate decision rule combination, the system ignores the transaction data and does not execute any process. This prevents data that does not meet the transaction conditions from being incorrectly processed.

[0225] In one or more embodiments of this specification, the above-described method enables the dynamic monitoring of transaction data using a target multivariate decision rule system, and automatically executes or ignores corresponding transaction operation processes based on the combination of conditions satisfied by the data. This process ensures that the system can execute transaction operations quickly and efficiently when the conditions are met, while avoiding the execution of invalid operations when the conditions are not met, thereby improving the system's decision-making accuracy and processing efficiency. It can be applied to multivariate decision-making scenarios that require efficient decision-making and automated transaction processes.

[0226] The multivariate decision processing apparatus provided in this specification will now be described in detail with reference to Figure 12. It should be noted that the multivariate decision processing apparatus shown in Figure 12 is used to execute the methods of the embodiments shown in Figures 1 to 6 of this specification. For ease of explanation, only the parts relevant to this specification are shown; for specific technical details not disclosed, please refer to the embodiments shown in Figures 1 to 11 of this specification.

[0227] Please refer to Figure 12, which shows a schematic diagram of the multivariate decision processing device of this specification. This multivariate decision processing device 1 can be implemented as all or part of a user electronic device through software, hardware, or a combination of both. According to some embodiments, the multivariate decision processing device 1 includes: a rule configuration module 11, used to acquire an initial multivariate decision rule system configured by the user terminal based on standard DSL syntax rule information, wherein the standard DSL syntax rule information is preset DSL syntax rule information for a multivariate transaction decision development scenario; a job annotation module 12, used to determine all multivariate decision rule combinations corresponding to the initial multivariate decision rule system, and determine the reference transaction job flow corresponding to the multivariate decision rule combination; a conflict detection module 13, used to construct a multivariate combination instance library for the initial multivariate decision rule system, and perform engineering language conflict detection processing on the initial multivariate decision rule system based on the multivariate combination instance library to obtain a target multivariate decision rule system after conflict detection; and a decision application module 14, used to perform transaction job flow decision processing on transaction data using the target multivariate decision rule system.

[0228] Optionally, the rule configuration module 11 is used to: obtain a set of target multivariate decision rules developed by the user terminal based on standard DSL syntax rule information; and perform engineering language conversion processing based on the set of target multivariate decision rules to obtain an initial multivariate decision rule system.

[0229] Optionally, the rule configuration module 11 is used to: combine the multivariate decision rules in the target multivariate decision rule set to obtain multiple multivariate decision rule combinations; translate the multivariate decision rule combinations using a preset rule logic language to obtain decision rule logic language structure data; and convert the decision rule logic language structure data into engineering code language to obtain an initial multivariate decision rule system.

[0230] Optionally, the job labeling module 12 is used to: determine all multivariate decision rule combinations corresponding to the initial multivariate decision rule system, and determine the reference transaction job flow corresponding to the multivariate decision rule combination, including: determining all multivariate decision rule combinations corresponding to the initial multivariate decision rule system; obtaining multiple transaction job flows, performing job flow matching on the multivariate decision rule combination based on the transaction job flow, and obtaining the reference transaction job flow matched by each multivariate decision rule combination; and labeling the rule and flow mapping relationship between the multivariate decision rule combination and the reference transaction job flow.

[0231] Optionally, the conflict detection module 13 is used to: determine the range of discrete values ​​of the decision variables in the initial multivariate decision rule system, and construct a multivariate combination instance library based on the range of discrete values ​​of the variables.

[0232] Optionally, the conflict detection module 13 is configured to: acquire all decision variables corresponding to the initial multivariate decision rule system, determine the range of discrete values ​​of each decision variable; determine multivariate decision rule combination instances corresponding to the multivariate decision variable combination type based on the range of discrete values ​​of each decision variable; and construct a multivariate combination instance library based on all the multivariate decision rule combination instances.

[0233] Optionally, the conflict detection module 13 is configured to: perform engineering language expression conversion processing on each multivariate decision rule combination instance in the multivariate combination instance library to obtain a reference multivariate decision rule logic language; perform conflict detection processing on all the reference multivariate decision rule logic languages ​​to obtain a conflict detection result; and adjust the rules of the initial multivariate decision rule system based on the conflict detection result to obtain a target multivariate decision rule system after rule adjustment.

[0234] Optionally, the conflict detection module 13 is configured to: obtain the rule-process mapping relationship corresponding to the initial multivariate decision rule system, wherein the rule-process mapping relationship is the mapping relationship between the multivariate decision rule combination of the initial multivariate decision rule system and the reference transaction operation process; based on the rule-process mapping relationship, perform rule annotation missing detection processing on the reference multivariate decision rule combination corresponding to the reference multivariate decision rule logic language to obtain the rule annotation missing detection result; and based on the rule-process mapping relationship, perform annotation content conflict detection processing on all reference multivariate decision rule combinations of the reference multivariate decision rule logic language to obtain the annotation content conflict detection result.

[0235] Optionally, the conflict detection module 13 is used to: determine an abnormal multivariate decision rule combination of conflict detection type based on the conflict detection result; and adjust the abnormal multivariate decision rule combination in the initial multivariate decision rule system to obtain the target multivariate decision rule system after rule adjustment.

[0236] Optionally, the decision application module 14 is configured to: monitor transaction data for the reference transaction process using the target multivariate decision rule system; determine all target decision rules satisfied by the transaction data; detect whether there is an actual multivariate decision rule combination in the multivariate decision rule combination, wherein the actual decision rule combination comprises at least two of the target decision rules; if the actual multivariate decision rule combination exists in the multivariate decision rule combination, determine the target transaction process corresponding to the actual multivariate decision rule combination from the target multivariate decision rule system and execute the target transaction process; if the actual multivariate decision rule combination does not exist in the multivariate decision rule combination, perform transaction ignoring processing.

[0237] It should be noted that the multivariate decision processing device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the multivariate decision processing method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the multivariate decision processing device and the multivariate decision processing method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0238] The serial numbers in this specification are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0239] This specification also provides a computer storage medium that can store multiple instructions adapted for loading and execution by a processor of the multivariate decision processing method as described in the embodiments shown in Figures 1 to 11 above. For details of the execution process, please refer to the specific description of the embodiments shown in Figures 1 to 11, which will not be repeated here.

[0240] This specification also provides a computer program product that stores at least one instruction, which is loaded by the processor and executed as described in the embodiments shown in Figures 1 to 11 above. For details of the execution process, please refer to the specific description of the embodiments shown in Figures 1 to 11, which will not be repeated here.

[0241] Please refer to Figure 13, which is a structural block diagram of an electronic device provided in an embodiment of this specification. The electronic device in this specification may include one or more of the following components: a processor 1010, a memory 1020, an input device 1030, an output device 1040, and a bus 1050. The processor 1010, memory 1020, input device 1030, and output device 1040 can be connected via the bus 1050.

[0242] Processor 1010 may include one or more processing cores. Processor 1010 connects to various parts of the electronic device using various interfaces and lines, and performs various functions and processes data of electronic device 100 by running or executing instructions, programs, code sets, or instruction sets stored in memory 1020, and by calling data stored in memory 1020. Optionally, processor 1010 may be implemented using at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). Processor 1010 may integrate one or a combination of central processing unit (CPU), graphics processing unit (GPU), and modem. The CPU mainly handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem is used for wireless communication. It is understood that the modem may also not be integrated into processor 1010 and may be implemented separately through a communication chip.

[0243] The memory 1020 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 1020 may include non-transitory computer-readable storage medium. The memory 1020 may be used to store instructions, programs, code, code sets, or instruction sets.

[0244] The input device 1030 is used to receive input instructions or data, and includes, but is not limited to, a keyboard, mouse, camera, microphone, or touch device. The output device 1040 is used to output instructions or data, and includes, but is not limited to, a display device and a speaker. In this embodiment, the input device 1030 can be a temperature sensor for acquiring the operating temperature of the electronic device. The output device 1040 can be a speaker for outputting audio signals.

[0245] In addition, those skilled in the art will understand that the structure of the electronic device shown in the above figures does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the electronic device may also include radio frequency circuits, input units, sensors, audio circuits, wireless fidelity (WIFI) modules, power supplies, Bluetooth modules, etc., which will not be described in detail here.

[0246] In the embodiments of this specification, the executing entity for each step can be the electronic device described above. Optionally, the executing entity for each step can be the operating system of the electronic device. The operating system can be Android, iOS, or other operating systems; this specification does not limit this.

[0247] In the electronic device of Figure 12, the processor 1010 can be used to call a program stored in the memory 1020 and execute it to implement the multivariate decision processing method as described in the various method embodiments of this specification.

[0248] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0249] It should be noted that the information (including but not limited to user equipment information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the DSL syntax rule information and transaction data involved in this specification were obtained under full authorization.

[0250] The above-disclosed embodiments are merely preferred embodiments of this specification and should not be construed as limiting the scope of this specification. Therefore, any equivalent variations made in accordance with the claims of this specification shall still fall within the scope of this specification.

Claims

1. A multivariate decision processing method, the method comprising: The system obtains an initial multivariate decision rule system configured by the user terminal based on standard DSL syntax rule information, wherein the standard DSL syntax rule information is DSL syntax rule information preset for multivariate transaction decision development scenarios; Determine all combinations of multivariate decision rules corresponding to the initial multivariate decision rule system, and determine the reference transaction operation process corresponding to the combination of multivariate decision rules; A multivariate combination instance library is constructed for the initial multivariate decision rule system. Based on the multivariate combination instance library, the initial multivariate decision rule system is subjected to engineering language conflict detection processing to obtain the target multivariate decision rule system after conflict detection. The target multivariate decision rule system is used to process transaction operation flow decisions on transaction data.

2. The method according to claim 1, wherein the initial multivariate decision rule system configured by the user terminal based on standard DSL syntax rule information comprises: Obtain the set of target multivariate decision rules developed by the user end based on standard DSL syntax rules; An initial multivariate decision rule system is obtained by performing engineering language conversion processing based on the target multivariate decision rule set.

3. The method according to claim 2, wherein the step of converting the target multivariate decision rule set into engineering language to obtain the initial multivariate decision rule system comprises: The multivariate decision rules in the target multivariate decision rule set are combined to obtain multiple multivariate decision rule combinations. The multivariate decision rule combination is translated using a pre-defined rule logic language to obtain the decision rule logic language structure data. The initial multivariate decision rule system is obtained by converting the logical language structure data of the decision rules into engineering code language.

4. The method according to claim 1, wherein determining all combinations of multivariate decision rules corresponding to the initial multivariate decision rule system and determining the reference transaction workflow corresponding to the multivariate decision rule combinations includes: Determine all combinations of multivariate decision rules corresponding to the initial multivariate decision rule system; Multiple transaction job processes are obtained, and the multivariate decision rule combination is matched based on the transaction job processes to obtain a reference transaction job process matched by each multivariate decision rule combination. The rule-process mapping relationship between the combination of multivariate decision rules and the reference transaction operation process is marked.

5. The method according to claim 1, wherein constructing a multivariate combination instance library for the initial multivariate decision rule system comprises: Determine the range of discrete values ​​of the decision variables in the initial multivariate decision rule system, and construct a multivariate combination instance library based on the range of discrete values ​​of the variables.

6. The method according to claim 5, wherein determining the range of discrete values ​​of the decision variables in the initial multivariate decision rule system and constructing a multivariate combination instance library based on the range of discrete values ​​of the variables includes: Obtain all decision variables corresponding to the initial multivariate decision rule system, and determine the range of discrete values ​​for each decision variable; Based on the range of discrete values ​​of each decision variable, determine the multivariate decision rule combination instance corresponding to the multivariate decision variable combination type; A multivariate combination instance library is constructed based on all the aforementioned multivariate decision rule combination instances.

7. The method according to claim 1, wherein the step of performing engineering language conflict detection processing on the initial multivariate decision rule system based on the multivariate combination instance library to obtain the conflict-detected target multivariate decision rule system comprises: Each multivariate decision rule combination instance in the multivariate combination instance library is converted into a reference multivariate decision rule logic language by performing engineering language expression conversion. Conflict detection processing is performed on all the aforementioned reference multivariate decision rule logic languages ​​to obtain conflict detection results; Based on the conflict detection results, the initial multivariate decision rule system is adjusted to obtain the target multivariate decision rule system after rule adjustment.

8. The method according to claim 7, wherein performing conflict detection processing on all the reference multivariate decision rule logic languages ​​to obtain conflict detection results includes: Obtain the rule-process mapping relationship corresponding to the initial multivariate decision rule system, wherein the rule-process mapping relationship is the mapping relationship between the multivariate decision rule combination of the initial multivariate decision rule system and the reference transaction operation process; Based on the rule-process mapping relationship, rule annotation missing detection processing is performed on the reference multivariate decision rule combination corresponding to the reference multivariate decision rule logic language to obtain the rule annotation missing detection result. Based on the aforementioned rule-process mapping relationship, the reference multivariate decision rule combinations of all the aforementioned reference multivariate decision rule logic languages ​​are subjected to annotation content conflict detection processing to obtain annotation content conflict detection results.

9. The method according to claim 7, wherein adjusting the rules of the initial multivariate decision rule system based on the conflict detection result to obtain the adjusted target multivariate decision rule system comprises: Based on the conflict detection results, determine the combination of abnormal multivariate decision rules for the conflict detection type; The abnormal multivariate decision rule combination is adjusted in the initial multivariate decision rule system to obtain the target multivariate decision rule system after rule adjustment.

10. The method according to claim 1, wherein the step of using the target multivariate decision rule system to perform transaction operation process decision processing on transaction data includes: The target multivariate decision rule system is used to monitor transaction data for the reference transaction workflow; Determine all target decision rules satisfied by the transaction data, and detect whether there is an actual multivariate decision rule combination in the multivariate decision rule combination, wherein the actual decision rule combination comprises at least two of the target decision rules; If the actual multivariate decision rule combination exists in the multivariate decision rule combination, then the target transaction operation process corresponding to the actual multivariate decision rule combination is determined from the target multivariate decision rule system, and the target transaction operation process is executed. If the actual multivariate decision rule combination does not exist in the multivariate decision rule combination, then the transaction is ignored.

11. A multivariate decision processing device, applied to a service platform, the device comprising: The rule configuration module is used to obtain the initial multivariate decision rule system configured by the user terminal based on the standard DSL syntax rule information, wherein the standard DSL syntax rule information is the DSL syntax rule information preset for the multivariate transaction decision development scenario; The job annotation module is used to determine all combinations of multivariate decision rules corresponding to the initial multivariate decision rule system and to determine the reference transaction job flow corresponding to the combination of multivariate decision rules. The conflict detection module is used to construct a multivariate combination instance library for the initial multivariate decision rule system, and to perform engineering language conflict detection processing on the initial multivariate decision rule system based on the multivariate combination instance library to obtain the target multivariate decision rule system after conflict detection. The decision application module is used to perform transaction operation process decision processing on transaction data using the target multivariate decision rule system.

12. A computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the method steps of any one of claims 1 to 10.

13. A computer program product storing at least one instruction, said at least one instruction being loaded by a processor and executing the method steps of any one of claims 1 to 10.

14. An electronic device, comprising: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed the method steps as claimed in any one of claims 1 to 10.

Images