Rule engine quality inspection method and device, storage medium and computer program product

Abstract

The invention discloses a rule engine quality inspection method and device, a storage medium and a computer program product, and relates to the technical field of software testing, the method comprises the following steps: receiving an expected target description input by a user, and determining an executable script code corresponding to a rule engine to be subjected to quality inspection based on the expected target description; extracting parameter information corresponding to the rule definition text of the rule engine to be subjected to quality inspection; embedding the expected target description, the executable script code and the parameter information into a preset cue word template; and calling a quality inspection model to perform quality inspection on the cue word template to obtain a rule engine quality inspection result. The rule engine is converted into the script code based on the mainstream computer programming language from the proprietary grammar, so that the quality inspection efficiency and the quality inspection accuracy of the quality inspection model on the rule engine are improved.

Description

Technical Field

[0001] The present application relates to the field of software testing, and in particular to a rule engine quality inspection method, device, storage medium, and computer program product. Background Art

[0002] Rule engines are widely used in fields like finance and insurance, defining complex business rules using XML. While XML decouples rules from business systems, its syntax contains numerous proprietary tags, and the syntax varies significantly between rule engines. Rule definition text is lengthy and highly specialized. With the rapid development of quality inspection models, large language models have been explored for use in rule engine quality inspection. However, due to the lengthy and highly specialized rule definition text, it exceeds the context window that the model can process at a single time. Furthermore, the semantic logic of XML tags is private domain knowledge, and quality inspection models lack pre-trained data for proprietary tags, making it difficult to accurately parse rule logic.

[0003] Therefore, how to improve the quality inspection efficiency and accuracy of the quality inspection model for the rule engine has become an urgent problem that needs to be solved in this application.

[0004] The above content is only used to assist in understanding the technical solution of this application and does not constitute an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a rule engine quality inspection method, device, storage medium and computer program product, aiming to improve the quality inspection efficiency and quality inspection accuracy of the rule engine by the quality inspection model.

[0006] To achieve the above objectives, this application proposes a rule engine quality inspection method, which includes:

[0007] Receive the expected target description from the user,

[0008] Determine the executable script code corresponding to the rule engine to be inspected based on the expected target description;

[0009] Extracting parameter information corresponding to the rule definition text in the rule engine to be inspected;

[0010] Embedding the expected target description, the executable script code, and the parameter information into a preset prompt word template;

[0011] The quality inspection model is called to perform quality inspection on the prompt word template to obtain the rule engine quality inspection result.

[0012] In one embodiment, the step of determining the executable script code corresponding to the rule engine to be inspected based on the expected target description includes:

[0013] Determine the rule engine to be inspected according to the expected target description, and query whether there is an executable script code corresponding to the rule version number of the rule engine to be inspected in the script repository;

[0014] If there is an executable script code corresponding to the rule version number, then verify the consistency of the association between the rule version and the executable script code;

[0015] If the association consistency check passes, it is determined that the rule version of the rule engine to be inspected already has executable script code, and the executable script code is directly called;

[0016] If there is no executable script code corresponding to the rule version number, the engine parses the rule to be inspected to obtain the rule definition text, and generates an executable script code according to the rule definition text.

[0017] In one embodiment, the step of parsing the to-be-checked rule engine to obtain a rule definition text and generating an executable script code according to the rule definition text includes:

[0018] Parsing the rule engine to be inspected to obtain a rule definition text, and generating a structured abstract syntax tree according to the rule definition text;

[0019] Analyzing syntax errors and logical conflicts of the structured abstract syntax tree, and automatically correcting the syntax errors and logical conflicts using a predefined rule base;

[0020] The automatically corrected structured abstract syntax tree is converted into executable script code of the target script language through the semantic mapping rule library.

[0021] In one embodiment, the step of extracting parameter information corresponding to the rule definition text in the rule engine to be inspected includes:

[0022] Extract the Chinese name, English name, data type and parameter group information of the parameter field in the rule definition text of the rule engine to be inspected;

[0023] The Chinese name, the English name, the data type, and the parameter group information are sorted in a list format to obtain parameter information.

[0024] In one embodiment, the step of embedding the expected target description, the executable script code, and the parameter information into a preset prompt word template includes:

[0025] Performing natural language processing on the expected target description to extract key entities and processing logic, and generating a standardized semantic description based on the key entities and the processing logic, wherein the natural language processing includes entity recognition, semantic standardization, and intent verification;

[0026] Performing context enhancement on the standardized semantic description based on a domain knowledge base, extracting relevant terms and appending them to a preset prompt word template;

[0027] The standardized semantic description, the executable script code, and the parameter information are respectively embedded in the prompt word template.

[0028] In one embodiment, the quality inspection model adopts a master-slave model architecture, and the step of calling the quality inspection model to perform quality inspection on the prompt word template and obtaining the rule engine quality inspection result includes:

[0029] Calling a quality inspection model and passing the prompt word template into the quality inspection model for quality inspection, wherein the quality inspection model includes a master model and a slave model. The master model detects conditional branch coverage, logical contradictions, and compliance of the executable script code, and the slave model verifies the numerical calculation link and formula accuracy.

