Executive file processing method and system of decision engine

Abstract

The invention discloses an execution file processing method and system of a decision engine, and relates to the technical field of information. Creating a global execution context according to the parameter set; establishing a parameter hierarchical pool structure according to the global execution context; loading the entity object data to the parameter hierarchical pool structure according to the access authority configured by the association rule; obtaining an association rule corresponding to the decision set number from a preset rule base according to the decision set number; sorting the association rules according to the priorities and historical execution success rates of the association rules; sequentially executing the sorted association rules through a rule execution engine by utilizing a parameter hierarchical pool structure to obtain an association rule execution result set; selecting a predefined decision strategy; and taking the association rule execution result set as input, and calculating a decision result according to the selected decision strategy. Aiming at low rule execution efficiency in the prior art, the execution efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of information technology, and particularly to a method and system for processing execution files of a decision engine. Background Art

[0002] A decision engine is a core component in modern information systems and is widely used in fields such as financial risk control, insurance underwriting, intelligent manufacturing, e-commerce, and smart healthcare. As the core platform for business rule management and execution, a decision engine can abstract and encapsulate complex business logics in the form of rules, achieving decoupling of business logics and application programs, and improving the flexibility and maintainability of the system. With the rapid development of big data and artificial intelligence technologies, decision engines are facing increasingly complex rule sets, higher requirements for execution efficiency, and more diverse decision strategy needs.

[0003] The basic working principle of a decision engine is to receive business data as input, perform rule matching and execution based on a preset rule set, and finally generate a decision result. A typical decision engine usually includes core modules such as rule management, rule compilation, rule execution, data management, and decision strategies. Among them, the rule execution efficiency directly affects the overall performance of the decision engine. Especially in business scenarios that require real-time decisions, such as credit card fraud detection and online loan approval, the level of rule execution efficiency has a decisive impact on the business response time and user experience.

[0004] Existing decision engines generally adopt simple memory management strategies, such as global unified allocation or fixed-size memory block allocation, lacking a refined memory management mechanism targeted at the characteristics of rule execution. During the rule execution process, the memory spaces for temporary variables and intermediate results are often not released in a timely manner, resulting in waste of memory resources and even memory leakage problems after long-term operation. Especially for large rule sets, the problem of low memory usage efficiency is more prominent, directly affecting the stability and scalability of the system.

[0005] For example, the related patent document CN112907234B discloses a method for implementing a decision engine based on dynamic configuration rules. The present invention aims to solve the problem that when the verification rules need to be adjusted in the business process, there is no need to modify the code and release a new version, and the solution can take effect immediately by modifying the configuration of the decision rules. The main solutions include obtaining the dependent parameters of the associated rules according to the input parameters of the core logic of the execution rules and initializing them into the parameter pool, obtaining the entity object data on which the associated rules depend from the configuration rule reference entity object and initializing it into the entity object data pool; according to the rule number of the associated rules, giving the values of the entity object data pool and the parameter pool to the rule core execution logic Content of the configuration rules, performing rule execution, and obtaining the rule execution result; all the rule execution results form a decision set, and if one rule execution result is false, the final decision result is false, otherwise the final decision result is true. However, in this solution, all parameters are mixed in a single parameter pool, and the risk of parameter coverage between rules is high. In addition, this solution cannot distinguish between global parameters and rule local parameters, and even temporary variables used only by a single rule will occupy the memory resources of the entire decision-making process. Therefore, the execution efficiency of this solution needs to be further improved. Summary of the Invention

[0006] Aiming at the low rule execution efficiency in the prior art, the present application provides a method and system for processing execution files of a decision engine, which realizes the precise allocation and release of memory resources, the priority sorting and parallel execution of rules, etc. by constructing a parameter hierarchical pool structure and a rule execution dependency graph, so as to improve the execution efficiency.

[0007] The object of the present application is achieved by the following technical solutions.

[0008] An aspect of the present application provides a method for processing an execution file of a decision engine, including: S1, obtaining a parameter set, where the parameter set includes a decision set number and business data; creating a global execution context according to the parameter set; S2, establishing a parameter hierarchical pool structure according to the global execution context; classifying and loading the data in the parameter set into the corresponding parameter pools in the parameter hierarchical pool structure according to the configuration information of the association rules according to the parameter scope; S3, establishing an entity object caching mechanism; obtaining entity object data on which the association rules depend from an entity object data source; loading the entity object data into the parameter hierarchical pool structure according to the access permissions configured by the association rules; S4, obtaining the association rules corresponding to the decision set number from a preset rule library according to the decision set number; sorting the association rules according to the priority and historical execution success rate of the association rules; S5, using the parameter hierarchical pool structure, sequentially executing the sorted association rules through a rule execution engine to obtain an association rule execution result set; S6, selecting a predefined decision strategy according to the decision set configuration corresponding to the decision set number; using the association rule execution result set as input, and calculating a decision result according to the selected decision strategy.

[0009] Further, the global execution context is used to configure a decision mode, store intermediate results, and control an execution process; the historical execution success rate represents the proportion of the association rules that return true in historical executions; the predefined decision strategies include at least one of an all-pass mode, any-pass mode, threshold mode, weighted mode, and expression mode.

[0010] Further, S1, creating a global execution context according to the parameter set includes: extracting the decision set number from the parameter set; obtaining the dependency relationship of the association rules according to the decision set number; dividing the association rules into multiple execution levels according to the dependency relationship, where there is no dependency relationship between the rules within each execution level, and the execution level is used to control the execution order of the association rules; calculating the maximum number of parallel execution threads of the system according to the computing resources of the system; setting the parallelism parameter of each execution level according to the maximum number of parallel execution threads; and constructing a global execution context according to the execution level and the parallelism parameter.

[0011] In the traditional creation of a global execution context, due to the adoption of a single-threaded serial processing mode and the lack of effective management of rule dependency relationships, the efficiency is low, especially in the scenario of a large-scale rule set, which is more prominent and cannot meet the high-concurrency business requirements.

[0012] The present application effectively solves the performance bottleneck problem in the traditional method by introducing rule dependency relationship analysis and a multi-level parallel execution architecture, combined with dynamic resource scheduling and priority management, significantly improves the execution efficiency of a large-scale rule set, and enables the decision engine to adapt to more complex business scenario requirements.

[0013] Further, in S2, a parameter hierarchical pool structure is established according to the global execution context; according to the configuration information of the association rules, the data in the parameter set is classified and loaded into the corresponding parameter pools in the parameter hierarchical pool structure, including: initializing a set of parameter pool objects according to the execution level information and system historical load conditions in the global execution context, pre-creating a certain number of parameter pool instances, and establishing a hierarchical pool structure; obtaining the corresponding rule group division configuration and rule inter-dependency configuration from the preset rule library according to the decision set number, and constructing a rule execution dependency graph; associating the global parameter pool with the global execution context according to the rule execution dependency graph; creating identifiers for each rule group according to the rule group division configuration, and classifying the rules with the same identifier into the same rule group; for the rule groups that are independent of each other and will not be executed in parallel, creating a shared parameter pool independent of the global parameter pool and the rule group parameter pools; setting a first allocation table and a second allocation table in the rule parameter pool reuse area, where the first allocation table is used to record the variable addresses and sizes created during the execution of a single rule, and the memory occupied by the variables is uniformly released after the rule execution is completed; the second allocation table records the addresses, sizes, and access rule lists of the intermediate result variables passed between consecutive rules, and the corresponding memory is released only after all dependent rules are executed; according to the parameter scopes in the association rule configuration information, classifying and loading the business data in the parameter set into the corresponding parameter pools, where the parameters in the global scope are loaded into the global parameter pool, and the parameters in the rule group scope are loaded into the corresponding associated rule group parameter pools.

