Rule engine configuration method and device based on machine learning, equipment and storage medium

Abstract

The invention belongs to the technical field of artificial intelligence, is applied to the field of financial science and technology and the field of medical health, and discloses a rule engine configuration method, device and equipment based on machine learning and a storage medium. The method comprises the steps that historical calculation data and performance indexes in historical calculation tasks are collected, and a training data set is constructed; a machine learning model is trained, and algorithm parameters of the rule engine are dynamically optimized through the training data set; configuring an expression and a user-defined function of a rule engine, and realizing analysis and execution of scripts through JEXL (JavaScript Exchange Library); establishing a dynamic mapping relationship between the algorithm configuration library and the business variables, mapping algorithm variable names and business variable names, and generating configurable algorithm rules; and analyzing task load and resource requirements based on a pre-trained machine learning model, distributing system resources, and repairing abnormal behaviors in a calculation process. According to the invention, the problems of low processing efficiency, high maintenance cost, unreasonable resource allocation and poor expandability in the prior art are solved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of artificial intelligence, and is applied to the fields of financial technology and medical health, and particularly relates to a rule engine configuration method and device based on machine learning, equipment and a storage medium. BACKGROUND

[0002] In the fields of finance and insurance, medical health, etc., automatic decision and batch calculation based on a rule engine are core links to support efficient operation of business. Taking real-time risk control in the financial industry, premium accounting in the insurance industry, and medical insurance expense auditing in the medical industry as examples, such scenarios usually need to perform rule verification, logical judgment and complex calculation on massive structured and unstructured data, and the core requirement is to make automatic decisions and dynamic calculations based on dynamic data and business rules to generate accurate business results.

[0003] The traditional rule engine and configuration method has the following technical defects: the traditional rule engine relies on single-node calculation or simple distributed architecture, and adopts a hard coding method to implement rule logic, or configures simple rules based on a fixed template. When facing massive business data or high-concurrency rule calls, the single-node calculation resource is limited, and conflicts in multi-thread processing and accumulation of intermediate variables can cause frequent JVM Full GC, and even OOM errors, resulting in a significant decline in calculation efficiency. The time consumption of monthly settlement and other key businesses is as long as several hours or even longer, which cannot meet the real-time requirements. In the traditional method, rule expressions are deeply coupled with business variables and calculation logic, and execution codes, and when business rules change or new rules are added, the codes need to be manually modified and redeployed, which not only has high maintenance cost, but also easily introduces calculation errors in complex rule iteration, and the accuracy is difficult to guarantee. In addition, the rule association of multi-source data relies on fixed table connection and field mapping, and when the data source structure changes, the rule extraction logic is easily invalidated, and the system scalability is extremely poor. At the same time, the traditional rule engine lacks intelligent exception detection and repair mechanism, and cannot automatically identify data errors and rule conflicts in the calculation process, which needs manual intervention for troubleshooting, and the data blood relationship tracking ability is weak, and it is difficult to locate the root cause of the problem. In terms of resource allocation, the traditional system cannot dynamically schedule CPU, memory and other resources according to task load, which causes some tasks to timeout due to insufficient resources, while some resources are idle for a long time, and the utilization rate is low.

[0004] In summary, the prior art has the problems of low processing efficiency, high maintenance cost, insufficient intelligence level, unreasonable resource allocation, poor scalability and difficulty in meeting the needs of large-scale and high-complexity business scenarios in the configuration and operation of the rule engine. SUMMARY

[0005] The application provides a rule engine configuration method and device based on machine learning, and a storage medium, to solve the problems of low efficiency and non-authenticity of underwriting materials in the traditional underwriting process used by the prior art in underwriting.

[0006] In a first aspect, the application provides a rule engine configuration method based on machine learning, comprising:

[0007] Collecting performance indicators in historical calculation data and historical calculation tasks to build a training data set;

[0008] Training a machine learning model to dynamically optimize the algorithm parameters of the rule engine using the training data set;

[0009] Configuring the expressions and custom functions of the rule engine to realize script parsing and execution through JEXL;

[0010] Establishing a dynamic mapping relationship between the algorithm configuration library and the business variables, mapping the algorithm variable name and the business variable name, and generating configurable algorithm rules;

[0011] Based on the pre-trained machine learning model, the task load and resource demand are analyzed, the system resources are allocated, and the abnormal behavior in the calculation process is repaired.

[0012] In a second aspect, the application provides a rule engine configuration device based on machine learning, comprising:

[0013] A collection module for collecting historical calculation data and performance indicators to build a training data set;

[0014] A training module for training a machine learning model to dynamically optimize the algorithm parameters of the rule engine using the training data set;

[0015] A configuration module for configuring the expressions and custom functions of the rule engine to realize script parsing and execution through JEXL;

[0016] A generation module for establishing a dynamic mapping relationship between the algorithm configuration library and the business variables, mapping the algorithm variable name and the business variable name, and generating configurable algorithm rules;

[0017] An analysis module for analyzing the task load and resource demand based on the pre-trained machine learning model, allocating system resources, and repairing abnormal behavior in the calculation process.

[0018] In a third aspect, the present application provides a computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the rule engine configuration method based on machine learning when executing the computer program.

[0019] In a fourth aspect, the present application provides a computer readable storage medium storing a computer program, wherein the computer program implements the steps of the rule engine configuration method based on machine learning when executed by a processor.

[0020] In the rule engine configuration method, device, equipment and storage medium based on machine learning, the training data set is constructed by collecting historical calculation data and performance indicators, which provides a data-driven scientific basis for the optimization of the rule engine compared to the traditional rule engine relying on manual experience to set fixed parameters, and improves the pertinence and accuracy of parameter optimization. Training a machine learning model and dynamically optimizing algorithm parameters, combining the rule engine configuration JEXL based on machine learning to realize flexible configuration of expressions and custom functions, and establishing dynamic mapping of algorithm configuration library and business variables, effectively realize the intelligentization and configurability of the rule engine, avoid the disadvantages of frequent code modification in the traditional hard coding mode, and form a high-quality rule system that adapts to dynamic changes of business. With the help of machine learning model, the rule engine is optimized in all directions, including dynamic adjustment of parameters, intelligent allocation of resources and automatic repair of exceptions. Compared with the traditional rule engine which runs statically, the resource allocation is unbalanced and the exception handling is passive, it can more accurately adapt to different task loads, improve the rule execution efficiency and system stability, and provide more efficient and reliable rule support for business decision-making. Deeply integrating machine learning and rule engine realizes the automation and intelligent upgrading of rule configuration, and breaks through the limitations of traditional rule engine in flexibility, adaptability and efficiency. In the field of financial technology, it helps to improve the real-time performance and accuracy of risk control rules and optimize transaction processing efficiency; in the field of medical health, it can realize dynamic adaptation and accurate execution of diagnosis and treatment rules, and assist in improving the quality of medical services. This method realizes the double improvement of configuration quality and running efficiency of the rule engine in complex business scenarios, and provides strong technical support for automatic decision-making in various industries.

[0021] In summary, the present application can solve the problems of low processing efficiency, high maintenance cost, insufficient intelligence, unreasonable resource allocation and poor scalability in the configuration and running process of the rule engine in the prior art, which cannot meet the needs of large-scale and high-complexity business scenarios. BRIEF DESCRIPTION OF DRAWINGS

[0022] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the description of the embodiments of the present application. Obviously, the drawings described in the following description are only some embodiments of the present application, and all other drawings obtained by those of ordinary skill in the art without creative labor based on these drawings also belong to the protection scope of the present application.

[0023] Figure 1 is a flowchart of a rule engine configuration method based on machine learning in an embodiment of the present application;

[0024] Figure 2 is Figure 1 is a flowchart of step S110 in the method;

[0025] Figure 3 is Figure 1 is a flowchart of step S120 in the method;

[0026] Figure 4 is Figure 1 is a flowchart of step S130 in the method;

[0027] Figure 5 is Figure 1 is a flowchart of step S150 in the method;

[0028] Figure 6 is Figure 1 is another flowchart of step S150 in the method;

[0029] Figure 7 is another flowchart of a rule engine configuration method based on machine learning in an embodiment of the present application;

[0030] Figure 8 is a structural diagram of a rule engine configuration device based on machine learning in an embodiment of the present application.

[0031] Figure 9 is a structural diagram of a computer device in an embodiment of the present application;

[0032] Figure 10 is another structural diagram of a computer device in an embodiment of the present application. DETAILED DESCRIPTION

[0033] The technical solutions of the embodiments of the present application will be described clearly and completely in the following with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, and not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor also belong to the protection scope of the present application.

[0034] Referring to Figure 1 As shown in the flowchart of the method for configuring a rule engine based on machine learning provided by an embodiment of the application, the method comprises the following steps.

[0035] In step S110, historical calculation data and performance indicators in historical calculation tasks are collected to construct a training data set.

[0036] It should be noted that the training data set construction mechanism in the step of configuring a rule engine based on machine learning S110 is a machine learning empowerment technology based on full data collection and multi-dimensional index fusion. The core of the technology is to collect historical calculation data and performance indicators systematically to construct a high-quality training data set covering the whole link of business scenarios, which is suitable for scenarios such as risk control rule optimization and insurance underwriting parameter optimization in the field of financial technology, and scenarios such as diagnosis and treatment rule adaptation and medical insurance settlement logic optimization in the field of medical and health care. The historical calculation data and performance indicators are multi-dimensional data reflecting the running state of the rule engine and the business processing results. The types and collection methods of the data are closely related to the characteristics of the application scenarios of the rule engine, and are highly consistent with the intelligent needs in the fields of financial technology and medical and health care.