[0030] The output results of the master model and the output results of the slave model are integrated to obtain the rule engine quality inspection results.

[0031] In one embodiment, after the step of calling the quality inspection model to perform quality inspection on the prompt word template and obtaining the rule engine quality inspection result, the following steps are further included:

[0032] The rule engine quality inspection results are associated with the logic blocks of the executable script code, and an interactive flow chart is generated through a visual interpretation module.

[0033] In addition, to achieve the above-mentioned purpose, the present application also proposes a rule engine quality inspection device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the computer program is configured to implement the steps of the rule engine quality inspection method described above.

[0034] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the rule engine quality inspection method described above are implemented.

[0035] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the rule engine quality inspection method described above.

[0036] One or more technical solutions proposed in this application have at least the following technical effects:

[0037] The system receives a user-entered description of an expected goal and, based on the description, determines the executable script code corresponding to the rule engine to be inspected. It then extracts parameter information corresponding to the rule definition text in the rule engine to be inspected. The description, executable script code, and parameter information are embedded into a preset prompt word template. The quality inspection model is then invoked to perform quality inspection on the prompt word template, yielding a rule engine quality inspection result. First, determining the executable script code based on the expected goal description avoids repeated parsing and conversion of XML rule definition text, reducing redundant computation and resource consumption, and shortening the quality inspection process. Furthermore, the executable script code uses a scripting language more familiar to the quality inspection model, lowering the threshold for the quality inspection model to understand rule logic and avoiding logical misjudgments caused by ambiguous proprietary tags. Furthermore, parameter information eliminates ambiguity in natural language descriptions and is embedded into the prompt word template, reducing the computational overhead of the quality inspection model in parsing unstructured text and improving input processing speed. Finally, the quality inspection model is invoked to perform quality inspection on the prompt word template. The quality inspection model covers different quality inspection dimensions, reducing the number of iterations required for a single quality inspection and improving overall response speed. In summary, this application improves the quality inspection efficiency and accuracy of the quality inspection model for the rule engine by converting the rule engine from a proprietary syntax in XML format to a script code based on a mainstream computer programming language. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0039] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0040] Figure 1 A flowchart of the first embodiment of the rule engine quality inspection method of this application is provided;

[0041] Figure 2 A flowchart of the second embodiment of the rule engine quality inspection method provided in this application;

[0042] Figure 3 A flowchart of the third embodiment of the rule engine quality inspection method provided in this application;

[0043] Figure 4 A flowchart of the fifth embodiment of the rule engine quality inspection method provided in this application;

[0044] Figure 5 This is a schematic diagram of the module structure of the rule engine quality inspection device according to an embodiment of the present application;

[0045] Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the rule engine quality inspection method in the embodiment of the present application.

[0046] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0047] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0048] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0049] The main solution of the embodiment of the present application is: receiving the expected target description input by the user; determining the executable script code corresponding to the rule engine to be quality inspected based on the expected target description; extracting the parameter information corresponding to the rule definition text in the rule engine to be quality inspected; embedding the expected target description, the executable script code, and the parameter information into a preset prompt word template; calling the quality inspection model to perform quality inspection on the prompt word template to obtain the rule engine quality inspection result.

[0050] In this embodiment, for ease of description, the following description is made with the rule engine quality inspection device as the execution entity.

[0051] The embodiments of the present application take into account that: since rule engines are widely used in finance, insurance and other fields, complex business rules are defined in XML format. Although the XML format decouples rules from business systems, its syntax contains a large number of proprietary tags and the syntax of different engines varies significantly, resulting in lengthy and highly specialized rule definition texts. Traditional quality inspection methods rely on manual review of the integrity and compliance of rule logic, and have the defects of low efficiency and high missed detection rate. With the rapid development of large language models, large language models have been attempted to be used for rule quality inspection, but in actual applications, they face the following technical bottlenecks: The input text is too long: the quality inspection model needs to receive the rule definition text and the complete XML syntax description at the same time, which exceeds the context window limit of the model's single processing, resulting in a sharp increase in response delays and resource consumption. Insufficient understanding of proprietary grammar: The semantic logic of XML tags belongs to non-public domain knowledge. The quality inspection model lacks pre-training data for proprietary tags, making it difficult to accurately parse the rule logic.

[0052] Therefore, the present application provides a solution, which receives the expected target description input by the user, determines the executable script code corresponding to the rule engine to be inspected based on the expected target description; extracts the parameter information corresponding to the rule definition text in the rule engine to be inspected; embeds the expected target description, the executable script code, and the parameter information into a preset prompt word template; calls the quality inspection model to perform quality inspection on the prompt word template to obtain the rule engine quality inspection result. First, the executable script code is determined by the expected target description, avoiding repeated parsing and conversion of the XML rule definition text, reducing redundant calculations and resource consumption, and shortening the time-consuming quality inspection process. Furthermore, the executable script code uses a scripting language that the quality inspection model is more familiar with, lowering the threshold for the quality inspection model to understand the rule logic and avoiding logical misjudgments caused by the ambiguity of proprietary tags. Furthermore, the parameter information eliminates the ambiguity of the natural language description and embeds the prompt word template, reducing the computational overhead of the quality inspection model in parsing unstructured text and improving the input processing speed. Finally, the quality inspection model is called to perform quality inspection on the prompt word template. The quality inspection model covers different quality inspection dimensions, reduces the number of iterations of a single quality inspection, and improves the overall response speed. In summary, this application improves the quality inspection efficiency and accuracy of the quality inspection model for the rule engine by converting the rule engine from a proprietary syntax in XML format to a script code based on a mainstream computer programming language.