[0014] Traditional decision engine systems have defects such as unreasonable memory management, rigid parameter sharing mechanisms, and inefficient data transfer between rules when dealing with large-scale complex rule executions, often resulting in system resource waste, memory leaks, and low rule execution efficiency. Especially in high-concurrency scenarios, due to the lack of a memory allocation strategy targeting the characteristics of rule execution, frequent memory allocation and release operations will cause serious performance bottlenecks and it is difficult to support complex rule dependencies.

[0015] This application solves the above problems by establishing a parameter hierarchical pool structure and a refined memory management mechanism. Specifically, parameter pool instances are pre-created based on the execution level information and historical load conditions, and a hierarchical structure of the global parameter pool, rule group parameter pools, and rule parameter pool reuse area is constructed in combination with the rule execution dependency graph; by creating a shared parameter pool for independent rule groups, the utilization of memory resources is optimized; the first allocation table and the second allocation table are set to manage the variable memory of the single-rule life cycle and cross-rule transfer respectively, realizing precise memory allocation and timely recycling; at the same time, the business data is classified and loaded into the corresponding parameter pools according to the parameter scopes, improving the data access efficiency and the overall performance of the system.

[0016] Furthermore, the hierarchical pool structure includes a global parameter pool, a rule group parameter pool, and a rule parameter pool reuse area; the shared parameter pool is used for temporary data shared among rules within the same rule group. By establishing a mapping relationship between the rule group identifier and the shared parameter pool instance in the global execution context, the shared parameter pool of the rule group is associated with the corresponding execution level of the global execution context.

[0017] Furthermore, according to the decision set number, obtain the corresponding rule group division configuration and inter-rule dependency relationship configuration from the preset rule library, and construct a rule execution dependency graph, including: through a joint query mechanism, respectively obtain rule metadata and dependency relationship configuration from the preset rule library according to the decision set number; extract the rule identifiers of the rule metadata; construct a rule identifier dictionary based on the rule metadata, and establish a mapping relationship between the rule identifier and the rule metadata using a hash table structure; according to the mapping relationship and the dependency relationship configuration, construct a directed acyclic graph as the initial rule execution dependency graph; where the nodes of the graph represent rules and the edges represent the dependency relationships between rules; use the topological sorting algorithm to perform hierarchical division on the initial rule execution dependency graph to determine the execution order of the rules and obtain the final rule execution dependency graph.

[0018] The traditional method of constructing a rule execution dependency graph using a directed acyclic graph has defects such as multiple database accesses, inefficient mapping between rule metadata and dependency relationships, and slow determination of rule execution order. This application combines a joint query mechanism with a hash table mapping structure to solve the performance bottleneck problem under a large-scale rule set. At the same time, the hierarchical division by topological sorting optimizes the rule parallel execution efficiency, significantly improving the decision set execution performance and resource utilization rate.

[0019] Furthermore, the dependency relationship configuration represents the pre-execution conditions, input / output parameter dependencies, and trigger conditions between rules.

[0020] Furthermore, in S4, obtain the associated rules corresponding to the decision set number from the preset rule library; sort the associated rules according to the priority and historical execution success rate of the associated rules, including: obtain the priority and historical execution success rate of each associated rule from the preset rule library; perform an ascending sort on all associated rules according to the priority to obtain a priority sorting sequence A; perform a descending sort on all associated rules according to the historical execution success rate to obtain a historical execution success rate sorting sequence B; obtain the position index rankAP i of each associated rule P i in the sequence A, and obtain the associated rule P i 's position index rankBP i in the sequence B; according to the position index rankAP i and the position index rankBP i, calculate the comprehensive sorting value rankP of each association rule i ; According to the comprehensive sorting value rankP i Ascendingly sort all association rules to obtain the sorted association rules.

[0021] Furthermore, in S5, using the parameter hierarchical pool structure, sequentially execute the sorted association rules through the rule execution engine to obtain the association rule execution result set, including: for each rule in the current execution level, dynamically apply for the memory space required to execute the current rule in the first allocation table of the rule parameter pool reuse area to store the rule local variables; obtain the parameters required for the current rule execution from the rule local parameter pool, rule group parameter pool, and global parameter pool according to the configuration information of the association rule; execute the conditional judgment logic of the current association rule, and select to execute the true branch or false branch of the association rule according to whether the condition is satisfied; during the process of executing the association rule branch, store the intermediate results in the rule parameter pool reuse area or the shared parameter pool of the rule group; if the intermediate result is only used by the current rule, register the variable information in the first allocation table, and uniformly release it after the current rule execution is completed; if the intermediate result needs to be passed between multiple association rules, register the variable information in the second allocation table, and register the other association rules that depend on this variable, and release the memory occupied by the variable only after all dependent rules are executed; after the current association rule is executed, store the boolean execution result of the rule in the association rule execution result set; release all temporary variables generated during the execution of the current rule registered in the first allocation table; after all association rules in the current level are executed, traverse the second allocation table and release the memory occupied by the intermediate result variables generated in the current level and no longer used in the subsequent levels; after completing the current execution level, if there are subsequent execution levels, jump to the next level and continue to execute until the last level is executed; finally, output the complete association rule execution result set.

[0022] Traditional rule execution engines, first, use a global variable pool to uniformly manage all rule variables, lacking an effective memory isolation mechanism, resulting in data contamination between rules; second, rely on a general garbage collection mechanism to handle intermediate results, with an uncertain memory release timing, which may cause both memory leaks and premature releases leading to data access errors; third, lack precise tracking of data dependencies between rules and cannot optimize memory resource allocation according to actual usage, showing obvious performance bottlenecks and memory pressure during the execution of large-scale rule sets.

[0023] This application realizes precise memory lifecycle control through a two - layer memory management architecture of a first allocation table and a second allocation table, fundamentally solving the above - mentioned technical defects. The first allocation table focuses on memory management within a single rule. By precisely recording the addresses, sizes, and lifecycles of rule local variables, it realizes immediate release after rule execution is completed, eliminating the possibility of memory leaks. The second allocation table, by explicitly recording the dependency relationships of shared variables among multiple rules, precisely tracks the last usage time point of each intermediate result variable, ensuring that variables are neither released prematurely, causing data loss, nor occupy memory for a long time, resulting in resource waste. On the one hand, this application eliminates the uncertainty of traditional garbage collection mechanisms, making the system execution performance more stable and predictable; on the other hand, by reducing memory allocation and recycling operations, it reduces CPU resource consumption, especially in high - concurrency scenarios.

[0024] Another aspect of this application also provides an execution file processing system for a decision engine, which is used to execute an execution file processing method for a decision engine of this application.

[0025] Compared with the prior art, the advantages of this application are as follows:

[0026] Aiming at the technical defects in the prior art, such as the difficulty in balancing data sharing and isolation and frequent data pollution problems caused by the common use of a single global parameter space or a simple parameter isolation mechanism in decision engines, this application realizes fine - grained control of data access rights by constructing a three - level hierarchical parameter pool structure of a global parameter pool, a rule - group parameter pool, and a rule - parameter pool reuse area, avoiding data pollution during rule execution. At the same time, in scenarios where data needs to be shared, it provides a rule - group parameter pool and a global parameter pool mechanism, balancing the needs of data isolation and sharing. This design is based on the principle of data classification and loading according to parameter scopes. It precisely divides data into different scopes according to the configuration information of rules, realizes precise control of data access through the hierarchical access control mechanism between parameter pools, and optimizes the memory call path according to the parameter access mode, fundamentally solving the technical bottleneck of traditional decision engines in data management.