[0037] At the data type level, the historical calculation data includes expression logic, function call parameters, calculation results (such as risk score, premium amount, and medical insurance reimbursement ratio), and intermediate variable values executed by the rule engine; the performance indicator data includes time indicators (single rule execution time, batch task total time, and expression parsing delay), resource indicators (CPU usage, memory usage, and JVM garbage collection frequency), and quality indicators (calculation error times, rule conflict occurrence rate, and data verification failure rate). In the financial field, the historical calculation data can include transaction risk control rule calculation records in the past 3 years and policy premium accounting process data; in the medical field, it can cover diagnosis and treatment rule execution logs and medical insurance expense settlement calculation details. After these data are integrated and processed, they lay a foundation for subsequent machine learning model training and rule engine parameter optimization.

[0038] In terms of collection equipment and methods, full data capture is achieved by relying on a distributed data collection framework (such as a machine learning-based rule engine configuration Flume, Logstash) combined with business system burying points. Taking the machine learning-based rule engine configuration Flume as an example, it has high reliability and scalability, and is suitable for collecting rule calculation logs of high-frequency transactions in the financial field; the machine learning-based rule engine configuration Logstash is good at powerful log parsing capabilities and can be used to process complex diagnosis and treatment rule execution records in the medical field. During the collection process, a collection agent is deployed on the rule engine execution node to capture real-time calculation process data, and the historical database of the business system (such as Oracle and MySQL based on machine learning-based rule engine configuration) is connected to regularly extract historical archive data. In the field of financial technology, these collected data are used to train risk control rule parameter optimization models and improve transaction processing efficiency; in the field of medical health, they can be used to train diagnosis and treatment rule adaptation models and optimize medical insurance settlement logic, providing data support for intelligent configuration of rule engines.

[0039] The collection frequency is flexibly set according to the data generation speed and business needs. For example, for high-frequency transaction risk control rules, thousands of calculation records are generated per second, which need to be collected in real time; for insurance policy accounting tasks that are executed once a day, performance indicators can be collected synchronously according to the task period; for historical archive calculation data, batch collection is performed on a weekly or monthly basis. In addition, the collected data are temporarily stored in a structured format (such as CSV and Parquet) in a distributed cache (such as Redis), and after cleaning and deduplication, they are written into a training dataset warehouse (such as Hive and ClickHouse). Through the interface of a machine learning platform (such as TensorFlow and PyTorch), data access is realized, ensuring that in the fields of financial technology and medical health, the training dataset accurately reflects the characteristics of the rule engine and provides high-quality input for model training.

[0040] In some embodiments of the present application, as shown in Figure 2 Step S110 includes the following steps:

[0041] Step S111, extracting performance indicators in historical calculation tasks, the performance indicators including calculation time, memory occupation and error rate;

[0042] Step S112, cleaning noise and outliers in the historical calculation data to generate standardized training samples;

[0043] Step S113, labeling the optimization target of the training sample, the optimization target including calculation efficiency improvement and resource occupation reduction.

[0044] It should be noted that the step of configuring the rule engine based on machine learning S111, the step of configuring the rule engine based on machine learning S113 and the step of configuring the rule engine based on machine learning S113 constitute a fine construction link of a training data set. Through the layered operations of performance index extraction, data cleaning and noise reduction, and optimization target labeling, the original collected historical data is converted into standardized samples meeting the requirements of machine learning model training, providing data support for the precise optimization of rule engine parameters. This link adapts to the fine analysis requirements of high-frequency trading calculation indicators in the field of financial technology, and the strict quality control standards of diagnosis and treatment rule execution data in the field of medical and health care.

[0045] Specifically, in step S111, the performance indicator extraction adopts a strategy of combining multi-dimensional real-time monitoring and structured log analysis. In the financial technology field, for high-frequency transaction risk control rule calculation tasks, the calculation time extracted includes the time consumed by parsing a single rule expression (such as “0.02 seconds” for a machine learning-based rule engine configuration), the total processing time of 10 million pieces of transaction data for batch machine learning-based rule engine configuration (such as “150 seconds” for a machine learning-based rule engine configuration), the memory occupancy covers the JVM heap memory peak (such as “4 GB”) of the rule engine runtime, the intermediate variable storage occupancy (such as “800 MB”), and the error rate includes the expression syntax error occurrence rate (such as “0.03%”), and the calculation failure rate caused by data type mismatch (such as “0.12%”). By parsing the running logs of the rule engine (such as the JSON performance logs generated every hour), combined with the real-time monitoring data of the APM tool (such as Dynatrace), a structured indicator table containing “task ID, indicator name, indicator value, timestamp” is generated. For example, when a bank extracts the performance indicators of credit card anti-fraud rule calculation, the average processing time of 5,000 transactions per second (0.05 seconds), the memory occupancy peak (3.2 GB), and the error rate (0.01%) are included in the indicator library.In the medical health field, for diagnosis and treatment rule checking tasks, the extraction of computing time includes the rule matching time of a single electronic medical record (such as a machine learning-based rule engine configuration "2.3 seconds based on machine learning-based rule engine configuration"), the total time of batch processing of 10 million inspection reports based on machine learning-based rule engine configuration per day (such as a machine learning-based rule engine configuration "5 hours based on machine learning-based rule engine configuration"); the memory occupation covers the memory consumption of medical terminology dictionary loading (such as a machine learning-based rule engine configuration "2GB"), the memory allocation when multiple departments concurrently call the rule engine (such as a machine learning-based rule engine configuration "800MB per department on average based on machine learning-based rule engine configuration"); the error rate includes the checking failure rate caused by rule condition conflicts (such as a machine learning-based rule engine configuration "0.5%"), and the proportion of calculation interruption caused by missing medical record data (such as a machine learning-based rule engine configuration "0.3%"). Through a medical rule engine special monitoring module (such as an ELK stack-based log analysis system based on a machine learning-based rule engine configuration), the indicators are extracted from the operation log and associated with patient ID, department information and other business labels. For example, when a hospital extracts the performance indicators of tumor diagnosis and treatment rules, the rule analysis time of each pathological report (1.8 seconds based on machine learning-based rule engine configuration), memory occupation (1.5GB) and error rate (0.2%) are associated with the corresponding department (oncology department) and doctor ID for storage.

[0046] Specifically, in step S112, the data cleaning adopts a strategy combining statistical analysis and business rule verification. In the field of financial technology, for historical data of insurance policy accounting, noise data includes abnormal values of calculation time caused by system clock deviation (such as “-0.5 seconds” and “1000 seconds” based on the machine learning rule engine configuration), and memory occupation jumps caused by temporary network fluctuations (such as an instantaneous jump from 2 GB to 10 GB). By setting the 3σ principle based on the machine learning rule engine configuration to filter the reasonable range of time indicators (such as normal calculation time interval of 0.01-1 second, exceeding which is marked as abnormal), combining business rules (such as “the memory occupation of policy accounting should not exceed 8 GB”), verifying resource indicators, and using interpolation method to repair abnormal values (such as replacing with the average value of adjacent 5 normal records), the data format is standardized, such as unified calculation time unit of “milliseconds” and memory occupation unit of “MB”, and training samples containing “policy number, calculation logic, standardized indicator value” based on the machine learning rule engine configuration are generated. For example, when cleaning 100 million vehicle insurance premium calculation data of a certain insurance company, 320 abnormal records caused by server downtime are removed, and the calculation time of the remaining data is converted to millisecond level and the memory occupation is accurate to two decimal places. In the medical and health field, for historical data of medical insurance reimbursement rule calculation, noise data includes calculation time distortion caused by OCR recognition error (such as “0.1 second” and “100 seconds” based on the machine learning rule engine configuration), and memory occupation anomaly caused by temporary device overload (such as sudden drop to 100 MB).A reasonable value range is determined by box plot analysis (e.g., the reasonable interval for the calculation time of the diagnosis and treatment rules is 1-10 seconds for the machine learning-based rule engine configuration), combined with medical business specifications (e.g., the machine learning-based rule engine configuration "The peak memory occupation for medical insurance settlement shall not exceed 16 GB"), and invalid values are filtered. For abnormal samples, the mean value of the same type of business is filled (e.g., replaced with the average time of the same department and the same type of reimbursement calculation). At the same time, the data format is standardized, such as converting the error rate to a percentage form (with two decimal places), unifying the timestamp to "yyyy-MM-dd HH:mm:ss", and generating training samples containing "reimbursement order number, rule ID, standardized indicator value" based on the machine learning-based rule engine configuration.

[0047] Specifically, in step S113, the optimization target label adopts a strategy of combining business demand mapping and model training target. In the field of financial technology, for high-frequency transaction rule engine, the label of computing efficiency improvement includes that the rule engine configuration based on machine learning “compresses the single transaction computing time from 0.05 seconds to 0.03 seconds”, “reduces the batch processing time consumption by 40%”, and the label of resource occupation reduction includes that the rule engine configuration based on machine learning “reduces the memory peak value from 4 GB to 2.5 GB”, “reduces the JVM GC frequency by 50%”. By establishing the mapping relationship between business target and index (such as “transaction response delay requirement ≤ 0.04 seconds” corresponding to “computing efficiency improvement by 20%”), a binary label (such as “1 = needs optimization, 0 = meets the standard”) or a quantitative label (such as “target improvement rate 30%”) is added to each training sample. For example, when a certain bank labels the training samples of credit card risk control rules, the samples with “computing time > 0.04 seconds” are marked as “needs to improve efficiency by 30%”, and the samples with “memory occupation > 3 GB” are marked as “needs to reduce resource occupation by 25%”.In the medical health field, for diagnosis and treatment rule engines, the efficiency improvement labels include "shortening the single medical record rule checking time from 3 seconds to 1.5 seconds" of the machine learning-based rule engine configuration, "reducing the daily settlement task time consumption from 8 hours to 4 hours" of the machine learning-based rule engine configuration, and the resource occupation reduction labels include "reducing the memory occupation from 6 GB to 4 GB" of the machine learning-based rule engine configuration, "reducing the CPU usage rate from 80% to 60%" of the machine learning-based rule engine configuration. The optimization threshold is set in combination with the medical business SLA (such as "emergency rule response time ≤ 2 seconds") of the machine learning-based rule engine configuration, and the target labels are added to the samples, such as "test report calculation sample: efficiency improvement 50%, resource reduction 30%". For example, when a hospital annotates the training samples of tumor diagnosis and treatment rules, the samples with "calculation time > 2 seconds" are marked as "need to improve efficiency by 40%", and the samples with "memory occupation > 5 GB" are marked as "need to reduce resource occupation by 20%". After annotation, the training samples are stored in categories according to "business scenario + optimization type" of the machine learning-based rule engine configuration, such as "high-frequency transaction - efficiency optimization" of the machine learning-based rule engine configuration sample set in the financial field, and "medical insurance settlement - resource optimization" of the machine learning-based rule engine configuration sample set in the medical field, to provide structured input for subsequent targeted training of machine learning models.