[0053] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device capable of performing the above functions, a rule engine quality inspection device, etc. The following uses the rule engine quality inspection device as an example to illustrate this embodiment and the following embodiments.

[0054] Based on this, the embodiment of the present application provides a rule engine quality inspection method, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the rule engine quality inspection method of this application.

[0055] In this embodiment, the rule engine quality inspection method includes steps S10 to S50:

[0056] Step S10, receiving the expected target description input by the user;

[0057] The user enters a target description through the interactive interface. This target description is a clear description of the specific business logic objectives that the rule engine needs to achieve, entered in natural language. For example, in a simplified individual income tax calculation process, a rule quality check step might look like this: "Calculate the individual income tax payable this month, deducting pension, medical, unemployment insurance, and provident fund contributions, and subtracting a 5,000 yuan exemption."

[0058] Step S20, determining the executable script code corresponding to the rule engine to be inspected based on the expected target description;

[0059] According to the expected goal description of the rule entered by the user, the rule engine name and version number can be extracted, and the rule version unique identifier can be generated from the rule engine name and version number. The rule version unique identifier is composed of a combination of the rule ID and the semantic version number. According to the rule version unique identifier, the relational database or distributed file system is searched to see whether there is an executable script file corresponding to the rule version unique identifier.

[0060] If there is an executable script file corresponding to the unique identifier of the rule version in the relational database or distributed file system, the executable script file is directly called to execute the next step; if there is no executable script file corresponding to the unique identifier of the rule version, an executable script file corresponding to the unique identifier of the rule version needs to be generated.

[0061] Step S30, extracting parameter information corresponding to the rule definition text in the rule engine to be inspected;

[0062] Parse the rule definition text (XML format), identify tags and their attributes, extract fields including Chinese and English names, and data types, and perform mandatory field verification and data type standardization. Mandatory field verification checks whether the extracted fields are missing and, if so, automatically generates default values ​​based on the context. Data type standardization converts non-standard data types into types supported by the scripting language. Furthermore, the extracted fields are organized according to a pre-set format, with each parameter mapped as an independent object and integrated into parameter information.

[0063] Step S40, embedding the expected target description, the executable script code, and the parameter information into a preset prompt word template;

[0064] The preset prompt template includes the following labeled areas: target description, script code, and parameter list. Before embedding the prompt template, pre-processing is performed: the user's natural language description is cleaned to remove colloquial vocabulary, correct typos, and segment the description into logical paragraphs to ensure semantic coherence. Code comments are added to the script code to mark key logical nodes, and variable declarations are automatically generated based on the parameter list. Long text is split into logical units, unique identifiers are generated for each sub-block, and dependencies between sub-blocks are recorded. The pre-processed target description, executable script code, and parameter information are then embedded into the preset prompt template.

[0065] Step S50: calling the quality inspection model to perform quality inspection on the prompt word template to obtain the rule engine quality inspection result.

[0066] The prompt word template is split into multiple sub-blocks based on logical paragraphs, and each sub-block is assigned a unique identifier. Based on the context window restrictions of the quality inspection model, the sub-blocks are loaded in order of priority, with priority given to logical blocks that are strongly related to the current quality inspection task, ensuring that core quality inspection requirements are fully covered. The prompt word template is quality inspected by the quality inspection model, and its output results are scored with confidence. A comprehensive quality inspection report is generated based on the weighted integration.

[0067] This embodiment provides a rule engine quality inspection method, which receives a user-entered expected goal description, determines executable script code corresponding to the rule engine to be inspected based on the expected goal description, extracts parameter information corresponding to the rule definition text in the rule engine to be inspected, embeds the expected goal description, the executable script code, and the parameter information into a preset prompt word template, and invokes a quality inspection model to perform quality inspection on the prompt word template, thereby obtaining a rule engine quality inspection result. First, the executable script code is determined based on the expected goal description, avoiding repeated parsing and conversion of XML rule definition text, reducing redundant computation and resource consumption, and shortening the quality inspection process. Furthermore, the executable script code uses a scripting language more familiar to the quality inspection model, lowering the threshold for the quality inspection model to understand rule logic and avoiding logical misjudgments caused by proprietary tag ambiguity. Furthermore, the parameter information eliminates ambiguity in natural language descriptions and is embedded in the prompt word template, reducing the computational overhead of the quality inspection model in parsing unstructured text and improving input processing speed. Finally, the quality inspection model is invoked to perform quality inspection on the prompt word template. The quality inspection model covers different quality inspection dimensions, reducing the number of iterations for a single quality inspection and improving overall response speed. In summary, this application improves the quality inspection efficiency and accuracy of the quality inspection model for the rule engine by converting the rule engine from a proprietary syntax in XML format to a script code based on a mainstream computer programming language.

