A method and system for processing execution files of a decision engine

Abstract

The application discloses an execution file processing method and system of a decision engine, and relates to the field of information technology, which comprises the following steps: obtaining a parameter set; creating a global execution context according to the parameter set; establishing a parameter hierarchical pool structure according to the global execution context; loading entity object data into the parameter hierarchical pool structure according to the access authority configured according to the association rule; obtaining the association rule corresponding to the decision set number from a preset rule library according to the decision set number; sorting the association rule according to the priority of the association rule and the historical execution success rate; obtaining an association rule execution result set by sequentially executing the sorted association rule through a rule execution engine by using the parameter hierarchical pool structure; selecting a predefined decision strategy; and calculating a decision result according to the selected decision strategy by taking the association rule execution result set as input. The application can improve the execution efficiency in view of the low rule execution efficiency in the prior art.

Description

Technical Field

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

[0002] Decision engines are core components of modern information systems, widely used in fields such as financial risk management, insurance underwriting, intelligent manufacturing, e-commerce, and smart healthcare. As the core platform for business rule management and execution, decision engines abstract and encapsulate complex business logic in the form of rules, decoupling business logic from applications and improving system flexibility and maintainability. With the rapid development of big data and artificial intelligence technologies, decision engines face increasingly complex rule sets, higher execution efficiency requirements, and more diverse decision strategies.

[0003] The basic operating principle of a decision engine is to receive business data as input, match and execute rules according to a pre-set set of rules, and ultimately produce a decision result. A typical decision engine typically includes core modules such as rule management, rule compilation, rule execution, data management, and decision strategies. The efficiency of rule execution directly impacts the overall performance of the decision engine. This is particularly true in business scenarios requiring real-time decision-making, such as credit card fraud detection and online loan approval. Rule execution efficiency has a decisive impact on business response time and user experience.

[0004] Existing decision engines generally employ simple memory management strategies, such as global uniform allocation or fixed-size memory blocks, lacking refined memory management mechanisms tailored to the specific characteristics of rule execution. During rule execution, the memory space for temporary variables and intermediate results is often not released promptly, leading to wasted memory resources and even memory leaks after long runs. This inefficient memory usage is particularly prominent for large rule sets, directly impacting system stability and scalability.

[0005] For example, the related patent document CN112907234B discloses a decision engine implementation method based on dynamic configuration rules. The present invention aims to solve the problem of instant adjustment of verification rules in business processes without the need for code revisions. The main solution includes obtaining the dependent parameters of the association rule based on the input parameters of the core logic of the execution rule and initializing them into a parameter pool. The entity object data on which the association rule depends is obtained from the entity object referenced by the configuration rule and initialized into the entity object data pool. According to the rule number of the association rule, the values ​​of the entity object data pool and parameter pool are assigned to the core execution logic of the configuration rule, the rule is executed, and the rule execution result is obtained. All rule execution results form a decision set. If one rule execution result is false, the final decision result is false; otherwise, the final decision result is true. However, all parameters of this solution are mixed in a single parameter pool, which has a high risk of overlapping parameters between rules. In addition, this solution cannot distinguish between global parameters and rule-local parameters. Even temporary variables used by a single rule will occupy memory resources of the entire decision process. Therefore, the execution efficiency of this solution needs to be further improved. Summary of the Invention

[0006] In response to the low efficiency of rule execution in the existing technology, the present application provides an execution file processing method and system for a decision engine, which realizes the precise allocation and release of memory resources, priority sorting and parallel execution of rules, etc. by constructing a parameter hierarchical pool structure and a rule execution dependency graph strategy, thereby improving execution efficiency.

[0007] The purpose of this application is achieved through the following technical solutions.

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

[0009] Furthermore, 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 association rules that return true in historical executions; the predefined decision strategy includes at least one of the all-pass mode, any-pass mode, threshold mode, weighted mode and expression mode.

[0010] Furthermore, S1 creates a global execution context based on the parameter set, including: extracting the decision set number from the parameter set; obtaining the dependency of the association rules based on the decision set number; dividing the association rules into multiple execution levels based on the dependency, and there is no dependency between the rules in 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 based on the computing resources of the system; setting the parallelism parameter of each execution level based on the maximum number of parallel execution threads; and constructing the global execution context based on the execution level and the parallelism parameter.

[0011] Traditional creation of a global execution context uses a single-threaded serial processing mode and lacks effective management of rule dependencies, resulting in low efficiency. This is especially prominent in large-scale rule set scenarios and cannot meet high-concurrency business needs.

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

[0013] Furthermore, S2 establishes a parameter hierarchical pool structure according to the global execution context; according to the configuration information of the association rule, the data in the parameter set is loaded into the corresponding parameter pool in the parameter hierarchical pool structure according to the parameter scope classification, including: according to the execution level information and the historical load of the system in the global execution context, the parameter pool object set is initialized, a certain number of parameter pool instances are pre-created, and a hierarchical pool structure is established; according to the decision set number, the corresponding rule group division configuration and the rule dependency configuration are obtained from the preset rule library, and a rule execution dependency graph is constructed; according to the rule execution dependency graph, the global parameter pool is associated with the global execution context; according to the rule group division configuration, an identifier is created for each rule group, and rules with the same identifier are classified into the same rule group; For rule groups that are independent and will not be executed in parallel, a shared parameter pool independent of the global parameter pool and the rule group parameter pool is created; a first allocation table and a second allocation table are set in the rule parameter pool reuse area, wherein the first allocation table is used to record the address and size of variables 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 address, size and access rule list of intermediate result variables passed between multiple consecutive rules, and the corresponding memory is released only after all dependent rules are executed; according to the parameter scope in the association rule configuration information, the business data in the parameter set are classified and loaded into the corresponding parameter pool, wherein the parameters of the global scope are loaded into the global parameter pool, and the parameters of the rule group scope are loaded into the corresponding association rule group parameter pool.