[0027] In view of the problems in the prior art such as untimely release of temporary variables in the decision engine, premature release or non-release of intermediate result variables leading to memory leaks, etc., the present application innovatively designs a dual-table memory precise management mechanism based on a first allocation table and a second allocation table. The first allocation table records variable information created during the execution of a single rule, and releases the corresponding memory immediately after the rule execution is completed; the second allocation table manages intermediate result variables shared by multiple rules, and releases them only after all dependent rules have been executed, avoiding memory leaks and errors caused by premature release. Through the precise tracking and recording of the variable life cycle, combined with the rule execution order information in the rule execution dependency graph, this dual-table mechanism realizes the precise allocation and release of memory resources, significantly reduces memory fragmentation, optimizes the utilization efficiency of memory resources, and is particularly suitable for scenarios of large-scale rule sets and long-running decision engines.

[0028] In view of the problem of low decision-making efficiency caused by the fixed and unoptimizable rule execution order in the prior art, the present application uses a directed acyclic graph mathematical model to represent the complex dependency relationships between rules, combines a topological sorting algorithm for hierarchical division, and automatically identifies and correctly processes the pre-execution conditions, input-output parameter dependencies, and trigger conditions between rules. The hierarchical division based on the dependency graph ensures the correct order of rule execution. At the same time, without violating the dependency relationships, it optimizes the rule execution order, avoiding unnecessary waiting and blocking. This method establishes a mapping relationship between rule identifiers and rule metadata through a hash table structure, uses graph theory algorithms to automatically detect cyclic dependencies and resolve dependency conflicts, realizes the automated management of complex rule relationships, greatly improves the parallelism and overall execution efficiency of rule execution, and at the same time ensures the correctness and consistency of rule execution results. Brief Description of the Drawings

[0029] The present application will be further described in the form of exemplary embodiments, and these exemplary embodiments will be described in detail through the drawings. These embodiments are not restrictive. In these embodiments, the same numbers represent the same structures, where:

[0030] Figure 1 is an exemplary flowchart of an execution file processing method for a decision engine according to some embodiments of the present application;

[0031] Figure 2 is an exemplary flowchart of creating a global execution context according to some embodiments of the present application;

[0032] Figure 3 is an exemplary flowchart of constructing a rule execution dependency graph according to some embodiments of the present application;

[0033] Figure 4 is an exemplary flowchart of sorting associated rules according to some embodiments of the present application. Specific implementation manner

[0034] The method and system provided by the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0035] As Figure 1 shown, a method for processing an execution file of a decision engine includes: obtaining a parameter set, where the parameter set includes a decision set number and service data; creating a global execution context according to the parameter set; establishing a parameter hierarchical pool structure according to the global execution context; the parameter hierarchical pool structure includes a global parameter pool, a rule group parameter pool, and a rule parameter pool reuse area; classifying and loading the data in the parameter set into the corresponding parameter pools in the parameter hierarchical pool structure according to the configuration information of the association rules; establishing an entity object caching mechanism; obtaining entity object data on which the association rules depend from an entity object data source according to the entity object caching mechanism; loading the entity object data into the parameter hierarchical pool structure according to the access permissions configured by the association rules; obtaining the association rules corresponding to the decision set number from a preset rule library according to the decision set number; sorting the association rules according to the priorities and historical execution success rates of the association rules; using the parameter hierarchical pool structure to sequentially execute the sorted association rules through a rule execution engine to obtain an association rule execution result set; selecting a predefined decision strategy according to the decision set configuration corresponding to the decision set number; and calculating a decision result by using the association rule execution result set as an input according to the selected decision strategy.

[0036] As Figure 2 shown, S1, the decision engine receives a parameter set passed in by an external system through multiple access methods (such as REST API, RPC call, or message queue). The process of obtaining the parameter set first parses the original data format (such as JSON, XML, or binary format), and then converts it into a standardized parameter set object used internally by the system.

[0037] The parameter set mainly includes two core pieces of information: one is the decision set number, which is used as the only identifier to determine which set of rules to execute; the other is the service data, that is, various service parameters required for rule execution. In addition, the parameter set may also include metadata information, such as control parameters such as call source identifier, timeout configuration, and priority.

[0038] After receiving the parameter set, the system performs necessary legality verification to ensure that the decision set number exists and has a correct format, and the service data structure meets the expectations, preventing system errors caused by illegal parameters. After passing the verification, the parameter set is converted into an internal standard format for subsequent processing.

[0039] The global execution context is the core control component throughout the execution process of the decision engine, responsible for managing various resources and states in the execution lifecycle. Its creation process first generates a unique context identifier, records the creation timestamp, and associates the decision set number in the parameter set with the context.

[0040] The global execution context maintains multiple key data structures internally: one is the parameter management structure, including the global parameter pool, the rule group parameter pool mapping table, and the parameter pool registration table, which are used to implement hierarchical parameter management; the second is the memory management structure, including the first allocation table and the second allocation table, which are responsible for precisely tracking and managing memory resources; the third is the rule execution structure, including the rule dependency graph and the execution hierarchy list, which control the execution order of rules and dependency processing.

[0041] During the creation process, the system initializes the global parameter pool based on the business data in the parameter set to prepare for subsequent rule execution. At the same time, the system also sets the decision mode (such as all pass, any pass, threshold mode, etc.) according to the configuration information or the specification in the parameter set. After the global execution context is created, its status is marked as "initialized" and waits for subsequent execution.

[0042] The extraction of the decision set number is the process of obtaining the unique identifier of the decision set from the parameter set. The system first checks whether there is a decision set number field in the parameter set, and then verifies whether its format conforms to the system-defined specification (usually a string in a specific format, such as a string prefixed with "DS" plus a number or UUID format).

[0043] The extracted decision set number is used to query the rule library of the decision engine to confirm whether the decision set exists and whether it is in a valid state. The system also checks whether the current user or caller has the permission to execute this decision set. If the decision set does not exist, is invalid, or is not accessible, the system will throw the corresponding exception and terminate the execution process.

[0044] After the decision set number is successfully verified, the system loads the basic information of the decision set from the rule library, such as decision strategies, timeout settings, priority configurations, etc., and these information will be used for subsequent execution context configuration.

[0045] According to the verified decision set number, the system queries all rule definitions associated with this decision set from the rule library. The rule definition includes the basic information of the rule (such as rule identifier, name, description), execution conditions, input parameters, output parameters, execution priority, etc.

[0046] The acquisition of rule dependencies is a key step in constructing a rule execution dependency graph. The system identifies various types of dependencies between rules by analyzing the list of prerequisite rules, input parameter dependencies, and trigger conditions in the rule definitions. There are mainly three types of dependencies: prerequisite execution dependency (rule A must be executed before rule B), parameter dependency (the input of rule B depends on the output of rule A), and trigger dependency (the execution result of rule A affects whether rule B is executed).

[0047] The system uses a directed graph data structure to represent rule dependencies, where nodes represent rules and edges represent dependencies. The dependency graph construction process automatically detects cyclic dependencies. If a cyclic dependency is found, the system will handle it according to the configured strategy (interrupt execution or break the cycle) to ensure that the final formed dependency graph is a directed acyclic graph.

[0048] Based on the constructed rule dependency graph, the system uses a topological sorting algorithm to divide the rules into multiple execution levels. Topological sorting ensures that if rule A depends on rule B, then the level where rule B is located must be earlier than the level where rule A is located.

[0049] Specifically, the system first identifies the "source" nodes in the dependency graph (nodes with no incoming edges, i.e., rules that do not depend on other rules). These nodes are assigned to the first execution level. Then, these nodes and their related edges are removed, and new "source" nodes are identified and assigned to the second execution level, and so on, until all rules are assigned to the corresponding execution levels.