[0068] In a feasible implementation, step S20 may include steps S21 to S24:

[0069] Step S21: determining the rule engine to be inspected according to the expected target description, and querying whether there is an executable script code corresponding to the rule version number of the rule engine to be inspected in the script repository;

[0070] The expected target description entered by the user is segmented to extract key entities and operation verbs. Based on the extracted keywords, the corresponding rule engine instance is matched from the rule engine registry to determine the rule engine that needs to be quality checked.

[0071] Furthermore, a rule version number is generated based on the semantics of the user input and the rule engine update log. The rule engine name and version number are concatenated to create a unique identifier for subsequent script repository queries. Script code files are named according to the rule version unique identifier and stored in the script repository. SQL statements are executed, and the script repository is scanned based on the unique identifier to match executable script code corresponding to the rule version of the rule engine under quality inspection.

[0072] Step S22: If there is an executable script code corresponding to the rule version number, verify the consistency of the association between the rule version and the executable script code;

[0073] If there is an executable script code corresponding to the rule version number, the association consistency between the rule version and the executable script code is verified. The specific association consistency verification process includes: hash value consistency verification, calculating the SHA-256 hash value of the current rule definition text (XML format), and comparing it with the hash value recorded in the script metadata; timestamp verification, obtaining the last modification time of the rule definition and the script generation time, and judging whether the script generation time and the last modification time are consistent.

[0074] Step S23: If the association consistency check passes, it is determined that the rule version of the rule engine to be inspected already has executable script code, and the executable script code is directly called;

[0075] If the associated consistency check passes, the executable script is loaded from the script repository and the access timestamp of the script metadata is updated for heat analysis and cache optimization. If the script fails to load, an alarm is triggered and the manual processing process is returned. The verification log, including the hash value, timestamp, and operation results, is recorded for audit tracking. If the script loads successfully, it indicates that the rule version of the rule engine to be inspected already has executable script code, eliminating the need to generate additional script code. In subsequent steps, the script code can be directly called.

[0076] Step S24: If there is no executable script code corresponding to the rule version number, the engine of the rule to be inspected is parsed to obtain the rule definition text, and an executable script code is generated according to the rule definition text.

[0077] Specifically, the rule definition text in XML format is extracted from the rule engine to be inspected, including structured tag content such as logical conditions, execution actions, parameter definitions, etc. For example, for the individual tax calculation rule, the XML fragment containing the "three insurances and one fund total amount calculation" logic is extracted.

[0078] The XML rule definition text is parsed into an intermediate representation (IR). The IR describes the hierarchical relationship of the rule logic in a tree structure, removes redundant tags (such as comments and empty tags), and merges consecutive operations of the same type. The IR is converted into executable code in the target scripting language (such as AviatorScript). The conversion process includes: logical mapping, mapping the semantics of XML tags to the grammatical elements of the scripting language; parameter adaptation, generating variable declarations and references in the script based on parameter definitions; and code optimization, simplifying redundant logic, removing unreferenced parameters, and merging repeated calculation steps.

[0079] In a feasible implementation, step S30 may include steps S31 to S32:

[0080] Step S31, extracting the Chinese name, English name, data type and parameter group information of the parameter field in the rule definition text of the rule engine to be inspected;

[0081] Use XPath expressions to locate all parameter fields in the XML rule definition text and extract the Chinese name, English name, data type, and parameter array information of the parameter field. Furthermore, check whether the Chinese and English names of the parameter field are missing. If the Chinese name is missing, generate a default name based on the context; if the English name is missing, convert the Chinese name to camel case to form the corresponding English name. Convert non-standard data types into types supported by the target scripting language; verify whether the parameter group information exists in the rule definition. If not, automatically create a default parameter group and ensure that the parameters are actually referenced in the script code.

[0082] Step S32: Arrange the Chinese name, the English name, the data type, and the parameter group information in a list format to obtain parameter information.

[0083] Map the Chinese name, English name, data type, and parameter group information to independent JSON objects, aggregate all parameter objects into a JSON array, and form complete parameter information in list format. Associate the parameter information with the unique identifier of the rule version to ensure strict synchronization between the parameter information and the script code; record the verification results in the metadata of the parameter list information for subsequent quality inspection reference. Store the parameter information in a parameter database or file system for subsequent quality inspection reference.

[0084] Based on the first embodiment of the present application, the second embodiment of the present application is proposed. In the second embodiment of the present application, the same or similar contents as those of the above-mentioned first embodiment can be referred to the above introduction and will not be repeated hereafter.

[0085] On this basis, please refer to Figure 2 , Figure 2 A flow chart of the second embodiment of the rule engine quality inspection method provided in this application.

[0086] In this embodiment, the step S24 of parsing the rule engine to be inspected to obtain the rule definition text and generating the executable script code according to the rule definition text may include steps S241 to S243:

[0087] Step S241: parsing the rule engine to be inspected to obtain a rule definition text, and generating a structured abstract syntax tree according to the rule definition text;

[0088] The ANTLR parser is used to parse the XML rule definition text and extract the following key nodes: logic nodes (conditional branches, execution actions, and rule groups); computation nodes (arithmetic operations and parameter references); and parameter nodes (field definitions and data types). A tree structure is constructed based on these key nodes. The hierarchy of this tree structure reflects the nested relationship of XML tags. Comments, empty tags, and unreferenced parameter nodes are removed from the tree structure, and consecutive operations of the same type are merged to obtain a structured abstract syntax tree.

[0089] Furthermore, the structured abstract syntax tree is serialized into JSON or binary format, stored in an intermediate representation library, and associated with a unique identifier of the rule version.

[0090] It should be noted that the ANTLR parser provides a framework for automatically constructing recognizers, compilers, and interpreters of custom languages ​​through grammatical descriptions. The ANTLR parser can accurately parse XML rule definition texts.

[0091] Step S242, analyzing syntax errors and logical conflicts of the structured abstract syntax tree, and automatically correcting the syntax errors and logical conflicts using a predefined rule base;

[0092] Syntax error detection specifically includes: tag closure check: detecting unclosed XML tags and locating them to specific line numbers; attribute integrity check: checking for missing required attributes; data type conflict: detecting the compatibility of parameter types and operators.

[0093] Logical conflict analysis specifically includes: uninitialized variable references: identifying variables referenced in the script that are not declared in the parameter list; infinite loop conditions: detecting loop conditions that are always true or always false; redundant logic: discovering repeated conditional judgments.

[0094] If the above syntax errors or logical conflicts are found, the predefined rule library will be used to automatically correct the syntax errors and logical conflicts. The automatic corrections of the predefined rule library include: tag completion: automatically completing missing closing tags; default value filling: assigning default values ​​to missing attributes; logic optimization: deleting redundant conditions or merging repeated calculation steps.

[0095] Step S243 : converting the automatically corrected structured abstract syntax tree into executable script code of the target script language through a semantic mapping rule library.

[0096] The nodes of the revised structured abstract syntax tree are converted into executable script code of the target script language according to the mapping rules of the semantic mapping rule library, and the code structure is adjusted according to the parent node type, and parameter type safety conversion is performed to obtain the final executable script code.

[0097] In this embodiment, a structured abstract syntax tree is used to ensure semantic consistency between XML tags and script codes, avoiding conversion ambiguity. Automatic correction of the predefined rule base eliminates low-level errors caused by human negligence. The intermediate representation of the structured abstract syntax tree accelerates subsequent conversion and quality inspection processes, code optimization reduces redundant calculations, and improves script execution efficiency. The semantic mapping rule base supports flexible expansion, adapts to XML variants of different rule engines, and supports the generation of multi-target script languages.

[0098] Based on the first embodiment and / or the second embodiment of the present application, the third embodiment of the present application is proposed. In the third embodiment of the present application, the same or similar contents as those in the above embodiments can be referred to the above introduction and will not be repeated hereafter.

[0099] On this basis, please refer to Figure 3 , Figure 3 A flowchart of the third embodiment of the rule engine quality inspection method provided in this application.

[0100] In this embodiment, the step S40 of embedding the expected target description, the executable script code, and the parameter information into a preset prompt word template may include steps S41 to S43:

[0101] Step S41, performing natural language processing on the expected target description, extracting key entities and processing logic, and generating a standardized semantic description based on the key entities and the processing logic, wherein the natural language processing includes entity recognition, semantic standardization, and intent verification;

[0102] A domain-customized model based on the BERT architecture is used to extract the following entities from the expected target description entered by the user: parameter entities: such as "three insurances and one fund" and "exemption amount"; operation entities: such as "calculation" and "deduction"; compliance terms: such as "Article X of the Personal Income Tax Law".

[0103] Convert unstructured descriptions into logical expressions and mark the operation priority. For example, if the logical expression is taxable income = this month's income - total of three insurances and one fund - exemption amount, the operation priority is: deduct the three insurances and one fund first, then deduct the exemption amount.

[0104] Semantic standardization refers to the conversion of colloquial expressions into standard terms, such as converting pension money into pension insurance amounts; logical chain completion: detecting logical missing items (such as it is not clear that "three insurances and one fund" includes "provident fund"), and automatically completing them based on predefined rules (such as adding "including pension, medical care, unemployment and provident fund").

[0105] Intent verification and conflict detection include: Integrity verification: Check whether the logic chain covers all required parameters. For example, when it is detected that "three insurances and one fund" does not include "provident fund", a warning prompt is generated; Conflict resolution: If contradictory operations are detected (such as "deduct A" and "accumulate A" coexisting), the main logic is automatically selected according to the context priority (such as the latest operation).

[0106] Step S42: contextually enhance the standardized semantic description based on the domain knowledge base, extract relevant terms and append them to a preset prompt word template;