[0014] Traditional decision-making engine systems, when handling large-scale, complex rule execution, suffer from flaws such as poor memory management, rigid parameter sharing mechanisms, and inefficient data transfer between rules. These flaws often lead to wasted system resources, memory leaks, and inefficient rule execution. Particularly in high-concurrency scenarios, the lack of a memory allocation strategy tailored to the specific characteristics of rule execution leads to severe performance bottlenecks caused by frequent memory allocation and release operations, making it 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, based on the execution level information and historical load conditions, a parameter pool instance is pre-created, and a hierarchical structure of a global parameter pool, a rule group parameter pool, and a 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, memory resource utilization is optimized; the first allocation table and the second allocation table are set to manage the single rule life cycle and the variable memory transferred across rules respectively, achieving accurate memory allocation and timely recovery; at the same time, the business data is classified and loaded into the corresponding parameter pool according to the parameter scope, which improves data access efficiency and overall system performance.

[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 between rules in the same rule group, and 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, the corresponding rule group division configuration and the dependency configuration between rules are obtained from the preset rule library to construct a rule execution dependency graph, including: through a joint query mechanism, respectively obtaining the rule metadata and dependency configuration from the preset rule library according to the decision set number; extracting the rule identifier of the rule metadata; constructing a rule identifier dictionary according to the rule metadata, and using a hash table structure to establish a mapping relationship between the rule identifier and the rule metadata; constructing a directed acyclic graph as the initial rule execution dependency graph according to the mapping relationship and the dependency configuration; wherein the nodes of the graph represent the rules, and the edges represent the dependencies between the rules; using a topological sorting algorithm to hierarchically divide the initial rule execution dependency graph, determine the execution order of the rules, and obtain the final rule execution dependency graph.

[0018] Traditional directed acyclic graphs for constructing rule execution dependency graphs have defects such as multiple database accesses, inefficient mapping of rule metadata and dependencies, and slow determination of rule execution order. This application solves the performance bottleneck problem under large-scale rule sets by combining a joint query mechanism with a hash table mapping structure. At the same time, it optimizes the efficiency of parallel rule execution through hierarchical division of topological sorting, significantly improving the decision set execution performance and resource utilization.

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

[0020] Further, S4, according to the decision set number, obtains the association rule corresponding to the decision set number from the preset rule library; according to the priority and historical execution success rate of the association rule, sorts the association rules, including: obtaining the priority and historical execution success rate of each association rule from the preset rule library; sorting all the association rules in ascending order according to the priority to obtain a priority sorting sequence A; sorting all the association rules in descending order according to the historical execution success rate to obtain a historical execution success rate sorting sequence B; obtaining each association rule P in sequence A i Position index rankAP i , and obtain the association rule P i Position index rankBP in sequence B i ; According to the position index rankAP i and position index rankBP i, calculate the comprehensive ranking value rankP of each association rule i ; According to the comprehensive ranking value rankP i Sort all association rules in ascending order to obtain sorted association rules.

[0021] Furthermore, S5 utilizes the parameter hierarchical pool structure and executes the sorted association rules in sequence through the rule execution engine to obtain an association rule execution result set, including: for each rule in the current execution level, dynamically applying for the memory space required for executing the current rule in the first allocation table of the rule parameter pool reuse area to store the rule local variables; obtaining the parameters required for the current rule execution from the rule local parameter pool, the rule group parameter pool and the global parameter pool according to the configuration information of the association rule; executing the condition judgment logic of the current association rule, and selecting the true branch or false branch of the association rule to execute according to whether the condition is met; in the process of executing the association rule branch, storing 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, registering the variable information in the first allocation table. After the current rule is executed, all the temporary variables are released. If the intermediate result needs to be transferred between multiple association rules, the variable information is registered in the second allocation table, and other association rules that depend on this variable are registered. The memory occupied by the variable is not released until all dependent rules are executed. After the current association rule is executed, the Boolean execution result of the rule is stored in the association rule execution result set. All temporary variables generated during the execution of the current rule registered in the first allocation table are released. After all association rules in the current level are executed, the second allocation table is traversed to release the memory occupied by the intermediate result variables generated in the current level that are no longer used in subsequent levels. After completing the current execution level, if there is a subsequent execution level, jump to the next level to continue execution until the last level is executed. Finally, the complete association rule execution result set is output.

[0022] Traditional rule execution engines, first, use a global variable pool to uniformly manage all rule variables, lack an effective memory isolation mechanism, and thus cause data contamination between rules. Second, they rely on a general garbage collection mechanism to process intermediate results. The timing of memory release is uncertain, which may cause memory leaks and premature release, leading to data access errors. Third, there is a lack of precise tracking of data dependencies between rules, making it impossible to optimize memory resource allocation based on actual usage, resulting in obvious performance bottlenecks and memory pressure when executing large-scale rule sets.

[0023] The present application achieves precise memory lifecycle control through a two-layer memory management architecture of the first allocation table and the second allocation table, fundamentally solving the above-mentioned technical defects. The first allocation table focuses on memory management within a single rule, and by accurately recording the address, size and lifecycle of the rule's local variables, it realizes immediate release after the rule execution is completed, eliminating the possibility of memory leaks. The second allocation table accurately tracks the last use time point of each intermediate result variable by explicitly recording the dependencies of shared variables between multiple rules, ensuring that the variables will neither be released too early to cause data loss, nor occupy memory for a long time to cause resource waste. On the one hand, the present application eliminates the uncertainty of the traditional garbage collection mechanism, making the system execution performance more stable and predictable; on the other hand, by reducing memory allocation and recovery operations, it reduces CPU resource consumption, especially in high-concurrency scenarios.

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

[0025] Compared with the existing technology, the advantages of this application are:

[0026] In response to the technical defects of the existing technology, 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 constructs a three-level hierarchical parameter pool structure consisting of a global parameter pool, a rule group parameter pool, and a rule parameter pool reuse area, thereby achieving refined control of data access rights and avoiding data pollution during rule execution. At the same time, it provides a rule group parameter pool and a global parameter pool mechanism in scenarios where data sharing is required, balancing data isolation and sharing requirements. This design is based on the principle of data classification loading based on parameter scopes, accurately divides data into different scopes according to the configuration information of the rules, and achieves precise control of data access through a hierarchical access control mechanism between parameter pools. It optimizes the memory call path based on the parameter access mode, fundamentally solving the technical bottleneck of traditional decision engines in data management.

[0027] In response to the problems of memory leaks caused by untimely release of temporary variables and premature release or non-release of intermediate result variables in decision engines in the prior art, this application innovatively designs a dual-table memory precision management mechanism based on a first allocation table and a second allocation table, wherein the first allocation table records the 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 the intermediate result variables shared by multiple rules and releases them only after all dependent rules have been executed, thus avoiding errors caused by memory leaks and premature release. This dual-table mechanism achieves precise allocation and release of memory resources by accurately tracking and recording the variable life cycle, combined with the rule execution order information in the rule execution dependency graph, significantly reducing memory fragmentation and optimizing memory resource utilization efficiency. It is particularly suitable for large-scale rule sets and long-running decision engine scenarios.

[0028] In response to the problem of low decision-making efficiency caused by the fixed and unoptimizable order of rule execution in the prior art, this application adopts a directed acyclic graph mathematical model to represent the complex dependency relationships between rules, and combines it with a topological sorting algorithm for hierarchical division, automatically identifying and correctly processing the pre-execution conditions, input and output parameter dependencies and trigger conditions between rules. The hierarchical division based on the dependency graph ensures the correct order of rule execution, and at the same time, optimizes the execution order of the rules without violating the dependency relationship, 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 circular 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 ensures the correctness and consistency of the rule execution results. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The present application will be further described in the form of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting, and in these embodiments, the same numbers represent the same structures, wherein:

[0030] Figure 1 is an exemplary flow chart of an execution file processing method of 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 flow chart of constructing a rule execution dependency graph according to some embodiments of the present application;

[0033] Figure 4 This is an exemplary flowchart of sorting association rules according to some embodiments of the present application. DETAILED DESCRIPTION

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

[0035] like Figure 1 As shown, a method for processing an execution file of a decision engine includes: obtaining a parameter set, the parameter set including a decision set number and business data; creating a global execution context based on the parameter set; establishing a parameter hierarchical pool structure based on the global execution context; the parameter hierarchical pool structure including a global parameter pool, a rule group parameter pool, and a rule parameter pool reuse area; loading the data in the parameter set into the corresponding parameter pool in the parameter hierarchical pool structure according to parameter scope classification based on the configuration information of the association rule; establishing an entity object caching mechanism; obtaining entity object data on which the association rule depends from the entity object data source based on the entity object caching mechanism; loading the entity object data into the parameter hierarchical pool structure according to the access rights configured for the association rule; obtaining the association rule corresponding to the decision set number from a preset rule library based on the decision set number; sorting the association rules based on the priority and historical execution success rate of the association rules; using the parameter hierarchical pool structure, sequentially executing the sorted association rules through the rule execution engine to obtain an association rule execution result set; selecting a predefined decision strategy based on the decision set configuration corresponding to the decision set number; using the association rule execution result set as input, and calculating the decision result based on the selected decision strategy.

[0036] like Figure 2 As shown in S1, the decision engine receives parameter sets from external systems through various access methods (such as REST API, RPC calls, or message queues). The parameter set acquisition process 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] A parameter set primarily contains two core pieces of information: a decision set number, which uniquely identifies which set of rules to execute; and business data, which represents the various business parameters required for rule execution. Furthermore, a parameter set may also contain metadata, such as the call source identifier, timeout settings, and priority levels.