[0048] It can be understood that, compared with the traditional method of collecting only part of the core indicators or relying on manual sample screening, the three-order collaborative mechanism of multi-dimensional extraction of performance indicators, historical data cleaning and noise reduction, and accurate labeling of optimization targets can more accurately construct a high-quality training data set, laying a data foundation for optimizing the parameters of the rule engine of the machine learning model. In the field of financial technology, this mechanism is particularly critical because the comprehensive extraction of performance indicators for high-frequency transaction risk control, policy accounting, and other tasks, effective cleaning of abnormal data, and clear optimization targets help financial institutions provide samples that are consistent with business reality for model training, thereby improving the relevance and effectiveness of rule engine parameter optimization. This training data set construction framework based on full-link data processing exhibits strong robustness in multiple types of financial business scenarios, whether it is transaction risk control calculation of tens of thousands of transactions per second, large-scale policy batch accounting, or cross-regional settlement business rule execution. As long as the calculation task involves a rule engine, the mechanism can generate standardized training samples to provide reliable input for model training.

[0049] Step S120, training a machine learning model, dynamically optimizing the algorithm parameters of the rule engine using the training data set.

[0050] It should be noted that step S120 is the core step of dynamically optimizing the algorithm parameters of the rule engine through the machine learning model, and its core is to use the training data set constructed in step S110 to learn the mapping relationship between historical data and optimal parameters through a neural network model, and to realize policy iteration combined with reinforcement learning, finally outputting optimization parameters that meet the efficiency requirements. This step is suitable for scenarios such as risk control rule parameter tuning and insurance underwriting algorithm optimization in the field of financial technology, as well as scenarios such as diagnosis and treatment rule parameter adaptation and medical insurance settlement formula optimization in the field of medical and health care, providing parameter support for the intelligent operation of the rule engine.

[0051] In some embodiments of the present application, as shown in Figure 3 Step S120 includes the following steps:

[0052] Step S121, constructing a neural network model, wherein the input of the neural network model is the performance indicators in the historical calculation data and historical calculation tasks, and the output of the neural network model is the optimized algorithm parameters;

[0053] Step S122, iteratively training the neural network model, and dynamically adjusting the parameter optimization strategy through a reinforcement learning algorithm;

[0054] Step S123, verifying the performance of the neural network model to ensure that the optimized algorithm parameters meet the preset efficiency improvement threshold.

[0055] Specifically, in step S121, the neural network model adopts a three-layer architecture of "feature extraction-nonlinear mapping-parameter output". In the field of financial technology, the input features include historical transaction data (such as transaction amount, frequency, and type) and performance indicators (such as calculation time, memory occupation, and error rate), which are standardized (such as normalized to the interval [0, 1]) and then input into the model. The model structure adopts a deep feedforward neural network, the input layer dimension is dynamically adjusted according to the number of features (such as 20 features, the input layer is 20-dimensional), the hidden layer is set to 3-5 layers (64-128 neurons per layer), the ReLU activation function is used to handle nonlinear relationships, the output layer dimension is consistent with the number of algorithm parameters of the rule engine (such as threshold parameters of risk control rules, thread numbers of parallel computing, etc.), and the output value is mapped to a reasonable parameter interval (such as thread number mapped to [1, 32]) through the Sigmoid function. For example, a risk parameter optimization model built by a certain bank, the input contains 15 features such as "transaction amount, overdue times in the past 3 months, and historical calculation time", and the output layer outputs 3 key parameters such as "risk score threshold, rule execution priority, and memory allocation ratio".

[0056] In the field of medical health, the input features include historical diagnosis and treatment data (such as patient symptom codes, test indicator values, and medication records) and performance indicators (such as rule matching time consumption and verification error rate), which are standardized and then input into the model. The model adopts a residual network (ResNet) structure to alleviate the gradient vanishing problem of deep networks, the hidden layer is set to 4-6 layers (128-256 neurons per layer), and the output layer corresponds to key parameters of diagnosis and treatment rules (such as test indicator abnormal threshold, medical insurance reimbursement ratio calculation coefficient, and department priority of concurrent processing, etc.). For example, a medical insurance settlement parameter optimization model built by a certain hospital, the input contains 25 features such as "diagnosis and treatment project code, patient age, and historical settlement time consumption", and the output layer outputs 4 parameters such as "reimbursement ratio coefficient, data verification strictness, and CPU allocation weight".

[0057] Specifically, in step S122, the model training adopts a two-stage strategy of "supervised learning pre-training + reinforcement learning fine-tuning". In the financial technology field, first, use the historical labeled data (input features + optimal parameters) for supervised learning, use the Adam optimizer to minimize the MSE loss of the predicted parameters and the real optimal parameters, and iterate 100-200 rounds until the loss converges (such as MSE<0.001). Subsequently, introduce reinforcement learning (DQN algorithm), take the running state of the rule engine (such as the current task load, resource utilization) as the environment state, and the parameter adjustment action (such as increasing the thread number, reducing the verification threshold) as the agent behavior, and take the "computing efficiency improvement rate-resource waste rate" as the reward function (such as 10 points for 10% efficiency improvement, 5 points for resource waste over 20%). Through the ε-greedy strategy (ε linearly decays from 0.9 to 0.1), the exploration and utilization are balanced, and the strategy network is updated every 1000 parameter adjustment iterations. For example, in the training of the premium accounting parameters of an insurance company, the reinforcement learning stage adjusts the "block calculation granularity" parameter dynamically, so that when the batch accounting efficiency is improved by 30%, a positive reward is obtained, and when the resource occupancy exceeds the threshold, the penalty mechanism is triggered. In the medical and health field, the historical diagnosis and treatment rule parameter data is used to train the model in the supervised learning stage, and the weighted MSE is used as the loss function (higher weight is given to key parameters such as "reimbursement ratio coefficient"). Reinforcement learning uses the PPO (Proximal Policy Optimization) algorithm, the environment state includes the number of current medical records processed, department priority, system resource utilization, the action space is the parameter adjustment amplitude (such as ±5%), and the reward function is set as "rule execution accuracy rate improvement + processing time reduction" (such as 20 points for 2% accuracy rate improvement, 10 points for 10% time increase). Trigger strategy update every 1000 medical records processed to ensure that the parameter optimization adapts to the dynamic changes of medical business. For example, in the training of the diagnosis and treatment rule parameters of a hospital, the "test index abnormality judgment threshold" is adjusted through reinforcement learning, so that when the false negative rate of malignant tumor screening is reduced by 15%, a high reward is obtained.

[0058] Specifically, in step S123, performance verification adopts a double-layer verification mechanism of "offline testing + online gray release". In the field of financial technology, offline testing uses nearly 3 months of historical data to build a test set (20% of the total data), and the optimized parameters output by the model are substituted into the rule engine to calculate key indicators (such as processing time and error rate) and compare them with the parameters before optimization. The preset efficiency improvement threshold is set according to business scenarios: high-frequency transaction risk control requires a reduction of ≥20% in processing time and ≥15% in error rate; policy batch accounting requires a reduction of ≥30% in processing time and ≥25% in resource occupation. If offline verification is passed, it enters the online gray release stage, and 10% of real-time business traffic uses optimized parameters for continuous monitoring for 72 hours, and if the indicators are stable and meet the standards, full release is implemented. For example, in the verification of a bank's risk control parameters, offline testing shows that transaction verification time is reduced from 50ms to 35ms (30% reduction), and error rate is reduced from 2% to 1.5% (25% reduction), and there is no fluctuation in indicators during the gray release period, and finally the parameters are applied in full. In the field of medical health, offline testing uses 5000 historical medical records to verify the improvement effect of the optimized parameters on rule execution, and the preset threshold includes: diagnosis and treatment rule matching accuracy ≥95%, medical insurance settlement error rate ≤0.5%, and batch processing time reduction ≥25%. Online verification selects 2 pilot departments (such as internal medicine and surgery) to run the optimized parameters, records the clinical feedback (such as the adoption rate of rule suggestions by doctors) and system indicators within 1 week, and gradually promotes to the whole hospital after meeting the standards. For example, in the verification of a hospital's medical insurance settlement parameters, offline testing shows that the settlement error rate is reduced from 1.2% to 0.3%, and the processing time is reduced from 8 hours to 5 hours (37.5% reduction), and the feedback from the pilot departments shows that the accuracy of rule suggestions is improved to 98%, and finally the verification is passed and the parameters are applied in full.