[0107] Enhanced contextual search specifically includes: Dynamic knowledge base search: Keyword matching and clause extraction. Based on entities in standardized semantic descriptions (such as "individual tax calculation"), relevant clauses (such as the "Regulations for the Implementation of the Individual Income Tax Law") are retrieved from domain knowledge bases (such as the tax regulations library) to extract key content (such as "Three Insurances and One Housing Fund must include pension, medical, unemployment, and provident fund"). Clause formatting and weighting are performed, with clauses graded by importance (e.g., "Mandatory Compliance Items" > "Recommended Items") and labeled with confidence levels (e.g., 100% confidence for regulatory clauses, 80% for industry recommendations).

[0108] Context enhancement and dynamic update: Real-time synchronization of external knowledge bases, updating of regulatory clauses through API interfaces (such as the State Administration of Taxation data interface) to ensure the timeliness of the knowledge base, and construction of context association graphs: associating clauses with parameters and script logic to generate traceable reference relationships.

[0109] After the above domain knowledge base context enhancement operation, the relevant clauses are appended to the end of the prompt word template according to priority. If a conflict between the script logic and the clause is detected, a high-risk warning mark is inserted into the prompt word.

[0110] Step S43: embed the standardized semantic description, the executable script code, and the parameter information into the prompt word template respectively.

[0111] The prompt word template adopts a structured design with labeled partitions. Standardized semantic descriptions, executable script code, and parameter information are embedded in each labeled partition. Specifically, the embedding process uses a logical segmentation strategy to split long text into independent sub-blocks based on function. Unique IDs are generated for each sub-block, and frequently accessed sub-blocks are cached in memory to reduce repeated parsing overhead.

[0112] Necessarily, sub-blocks are dynamically loaded and prioritized according to the context window restrictions of the quality inspection model, allowing the embedding of non-text data, such as screenshots of business process diagrams, to extract key information through OCR and convert it into text descriptions.

[0113] In this embodiment, semantic standardization and knowledge augmentation eliminate natural language ambiguity, addressing missed inspections in cases; proactively identifying logical contradictions reduces the error rate of quality inspection results; dynamic segmentation and caching adapt to the processing limitations of the quality inspection model, shortening the time required for a single quality inspection; tabular parameters and annotated scripts improve the efficiency of the quality inspection model in parsing structured input. Real-time knowledge base synchronization ensures that the quality inspection basis is consistent with the latest regulations; and clause grading and traceability support audit tracking and compliance verification. Through deep natural language analysis, dynamic knowledge augmentation, and intelligent input adaptation, the quality inspection model improves the efficiency and accuracy of the rule engine's quality inspection.

[0114] Based on the above embodiments of the present application, a fourth embodiment of the present application is proposed. In the fourth embodiment of the present application, the same or similar contents as those of the above embodiments can be referred to the above introduction and will not be repeated hereafter.

[0115] In this embodiment, the quality inspection model adopts a master-slave model architecture. The step S50 of calling the quality inspection model to perform quality inspection on the prompt word template and obtaining the rule engine quality inspection result includes steps S51 to S52:

[0116] Step S51: calling a quality inspection model and passing the prompt word template into the quality inspection model for quality inspection. The quality inspection model includes a master model and a slave model. The master model detects conditional branch coverage, logical contradictions, and compliance of the executable script code, and the slave model verifies the numerical calculation link and formula accuracy.

[0117] The quality inspection model utilizes a master-slave model architecture, comprising a master model and a slave model. Calling the quality inspection model to perform quality inspection on the prompt word template relies on multi-model collaborative quality inspection. Specifically, the master model is used to detect conditional branch coverage, logical contradictions, and compliance in the executable script code, while the slave model is used to verify the numerical calculation links and formula accuracy in the script. Using two quality inspection models with different capabilities (or different modules of the same model) to address different dimensions of rule logic, the comprehensiveness and accuracy of quality inspection are improved.

[0118] Specifically, large language models or knowledge-enhanced models can be used as master models, while Mathematica Kernel models and NumPy / Pandas numerical simulation models can be used as slave models. Inter-model communication overhead is reduced by simplifying data exchange formats using Protocol Buffers or JSON, and external interfaces are synchronized in real time via APIs to ensure compliance with the master model.

[0119] The specific steps for using the main model to check conditional branch coverage in executable script code include: Based on the abstract syntax tree of the script code, the main model traverses all conditional branches to check whether all business scenarios are covered; the coverage ratio is calculated by counting the number of covered branches relative to the total number of branches. The specific steps for detecting logical contradictions include: using a predefined logical rule base to detect conflicts and perform rule base matching; training the model based on historical quality inspection data to identify implicit logical contradictions. The specific steps for compliance verification include: comparing script logic with knowledge base clauses, detecting noncompliant lines, and interacting with the domain knowledge base.

[0120] The specific steps for using the model to verify the calculation links and formula accuracy in the script code include: using the symbolic execution tool from the model to parse the arithmetic expressions in the script, verify the logical integrity of the formula, and generate symbolic constraints to verify the mathematical correctness of the calculation path; performing numerical simulation and boundary testing, injecting extreme value test cases, executing the script and comparing the output with the expected results, detecting numerical overflow, loss of precision and type conversion errors; further, calculating the time complexity and space occupancy of the expression, and making optimization suggestions for high-risk calculations.