[0038] After receiving the parameter set, the system performs necessary validation to ensure the decision set number exists and is formatted correctly, and that the business data structure meets expectations, thus preventing system errors caused by illegal parameters. Once validation is successful, the parameter set is converted to an internal standard format for subsequent processing.

[0039] The global execution context is the core control component throughout the entire decision engine execution process, responsible for managing various resources and states throughout the execution lifecycle. Its creation process begins by generating a unique context identifier, recording a creation timestamp, and associating the decision set number in the parameter set with the context.

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

[0041] During the creation process, the system initializes the global parameter pool based on the business data in the parameter set, preparing for subsequent rule execution. The system also sets the decision mode (e.g., all pass, any pass, threshold mode, etc.) based on the configuration information or the parameters specified in the parameter set. Once the global execution context is created, its status is marked as "Initialization Completed," awaiting subsequent execution.

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

[0043] The extracted decision set ID is used to query the decision engine's rule base to confirm whether the decision set exists and is valid. The system also checks whether the current user or caller has permission to execute the decision set. If the decision set does not exist, is invalid, or has no access permission, the system throws an appropriate exception and terminates the execution process.

[0044] After the decision set number is successfully verified, the system will load the basic information of the decision set from the rule base, such as decision strategy, timeout setting, priority configuration, etc. This information will be used for subsequent execution context configuration.

[0045] Based on the verified decision set number, the system queries the rule base for all rule definitions associated with the decision set. A rule definition contains basic rule information (such as rule identifier, name, description), execution conditions, input parameters, output parameters, execution priority, etc.