[0059] It can be understood that, by constructing a neural network model to map historical data and algorithm parameters, combining a reinforcement learning dynamic optimization strategy, and a double-layer verification mechanism to ensure performance compliance, the full-process method can more accurately realize the intelligent optimization of rule engine algorithm parameters compared to the traditional method of relying on manual experience to configure parameters or adjusting static rules. In the field of financial technology, this technology is particularly critical because models trained based on historical transaction data and performance indicators can optimize parameters for tasks such as risk control rules and policy accounting, helping financial institutions improve the adaptability of rule engines to high-frequency transactions and large-scale data processing, and ensuring the efficient operation of businesses. This parameter optimization framework based on the integration of deep learning and reinforcement learning exhibits strong robustness in multiple types of financial business scenarios, whether it is real-time payment risk control, massive policy batch accounting, or cross-institution settlement rule execution. As long as it involves parameter configuration of the rule engine, this mechanism can output the optimal parameters that adapt to the current business status, thereby improving the efficiency of rule execution.

[0060] Step S130, configure the expression and custom function of the rule engine, and realize the parsing and execution of the script through JEXL.

[0061] It should be noted that step S130 is the core link of the rule engine to realize the dynamic configuration and execution of business logic, and the core is to generate a reusable template by analyzing the business expression, rely on the JEXL engine to realize the flexible execution of the script, and guarantee the accuracy of the business through the result verification. This step is suitable for the risk control rule configuration in the field of financial technology, the insurance premium calculation and the like, and the diagnosis and treatment path rule setting in the field of medical and health, the medical insurance reimbursement proportion accounting and the like, thereby providing key support for the business adaptability of the rule engine.

[0062] In some embodiments of the present application, as shown in Figure 4 Step S130 includes the following steps:

[0063] Step S131, analyze the expression logic in the business scenario, and generate a configurable script template;

[0064] Step S132, load the script template to the rule engine, and dynamically execute the expression through the JEXL engine;

[0065] Step S133, verify the script execution result to ensure consistency with the business requirement.

[0066] Specifically, in step S131, the expression logic parsing adopts a double-layer parsing strategy of "syntax analysis + semantic mapping". In the financial technology field, the expressions in business scenarios include risk control rules (such as "if (overdue times > 3 && debt-income ratio > 0.5) then risk level = high"), premium calculation formulas (such as "premium = basic premium x age coefficient x occupation coefficient"), and loan quota evaluation (such as "quota = monthly income x 12 x credit multiplier"). In the parsing process, first, the expression is converted into an abstract syntax tree (AST) by a syntax parser (such as ANTLR), which identifies logical operators (&&, ||), comparison operators (>, <), and function calls (such as a custom function to calculate the age coefficient), and then the AST is mapped to a configurable script template, which contains variable placeholders. In the medical and health field, business expressions include medical insurance reimbursement rules (such as "if (project belongs to class A && expense > deductible line) then reimbursement ratio = 90%"), clinical pathway judgment (such as "if (body temperature > 38.5°C && cough) then perform blood routine examination"), and drug dosage calculation (such as "dose = weight x 3 mg / kg"). During parsing, combined with a medical terminology dictionary (such as ICD-10 coding and ATC drug coding), domain-specific variables (such as "class A project" and "blood routine examination") are identified, and the expression is converted into a template containing medical terminology placeholders. For example, after parsing the expression "initial insulin dose for diabetic patients = weight (kg) x 0.5 U / kg" of a certain hospital, the generated template contains and tags, and is associated with the version information of the diabetes diagnosis and treatment specification. The generated script template is stored in XML or JSON format, including expression ID, business scenario label (such as "credit card risk control" and "outpatient reimbursement"), variable list, logic structure, and function list, supporting manual editing and parameter adjustment through a visual configuration interface (such as a Vue-based form tool).

[0067] Specifically, in step S132, the template loading and execution adopts an efficient execution strategy of "pre-compilation + dynamic binding". In the field of financial technology, the rule engine reads the script template through the template loader (such as SpringBean) when starting, calls the pre-compilation interface (such as createExpression) of the JEXL engine to convert the template into an executable Expression object, and reduces the time-consuming of repeated parsing. In the execution stage, real-time data (such as "overdue times = 4" "monthly income = 15000" of a certain user) is obtained from the business system, a JEXL context (JexlContext) is constructed, variable values are bound to placeholders in the template, and the expression is dynamically executed through the expr. evaluate(context) method. For custom functions (such as functions for calculating loan annual interest rates), Java methods are mapped to function calls (such as #{calcAnnualRate(monthly interest rate, number of periods)}) in expressions through the function registration mechanism (such as registerFunction) of the JEXL engine. For example, after a certain insurance company loads the "vehicle insurance premium = basic premium x (1 + NCD coefficient) x vehicle model coefficient" template, it binds real-time data such as "basic premium = 5000" and "NCD coefficient = 0.85" during execution, and calculates the final premium of 4250 yuan through the JEXL engine. In the field of medical health, the template is loaded in association with the medical terminology coding system (such as mapping "Class A items" to medical directory codes), and the JEXL engine checks the compatibility of the expression with medical specifications (such as "the reimbursement ratio shall not exceed 100%") during pre-compilation. In the execution stage, patient data (such as "weight = 70kg" "diagnosis = type 2 diabetes") is obtained from the electronic medical record system, and is passed to the template through context binding, and custom functions such as "insulin dose = #{calcDose(weight, diagnosis)}" are executed. For example, after a certain hospital loads the "initial dose for hypertension patients = weight x 0.02mg" template, it binds the patient's weight of 70kg, and calculates the dose of 1.4mg through the JEXL engine by calling the calcDose function, and automatically associates the drug specification (such as "2.5mg / tablet") to generate the taking suggestion ("half a tablet per day").

[0068] Specifically, in step S133, the result verification adopts a "multi-level verification + exception feedback" guarantee mechanism. In the field of financial technology, the verification dimensions include: business rule verification (such as "the loan limit cannot exceed 500,000 yuan upper limit"), data consistency verification (such as "the premium calculation result and the manual review value deviation ≤0.1%"), compliance verification (such as "the interest rate calculation conforms to the LPR pricing rules"). Through the preset verification rule library (such as the secondary verification engine based on Drools), the JEXL execution result is automatically checked, for example, when the calculation amount of a certain loan is 55,000 yuan, the "exceeding the upper limit" exception alarm is triggered. For complex scenarios (such as cross-border settlement), an artificial sampling mechanism (1% of the results are reviewed) is introduced, and the verification process is recorded through the blockchain to ensure that it cannot be tampered with. When the verification fails, the system automatically returns an error code (such as "ERR_AMOUNT_EXCEED") and a correction suggestion (such as "suggesting the amount to be adjusted to 500,000 yuan"). In the field of medical health, the verification dimensions include: clinical rationality verification (such as "the drug dosage cannot exceed the adult maximum daily dose"), medical insurance policy verification (such as "the reimbursement amount cannot exceed the total cost"), data type verification (such as "the test index value is a non-negative number"). Through the interface with the medical knowledge base (such as the UpToDate clinical decision library), the execution result is verified for medical logic, for example, the antibiotic dosage calculation result of a certain patient is 2g / day, and the system verification finds that the adult maximum dose of this drug is 1.5g / day, which immediately triggers an exception prompt. For high-risk scenarios (such as tumor chemotherapy scheme calculation), the "double physician review" process is forcibly started, and the rule engine pushes the calculation result to two attending physicians for confirmation. After the verification is passed, the result is synchronized to the electronic medical record system and a verification report is generated, including the verification item, result, timestamp and operator information.

[0069] It can be understood that, compared with the traditional hard-coded implementation of expression and function, the whole process mechanism of generating a configurable script template by analyzing business expression logic, relying on JEXL engine to dynamically execute the expression and verifying the execution result, can more flexibly adapt to changes in business requirements of the rule engine. In the field of financial technology, this mechanism is particularly critical, because accurately parsing risk control rule expression, policy accounting logic, etc., generating a configurable template and dynamically executing it, helps financial institutions quickly respond to regulatory policy adjustments and market demand changes, reducing the development cycle of rule changes. This JEXL-based dynamic configuration framework shows strong robustness in multiple types of financial business scenarios, whether it is real-time transaction risk control rule verification, insurance product rate calculation, or bank loan amount assessment. As long as business expressions and custom functions are involved, flexible configuration and efficient execution can be achieved through this mechanism, thereby improving the business adaptation ability of the rule engine.

[0070] Step S140, a dynamic mapping relationship between the algorithm configuration library and the business variable is established, the algorithm variable name and the business variable name are mapped, and a configurable algorithm rule is generated.

[0071] It should be noted that step S140 is a key link for decoupling the rule engine and the business system, and the core is to eliminate the direct binding of the algorithm variable name and the business variable name by constructing a dynamic mapping mechanism of the algorithm configuration library and the business variable, and to generate a flexible algorithm rule. This step is suitable for scenarios such as risk control model variable mapping in the financial technology field, insurance underwriting factor correlation, and scenarios such as diagnosis and treatment index matching in the medical and health field, medical insurance item correspondence, and provides bottom support for cross-business adaptation of the rule engine.

[0072] In some embodiments of the application, the specific operation of step S140 is as follows:

[0073] In the field of financial technology, the algorithm configuration library stores algorithm variables required by the rule engine, including basic variables (such as “transaction amount” “overdue days”), derived variables (such as “average transaction amount in the past 3 months” “overdue frequency ratio”), and function variables (such as “risk score function output value”), each variable contains unique identification (such as “VAR_TRX_AMT”), data type (such as “DECIMAL(18,2)”), calculation logic (such as “transaction amount = order amount - discount amount”) and other meta information. The business variable pool corresponds to the fields in the actual business system, such as “TX_AMOUNT” (transaction amount) in the bank core system and “OVERDUE_DAYS” (overdue days) in the credit system, and records the business meaning, source table name, update frequency and other attributes of the variable. For example, “VAR_TRX_AMT” in the algorithm configuration library of a certain bank and “TX_AMOUNT” “ORDER_AMOUNT-DISCOUNT_AMOUNT” in the business variable pool both exist mapping possibilities. In the medical and health field, the algorithm configuration library contains diagnosis and treatment rule variables (such as “temperature value” “white blood cell count”), medical insurance settlement variables (such as “item cost” “reimbursement ratio”), and model variables (such as “disease risk probability”), and the variable identifier uses medical standard coding (such as “VAR_TEMP” corresponding to temperature). The business variable pool covers “TEMPERATURE” (temperature) in the electronic medical record system, “WBC_COUNT” (white blood cell count) in the laboratory information system, and “ITEM_COST” (item cost) in the medical insurance system, and also associates the medical units (such as “℃” “×10 9 / L”) and normal reference ranges (such as “36.3-37.2℃”) of the variables. For example, the algorithm variable “VAR_WBC” can be mapped to the business variable “WBC_COUNT” or “white blood cell test result”.

[0074] The mapping relationship is realized by a "many-to-many" association table, and the table structure includes algorithm variable ID, business variable ID, mapping type (such as "direct mapping", "formula mapping", and "function mapping"), conversion rule (such as unit conversion formula "business variable value x 1000"), and effective state. In the field of financial technology, direct mapping is suitable for scenarios where variable names have consistent semantics, such as algorithm variable "transaction amount" directly mapping to business variable "TX_AMOUNT"; formula mapping is used for derived variables, such as "average transaction amount in the past 3 months" being mapped to "(sum of business variable TX_AMOUNT in the past 90 days) / 3"; function mapping is used for complex conversion, such as "risk level" being mapped to algorithm variable "RISK_LEVEL" through a custom function "mapRiskLevel(business variable SCORE)". For example, an insurance company associates algorithm variable "premium coefficient" with business variables "age" and "occupation level" through formula mapping, with the mapping rule being "premium coefficient = age coefficient x occupation coefficient", where the age coefficient and occupation coefficient are obtained by function conversion of business variables. In the field of medical health, direct mapping is used for standardized variables, such as algorithm variable "temperature value" directly mapping to business variable "TEMPERATURE"; unit conversion mapping handles unit differences, such as the mapping rule for algorithm variable "weight (kg)" and business variable "weight (g)" being "business variable value / 1000"; coding mapping is used for term matching, such as algorithm variable "disease code" being mapped to business variable "diagnosis name" through an ICD-10 coding correspondence table. For example, a hospital associates algorithm variable "ICD10_CODE" with business variable "diagnosis result" through coding mapping, and when the business system enters "type 2 diabetes", it is automatically mapped to algorithm variable "E11.9".

[0075] Based on the mapping relationship, the system automatically generates an algorithm rule template containing variable placeholders, and the algorithm variables in the rule are associated with business variables through mapping identification. In the field of financial technology, a rule template is "if VAR_TRX_AMT > 100000 and {VAR_OVERDUE_DAYS} > 30, then trigger manual review", where "${VAR_TRX_AMT}" corresponds to the actual business variable "TX_AMOUNT" through the mapping relationship. When the variable name of the business system changes (such as "TX_AMOUNT" to "TRANSACTION_AMOUNT"), only the mapping relationship table needs to be updated, and the rule template does not need to be modified. For example, the risk control rules of a bank changed due to the upgrade of the core system, and by updating the association between "VAR_TRX_AMT" and "TRANSACTION_AMOUNT" in the mapping table, the rule template can be executed normally without adjustment. In the field of medical health, an algorithm rule template is "if VAR_TEMP > 38.5 and {VAR_WBC} > 10 x 109 / L, then trigger manual review", where "${VAR_TEMP}" corresponds to the actual business variable "TEMPERATURE" through the mapping relationship. When the variable name of the business system changes (such as "TEMPERATURE" to "BODY_TEMPERATURE"), only the mapping relationship table needs to be updated, and the rule template does not need to be modified. 9VARTEMP, VAR_WBC} are associated with business variables through mapping. When the hospital introduces a new test device, causing the white blood cell count variable name to change to "WBC_LEVEL", the rule template remains unchanged after updating the mapping relationship. In addition, manual adjustment of the mapping relationship is supported through a visual configuration interface, such as adding the mapping of the business variable "C-reactive protein" to the algorithm variable "inflammation indicator", without the need for coding to extend the rule dimension.