[0121] Step S52: The output result of the master model and the output result of the slave model are integrated to obtain a rule engine quality inspection result.

[0122] The confidence levels of the master and slave model outputs are weighted and merged. If the master and slave model conclusions conflict, the higher-confidence result is prioritized, and review suggestions are generated for the lower-confidence conclusion. The rule engine quality inspection results categorize and grade errors found during quality inspection by severity, pinpointing each error and providing corresponding correction suggestions.

[0123] In this embodiment, the main model ensures logical integrity, the slave model guarantees calculation accuracy, reduces missed detections, and the prompt word template splits the target description, script code, and parameter list into sub-blocks, which are dynamically loaded into the large model according to priority, adapting to the context window restrictions to avoid reasoning interruptions or performance degradation caused by excessively long input, thereby achieving efficient and accurate automated rule engine quality inspection.

[0124] Based on the above embodiments of the present application, a fifth embodiment of the present application is proposed. In the fifth embodiment of the present application, the same or similar contents as those in the above embodiments can be referred to the above introduction and will not be repeated hereafter.

[0125] On this basis, reference Figure 4 , Figure 4 This is a flowchart of the fifth embodiment of the present application. In this embodiment, after calling the quality inspection model to perform quality inspection on the prompt word template and obtaining the rule engine quality inspection result in step S50, step S60 is also included:

[0126] Step S60: Associating the rule engine quality inspection result with the logic block of the executable script code, and generating an interactive flowchart through a visual interpretation module.

[0127] The quality inspection results are linked to the logical blocks of the executable script code, and the logical blocks are converted into flowchart nodes, annotated with types and key code snippets. The nodes are then connected according to the logical jump relationships in the executable script code to form a directed graph. The directed graph is rendered using the visual interpretation module to form an interactive flowchart with support for zooming, dragging, and node highlighting.

[0128] Users can hover their mouse to display logic block code snippets and parameter references, and click on a node to pop up quality inspection results. Error nodes and their associated paths are automatically highlighted. Furthermore, quality inspection results are linked to flowchart nodes in real time, allowing the view to be dynamically updated via WebSocket or API. For example, when a user corrects a script, the flowchart automatically refreshes its error status.

[0129] In this embodiment, by accurately associating with script line numbers and logic blocks, the problem troubleshooting time is shortened, and the control flow diagram intuitively displays the script logic context, helping non-technical personnel understand the execution path of complex rule engines; dynamic highlighting and drill-down functions support in-depth analysis of nested logic problems, providing intuitive and efficient decision support tools for rule engine quality inspection.

[0130] This application also provides a rule engine quality inspection device, please refer to Figure 5 , the rule engine quality inspection device includes:

[0131] The expected goal description module 10 is used to receive the expected goal description input by the user;

[0132] An executable script code generation module 20 is used to determine the executable script code corresponding to the rule engine to be inspected based on the expected target description;

[0133] Parameter information extraction module 30, used to extract parameter information corresponding to the rule definition text in the rule engine to be inspected;

[0134] A prompt word template embedding module 40 is used to embed the expected target description, the executable script code, and the parameter information into a preset prompt word template;

[0135] The quality inspection module 50 is used to call the quality inspection model to perform quality inspection on the prompt word template and obtain the rule engine quality inspection result.

[0136] The rule engine quality inspection device provided in this application utilizes the rule engine quality inspection method of the above-mentioned embodiment to solve the technical problems of rule engine quality inspection. Compared with the prior art, the beneficial effects of the rule engine quality inspection device provided in this application are the same as those of the rule engine quality inspection method provided in the above-mentioned embodiment. The other technical features of the rule engine quality inspection device are the same as those disclosed in the above-mentioned embodiment method, and are not further described here.

[0137] The present application provides a rule engine quality inspection device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the rule engine quality inspection method in the above-mentioned embodiment one.

[0138] Reference below Figure 6 , which shows a schematic diagram of the structure of a rule engine quality inspection device suitable for implementing the embodiments of the present application. The rule engine quality inspection device in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (such as in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The rule engine quality inspection device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0139] like Figure 6As shown, the rule engine quality inspection device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory 1002 or programs loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the rule engine quality inspection device. The processing device 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: an input device 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the rule engine quality inspection device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a rule engine quality inspection device with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems can be implemented or have alternatively.

[0140] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a read-only memory 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are performed.

[0141] The rule engine quality inspection device provided in this application utilizes the rule engine quality inspection method of the above-mentioned embodiment to solve the technical problems of rule engine quality inspection. Compared with the prior art, the beneficial effects of the rule engine quality inspection device provided in this application are the same as those of the rule engine quality inspection method provided in the above-mentioned embodiment. The other technical features of the rule engine quality inspection device are the same as those disclosed in the above-mentioned embodiment, and are not further described here.

[0142] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0143] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0144] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer program) stored thereon, and the computer-readable program instructions are used to execute the rule engine quality inspection method in the above embodiment.