[0050] After the execution level division is completed, the system assigns a unique identifier to each level and establishes a mapping relationship from rules to levels, which is convenient for quickly locating the level to which a rule belongs during the subsequent execution process. At the same time, the system also records the number of rules included in each level as a reference for setting the parallelism parameter.

[0051] To make full use of system resources without causing excessive competition, the system needs to calculate an appropriate maximum number of parallel execution threads. The calculation process takes into account multiple factors: First, the system obtains the available processor cores of the current server as a basic reference value for parallelism. Then, considering the thread pool size limit configured in the system and the current system load situation, the number of processor cores is appropriately adjusted. The system also refers to historical execution data, analyzes the relationship curve between the optimal parallelism and performance, and finds the optimal parallelism setting.

[0052] In addition, the system considers the characteristics of the decision set (such as rule complexity, I / O-intensive or compute-intensive) and business requirements (such as response time requirements) to further optimize the number of parallel threads. Finally, the system applies the configured minimum and maximum thread number limits to ensure that the calculation result is within a reasonable range.

[0053] Based on the calculated maximum number of parallel execution threads and the execution level division results, the system sets appropriate parallelism parameters for each execution level. The parallelism parameters determine the maximum number of rules that can be executed simultaneously within that level.

[0054] The system first considers the number of rules in each level. For levels where the number of rules is less than or equal to the maximum number of parallel threads, the parallelism can be set equal to the number of rules; for levels where the number of rules is greater than the maximum number of parallel threads, the parallelism is set equal to the maximum number of parallel threads.

[0055] Then, the system adjusts according to the characteristics of the rules. For levels with more compute-intensive rules, the system appropriately reduces the parallelism to avoid CPU resource contention; for levels with more I / O-intensive rules, the system may appropriately increase the parallelism to mask the I / O waiting time.

[0056] The system also considers the data locality among the rules. For rules that share the same data, they may be assigned to the same execution batch to improve cache utilization. Finally, the system ensures that the sum of the parallelism parameters for all levels does not exceed the maximum number of parallel execution threads of the system.

[0057] Based on the execution levels and parallelism parameters obtained in the foregoing steps, the system completes the construction of the global execution context. During the construction process, the system associates the list of execution levels and the parallelism parameters for each level with the context, and at the same time creates corresponding execution control structures for each execution level, such as level execution status monitors, inter-level synchronization controllers, etc.

[0058] The system also initializes the memory resource management structure according to the rule dependencies, including the first allocation table and the second allocation table. The first allocation table is used to manage the temporary variables during the execution of a single rule, and the second allocation table is used to manage the intermediate result variables shared by multiple rules. These two allocation tables are closely associated with the rule execution levels to ensure the precise allocation and release of memory resources.

[0059] In the final stage of the global execution context construction, the system initializes various monitoring and statistical components to collect performance data, resource usage, and exception information of rule execution. This data will be used for subsequent execution optimization and problem diagnosis.

[0060] After construction, the global execution context contains all the control information and resource management structures required for the decision engine to execute the decision set, which can support an efficient and reliable rule execution process, ensuring the optimal utilization of system resources and the correctness of execution results.

[0061] Such as Figure 3As shown in Figure S2, establish a parameter hierarchical pool structure according to the global execution context; the parameter hierarchical pool structure of the decision engine is a multi-level parameter management mechanism used to achieve fine-grained control of data access permissions and efficient management of memory resources. This structure mainly includes three levels: the global parameter pool, the rule group parameter pool, and the rule local parameter pool.

[0062] To establish the parameter hierarchical pool structure, it is first necessary to analyze the hierarchical division and execution order of the rules based on the execution level information in the global execution context. The system combines the load conditions in the historical execution data to predict the possible parameter access patterns and memory occupancy during this execution process, and accordingly determines the number and capacity of the initial parameter pools.

[0063] The system uses object pool technology to pre-create a certain number of parameter pool instances to avoid performance overhead and memory fragmentation caused by frequent object creation during execution. The pre-created parameter pool instances are organized into pooled resources and can be allocated to the required rule groups or individual rules at any time. The pre-creation quantity is dynamically adjusted according to the historical load conditions of the system, which not only avoids resource waste but also ensures that there are sufficient parameter pools available during peak loads.

[0064] During the establishment process of the parameter hierarchical pool structure, the system first creates the global parameter pool as the top-level data sharing space; then creates a rule group parameter pool for each rule group; finally, pre-allocates a group of reusable rule local parameter pools in the rule parameter pool reuse area for temporary data storage during rule execution. Strict access control rules are established between the three-layer parameter pools to ensure data isolation and security.

[0065] Construct a rule execution dependency graph, which is the core data structure for the decision engine to control the rule execution order and manage the dependencies between rules. Its construction process first requires obtaining relevant configuration information from the preset rule library.

[0066] The system adopts a union query mechanism to simultaneously retrieve multiple relevant data tables based on the decision set number, including the rule metadata table, the rule group configuration table, and the rule dependency relationship table. The rule metadata contains the basic attribute information of the rules, such as rule identifiers, names, descriptions, creation times, version numbers, etc.; the dependency relationship configuration contains the pre-execution conditions, input and output parameter dependencies, and trigger conditions between rules, and these information are the basic data for constructing the dependency graph.

[0067] The system extracts rule identifiers from the retrieved rule metadata, and these identifiers will be used as nodes in the dependency graph. To improve the efficiency of subsequent processing, the system constructs a rule identifier dictionary, using a hash table structure to establish a fast mapping relationship between rule identifiers and rule metadata, supporting lookup operations with an O(1) time complexity.

[0068] Based on the rule identifiers and dependency configurations, the system constructs an initial directed graph structure. Nodes in the graph represent rules, and edges represent the dependency relationships between rules. The direction of the edges is from the dependent rule to the rule with the dependency. The system uses an adjacency list or an adjacency matrix to represent this directed graph structure and selects an appropriate representation method according to the number of rules and the density of the dependency relationships.

[0069] The constructed initial graph structure may have circular dependencies. The system identifies circular dependencies through depth - first search or a dedicated cycle - detection algorithm. If circular dependencies are found, the system will handle them according to the configured strategy: either interrupt the execution and report an error, or automatically break the cycle based on rule priorities or other strategies. The processed graph structure is guaranteed to be a directed acyclic graph.

[0070] The system uses a topological sorting algorithm to partition the directed acyclic graph into levels. Specifically, first, it identifies the nodes with an in - degree of zero (i.e., rules that do not depend on other rules) and classifies them into the first execution level; then, it removes these nodes and their associated edges from the graph, continues to identify new nodes with an in - degree of zero, and classifies them into the second execution level; and so on until all nodes are classified into the corresponding execution levels. This level partitioning ensures that when rules are executed, all dependent rules of any rule have been executed.

[0071] Associate the parameter pool with the execution context: The association between the parameter pool and the global execution context is a key step in achieving unified control and resource management. The system first directly associates the global parameter pool instance with the global execution context object, making it an integral part of the context. The data stored in the global parameter pool is visible to all rules and is used to store business data and intermediate results that need to be globally shared.

[0072] The system creates a unique identifier for each rule group according to the previously obtained rule - group partitioning configuration. The identifier generation uses methods such as a specific prefix plus a serial number or UUID to ensure uniqueness throughout the system. Rules with the same identifier are grouped into the same rule group, and these rules usually have common business meanings or data - access requirements.

[0073] For rule groups that are independent of each other and will not be executed in parallel, the system creates independent shared parameter pools. These shared parameter pools are independent of the global parameter pool and the rule - group parameter pools and are specifically used for temporarily shared data among rules within the same rule group. This design avoids unnecessary global data sharing and reduces the risk of data conflicts and accidental modifications.