[0076] It can be understood that by constructing the dynamic mapping relationship between the algorithm configuration library and the business variable, the flexible association between the algorithm variable name and the business variable name is realized. Compared with the traditional hard-coded binding variable method, the configurable algorithm rule can be generated more accurately, and the adaptation ability of the rule engine to the business system is significantly improved. In the field of financial technology, this mechanism is particularly critical because accurately establishing the mapping relationship between the risk control model variable and the transaction data field, the insurance underwriting factor and the customer information field helps financial institutions quickly respond to business system upgrades or variable naming specification changes, providing flexible configuration support for risk control rule iteration, premium calculation logic adjustment, etc. This rule generation framework based on dynamic mapping shows strong robustness in multiple types of financial business scenarios. Whether it is a bank's credit approval rule, an insurance company's claim accounting logic, or a payment platform's anti-fraud strategy, as long as it involves the association between algorithm variables and business data, the mapping relationship can be adjusted to achieve rapid adaptation of the rule, thereby improving the iteration efficiency of financial business.

[0077] Step S150, based on the pre-trained machine learning model, analyzes the task load and resource demand, allocates system resources, and repairs abnormal behavior in the calculation process.

[0078] It should be noted that step S150 is the core link to ensure the efficient and stable operation of the rule engine, and its core lies in relying on the pre-trained machine learning model to realize the collaborative operation of task load analysis, intelligent allocation of system resources, and automatic repair of calculation abnormalities. This step is suitable for high-frequency transaction risk control in the field of financial technology, batch underwriting in the insurance industry, and large-scale diagnosis and treatment data processing in the medical and health field, as well as medical insurance expense batch settlement scenarios, providing key support for the rule engine to cope with complex business environments.

[0079] In some embodiments of the present application, as shown in Figure 5 Step S150 includes the following steps:

[0080] Step S1511, detecting calculation bias and data errors, identifying abnormal points based on an abnormal score formula, wherein the abnormal score = σx-μ;

[0081] Step S1512, matching the abnormal mode with the pre-trained repair model to generate a correction value;

[0082] Step S1513, triggering the automatic repair process, adjusting the calculation parameters or reallocating the task resources.

[0083] It should be noted that steps S1511 to S1513 constitute a closed-loop mechanism for exception handling in the rule engine calculation process, the core of which is to identify calculation bias and data errors through a quantitative exception score formula, generate a correction scheme combined with a pre-trained repair model, and automatically trigger the repair process to ensure the accuracy of the rule engine output. This mechanism is suitable for scenarios such as transaction data verification, risk control indicator calculation in the financial technology field, and diagnosis data accounting, medical insurance settlement in the medical and health field, providing key protection for high reliability of the rule engine.

[0084] Specifically, in step S1511, the exception detection adopts a dual strategy of "statistical analysis + business rule verification". In the financial technology field, calculation bias includes risk control rule execution result bias (such as actual risk score deviation from expectation exceeding 10%), premium accounting data error (such as policy amount not matching premium calculation result), and transaction data anomaly (such as single transaction amount far exceeding user historical average). By calculating the mean (μ) and standard deviation (σ) of historical data through a sliding window, the exception score formula "exception score = σx-μ" is applied to real-time calculation results (x), and when the absolute value of the score exceeds the pre-set threshold (such as 3σ in the financial field), it is marked as an abnormal point. For example, a bank monitors credit card transaction amounts and calculates that the user's historical transaction average μ = 5000 yuan, the standard deviation σ = 2000 yuan, when a transaction of x = 20000 yuan occurs, the exception score = 2000x20000-5000 = 39995000, far exceeding the threshold of 3x2000 = 6000, and is identified as an abnormal transaction. In the medical and health field, calculation bias includes diagnosis rule matching error (such as symptoms not matching recommended diagnosis and treatment plan), medical insurance settlement data error (such as reimbursement amount exceeding total cost), and test indicator anomaly (such as patient body temperature value far exceeding normal range). Similarly, based on the exception score formula, the threshold is adjusted in combination with medical reference ranges (such as the normal range of body temperature being 36.3-37.2°C, and the threshold being 2σ). For example, a hospital detects patient temperature data and calculates that the historical body temperature average μ = 36.5°C, the standard deviation σ = 0.3°C, when a detection value x = 39°C occurs, the exception score = 0.3x39-36.5 = 11.7-36.5 = -24.8, the absolute value far exceeds the threshold of 2x0.3 = 0.6, and is identified as an abnormal body temperature value. In addition, secondary verification is conducted in combination with domain business rules, such as verifying that "premium cannot be negative" in the financial field, and verifying that "drug dosage cannot exceed the maximum safe value" in the medical field, to ensure the accuracy of exception detection.

[0085] Specifically, in step S1512, the abnormal pattern matching adopts the strategy of "pattern clustering + model mapping". In the field of financial technology, the pre-trained repair model includes a data error repair model (such as an interpolation filling model for missing insurance information), a calculation logic repair model (such as a premium calculation formula parameter adjustment model), and a rule execution bias repair model (such as a dynamic correction model for risk control thresholds). The historical abnormal points are divided into "data missing", "parameter error", "logic conflict" and other patterns by the K-means clustering algorithm, and the corresponding repair model is matched according to the pattern to which the abnormal point belongs. For example, a certain insurance company identifies that the pattern of "abnormal premium calculation result" is "age parameter error", calls the pre-trained age parameter correction model, recalculates the age coefficient based on the user's ID card information, and generates the corrected premium value. In the field of medical and health care, the pre-trained repair model includes a test data repair model (such as a test value correction model caused by instrument error), a diagnosis and treatment rule repair model (such as a mapping correction model for symptom coding error), and a medical insurance settlement repair model (such as a reclassification model for project classification error). The features of the abnormal pattern are extracted by a deep learning model (such as an autoencoder), and compared and matched with the pattern features in the pre-trained model library. For example, a certain hospital identifies that the pattern of "abnormal white blood cell count" is "instrument detection error", calls the corresponding repair model, and generates the corrected white blood cell count based on the detection bias trend of other samples in the same batch. The generated correction value is accompanied by a confidence score (such as 0-100 points), and a high score (such as ≥80 points) indicates high repair reliability and can be directly applied; a low score (such as <60 points) needs to be manually reviewed.