[0145] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0146] The computer-readable storage medium may be included in the rule engine quality inspection device; or it may exist independently without being assembled into the rule engine quality inspection device.

[0147] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the rule engine quality inspection device, the rule engine quality inspection device: receives the expected target description input by the user; determines the executable script code corresponding to the rule engine to be quality inspected based on the expected target description; extracts the parameter information corresponding to the rule definition text in the rule engine to be quality inspected; embeds the expected target description, the executable script code, and the parameter information into a preset prompt word template; calls the quality inspection model to perform quality inspection on the prompt word template to obtain the rule engine quality inspection result.

[0148] Computer program code for performing the operations of the present application may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0149] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0150] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0151] The computer-readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned rule engine quality inspection method, thereby resolving the technical issues surrounding rule engine quality inspection. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the rule engine quality inspection method provided in the aforementioned embodiments, and are not further elaborated here.

[0152] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned rule engine quality inspection method when executed by a processor.

[0153] The computer program product provided in this application can solve the technical problems of rule engine quality inspection. Compared with the existing technology, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the rule engine quality inspection method provided in the above embodiment, which will not be repeated here.

[0154] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A rule engine quality inspection method, characterized in that: The rule engine quality inspection method includes: Receive the expected goal description from the user; Determine the executable script code corresponding to the rule engine to be inspected based on the expected target description; Extracting parameter information corresponding to the rule definition text in the rule engine to be inspected; Embedding the expected target description, the executable script code, and the parameter information into a preset prompt word template; The quality inspection model is called to perform quality inspection on the prompt word template to obtain the rule engine quality inspection result.

2. The rule engine quality inspection method according to claim 1, characterized in that: The step of determining the executable script code corresponding to the rule engine to be inspected based on the expected target description includes: Determine the rule engine to be inspected according to the expected target description, and query whether there is an executable script code corresponding to the rule version number of the rule engine to be inspected in the script repository; If there is an executable script code corresponding to the rule version number, then verify the consistency of the association between the rule version and the executable script code; If the association consistency check passes, it is determined that the rule version of the rule engine to be inspected already has executable script code, and the executable script code is directly called; If there is no executable script code corresponding to the rule version number, the engine parses the rule to be inspected to obtain the rule definition text, and generates an executable script code according to the rule definition text.

3. The rule engine quality inspection method according to claim 2, characterized in that: The step of parsing the rule engine to be inspected to obtain a rule definition text and generating an executable script code according to the rule definition text includes: Parsing the rule engine to be inspected to obtain a rule definition text, and generating a structured abstract syntax tree according to the rule definition text; Analyzing syntax errors and logical conflicts of the structured abstract syntax tree, and automatically correcting the syntax errors and logical conflicts using a predefined rule base; The automatically corrected structured abstract syntax tree is converted into executable script code of the target script language through the semantic mapping rule library.

4. The rule engine quality inspection method according to claim 1, wherein: The step of extracting parameter information corresponding to the rule definition text in the rule engine to be inspected includes: Extract the Chinese name, English name, data type and parameter group information of the parameter field in the rule definition text of the rule engine to be inspected; The Chinese name, the English name, the data type, and the parameter group information are sorted in a list format to obtain parameter information.

5. The rule engine quality inspection method according to claim 1, wherein: The step of embedding the expected target description, the executable script code, and the parameter information into a preset prompt word template includes: Performing natural language processing on the expected target description to extract key entities and processing logic, and generating a standardized semantic description based on the key entities and the processing logic, wherein the natural language processing includes entity recognition, semantic standardization, and intent verification; Performing context enhancement on the standardized semantic description based on a domain knowledge base, extracting relevant terms and appending them to a preset prompt word template; The standardized semantic description, the executable script code, and the parameter information are respectively embedded in the prompt word template.

6. The rule engine quality inspection method according to claim 1, wherein: The quality inspection model adopts a master-slave model architecture. The step of calling the quality inspection model to perform quality inspection on the prompt word template and obtaining the rule engine quality inspection result includes: Calling a quality inspection model and passing the prompt word template into the quality inspection model for quality inspection, wherein the quality inspection model includes a master model and a slave model. The master model detects conditional branch coverage, logical contradictions, and compliance of the executable script code, and the slave model verifies the numerical calculation link and formula accuracy. The output results of the master model and the output results of the slave model are integrated to obtain the rule engine quality inspection results.

7. The rule engine quality inspection method according to claim 1, wherein: After the step of calling the quality inspection model to perform quality inspection on the prompt word template and obtaining the rule engine quality inspection result, the following steps are further included: The rule engine quality inspection results are associated with the logic blocks of the executable script code, and an interactive flow chart is generated through a visual interpretation module.

8. A rule engine quality inspection device, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the rule engine quality inspection method according to any one of claims 1 to 7.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the rule engine quality inspection method according to any one of claims 1 to 7 are implemented.

10. A computer program product, characterized in that The computer program product includes a computer program, and when the computer program is executed by a processor, the steps of the rule engine quality inspection method according to any one of claims 1 to 7 are implemented.

Images