[0074] The system establishes a mapping relationship between the rule group identifier and the shared parameter pool instance in the global execution context, usually using a hash map data structure. This mapping relationship enables the system to quickly locate the corresponding shared parameter pool according to the rule group to which the current rule belongs during the rule execution process, achieving efficient data access. At the same time, the system associates the shared parameter pool with the corresponding execution level of the global execution context to ensure correct management of the parameter pool resources after the hierarchical execution is completed.

[0075] In the rule parameter pool reuse area, the system sets up two key memory management components: the first allocation table and the second allocation table. These two allocation tables together constitute the precise memory management mechanism of the decision engine.

[0076] The first allocation table focuses on managing the temporary variables created during the execution of a single rule. The table records information such as the memory address, occupied size, creation time, and the identifier of the rule to which the variable belongs. When the rule execution is completed, the system uniformly releases the memory occupied by all the temporary variables created by the rule according to the records in the first allocation table, avoiding memory leaks. This timely release mechanism significantly reduces the memory occupancy of the system, especially when dealing with a large number of rules, and the effect is more obvious.

[0077] The second allocation table is responsible for managing the intermediate result variables passed between multiple consecutive rules. The table records not only the memory address and occupied size of the variable but also the list of rules accessing the variable. The system determines when it is safe to release the intermediate result variables according to the rule execution order analyzed from the rule execution dependency graph. Only when all the rules depending on the variable have been executed, the system will release the corresponding memory resources. This precise memory release strategy avoids the uncertainty of the traditional garbage collection mechanism and improves the memory utilization efficiency of the system.

[0078] The two allocation tables are implemented using efficient data structures such as hash tables or balanced trees, supporting fast look-up, insertion, and deletion operations. The system periodically compresses and optimizes the allocation tables to reduce the memory resources occupied by the tables themselves. In a high-concurrency environment, the system uses techniques such as segmented locks or lock-free algorithms to ensure the thread safety of the allocation table operations while minimizing the performance overhead caused by lock contention.

[0079] Classify and load business data: The business data in the parameter set needs to be classified and loaded into different parameter pools according to its scope of action and usage characteristics. The system first analyzes the configuration information of the association rules to identify the scope attributes of each parameter.

[0080] For parameters marked with the global scope, the system directly loads them into the global parameter pool. Such parameters usually include basic user information, transaction basic data, system environment parameters, etc., which are accessed by multiple rule groups or almost all rules. The data in the global parameter pool is visible to all rules, but the system controls the read and write permissions of the parameters according to the configured access control rules to prevent accidental modification.

[0081] For parameters marked with the rule group scope, the system loads them into the corresponding rule group parameter pool. Such parameters are usually data shared within a specific business domain, such as risk metrics dedicated to the risk control rule group, user preference data dedicated to the marketing rule group, etc. The data in the rule group parameter pool is only visible to the rules within the same rule group, effectively isolating the data of different business domains.

[0082] During the data loading process, the system performs data type checks and format validations to ensure that the parameter data conforms to the expected format and range. For complex data structures, the system performs preprocessing and conversion as needed, such as JSON string parsing, date format standardization, numerical unit conversion, etc., to reduce the data processing burden during the rule execution process.

[0083] To improve data loading efficiency, the system adopts lazy loading and partial loading strategies, and loads data on demand according to the execution order of rules and parameter dependencies. For large data sets that may not be used, the system only loads them when they are actually needed, avoiding unnecessary memory occupation and processing overhead.

[0084] After the data loading is completed, the system records the data statistics information of each parameter pool, such as the number of parameters, memory occupation, access frequency, etc., as the basis for subsequent performance optimization and resource adjustment. The entire data loading process is designed to be efficient and flexible, and can adapt to the data processing requirements of different scales and complexities.

[0085] S3. Establish an entity object cache mechanism; the entity object cache mechanism of the decision engine adopts a multi-level cache architecture, including three levels: local memory cache, distributed cache, and persistent storage. The local memory cache is used to store frequently accessed hot data, providing the fastest data access speed; the distributed cache is used to share a large-scale entity object data across nodes; the persistent storage serves as the ultimate source of data to ensure data persistence and consistency.

[0086] The cache architecture design adopts a read-write separation strategy, which is optimized for the business characteristics of more reads and fewer writes. The system uses an asynchronous update mechanism to maintain cache consistency. When an entity object changes in the source system, the cache update is triggered through the change event notification mechanism to ensure the timely update and consistency of the cache data.

[0087] The system formulates differentiated caching strategies for different types of entity objects according to their access frequencies, data volumes, and real-time requirements. For entity objects with high access frequencies but low change frequencies, a long-life cycle caching strategy is adopted; for entity objects with high real-time requirements, a short-life cycle or non-caching strategy is adopted.

[0088] To obtain entity object data, the system first analyzes the rule execution dependency graph to identify all entity object types and their association relationships on which the association rules depend. For each type of entity object, the system maintains a dedicated data access adapter to support data acquisition from different data sources (such as relational databases, NoSQL databases, web services, file systems, etc.).

[0089] The data acquisition process adopts an intelligent batch processing mechanism. The system pre-analyzes the data requirements of the rules based on the rule execution dependency graph, merges the requests of multiple rules for the same type of entity object into a batch query, and reduces the number of interactions with the data source. For cross-data source association queries, the system adopts a data splicing strategy, first obtains the basic data from each data source, and then completes data association at the application layer.

[0090] The system implements a failure retry mechanism and a degradation strategy for data acquisition. When accessing the primary data source fails, the system will attempt to obtain data from the backup data source; when all data sources are unavailable, the system will, according to the configured strategy, use the historical data cached locally or default values for degradation processing to ensure that rule execution will not be interrupted due to data acquisition failures.

[0091] When loading entity objects, according to the access permissions configured in the association rules, the system loads the obtained entity object data into the parameter hierarchical pool structure. The access permissions are mainly divided into three categories: global access permissions, rule group access permissions, and rule-specific access permissions.

[0092] For entity objects with global access permissions, the system loads them into the global parameter pool, which can be accessed by all rules. To prevent accidental modification, the system will implement access control according to the permission settings of the rules. Some rules may only have read-only permissions, while specific management rules may have read-write permissions.

[0093] For entity objects with rule group access permissions, the system loads them into the corresponding rule group parameter pool. Rules within the same rule group can share access to these entity objects, but data between different rule groups is strictly isolated to prevent cross-rule group data contamination.

[0094] For entity objects with rule-specific access permissions, the system loads them into the rule local parameter pool, which can only be accessed by the current rule. Such data is usually temporary data or intermediate results during rule execution, and its life cycle is limited to the rule execution period.

[0095] During the loading process, the system performs necessary conversions and normalization on entity objects to ensure that the data format meets the requirements for rule execution. At the same time, the system records the metadata information of entity objects, such as data source, acquisition time, version number, etc., for subsequent data consistency verification and audit tracking.

[0096] As Figure 4 shown in S4, obtain association rules. The system retrieves all rules associated with the decision set from the preset rule library according to the decision set number. Rule acquisition adopts a multi-dimensional retrieval mechanism, which not only retrieves the basic rules directly associated with the decision set, but also retrieves the derived rules and dependent rules automatically associated by the system to ensure the acquisition of a complete set of rules.

[0097] During the rule acquisition process, the system simultaneously retrieves the complete metadata of the rules, including basic attributes such as rule identifier, version number, creation time, last modification time, rule type, execution mode, timeout setting, priority, etc., as well as execution necessary information such as input parameter definition, output parameter definition, execution condition, core logic reference, etc. of the rules.