[0086] Specifically, in step S1513, the automatic repair adopts a dual-track strategy of "parameter adjustment + resource scheduling". In the field of financial technology, for "computational logic bias" type exceptions, adjust the algorithm parameters of the rule engine (such as adjusting the risk control threshold from 60 points to 55 points); for "computational errors caused by insufficient resources", redistribute task resources (such as migrating a batch of underwriting tasks from a node with a load rate of 90% to a node with a load rate of 30%). For example, the real-time risk control task of a certain bank caused the rule execution to be delayed due to high node load, and the system automatically allocated 20% of the tasks to idle nodes and adjusted the timeout parameter from 1 second to 1.5 seconds to ensure task completion. The repair process ensures atomicity through transaction mechanisms, and automatically rolls back and triggers alarms in the event of repair failure. In the field of medical health, for "diagnosis and treatment rule matching errors", adjust the rule parameters (such as adjusting the body temperature abnormal threshold from 38.5°C to 38.3°C to adapt to child patients); for "abnormalities caused by data processing congestion", reschedule resources (such as temporarily adding 2 computing nodes for medical insurance settlement tasks). For example, the medical insurance settlement task of a certain hospital was interrupted due to a surge in data volume, and the system automatically split the task into 10 small tasks, distributed them to different nodes for parallel processing, and increased the resource priority of the task. After the repair is completed, a repair report is generated, recording the exception type, repair measures, results, and responsible person, facilitating audit tracing.

[0087] It can be understood that, through the three-order collaborative mechanism of accurate identification of abnormal points by the abnormal score formula, matching of pre-trained models to generate correction values, and triggering of automatic repair processes, compared with traditional manual exception checking or simple threshold judgment methods, the mechanism can more accurately realize the rapid detection and intelligent repair of exceptions in the rule engine calculation process. In the field of financial technology, this mechanism is particularly critical, as accurately identifying computational biases and data errors in scenarios such as transaction risk control and premium calculation, and automatically generating correction schemes, can help financial institutions improve the accuracy of data processing, avoid issues such as risk control misjudgment and underwriting errors caused by abnormal data, and provide strong protection for financial safety and business compliance. This exception handling framework based on the integration of statistical models and machine learning exhibits strong robustness in various types of financial business scenarios, whether it is fraud signal identification in real-time transactions, amount deviation detection in batch policy underwriting, or data inconsistency verification in cross-institution settlement. As long as the calculation process involves a rule engine, the mechanism can efficiently handle exceptions, thereby improving the reliability of financial data and the smoothness of business processes.

[0088] In some embodiments of the present application, as shown in Figure 6 Step S150 includes the following steps:

[0089] Step S1521, predict task load, estimate resource demand through a time series model;

[0090] Step S1522, allocate resource proportion, schedule tasks according to load balancing formula, resource allocation proportion = task load / total load;

[0091] Step S1523, schedule the computing task to the node with the lowest load.

[0092] It should be noted that the sub-steps in steps S1521 to S1523 around resource allocation are the key links to realize efficient use of rule engine resources. The core is to predict task load through time series model, allocate resource proportion according to load balancing formula, and schedule tasks to the optimal node to realize dynamic adaptation of system resources and load balancing. This link adapts to the high-concurrency transaction processing, batch data accounting and other scenarios in the field of financial technology, and the batch analysis of diagnosis and treatment data, centralized settlement of medical expenses and other scenarios in the field of medical and health care, providing precise resource support for rule engine to cope with business load fluctuations.

[0093] Specifically, in step S1521, the load prediction adopts the strategy of "time series analysis + business feature fusion". In the field of financial technology, task load includes real-time transaction verification request volume (such as transaction volume per second), batch task data volume (such as daily underwriting policy number), rule query frequency (such as the number of times of calling risk control rules per minute). Through ARIMA, LSTM and other time series models, combined with business features (such as holidays, promotional activities), the load trend in the next 1-24 hours is predicted, and the required CPU, memory, network bandwidth and other resource quantities are estimated. For example, a payment platform predicts the transaction peak during Double Eleven period through LSTM model, estimates that 50,000 transactions per second need to be processed, and needs to allocate 8-core CPU and 16GB memory resources. In the field of medical and health care, task load includes outpatient diagnosis and treatment rule call volume (such as the number of patients per hour), test report processing volume (such as the number of test samples per day), medical insurance settlement task volume (such as the number of reimbursement documents per month). Through Prophet model combined with medical business cycle (such as seasonal disease high incidence period) for load prediction. For example, a hospital predicts the test report processing volume during the flu high incidence period, estimates that 8000 reports need to be processed per day, and needs to allocate 10 computing nodes. The prediction result is output in the form of load curve and resource demand list to provide basis for subsequent resource allocation.

[0094] Specifically, in step S1522, the resource allocation adopts the strategy of "proportional allocation + priority adjustment". In the field of financial technology, the total load is the sum of the loads of all parallel tasks, and the CPU, memory and other resources are allocated to each task in proportion according to the formula "resource allocation proportion = task load / total load". At the same time, the allocation proportion is adjusted in combination with the task priority (such as the priority of real-time transaction risk control being higher than that of batch report generation), and the high-priority task can obtain 1.2-1.5 times the benchmark proportion of resources. For example, the total load of a certain bank is 100 units (real-time risk control 60 units + batch reconciliation 40 units), and the resource allocation proportion of real-time risk control is 60 / 100 = 60%, and considering the priority, 65% of the CPU resources are actually allocated. In the field of medical health, the total load is the sum of the loads of all departments, and the resources are allocated according to the formula, and the allocation proportion is increased for urgent tasks (such as emergency test report processing). For example, the total load of a certain hospital is 200 units (emergency treatment 50 units + outpatient treatment 150 units), and the benchmark allocation proportion of emergency tasks is 50 / 200 = 25%, and 40% of the resources are actually allocated to ensure rapid response. The resource allocation result is recorded through a resource scheduling table to clearly define the resource quota and allocation node of each task.

[0095] Specifically, in step S1523, the task scheduling adopts the strategy of "node health degree + load balancing". In the field of financial technology, the load rate (CPU usage rate, memory occupancy rate), response time, fault history and other health indicators of each computing node are monitored in real time, and the task is scheduled to the node with the lowest load rate (such as <50%) and the highest health degree. For distributed tasks, a sharding strategy (such as splitting 1 million insurance policy data into 10 shards) is adopted, and the tasks are scheduled to different nodes for parallel processing. For example, the batch claim processing task of a certain insurance company is scheduled to three nodes with load rates of 30%, 35% and 40%, respectively, achieving load balancing. In the field of medical health, according to the principles of department affiliation and data localization, the task is preferentially scheduled to the local node of the corresponding department, and if the local node is overloaded, it is scheduled to a remote idle node. For example, the internal medicine test task of a certain hospital is preferentially scheduled to the internal medicine server, and when the load rate of the internal medicine server reaches 85%, it is scheduled to the medical technology department server with a load rate of 20%. The scheduling process is optimized by an intelligent scheduling algorithm (such as genetic algorithm) to ensure that the average response time of the task is the shortest and the standard deviation of the node load is the smallest.

[0096] It can be understood that, compared with the traditional static resource configuration or manual scheduling mode, the three-order collaborative mechanism of predicting the task load by the time series model, allocating the resource proportion based on the load balancing formula, and scheduling the task to the optimal node can more accurately realize the dynamic adaptation of the resource of the rule engine and the load balancing. In the field of financial technology, this mechanism is particularly crucial because accurately predicting the load fluctuation of high-frequency trading, batch underwriting, and the like and dynamically allocating resources can help financial institutions improve the utilization rate of system resources, avoid transaction delays due to insufficient resources, or waste due to idle resources, and provide stable resource support for real-time risk control, rapid underwriting, and the like. This intelligent scheduling-based resource management framework exhibits strong robustness in multiple types of financial business scenarios. Whether it is payment risk control verification of tens of thousands of times per second, batch accounting of millions of insurance policies per day, or cross-regional settlement data processing, as long as the calculation task of the rule engine is involved, the optimal allocation of resources can be realized through this mechanism, thereby improving the processing efficiency and stability of financial businesses.

[0097] In some embodiments of the present application, as shown in Figure 7 After step S150, the method further includes the following steps:

[0098] Step S160, constructing a data bloodline graph;

[0099] Step S170, embedding the data bloodline graph into a low-dimensional space to generate a visual coordinate through a Node2Vec model;

[0100] Step S180, locating the root cause of the problem, backtracking the dependency path of the abnormal data based on a graph traversal algorithm, generating a visual coordinate, and locating the root cause of the problem.