[0046] Obtaining rule dependencies is a key step in building a rule execution dependency graph. The system identifies various dependencies between rules by analyzing the list of prerequisite rules, input parameter dependencies, and trigger conditions in the rule definition. Dependencies primarily fall into three categories: prerequisite execution dependencies (rule A must execute before rule B), parameter dependencies (rule B's input depends on rule A's output), and trigger dependencies (rule A's execution result affects whether rule B executes).

[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 circular dependencies. If a circular dependency is found, the system handles it according to the configured policy (interrupting execution or breaking the loop), ensuring that the resulting 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, the level where rule B is located must be earlier than the level where rule A is located.

[0049] Specifically, the system first identifies "source" nodes in the dependency graph (nodes without incoming edges, i.e., rules that do not depend on other rules) and assigns them to the first execution level. It then removes these nodes and their associated edges, identifies new "source" nodes, and assigns them to the second execution level, and so on, until all rules are assigned to the corresponding execution levels.

[0050] Once the execution layers are divided, the system assigns a unique identifier to each layer and establishes a mapping between rules and layers, making it easier to quickly locate the layer to which a rule belongs during subsequent execution. The system also records the number of rules in each layer as a reference for setting parallelism parameters.

[0051] To fully utilize system resources without causing excessive contention, the system needs to calculate an appropriate maximum number of parallel execution threads. This calculation takes into account multiple factors: First, the system obtains the number of available processor cores on the server as a baseline for parallelism. Then, the number of processor cores is adjusted appropriately, taking into account the configured thread pool size limit and the current system load. The system also analyzes the relationship between optimal parallelism and performance based on historical execution data to determine the optimal parallelism setting.

[0052] In addition, the system will consider the characteristics of the decision set (such as rule complexity, I / O intensity, or computation intensity) and business requirements (such as response time requirements) to further optimize the number of parallel threads. Finally, the system will apply the configured minimum and maximum thread limits to ensure that the calculation results are within a reasonable range.

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

[0054] The system first considers the number of rules at each level. For levels where the number of rules is less than or equal to the maximum number of parallel threads, its 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, its parallelism is set equal to the maximum number of parallel threads.

[0055] The system then adjusts based on the characteristics of the rules. For layers with more compute-intensive rules, the system will appropriately reduce parallelism to avoid CPU resource competition; for layers with more I / O-intensive rules, the system may appropriately increase parallelism to cover I / O wait times.

[0056] The system also considers data locality between rules and may assign rules that share the same data to the same execution batch to improve cache utilization. Finally, the system ensures that the sum of the parallelism parameters at all levels does not exceed the system's maximum number of parallel execution threads.

[0057] Based on the execution levels and parallelism parameters obtained in the previous steps, the system completes the construction of a global execution context. During this construction process, the system associates the list of execution levels and the parallelism parameters for each level with the context. It also creates corresponding execution control structures for each execution level, such as a level execution status monitor and an inter-level synchronization controller.

[0058] The system also initializes memory resource management structures based on rule dependencies, including the first and second allocation tables. The first allocation table manages temporary variables during the execution of a single rule, while the second allocation table manages intermediate result variables shared by multiple rules. These two allocation tables are closely linked to the rule execution hierarchy to ensure accurate allocation and release of memory resources.

[0059] During the final phase of building the global execution context, the system initializes various monitoring and statistics components to collect performance data, resource usage, and exception information about rule execution. This data is used for subsequent execution optimization and problem diagnosis.

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

[0061] like Figure 3As shown in Figure 2, S2 establishes a hierarchical parameter pool structure based on the global execution context. The decision engine's hierarchical parameter pool structure is a multi-level parameter management mechanism used to achieve refined control of data access permissions and efficient management of memory resources. This structure mainly consists of three levels: the global parameter pool, the rule group parameter pool, and the rule-local parameter pool.

[0062] Establishing a hierarchical parameter pool structure first requires analyzing the rule hierarchy and execution order based on the execution hierarchy information in the global execution context. The system then combines historical execution data with load data to predict the likely parameter access patterns and memory usage during this execution, and uses this information to determine the number and capacity of the initial parameter pool.

[0063] The system uses object pooling technology to pre-create a certain number of parameter pool instances, avoiding the performance overhead and memory fragmentation caused by frequent object creation during execution. Pre-created parameter pool instances are organized into pooled resources, ready to be allocated to rule groups or individual rules as needed. The number of pre-created instances is dynamically adjusted based on the system's historical load, avoiding resource waste while ensuring sufficient parameter pools are available during peak loads.

[0064] When establishing a hierarchical parameter pool structure, the system first creates a global parameter pool as the top-level data sharing space. Next, a rule group parameter pool is created for each rule group. Finally, a set of reusable rule local parameter pools is pre-allocated in the rule parameter pool reuse area for temporary data storage during rule execution. Strict access control rules are established between the three layers of parameter pools to ensure data isolation and security.

[0065] Build a rule execution dependency graph. The rule execution dependency graph is the core data structure used by the decision engine to control the order of rule execution and manage the dependencies between rules. The construction process first requires obtaining relevant configuration information from the preset rule library.

[0066] The system uses a joint query mechanism to simultaneously retrieve multiple related data tables based on decision set numbers, including rule metadata, rule group configuration, and rule dependency tables. Rule metadata contains basic rule attribute information, such as the rule identifier, name, description, creation time, and version number. Dependency configuration includes pre-conditions, input and output parameter dependencies, and trigger conditions between rules. This information is the foundational data for building the dependency graph.

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

[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 dependencies between rules, with edges pointing from dependent rules to dependent rules. The system uses either an adjacency list or an adjacency matrix to represent this directed graph structure, choosing the appropriate representation method based on the number of rules and the density of dependencies.

[0069] The initial graph structure may contain circular dependencies. The system identifies these dependencies using a depth-first search or a dedicated cycle detection algorithm. If a circular dependency is found, the system handles it according to the configured policy: either aborting execution and reporting an error, or automatically breaking the loop based on rule priority or other policies. The resulting graph structure is guaranteed to be a directed acyclic graph.

[0070] The system uses a topological sorting algorithm to hierarchically partition directed acyclic graphs. Specifically, it first identifies nodes with zero in-degree (i.e., rules that do not depend on other rules) and assigns them to the first execution level. These nodes and their associated edges are then removed from the graph, and new nodes with zero in-degree are identified and assigned to the second execution level. This continues until all nodes have been assigned to the appropriate execution level. This hierarchical partitioning ensures that all dependent rules of any given rule have already been executed.

[0071] Associating the parameter pool with the execution context: Associating the parameter pool with 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. 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 shared globally.

[0072] The system divides the configuration into previously acquired rule groups and creates a unique identifier for each rule group. This identifier is generated using a specific prefix followed by a serial number or a UUID to ensure uniqueness across the entire system. Rules with the same identifier are grouped together, typically sharing common business significance or data access requirements.

[0073] For independent rule groups that don't execute in parallel, the system creates separate shared parameter pools. These shared parameter pools are independent of the global and rule group parameter pools and are used specifically for temporary data shared between 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 between rule group identifiers and shared parameter pool instances within the global execution context, typically using a hash map data structure. This mapping enables the system to quickly locate the corresponding shared parameter pool based on the rule group to which the current rule belongs during rule execution, enabling efficient data access. The system also associates the shared parameter pool with the corresponding execution level within the global execution context, ensuring proper management of parameter pool resources after the level's execution completes.

[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 decision engine's precise memory management mechanism.

[0076] The first allocation table manages temporary variables created during the execution of a single rule. It records information such as the variable's memory address, size, creation time, and the rule identifier to which it belongs. When a rule completes execution, the system releases the memory occupied by all temporary variables created by that rule based on the records in the first allocation table, preventing memory leaks. This timely release mechanism significantly reduces system memory usage, especially when processing a large number of rules.

[0077] The second allocation table manages intermediate result variables passed between consecutive rules. This table not only records the variable's memory address and size, but also the list of rules accessing the variable. The system determines when it is safe to release intermediate result variables based on the rule execution order derived from the rule execution dependency graph. The system releases the corresponding memory resources only after all rules that depend on the variable have completed execution. This precise memory release strategy avoids the uncertainty of traditional garbage collection mechanisms and improves the system's memory efficiency.

[0078] The two allocation tables are implemented using efficient data structures, such as hash tables or balanced trees, to support fast lookup, insertion, and deletion operations. The system regularly compresses and optimizes the allocation tables to reduce the memory resources they occupy. In highly concurrent environments, the system employs techniques such as segmented locking or lock-free algorithms to ensure thread-safe allocation table operations while minimizing the performance overhead caused by lock contention.

[0079] Classified loading of business data: Business data in a parameter set needs to be classified and loaded into different parameter pools based on its scope and usage characteristics. The system first analyzes the configuration information of the association rule to identify the scope attributes of each parameter.

[0080] Parameters marked as globally scoped are loaded directly into the global parameter pool. These parameters typically include basic user information, transaction data, and system environment parameters, and are accessed by multiple rule groups or nearly all rules. Data in the global parameter pool is visible to all rules, but the system controls read and write permissions based on configured access control rules to prevent accidental modifications.

[0081] Parameters marked as rule group-scoped are loaded into the corresponding rule group parameter pool. These parameters are typically shared data within a specific business domain, such as risk indicators for risk control rule groups or user preference data for marketing rule groups. Data in the rule group parameter pool is visible only to rules within the same rule group, effectively isolating data from different business domains.

[0082] During data loading, the system performs data type checks and format validation to ensure 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, and numerical unit conversion, reducing the data processing burden during rule execution.

[0083] To improve data loading efficiency, the system employs lazy loading and partial loading strategies, loading data on demand based on the order of rule execution and parameter dependencies. For large datasets that may not be used, the system only loads them when they are truly needed, avoiding unnecessary memory usage and processing overhead.

[0084] After data loading is complete, the system records statistical information for each parameter pool, such as the number of parameters, memory usage, and access frequency, as a basis for subsequent performance optimization and resource adjustments. The entire data loading process is designed to be efficient and flexible, adapting to the data processing needs of businesses of varying scale and complexity.

[0085] S3 establishes an entity object caching mechanism. The decision engine's entity object caching mechanism uses a multi-level caching architecture, consisting of 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 large-scale entity object data across nodes; and the persistent storage, as the ultimate source of data, ensures data persistence and consistency.

[0086] The cache architecture design adopts a read-write separation strategy, optimized for businesses with high reads and low writes. The system uses an asynchronous update mechanism to maintain cache consistency. When entity objects change in the source system, a change event notification mechanism triggers a cache update, ensuring timely updates and consistency of cached data.

[0087] The system develops differentiated caching strategies for different types of entity objects based on their access frequency, data size, and real-time requirements. For frequently accessed but infrequently modified entity objects, a long-lifecycle caching strategy is used; for entities with high real-time requirements, a short-lifecycle or no-caching strategy is used.

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

[0089] The data acquisition process utilizes an intelligent batch processing mechanism. The system pre-analyzes the data requirements of rules based on the rule execution dependency graph and consolidates multiple rule requests for the same type of entity objects into batch queries, reducing the number of interactions with the data source. For cross-data source correlation queries, the system employs a data concatenation strategy, first acquiring basic data from each source and then completing data association at the application layer.

[0090] The system implements a retry mechanism and fallback strategy for data acquisition failures. When access to the primary data source fails, the system attempts to obtain data from a backup source. When all data sources are unavailable, the system falls back to locally cached historical data or default values ​​based on the configured strategy, ensuring that rule execution is not interrupted by data acquisition failures.

[0091] Loading entity objects. Based on the access permissions configured by the association rules, the system loads the acquired entity object data into the parameter hierarchical pool structure. 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, making them accessible to all rules. To prevent accidental modifications, the system implements access control based on the rule's permission settings. Some rules may have read-only permissions, while specific management rules may have read and 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 rights, the system loads them into the rule's local parameter pool, accessible only to the current rule. This type of data is typically temporary data or intermediate results during rule execution, and its lifecycle 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 complies with the requirements of rule execution. At the same time, the system records metadata information about the entity objects, such as data source, acquisition time, and version number, for subsequent data consistency verification and audit tracking.

[0096] like Figure 4 As shown in S4, association rules are obtained. The system retrieves all rules associated with the decision set from the preset rule base based on the decision set number. Rule acquisition uses a multi-dimensional retrieval mechanism, retrieving not only the base rules directly associated with the decision set, but also the derived rules and dependent rules automatically associated by the system, ensuring that a complete set of rules is obtained.

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

[0098] The system implements a rule versioning mechanism to ensure consistent rule sets are used within the same decision-making process. When inconsistent rule versions or missing rule definitions are detected, the system responds based on configured error handling strategies, such as aborting execution, using default rules, or rolling back to a previous version.

[0099] To obtain rule priority and historical execution success rate, the system retrieves the priority and historical execution success rate information for each associated rule from the rule metadata table and rule execution history table in the preset rule library. Priority is typically an integer value manually configured by business analysts or rule administrators during the rule design phase, representing the business importance and execution priority 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 will return a true value.

[0100] The historical execution success rate is calculated using a sliding window statistical method, which only considers the results of the most recent N executions or the most recent period of time, ensuring that the statistical value reflects the most recent execution pattern of the rule. The system also considers the statistical significance of the execution samples, and the weight of the historical execution success rate of rules with fewer executions is reduced accordingly.

[0101] For newly created rules with no execution history, the system assigns an initial estimated success rate based on the rule type and business characteristics. As the rule executes, the estimated value is gradually replaced by actual execution data, achieving a smooth transition from empirical value to measured value.

[0102] To sort the rules, the system first sorts all association rules in ascending order based on priority, resulting in a priority sequence A. The higher the priority, the higher the rule's position in the sequence. The sorting algorithm uses a stable sorting strategy to ensure that rules with the same priority maintain their original relative order.

[0103] The system then sorts all association rules in descending order based on their historical execution success rates, generating a historical execution success rate sorting sequence B. Rules with higher success rates are ranked higher in the sequence. This sorting approach is particularly valuable for "any-pass" decision-making models, as prioritizing rules with higher success rates allows for earlier decision results and reduces unnecessary rule execution.

[0104] For each association rule Pi, the system obtains its position index rankAP in the priority sorting sequence A i and the 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 higher the ranking.

[0105] The system calculates the comprehensive ranking 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 priority and historical success rate in sorting; the setting of 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 ranking value, the system will calculate the ranking value according to rankP i All association rules are sorted in ascending order 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. It can maximize the execution efficiency of the decision engine while ensuring business correctness.

[0107] The ranking results are associated with the global execution context, serving as an important reference for subsequent rule execution. The system continuously updates the historical success rate of rule execution based on actual execution, enabling the ranking mechanism to adaptively adjust and form a continuously optimizing closed-loop system.

[0108] S5, using the parameter hierarchical pool structure, executes the sorted association rules sequentially through the rule execution engine to obtain the association rule execution result set. This includes: the rule execution engine executes the association rules layer by layer according to the execution hierarchy divided in the rule execution dependency graph, starting from the first level. The system uses a dual loop to control the execution process: an outer loop traverses the execution hierarchy, and an inner loop processes the rules within the current level.

[0109] For each execution level, the system determines whether to use serial or parallel execution based on the parallelism parameter configured for that level. When the parallelism parameter is greater than 1, the system uses a thread pool for parallel rule execution; when the parallelism parameter is 1, single-thread serial execution is used.

[0110] In parallel execution mode, the system uses a work-stealing algorithm to optimize thread load balancing. When a thread completes executing its assigned rules, it can "steal" pending rules from the work queues of other threads, improving computing resource utilization. Simultaneously, the system implements sophisticated thread synchronization control to ensure thread-safety and data consistency within the hierarchy of rule execution.

[0111] To manage rule memory space, for each currently executing rule, the system first dynamically allocates the required memory space from the first allocation table in the rule parameter pool reuse area. This allocation is based on memory requirements estimated in the rule metadata or pre-allocated based on statistical values ​​from historical execution records.

[0112] Memory space allocation uses a block-based allocation strategy, allocating contiguous memory blocks to rules to avoid memory fragmentation. For very large rules, the system uses a special large object allocation mechanism to allocate space directly from the system memory pool, avoiding interference with normal rule memory allocation.

[0113] The system records the memory space requested by a rule in the first allocation table, including the memory block's starting address, size, allocation time, and the identifier of the rule to which it belongs. This information forms a memory allocation map, which serves as the basis for subsequent memory release. For rules that may throw exceptions, the system also maintains a special exception handling memory tracking mechanism to ensure that allocated memory is properly released even in exceptional circumstances.

[0114] To obtain rule parameters, the system uses a hierarchical parameter search strategy, sequentially searching from the rule local parameter pool, the rule group parameter pool, and finally the global parameter pool to obtain the parameters required for rule execution. This internal-to-external search ensures parameter priority and coverage.

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

[0116] The system implements strict parameter type checking and conversion mechanisms to ensure that the acquired parameters conform to the data types expected by the rule. When parameter types do not match, the system attempts implicit type conversion. If the conversion fails, the error handling strategy configured for the rule is used, such as using a default value, skipping rule execution, or throwing an exception.

[0117] The first step in rule execution is to execute the conditional logic. Based on the evaluation result of the conditional expression, the rule's true or false branch is executed, or the rule execution is skipped. Conditional expressions support various forms, including simple Boolean expressions, compound logical expressions, script expressions, and precompiled conditional functions.

[0118] During conditional evaluation, the system employs a short-circuit evaluation strategy, immediately ceasing the calculation of subsequent conditions once the final result is determined. For complex conditional expressions, the system decomposes and optimizes them, caching the results of frequently used sub-expressions to avoid repeated calculations.

[0119] Branch execution utilizes a dynamic scheduling mechanism. Based on the results of conditional judgments, the system retrieves the corresponding branch execution path 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 logic. The system also records branch execution paths for subsequent rule execution tracking and auditing.

[0120] Intermediate results generated during rule execution use different storage strategies depending on their scope of use. The system determines the scope and lifecycle of each intermediate result by analyzing the output parameter definitions of the rule and the input parameter dependencies of subsequent rules.

[0121] For local variables and intermediate results used only by the current rule, the system stores them in the rule's 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 released immediately after the rule execution completes.

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

[0123] For intermediate results that need to be transferred across rule groups or execution levels, the system stores them in a global parameter pool and registers the variable information and the list of rules that depend on it in a second allocation table. The system analyzes the rule execution dependency graph to determine the maximum lifetime of the variable and releases the memory occupied by the variable only after all dependent rules have completed execution.

[0124] The rule execution engine implements a multi-level memory release mechanism to ensure efficient use and timely recovery of memory resources. The memory release process follows the principle of precise release, that is, unused memory resources are released 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 registered in the first allocation table for that rule. The release process uses a batch release strategy, returning all pending memory blocks to the memory pool at once, reducing the overhead of memory management.

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

[0127] The system also implements a periodic garbage collection mechanism, periodically checking long-lived intermediate result variables to identify memory blocks that have not been properly released, possibly due to circular references or dependency errors. For variables that have exceeded their preset lifetime but remain unreleased, the system generates a warning and attempts to force a garbage collection.

[0128] After each execution level is completed, the system performs inter-level synchronization and state transitions. Inter-level synchronization ensures that all rules in the current level have been executed and all data dependencies have been satisfied before the next level can begin. This synchronization mechanism is particularly important in parallel execution mode, preventing data inconsistencies caused by cross-execution of rules between different levels.

[0129] The system assigns a unified result object to each rule execution result, which contains information such as the rule's Boolean execution result, execution status, execution time, resource usage, etc. These result objects are collected into the association rule execution result set and arranged in the order in which the rules are executed.

[0130] The result collection process implements idempotence checks to ensure that each rule's results are collected only once. Even if a rule is executed repeatedly under unusual circumstances, the results will not be duplicated. The system also records the context of rule execution, such as execution time, execution environment, and input parameter values, for subsequent audit tracking and problem diagnosis.

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

[0132] In S6, the system queries the decision set configuration table in the preset rule base according to the decision set number to obtain the decision policy configuration corresponding to the decision set. The decision policy configuration includes the decision mode type and the parameter settings required for the mode. The decision policy selection mechanism supports two methods: static configuration and dynamic switching. Static configuration is a fixed decision policy pre-set by the rule administrator when the decision set is created or updated; dynamic switching allows the system to select from multiple alternative decision policies based on real-time conditions (such as business scenarios, user attributes, system load, etc.).

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

[0134] The ALL_PASS mode is the strictest decision strategy, requiring all association rules to be true for the decision to be true. This mode is suitable for access scenarios that require multiple conditions to be met, such as loan approval and security checks.

[0135] In practice, the system iterates through each rule result in the association rule execution result set. If any rule result is found to be false, the decision result is immediately determined to be false, without further checking subsequent rule results. Only when all rule results are true is the decision result set to true.

[0136] The system applies an optimization strategy to all pass patterns, prioritizing rules with lower historical success rates for execution. This increases the probability of early negative results and reduces unnecessary rule execution. The system also records information about rules that led to decision failures for subsequent business analysis and optimization.

[0137] The ANY_PASS mode is a relatively loose decision strategy. As long as at least one of the associated rules is true, the decision result is true. This mode is suitable for qualification scenarios where multiple conditions must meet one of them, such as marketing campaign qualifications and special service qualifications.

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

[0139] The system's optimization strategy for any pass mode is the opposite of that for all pass modes. Rules with a high historical success rate are prioritized for execution, increasing the probability of achieving a positive result early. The system also records the rules that led to successful decisions, allowing analysis of which conditional paths are more likely to be met.

[0140] Threshold mode (THRESHOLD) is a decision strategy between "all pass" and "any pass." It requires that the number or proportion of rules that meet the conditions reach a preset threshold for the decision result to be true. This mode is suitable for fault-tolerant decision-making scenarios, such as multi-dimensional risk assessment and quality inspection.

[0141] In practice, the system first obtains threshold parameters from the decision set configuration, including the threshold type (absolute number or percentage) and the threshold value. The system then calculates the number or proportion of true rules in the association rule execution result set and compares it with the threshold. If the threshold is reached or exceeded, the decision result is true; otherwise, it is false.

[0142] The system implements a dynamic threshold adjustment mechanism for threshold modes. Based on historical decision data and business feedback, the system recommends optimal threshold settings, helping business personnel optimize decision-making strategies based on actual conditions. Furthermore, the system supports segmented threshold settings, allowing different threshold standards to be applied under different conditions.

[0143] The weighted model is a decision-making strategy that considers differences in rule importance. It assigns a weight to each rule and determines the final outcome based on the sum of the weights of the rules. This model is suitable for complex decision-making scenarios where the importance of each evaluation dimension varies, such as comprehensive scoring and multi-factor ratings.

[0144] In practice, the system first retrieves the weight of each rule from the decision set configuration or rule metadata. It then iterates over the set of associated rule execution results and calculates the sum of the weights of the rules that evaluate to true. Finally, this sum is compared with a preset weight threshold to determine the final decision.

[0145] The system implements an adaptive weight optimization mechanism. By analyzing the correlation between historical decision results and actual business outcomes, the system identifies the actual impact of each rule and recommends adjustments to weight distribution to align decision outcomes more closely with business expectations. Furthermore, the system supports a time-decay weight model, giving recently executed rule results greater influence.

[0146] Expression mode is the most flexible decision-making strategy, allowing business users to customize the combination of rule results using logical expressions. This mode is suitable for decision-making scenarios with complex logical relationships, such as multi-level condition combinations and complex business rules.

[0147] In terms of implementation, the system first retrieves a predefined logical expression from the decision set configuration. This expression uses rule identifiers as variables and logical operators (AND, OR, NOT) and parentheses to construct complex logical relationships. The system then substitutes the Boolean result from 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, supporting expression precompilation and caching to reduce runtime computational overhead. Furthermore, the system provides an expression validation tool that detects syntax errors and logical issues in expressions during the configuration phase, ensuring their correctness. The system also supports expression version control and change management, recording expression modification history and validation conditions to facilitate subsequent auditing and traceability.

[0149] After the decision result is calculated, the system will encapsulate the decision result, the executed rule set, the decision strategy used, the key execution parameters and other information into a complete decision record, which will be returned to the caller and 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: include: S1, obtaining a parameter set, wherein the parameter set includes a decision set number and business data; Create a global execution context based on the parameter set; S2, 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; According to the configuration information of the association rule, the data in the parameter set is loaded into the corresponding parameter pool in the parameter hierarchical pool structure according to the parameter scope classification; S3, establishes a physical object caching mechanism; According to the entity object cache mechanism, the entity object data that the association rule depends on is obtained from the entity object data source; Loading entity object data into the parameter hierarchical pool structure according to the access permissions configured by association rules; S4, obtaining the association rule corresponding to the decision set number from the preset rule base according to the decision set number; Sort the association rules according to their priority and historical execution success rate; S5, using the parameter hierarchical pool structure, the rule execution engine executes the sorted association rules in sequence to obtain the association rule execution result set; S6, selecting a predefined decision strategy according to the decision set configuration corresponding to the decision set number; The association rule execution result set is used as input and the decision result is calculated 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 association rules that return true in historical executions; The predefined decision strategy includes at least one of an all-pass mode, an any-pass mode, a threshold mode, a weighted mode, and an expression mode.

3. The method for processing an execution file of a decision engine according to claim 2, wherein: S1, creates a global execution context based on the parameter set, including: Extract the decision set number from the parameter set; Obtain the dependency relationship of association rules according to the decision set number; The association rules are divided into multiple execution levels according to the dependency relationship. There is no dependency relationship between the rules in each execution level. The execution level is used to control the execution order of the association rules. Based on the system's computing resources, calculate the system's maximum number of parallel execution threads; Set the parallelism parameters for each execution level based on the maximum number of parallel execution threads; Construct a global execution context based on the execution level and parallelism parameters.

4. The method for processing an execution file of a decision engine according to claim 2, wherein: S2, loads the data in the parameter set into the corresponding parameter pool in the parameter hierarchical pool structure according to the parameter scope classification, including: Initialize the parameter pool object set and pre-create a certain number of parameter pool instances based on the execution level information and historical system load in the global execution context; Create a global parameter pool, a rule group parameter pool, and a rule parameter pool reuse area in the parameter pool object collection, and establish a hierarchical pool structure; According to the decision set number, the corresponding rule group division configuration and rule dependency configuration are obtained from the preset rule library to build a rule execution dependency graph; Execute the dependency graph based on the rules and associate the global parameter pool with the global execution context; Divide the configuration into rule groups, create an identifier for each rule group, and group 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 that is independent of the global parameter pool and the rule group parameter pool; A first allocation table and a second allocation table are set in the rule parameter pool reuse area. The first allocation table is used to record the addresses and sizes of variables created during the execution of a single rule, and the memory occupied by the variables is released uniformly after the rule execution is completed. The second allocation table records the addresses, sizes, and access rule lists of intermediate result variables passed between multiple consecutive rules, and the corresponding memory is released only after all dependent rules are executed. According to the parameter scope in the association rule configuration information, the business data categories in the parameter set are loaded into the corresponding parameter pool, among which the parameters of the global scope are loaded into the global parameter pool, and the parameters of the rule group scope are loaded into the corresponding association rule group parameter pool.

5. The method for processing an execution file of a decision engine according to claim 4, characterized in that: The shared parameter pool is used for temporary data shared between rules in 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.

6. The method for processing an execution file of a decision engine according to claim 4, characterized in that: Build rule execution dependency graph, including: Through the joint query mechanism, rule metadata and dependency configuration are obtained from the preset rule base according to the decision set number; Extract rule identifiers for rule metadata; Construct a rule identifier dictionary based on the rule metadata, and use a hash table structure to establish a mapping relationship between the rule identifier and the rule metadata; Based on the mapping relationship and dependency configuration, a directed acyclic graph is constructed as the initial rule execution dependency graph. The nodes of the graph represent the rules, and the edges represent the dependencies between the rules. The topological sorting algorithm is used to divide the initial rule execution dependency graph into levels, determine the execution order of the rules, and obtain the final rule execution dependency graph.

7. The method for processing an execution file of a decision engine according to claim 6, characterized in that: Dependency configuration represents the pre-execution conditions, input and output parameter dependencies, and trigger conditions between rules.

8. The method for processing an execution file of a decision engine according to any one of claims 2 to 7, characterized in that: S4, obtaining the association rule corresponding to the decision set number from the preset rule base according to the decision set number; Sort association rules based on their priority and historical execution success rate, including: Obtain the priority and historical execution success rate of each association rule from the preset rule library; Sort all association rules in ascending order according to priority to obtain priority sorting sequence A; Sort all association rules in descending order according to their historical execution success rates to obtain a historical execution success rate sorting sequence B; Get each association rule P in sequence A i Position index rankAP i , and obtain the association rule P i Position index rankBP in sequence B i ; According to the position index rankAP i and position index rankBP i , calculate the comprehensive ranking value rankP of each association rule i ; According to the comprehensive ranking value rankP i Sort all association rules in ascending order to obtain sorted association rules.

9. The method for processing an execution file of a decision engine according to claim 4, wherein: S5: Using the parameter hierarchical pool structure, the rule execution engine executes the sorted association rules in sequence to obtain the association rule execution result set, including: For each rule in the current execution level: Dynamically apply for the memory space required for executing 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 based on the configuration information of the associated rule; Execute the conditional judgment logic of the current association rule and select the true branch or false branch of the association rule based on whether the condition is met; During the execution of the association rule branch, the intermediate results are stored 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, the variable information is registered in the first allocation table and released after the current rule is executed; If the intermediate result needs to be transferred between multiple association rules, the variable information is registered in the second allocation table, and other association rules that depend on this variable are registered. The memory occupied by the variable is not released until all dependent rules are executed. After the current association rule is executed, the Boolean execution result of the rule is stored in the association rule execution result set; Release all temporary variables generated during the current rule execution process registered in the first allocation table; After all association rules in the current level are executed, the second allocation table is traversed to release the memory occupied by the intermediate result variables generated in the current level that are no longer used in subsequent levels; After completing the current execution level, if there is a subsequent execution level, it will jump to the next level and continue execution until the last level is completed; Finally, the complete association rule execution result set is output.

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

Images