[0098] The system implements a rule version control mechanism to ensure the use of a consistent version of the rule set in the same decision-making process. When it detects inconsistent rule versions or missing rule definitions, the system will respond according to the configured error handling strategy, such as interrupting execution, using default rules, or reverting to historical versions.

[0099] Obtain rule priorities and historical execution success rates. The system obtains the priority and historical execution success rate information of each associated rule from the rule metadata table and rule execution history table in the preset rule library. The priority is usually an integer value manually configured by business analysts or rule administrators during the rule design phase, indicating the business importance and execution priority order of the rule; the historical execution success rate is a statistical value automatically calculated by the system based on the historical execution records of the rule, indicating the probability that the rule returns a true value.

[0100] The calculation of the historical execution success rate adopts a sliding window statistical method, that is, only considering the execution results in the most recent N executions or within a certain period of time recently, to ensure that the statistical value can reflect the latest execution mode of the rule. The system also considers the statistical significance of the execution samples. For rules with fewer execution times, the weight of their historical execution success rate will be reduced accordingly.

[0101] For newly created rules without execution history, the system will assign an initial estimated success rate according to the rule type and business characteristics. As the rules are continuously executed, the estimated value will gradually be replaced by the actual execution data, realizing a smooth transition from empirical values to measured values.

[0102] To sort the rules, the system first sorts all associated rules in ascending order according to their priorities, obtaining a priority sorting sequence A. The higher the priority, the more forward the position of the rule in the sequence. The sorting algorithm adopts a stable sorting strategy to ensure that rules with the same priority maintain their original relative order.

[0103] Then, the system sorts all associated rules in descending order according to their historical execution success rates, obtaining a historical execution success rate sorting sequence B. The higher the success rate, the more forward the position of the rule in the sequence. This kind of sorting is particularly valuable for the "any pass" type of decision-making mode because preferentially executing rules with high success rates can obtain decision results in advance and reduce unnecessary rule executions.

[0104] For each associated rule Pi, the system obtains its position index rankAP in the priority sorting sequence A i and its position index rankBP in the historical execution success rate sorting sequence B. i The position index starts from 0, and the smaller the value, the more forward the ranking.

[0105] The system calculates the comprehensive sorting value rankP of each rule according to the following strategy i : The basic calculation formula is: rankP i = w1 × rankAP i + w2 × rankBP i , where w1 and w2 are weight factors, reflecting the relative importance of priorities and historical success rates in sorting; the setting of the weight factors is related to the decision-making mode. For the "all pass" mode, w1 is usually larger; for the "any pass" mode, w2 is usually larger. The system also considers the average execution time of the rules and gives appropriate sorting advantages to rules with lower execution time.

[0106] After calculating the comprehensive sorting value, the system sorts all associated rules in ascending order according to rankP i to obtain the final rule execution order. This two-dimensional comprehensive sorting mechanism not only considers the importance of rules set by the business but also takes into account the efficiency optimization of rule execution, and can maximize the execution efficiency of the decision engine on the premise of ensuring business correctness.

[0107] The sorting result is associated with the global execution context and serves as an important reference basis for the subsequent rule execution stage. The system will continuously update the historical execution success rates of the rules according to the actual execution situation, enabling the sorting mechanism to be adjusted adaptively and forming a continuously optimized closed-loop system.

[0108] S5. Using the parameter hierarchical pool structure, the associated rules after sorting are sequentially executed by the rule execution engine to obtain the associated rule execution result set, including: the rule execution engine executes the associated rules layer by layer starting from the first layer according to the execution levels divided in the rule execution dependency graph. The system uses a double-loop to control the execution process: the outer loop traverses the execution levels, and the inner loop processes the rules within the current level.

[0109] For each execution level, the system determines whether to adopt a serial execution or parallel execution strategy according to the parallelism parameter configured for this level. When the parallelism parameter is greater than 1, the system enables a thread pool for parallel rule execution; when the parallelism parameter is 1, a single-threaded serial execution mode is adopted.

[0110] In the parallel execution mode, the system uses the Work Stealing algorithm to optimize the thread load balance. When a thread completes the execution of the assigned rules, it can "steal" the rules to be executed from the work queues of other threads, improving the utilization rate of computing resources. At the same time, the system implements fine-grained thread synchronization control to ensure the thread safety and data consistency of rule execution within the level.

[0111] Manage the rule memory space. For each currently executed rule, the system first dynamically applies for the memory space required for rule execution in the first allocation table of the rule parameter pool reuse area. The application process is based on the memory requirement estimation in the rule metadata or pre-allocated according to the statistical values of historical execution records.

[0112] The memory space application adopts a block allocation strategy, allocating continuous memory blocks for rule use to avoid memory fragmentation. For ultra-large rules, the system will enable a special large object allocation mechanism to directly apply for space from the system memory pool to avoid interfering with the normal rule memory allocation.

[0113] The system records the memory space information applied for by the rule in the first allocation table, including the starting address, size, allocation time, and the rule identification number of the memory block. This information forms the memory allocation mapping table, which is used as the basis for subsequent memory release. For rules that may throw exceptions, the system will also maintain a special exception handling memory tracking mechanism to ensure that the allocated memory can be correctly released even in exceptional cases.

[0114] Obtain rule parameters. The system adopts a hierarchical parameter search strategy and sequentially obtains the parameters required for rule execution from the rule local parameter pool, rule group parameter pool, and global parameter pool in the order from local to global. This inner-to-outer search order ensures the parameter priority and coverage relationship.

[0115] The parameter acquisition process uses the parameter mapping table in the rule configuration information to map the parameter names used inside the rule to the actual parameter names in each parameter pool. This indirect reference mechanism enhances the reusability of the rules, allowing the same rule logic to use different parameter names in different contexts.

[0116] The system implements a strict parameter type checking and conversion mechanism to ensure that the acquired parameters conform to the data types expected by the rules. When the parameter types do not match, the system will attempt implicit type conversion; if the conversion fails, it will be handled according to the error handling strategy configured in the rules, such as using default values, skipping rule execution, or throwing an exception.

[0117] The first step in rule execution is to execute the conditional judgment logic. Based on the calculation result of the conditional expression, it is decided whether to execute the true branch or the false branch of the rule, or to skip rule execution. The conditional expression supports multiple forms, including simple boolean expressions, compound logical expressions, script expressions, and precompiled conditional functions.

[0118] During the conditional judgment process, the system adopts a short-circuit evaluation strategy and immediately stops calculating subsequent conditions once the final result can be determined. For complex conditional expressions, the system will perform expression decomposition and optimization, caching the results of frequently used sub-expressions to avoid repeated calculations.

[0119] Branch execution adopts a dynamic scheduling mechanism. Based on the conditional judgment result, the system obtains the execution path of the corresponding branch from the rule configuration, such as method references, script paths, or rule chain references. The system supports multi-level nested branches and conditional combinations to implement complex business decision-making logic. At the same time, the system will record the branch execution path for subsequent rule execution tracking and auditing.

[0120] For the intermediate results generated during rule execution, different storage strategies are adopted according to their usage scopes. The system determines the scope and lifecycle of each intermediate result by analyzing the output parameter definitions of the rules and the input parameter dependencies of subsequent rules.

[0121] For local variables and intermediate results that are only used by the current rule, the system stores them in the rule local parameter pool and registers the variable information in the first allocation table. The lifecycle of such variables is limited to the execution cycle of the current rule, and the memory they occupy is immediately released after the rule execution is completed.

[0122] For intermediate results that need to be shared within the rule group, the system stores them in the shared parameter pool of the rule group. These results can be accessed by other rules within the same rule group to achieve data sharing within the rule group. The lifecycle of the data in the shared parameter pool is consistent with the execution cycle of the rule group and is released after all rules in the rule group have been executed.