[0101] ​Specifically, in step S160, the data lineage graph is constructed using a "node-relation" binary modeling strategy. In the field of financial technology, the graph nodes include data source nodes (such as transaction log tables, user information tables), processing nodes (such as risk control rule engines, premium calculation formulas), result nodes (such as risk scores, underwriting conclusions), and parameter nodes (such as risk control thresholds, interest rate parameters). The relationship types include "data input" (such as transaction log → risk control rule), "calculation dependency" (such as user age → premium coefficient), "parameter reference" (such as interest rate parameter → loan limit calculation), and "result output" (such as underwriting rule → underwriting conclusion). The graph is stored in a Neo4j graph database, and the data flow log is collected through Apache Atlas to automatically identify the dependency between nodes. For example, in the risk control data lineage graph of a certain bank, the "user A's transaction amount" node is connected to the "risk control rule R1" node through the "input to" relationship, the "risk control rule R1" is connected to the "risk threshold 60 points" node through the "reference" relationship, and finally the "user A's risk score 75 points" node is connected through the "output as" relationship, recording the full link of data from generation to result. In the field of medical health, the graph nodes include raw data nodes (such as patient temperature measurement values, blood routine test results), processing nodes (such as diagnosis and treatment rule engines, medical insurance reimbursement formulas), result nodes (such as diagnosis conclusions, reimbursement amounts), and standard nodes (such as ICD-10 codes, medical insurance catalog). The relationship types include "data collection" (such as thermometer → temperature value), "rule processing" (such as temperature value + symptoms → diagnosis rule), "standard mapping" (such as diagnosis conclusion → ICD-10 code), and "result application" (such as reimbursement amount → settlement single). The graph is constructed using IBM InfoSphere Information Governance Catalog tools, combined with HL7 FHIR standard to parse medical data flow relationship. For example, in the diagnosis and treatment data lineage graph of a certain hospital, the "patient B's white blood cell count 15 × 10 9 / L" node is connected to the "infectious disease rule R2" node through the "input to" relationship, the "rule R2" is connected to the "white blood cell normal range 4-10 × 10 9 / L" node through the "reference" relationship, and finally connected to the "bacterial infection diagnosis" node through the "output as" relationship, clearly presenting the dependency link of diagnosis and treatment data. The constructed lineage graph supports dynamic updating, and when the data processing process changes (such as adding a new rule node) or the data source is adjusted, the nodes and relationships are automatically updated to ensure the real-time nature of the graph.

[0102] Specifically, in step S170, the low-dimensional embedding adopts a strategy of "graph representation learning + coordinate mapping". In the field of financial technology, for high-dimensional bloodline graphs (such as containing 100,000 nodes and 1 million relationships), the Node2Vec model is used to represent the nodes in vectors. The model generates node sequences by random walk (such as walking from the "transaction amount" node to the "risk control rule" and then to the "risk score"), and uses the Skip-gram algorithm to train 128-dimensional node vectors, and then reduces them to 2-dimensional or 3-dimensional space by t-SNE to generate (x, y) or (x, y, z) visualization coordinates. For example, the bloodline graph of a certain insurance company contains 50,000 insurance data nodes. After Node2Vec processing, the "premium calculation" related nodes are clustered in the coordinate space (such as x∈[0.2, 0.4], y∈[0.3, 0.5]), and the "underwriting rules" related nodes form an independent cluster, providing a spatial distribution basis for subsequent visualization. In the field of medical health, for multi-source heterogeneous bloodline graphs (such as integrating electronic medical records, test equipment, and medical insurance system nodes), the random walk strategy of the Node2Vec model is combined with medical field knowledge (such as preferentially walking the "test results → diagnosis rules → treatment plan" path) to generate 256-dimensional node vectors, which are reduced to 2-dimensional coordinates by the UMAP algorithm. For example, the "blood routine test" related nodes (white blood cell count, red blood cell count, etc.) of a certain hospital form a dense cluster in the coordinate space (x∈[0.1, 0.3], y∈[0.6, 0.8]), which is significantly separated from the "biochemical test" node cluster (x∈[0.7, 0.9], y∈[0.2, 0.4]), reflecting the relevance of data types. The generated visualization coordinates are stored in JSON format, containing node ID, coordinate value, and node type label (such as "data source" and "rule engine"), supporting integration with visualization tools (such as D3.js and Gephi) to realize interactive display of the graph.

[0103] Specifically, in step S180, the problem positioning adopts the strategy of “abnormal node triggering + path backtracking + visualization marking”. In the field of financial technology, when the rule engine outputs an abnormal result (such as an abnormally high risk score of a certain user), the result node is taken as the starting point, and a depth-first search (DFS) algorithm is used to backtrack its dependent path: from the “abnormal risk score” node, backtracking to “risk control rule R3”, and then backtracking to the “user overdue times” data source, and finally locating to “overdue times statistical error” (such as miswriting “3 times” as “30 times”). During the backtracking process, the visualization coordinates of all nodes on the path are extracted, and the abnormal path is highlighted in red in the graph, and the backtracking direction is indicated by an arrow. For example, a bank's risk control system found that the “loan approval limit was abnormal”, and through DFS backtracking, it found that the root cause was “user income proof data entry error”. In the visualization interface, the error node is marked as red flashing, and the nodes such as “income verification rule” and “limit calculation formula” on the path are connected with red lines, which intuitively displays the problem propagation link. In the field of medical health, when the diagnosis and treatment rule outputs an abnormal conclusion (such as a patient being misdiagnosed as having diabetes), the conclusion node is taken as the starting point, and a breadth-first search (BFS) algorithm is used to backtrack the dependent nodes layer by layer: from the “misdiagnosis conclusion” to the “blood glucose detection value”, and then to the “blood glucose meter calibration record”, and finally to the “instrument uncalibrated leading to high detection value”. The backtracking path is highlighted in orange in the visualization graph, and the key abnormal nodes (such as “uncalibrated blood glucose meter”) are attached with detailed information pop-up windows (such as calibration time, error value). For example, a hospital found that the “medical insurance reimbursement amount was abnormal”, and through BFS backtracking, it was located to “diagnosis and treatment project classification error” (such as misclassifying a class A project as a class B project). In the visualization interface, the error classification node is marked, and the nodes such as “project coding rule” and “reimbursement ratio formula” on the path are connected with orange lines, helping medical staff quickly locate the problem link. The positioning result generates a report containing the root node ID, abnormal path description, and impact range assessment (such as the number of affected transactions, patients), and supports automatic pushing to the person in charge (such as data entry clerk, equipment maintainer), realizing the closed-loop processing of the problem.

[0104] Understandably, by constructing a three-tiered collaborative mechanism—comprising a data lineage graph, low-dimensional space embedding, and graph traversal algorithms to trace abnormal paths—it can more accurately achieve end-to-end tracing and root cause localization of abnormal data compared to traditional methods relying on manual log file checks or partial data verification. This mechanism is particularly crucial in the fintech field because fully recording and visualizing the lineage of risk control data and transaction results helps financial institutions quickly pinpoint the source of issues such as abnormal risk scores and incorrect underwriting conclusions, preventing financial losses or compliance risks caused by data errors and providing strong support for data quality control and business risk early warning. This graph-based lineage tracing framework demonstrates strong robustness across various financial business scenarios. Whether it's misjudgment of fraud signals in real-time transactions, amount discrepancies in batch policy calculations, or data inconsistencies in cross-institutional settlements, as long as the data link involves the rule engine, this mechanism can trace back to the original data source or processing node, thereby achieving precise problem remediation.

[0105] In summary, the solution implemented in this embodiment of the invention can solve the problems of low processing efficiency, high maintenance costs, insufficient intelligence, unreasonable resource allocation, and poor scalability in the configuration and operation of existing rule engines, making it difficult to meet the needs of large-scale and highly complex business scenarios.

[0106] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention. Software tools or components not belonging to this company that appear in the embodiments of this application are merely illustrative examples and do not represent actual use.

[0107] In one embodiment, a machine learning-based rule engine configuration device is provided, which corresponds one-to-one with the machine learning-based rule engine configuration method in the above embodiments. For example... Figure 8 As shown, the machine learning-based rule engine configuration device includes a data acquisition module 810, a training module 820, a configuration module 830, a generation module 840, and an analysis module 850. Detailed descriptions of each functional module are as follows:

[0108] The data acquisition module 810 collects historical computational data and performance metrics to build a training dataset.

[0109] The training module 820 is used to train a machine learning model and dynamically optimize the algorithm parameters of the rule engine using the training dataset.

[0110] Configuration module 830 is used to configure the expressions and custom functions of the rule engine, and implements script parsing and execution through JEXL;

[0111] The generating module 840 is configured to establish a dynamic mapping relationship between an algorithm configuration library and a business variable, map an algorithm variable name and a business variable name, and generate a configurable algorithm rule.

[0112] The analysis module 850 is configured to analyze a task load and a resource requirement based on a pre-trained machine learning model, allocate a system resource, and repair an abnormal behavior in a calculation process.

[0113] In an embodiment, the extracting module 810 is specifically configured to:

[0114] extract a performance index in a historical calculation task, the performance index including a calculation time, a memory occupation, and an error rate;

[0115] clean up noise and an abnormal value in the historical calculation data to generate a standardized training sample;

[0116] label an optimization target of the training sample, the optimization target including a calculation efficiency improvement and a resource occupation reduction.

[0117] In an embodiment, the generating module 820 is specifically configured to:

[0118] construct a neural network model, an input of the neural network model being the historical calculation data and the performance index in the historical calculation task, and an output of the neural network model being an optimized algorithm parameter;

[0119] iteratively train the neural network model, and dynamically adjust a parameter optimization strategy through a reinforcement learning algorithm;

[0120] verify a performance of the neural network model to ensure that the optimized algorithm parameter meets a preset efficiency improvement threshold.

[0121] In an embodiment, the generating module 830 is specifically configured to:

[0122] parse expression logic in a business scenario to generate a configurable script template;

[0123] load the script template to the rule engine, and dynamically execute an expression through a JEXL engine;

[0124] verify a script execution result to ensure consistency with a business requirement.

[0125] In an embodiment, the obtaining module 850 is specifically configured to:

[0126] detect a calculation deviation and a data error, and identify an abnormal point based on an abnormal score formula, wherein the abnormal score = σx-μ;

[0127] match an abnormal mode and a pre-trained repair model to generate a correction value.

[0128] Triggering an automatic repair process, adjusting calculation parameters or reallocating task resources.

[0129] In an embodiment, the acquisition module 850 is specifically further used for:

[0130] Predicting task load, estimating resource demand through a time series model;

[0131] Allocating resource proportion, scheduling tasks according to a load balancing formula, resource allocation proportion = task load / total load;

[0132] Scheduling calculation tasks to nodes with the lowest load.

[0133] In an embodiment, the acquisition module 850 is further used for:

[0134] Monitoring the execution state of the rule engine configuration task based on machine learning;

[0135] Building a data bloodline map;

[0136] Embedding the data bloodline map into a low-dimensional space to generate visual coordinates through a Node2Vec model;

[0137] Locating the root cause of the problem, backtracking the dependency path of the abnormal data based on a graph traversal algorithm, generating visual coordinates and locating the root cause of the problem.

[0138] The application provides a scheme provided by a rule engine configuration device based on machine learning, constructs a training data set by collecting historical calculation data and performance indicators, compared with a mode of setting fixed parameters by relying on artificial experience of a traditional rule engine, provides a scientific basis for optimization of the rule engine in a data-driven manner, and improves the pertinence and accuracy of parameter optimization. A machine learning model is trained and algorithm parameters are dynamically optimized, a JEXL based on machine learning is combined with the rule engine configuration based on machine learning to flexibly configure expressions and self-defined functions, and dynamic mapping of an algorithm configuration library and business variables is established, so that intelligentization and configurability of the rule engine are effectively realized, the disadvantages of frequent code modification caused by rule changes in a traditional hard coding mode are avoided, and a high-quality rule system suitable for dynamic changes of business is formed. The rule engine is comprehensively optimized by means of the machine learning model, including dynamic adjustment of parameters, intelligent allocation of resources and automatic repair of exceptions, compared with a mode of static running, unbalanced resource allocation and passive exception processing of the traditional rule engine, the rule engine can more accurately adapt to different task loads, improve rule execution efficiency and system stability, and provide more efficient and reliable rule support for business decision-making. The machine learning and the rule engine are deeply integrated, the automation and intelligentization of rule configuration are realized, and the limitations of the traditional rule engine in flexibility, adaptability and efficiency are broken. In the field of financial technology, the real-time performance and accuracy of risk control rules are improved, and the transaction processing efficiency is optimized. In the field of medical health, dynamic adaptation and accurate execution of diagnosis and treatment rules are realized, and the quality of medical services is improved. The method realizes double improvement of configuration quality and running efficiency of the rule engine in a complex business scenario, and provides strong technical support for automatic decision-making of various industries.

[0139] In summary, the scheme realized by the rule engine configuration method based on machine learning can solve the problems of low processing efficiency, high maintenance cost, insufficient intelligentization, unreasonable resource allocation and poor scalability of the existing technology in the configuration and running process of the rule engine, and cannot meet the needs of large-scale and high-complexity business scenarios.

[0140] The specific limitations of the rule engine configuration device based on machine learning can be referred to the limitations of the rule engine configuration method based on machine learning in the foregoing, and will not be described here. The modules in the rule engine configuration device based on machine learning can be realized by software, hardware and combinations thereof in whole or in part. The modules can be embedded in or independent of the processor in the computer device in the form of hardware, or stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations of the modules.

[0141] In one embodiment, a computer device can be a server, and an internal structure diagram of the computer device can be as shown in Figure 9As shown in the figure. The computer device includes a processor, a memory, a network interface and a database connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile and / or volatile storage media, internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with the external client through the network connection. The computer program is executed by the processor to realize the functions or steps of the server side of the optimal strategy recommendation method.

[0142] In one embodiment, a computer device is provided, which can be a client, and its internal structure diagram can be as shown in the figure. Figure 10 As shown in the figure. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile storage media, internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with the external server through the network connection. The computer program is executed by the processor to realize the functions or steps of the client side of the optimal strategy recommendation method.

[0143] In one embodiment, a computer device is provided, including a memory, a processor and a computer program stored on the memory and executable on the processor, and the processor executes the computer program to realize the following steps:

[0144] Collect performance indicators in historical computing data and historical computing tasks to build a training data set;

[0145] Train a machine learning model, and dynamically optimize the algorithm parameters of the rule engine using the training data set;

[0146] Configure the expressions and custom functions of the rule engine, and realize the parsing and execution of scripts through JEXL;

[0147] Establish a dynamic mapping relationship between the algorithm configuration library and the business variables, map the algorithm variable name and the business variable name, and generate configurable algorithm rules;

[0148] Based on the pre-trained machine learning model, analyze the task load and resource demand, allocate system resources, and repair abnormal behaviors in the computing process.

[0149] In one embodiment, a computer readable storage medium is provided, and a computer program is stored on the computer readable storage medium, and the computer program is executed by a processor to implement the following steps:

[0150] Collecting performance indicators in historical computing data and historical computing tasks to construct a training data set;

[0151] Training a machine learning model, and dynamically optimizing algorithm parameters of the rule engine using the training data set;

[0152] Configuring expressions and custom functions of the rule engine, and realizing script parsing and execution through JEXL;

[0153] Establishing a dynamic mapping relationship between the algorithm configuration library and the business variable, mapping the algorithm variable name and the business variable name, and generating a configurable algorithm rule;

[0154] Based on the pre-trained machine learning model, analyzing task load and resource demand, allocating system resources, and repairing abnormal behavior in the computing process.

[0155] It should be noted that the functions or steps that the computer readable storage medium or the computer device can implement above can be referred to the related descriptions of the server side and the client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0156] Those skilled in the art can understand that all or part of the processes in the foregoing embodiment methods can be completed by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, it can include the processes of the foregoing embodiments. Any reference to memory, storage, database or other medium used in the embodiments provided in the present application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM) and memory bus dynamic RAM (RDRAM) and the like.

[0157] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above-mentioned division of each functional unit and module is exemplified, and in actual application, the above-mentioned functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above.

[0158] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can be modified, or some technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A method for configuring a rule engine based on machine learning, characterized in that, include: Collect historical computing data and performance metrics from historical computing tasks to construct a training dataset; Train a machine learning model and dynamically optimize the algorithm parameters of the rule engine using the training dataset; Configure the expressions and custom functions of the rule engine, and use JEXL to parse and execute the script; Establish a dynamic mapping relationship between the algorithm configuration library and business variables, map algorithm variable names to business variable names, and generate configurable algorithm rules; Based on pre-trained machine learning models, the system analyzes task load and resource requirements, allocates system resources, and corrects abnormal behavior during the computation process.

2. The rule engine configuration method based on machine learning according to claim 1, characterized in that, The collection of historical computing data and performance metrics from historical computing tasks is used to construct a training dataset, including: Extract performance metrics from historical computing tasks, including computation time, memory usage, and error rate; Clean the noise and outliers from the historical computational data to generate standardized training samples; The optimization objectives for the training samples are labeled, including improving computational efficiency and reducing resource consumption.

3. The rule engine configuration method based on machine learning according to claim 1, characterized in that, The training of the machine learning model, utilizing the training dataset to dynamically optimize the algorithm parameters of the rule engine, includes: A neural network model is constructed, wherein the input of the neural network model is the historical computing data and the performance indicators in the historical computing tasks, and the output of the neural network model is the optimized algorithm parameters; The neural network model is trained iteratively, and the parameter optimization strategy is dynamically adjusted through reinforcement learning algorithm. Verify the performance of the neural network model to ensure that the optimized algorithm parameters meet the preset efficiency improvement threshold.

4. The rule engine configuration method based on machine learning according to claim 1, characterized in that, The expressions and custom functions configured for the rule engine are parsed and executed using JEXL, including: Parse the expression logic in the business scenario and generate configurable script templates; Load the script template into the rule engine, and dynamically execute the expression through the JEXL engine; Verify the script execution results to ensure they match business requirements.

5. The rule engine configuration method based on machine learning according to claim 1, characterized in that, The pre-trained machine learning model analyzes task load and resource requirements, allocates system resources, and corrects abnormal behavior during the computation process, including: Detect calculation biases and data errors, and identify outliers based on the outlier score formula, where outlier score = σx - μ; Match the abnormal pattern with the pre-trained repair model to generate a correction value; Trigger an automatic repair process to adjust calculation parameters or reallocate task resources.

6. The rule engine configuration method based on machine learning according to claim 1, characterized in that, The pre-trained machine learning model analyzes task load and resource requirements, allocates system resources, and corrects abnormal behavior during the computation process, including: Predict task load and estimate resource requirements using time series models; Allocate resources according to the load balancing formula: resource allocation ratio = task load / total load; Schedule computing tasks to the node with the lowest load.

7. The rule engine configuration method based on machine learning according to claim 1, characterized in that, After analyzing task load and resource requirements, allocating system resources, and correcting abnormal behavior during the computation process using the pre-trained machine learning model, the process also includes: Constructing a data lineage map; Embed the data lineage map into a low-dimensional space and generate visual coordinates using the Node2Vec model; To pinpoint the root cause of the problem, a graph traversal algorithm is used to backtrack the dependency paths of the abnormal data, generate visual coordinates, and locate the root cause of the problem.

8. A rule engine configuration device based on machine learning, characterized in that, include: The data acquisition module collects historical computational data and performance metrics to build a training dataset; The training module is used to train the machine learning model and dynamically optimize the algorithm parameters of the rule engine using the training dataset. The configuration module is used to configure the expressions and custom functions of the rule engine, and uses JEXL to parse and execute scripts. The generation module is used to establish a dynamic mapping relationship between the algorithm configuration library and business variables, mapping algorithm variable names to business variable names, and generating configurable algorithm rules. The analysis module is used to analyze task load and resource requirements based on pre-trained machine learning models, allocate system resources, and fix abnormal behaviors during the computation process.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the machine learning-based rule engine configuration method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the machine learning-based rule engine configuration method as described in any one of claims 1 to 7.

Images