[0123] For intermediate results that need to be passed across rule groups or execution levels, the system stores them in the global parameter pool and registers the variable information and the list of rules depending on this variable in the second allocation table. The system determines the longest life cycle of the variable by analyzing the rule execution dependency graph and releases the memory occupied by the variable only after all dependent rules have been executed.

[0124] The rule execution engine implements a multi-level memory release mechanism to ensure the efficient use and timely recycling of memory resources. The memory release process follows the principle of precise release, that is, to release unused memory resources as early as possible while ensuring data security.

[0125] When a single rule is executed, the system immediately releases the memory occupied by the temporary variables dedicated to this rule registered in the first allocation table. The release process adopts a batch release strategy, returning all memory blocks to be released to the memory pool at once to reduce the additional overhead of memory management.

[0126] When all rules at the current execution level are executed, the system traverses the second allocation table to identify intermediate result variables generated at the current level and no longer used in subsequent levels. The system analyzes the dependency relationships in the rule execution dependency graph to determine the last usage time point of each variable. Once it is confirmed that a variable is no longer used by any subsequent rules, its occupied memory is immediately released.

[0127] The system also implements a periodic garbage collection mechanism to periodically check intermediate result variables that exist for a long time and identify memory blocks that may not have been correctly released due to circular references or dependency errors. For variables that have exceeded the preset life cycle but have not been released, the system will generate an alarm message and attempt to perform forced recycling.

[0128] After each execution level is completed, the system performs synchronization and state transition between levels. The inter-level synchronization ensures that all rules at the current level have been executed and all data dependency relationships are satisfied before the execution of the next level can start. This synchronization mechanism is particularly important in the parallel execution mode to prevent data inconsistencies caused by cross-execution of rules between different levels.

[0129] The system assigns a unified result object to the execution result of each rule, which contains information such as the boolean execution result, execution status, execution time consumption, resource usage, etc. of the rule. These result objects are collected into an associated rule execution result set and arranged in the execution order of the rules.

[0130] The result collection process implements idempotency checks to ensure that the result of each rule is collected only once, and even if the rule is repeatedly executed under abnormal circumstances, it will not cause duplicate results. At the same time, the system also records the context information of rule execution, such as execution time, execution environment, input parameter values, etc., for subsequent audit tracking and problem diagnosis.

[0131] Finally, after all levels are executed, the system aggregates and cleans the execution result set of association rules, removes redundant information, and organizes it into a standardized result set format as the input for subsequent decision-making calculations.

[0132] S6. The system queries the decision set configuration table in the preset rule library according to the decision set number, and obtains the decision strategy configuration corresponding to the decision set. The decision strategy configuration includes the decision mode type and the parameter settings required for this mode. The selection mechanism of the decision strategy supports two methods: static configuration and dynamic switching. Static configuration means that when the decision set is created or updated, the rule administrator pre-sets a fixed decision strategy in advance; dynamic switching allows the system to select from multiple alternative decision strategies according to real-time conditions (such as business scenarios, user attributes, system load, etc.).

[0133] The system implements a decision strategy version control mechanism to record the change history and effective time of the decision strategy. When it is necessary to trace the historical decision results, the system can accurately restore the decision strategy used at that time according to the decision time point, ensuring the interpretability and consistency of the decision results.

[0134] The ALL_PASS mode is the strictest decision strategy, requiring that the execution results of all association rules are true for the decision result to be true. This mode is applicable to admission scenarios that require multiple conditions to be met, such as loan approval, security inspection, etc.

[0135] In terms of implementation, the system traverses each rule result in the execution result set of association rules. Once any rule result is found to be false, the decision result is immediately determined to be false without continuing to check the subsequent rule results. Only when all rule results are true is the decision result set to true.

[0136] The system implements an optimization strategy for the ALL_PASS mode, arranging the rules with relatively low historical execution success rates to be executed first, increasing the probability of obtaining a negative result in advance, and reducing unnecessary rule executions. At the same time, the system will record the rule information that causes the decision to fail for subsequent business analysis and optimization.

[0137] The ANY_PASS mode is a relatively loose decision strategy. As long as the execution result of one association rule is true, the decision result is true. This mode is applicable to qualification determination scenarios where any one of multiple conditions is met, such as marketing activity qualification, special service qualification, etc.

[0138] In terms of implementation, the system also traverses the execution result set of association rules. Once any rule result is found to be true, the decision result is immediately determined to be true without continuing to check the subsequent rule results. Only when all rule results are false is the decision result set to false.

[0139] For any optimization strategy implemented through the ANY_PASS mode, the system is contrary to the ALL_PASS mode. It ranks the rules with higher historical execution success rates at the front for execution, increasing the probability of obtaining a positive result earlier. At the same time, the system will record the rule information that leads to a successful decision for analyzing which conditional paths are more likely to be satisfied.

[0140] The THRESHOLD mode is a decision-making strategy that lies between ALL_PASS and ANY_PASS. It requires the number or proportion of rules that meet the conditions to reach a preset threshold for the decision result to be true. This mode is applicable to fault-tolerant decision-making scenarios such as multi-dimensional risk assessment and quality inspection.

[0141] In terms of implementation, the system first obtains the threshold parameters from the decision set configuration, including the threshold type (absolute number or percentage) and the threshold value. Then, the system calculates the number or proportion of rules with a true result in the associated rule execution result set and compares it with the threshold. If it reaches or exceeds the threshold, the decision result is true; otherwise, it is false.

[0142] The system has implemented a dynamic threshold adjustment mechanism for the THRESHOLD mode. Based on historical decision data and business feedback, the system can recommend the optimal threshold setting to help business personnel optimize the decision-making strategy according to the actual situation. At the same time, the system supports segmented setting of the threshold, allowing different threshold criteria to be applied under different conditions.

[0143] The WEIGHTED mode is a decision-making strategy that takes into account the differences in the importance of rules. It assigns weights to each rule and determines the final result based on the total weight of the passed rules. This mode is applicable to complex decision-making scenarios where the importance of each evaluation dimension is different, such as comprehensive scoring and multi-factor rating.

[0144] In terms of implementation, the system first obtains the weight value of each rule from the decision set configuration or rule metadata. Then, the system traverses the associated rule execution result set and calculates the total weight of the rules with a true result. Finally, it compares the total weight with the preset weight threshold to determine the final decision result.

[0145] The system has implemented a weight self-adaptive optimization mechanism. By analyzing the correlation between historical decision results and actual business effects, the system can identify the actual influence of each rule and recommend adjusting the weight assignment to make the decision result more in line with business expectations. At the same time, the system supports the time decay model of weights, making the results of the most recently executed rules have higher influence.

[0146] The EXPRESSION mode is the most flexible decision-making strategy, allowing business personnel to use logical expressions to customize the combination method of rule results. This mode is applicable to decision-making scenarios with complex logical relationships, such as multi-level conditional combinations and complex business rules.

[0147] In terms of implementation, the system first obtains predefined logical expressions from the decision set configuration. Rule identifiers are used as variables in the expressions, and complex logical relationships are constructed using logical operators (AND, OR, NOT) and parentheses. Then, the system substitutes the boolean results in the association rule execution result set into the expression and calculates the final value of the expression as the decision result.

[0148] The system implements an efficient expression parsing and evaluation engine that supports pre-compilation and caching of expressions to reduce the computational overhead at runtime. At the same time, the system provides an expression verification tool to detect syntax errors and logical problems in the expressions during the configuration phase to ensure the correctness of the expressions. The system also supports version control and change management of expressions, recording the modification history and effective conditions of the expressions for subsequent auditing and traceability.

[0149] After the decision result is calculated, the system encapsulates information such as the decision result, the executed rule set, the decision-making strategy used, and the key execution parameters into a complete decision record, which is not only returned to the calling party but also saved in the decision history library for subsequent analysis, optimization, and auditing.

Claims

1. A method for processing an execution file of a decision engine, characterized in that It includes: S1. Obtain a parameter set, where the parameter set contains a decision set number and business data; Create a global execution context according to the parameter set; S2. According to the global execution context, establish a parameter hierarchical pool structure; the parameter hierarchical pool structure includes a global parameter pool, a rule group parameter pool, and a rule parameter pool reuse area; According to the configuration information of the association rules, classify and load the data in the parameter set into the corresponding parameter pools in the parameter hierarchical pool structure according to the parameter scope; S3. Establish an entity object caching mechanism; According to the entity object caching mechanism, obtain the entity object data on which the association rules depend from the entity object data source; Load the entity object data into the parameter hierarchical pool structure according to the access rights configured by the association rules; S4. Obtain the association rules corresponding to the decision set number from a preset rule library according to the decision set number; Sort the association rules according to the priority and historical execution success rate of the association rules; S5. Use the parameter hierarchical pool structure to sequentially execute the sorted association rules through a rule execution engine to obtain an association rule execution result set; S6. Select a predefined decision strategy according to the decision set configuration corresponding to the decision set number; Use the association rule execution result set as input and calculate the decision result according to the selected decision strategy.

2. The method for processing an execution file of a decision engine according to claim 1, wherein: The global execution context is used to configure the decision mode, store intermediate results, and control the execution process; The historical execution success rate represents the proportion of the association rules that return true in historical executions; The predefined decision strategies include at least one of an all-pass mode, any-pass mode, threshold mode, weighted mode, and expression mode.

3. The method for processing an execution file of a decision engine according to claim 2, wherein: S1. Create a global execution context according to the parameter set, including: Extract the decision set number from the parameter set; Obtain the dependency relationship of the association rules according to the decision set number; Divide the association rules into multiple execution levels according to the dependency relationship, and there is no dependency relationship between the rules within each execution level, and the execution level is used to control the execution order of the association rules; Calculate the maximum number of parallel execution threads of the system according to the computing resources of the system; Set the parallelism parameter of each execution level according to the maximum number of parallel execution threads; Construct a global execution context according to the execution level and parallelism parameter.

4. The method for processing an execution file of a decision engine according to claim 2, wherein: S2. Classify and load the data in the parameter set into the corresponding parameter pools in the parameter hierarchical pool structure, including: Initialize the parameter pool object set and pre-create a certain number of parameter pool instances according to the execution level information in the global execution context and the system historical load situation; Create a global parameter pool, a rule group parameter pool, and a rule parameter pool reuse area in the parameter pool object set, and establish a hierarchical pool structure; According to the decision set number, obtain the corresponding rule group division configuration and rule inter-dependency relationship configuration from a preset rule library, and construct a rule execution dependency graph; Associate the global parameter pool with the global execution context according to the rule execution dependency graph; According to the rule group division configuration, create identifiers for each rule group, and classify rules with the same identifier into the same rule group; For rule groups that are independent of each other and will not be executed in parallel, create a shared parameter pool independent of the global parameter pool and the rule group parameter pool; Set a first allocation table and a second allocation table in the rule parameter pool reuse area. Among them, the first allocation table is used to record the variable addresses and sizes created during the execution of a single rule, and the memory occupied by the variables is uniformly released after the rule execution is completed; the second allocation table records the addresses, sizes, and access rule lists of the intermediate result variables passed between consecutive multiple rules, and the corresponding memory is released only when all dependent rules are executed; According to the parameter scopes in the associated rule configuration information, classify and load the business data in the parameter set into the corresponding parameter pools. Among them, the parameters with the global scope are loaded into the global parameter pool, and the parameters with the rule group scope are loaded into the corresponding associated rule group parameter pool.

5. The method for processing the execution file of the decision engine according to claim 4, wherein: The shared parameter pool is used for the temporary data shared between the rules within the same rule group. By establishing a mapping relationship between the rule group identifier and the shared parameter pool instance in the global execution context, the shared parameter pool of the associated rule group is associated with the corresponding execution level of the global execution context.

6. The method for processing the execution file of the decision engine according to claim 4, wherein: Construct a rule execution dependency graph, including: Through the joint query mechanism, respectively obtain the rule metadata and the dependency relationship configuration from the preset rule library according to the decision set number; Extract the rule identifiers of the rule metadata; Construct a rule identifier dictionary according to the rule metadata, and establish a mapping relationship between the rule identifier and the rule metadata using the hash table structure; According to the mapping relationship and the dependency relationship configuration, construct a directed acyclic graph as the initial rule execution dependency graph; where the nodes of the graph represent rules, and the edges represent the dependency relationships between rules; Use the topological sorting algorithm to perform hierarchical division on the initial rule execution dependency graph, determine the execution order of the rules, and obtain the final rule execution dependency graph.

7. The method for processing the execution file of the decision engine according to claim 6, wherein: The dependency relationship configuration represents the pre-execution conditions, input / output parameter dependencies, and trigger conditions between rules.

8. The method for processing the execution file of the decision engine according to any one of claims 2 to 7, wherein: S4, obtain the associated rules corresponding to the decision set number from the preset rule library according to the decision set number; Sort the associated rules according to the priorities and historical execution success rates of the associated rules, including: Obtain the priorities and historical execution success rates of each associated rule from the preset rule library; Sort all the associated rules in ascending order according to the priorities to obtain the priority sorting sequence A; Sort all the associated rules in descending order according to the historical execution success rates to obtain the historical execution success rate sorting sequence B; Obtain each association rule P in sequence A i 's position index rankAP i , and obtain the association rule P i 's position index rankBP in sequence B i ; According to the position index rankAP i and the position index rankBP i , calculate the comprehensive sorting value rankP of each association rule i ; According to the comprehensive sorting value rankP i Ascendingly sort all association rules to obtain the sorted association rules.

9. The method for processing the execution file of the decision engine according to claim 4, wherein: S5. Using the parameter hierarchical pool structure, sequentially execute the sorted association rules through the rule execution engine to obtain an association rule execution result set, including: For each rule in the current execution level: Dynamically apply for the memory space required to execute the current rule in the first allocation table of the rule parameter pool reuse area to store rule local variables; Obtain the parameters required for the execution of the current rule from the rule local parameter pool, rule group parameter pool, and global parameter pool according to the configuration information of the association rule; Execute the conditional judgment logic of the current association rule, and select to execute the true branch or false branch of the association rule according to whether the condition is met; During the execution of the association rule branch, store the intermediate result in the rule parameter pool reuse area or the shared parameter pool of the rule group; If the intermediate result is only used by the current rule, register the variable information in the first allocation table and release it uniformly after the execution of the current rule is completed; If the intermediate result needs to be passed between multiple association rules, register the variable information in the second allocation table and register other association rules that depend on this variable, and release the memory occupied by the variable only after all dependent rules are executed; After the execution of the current association rule is completed, store the boolean execution result of the rule in the association rule execution result set; Release all temporary variables generated during the execution of the current rule registered in the first allocation table; After all association rules in the current level are executed, traverse the second allocation table and release the memory occupied by the intermediate result variables generated in the current level and no longer used in the subsequent levels; After completing the current execution level, if there are subsequent execution levels, jump to the next level and continue to execute until the last level is executed; Finally, output the complete association rule execution result set.

10. An execution file processing system for a decision engine, characterized in that it includes: At least one processing unit; configured to execute instructions to implement the execution file processing method of the decision engine according to any one of claims 1 to 9.

Images