A multi-source feedback driven review rule self-evolution method and system

Abstract

The application relates to a multi-source feedback driven review rule self-evolution method and system, which belongs to the technical field of intelligent review, and the method comprises the following steps: collecting multi-source feedback data generated after the execution of a review rule, and determining whether to trigger the evolution process of the corresponding review rule according to the feedback of each review rule; when the target review rule triggers the evolution process, extracting all negative feedback of the target review rule, analyzing the negative feedback to identify at least one problem mode existing in the target review rule; inputting the rule content of the target review rule and the identified problem mode into a large language model, and generating a candidate rule for solving the problem mode by the large language model; verifying the candidate rule, and replacing the target review rule with the candidate rule after verification. The application can realize the automatic evolution of the review rule, and continuously improve the effect of the review accuracy without manual intervention.

Description

Technical Field

[0001] This application relates to the field of intelligent review technology, and in particular to a method and system for self-evolution of review rules driven by multi-source feedback. Background Technology

[0002] Traditional censorship rule systems primarily employ static rule engines, machine learning models, or prompt word schemes based on large language models. In static rule engines, rules are pre-written and fixed by experts; the conditions, thresholds, and judgment logic of the rules do not change with the running data. While machine learning models can learn censorship patterns from labeled data, updating the model requires collecting a large amount of new labeled data and retraining completely. Prompt word schemes based on large language models rely on manually written prompt words, and similarly cannot be automatically adjusted after deployment.

[0003] The common drawback of the above solutions is that the review rules become fixed once they are implemented. When false alarms or missed alarms occur, they can only be detected and corrected manually. The quality of the rules gradually declines over time, while the cost of manual maintenance continues to rise, thus requiring improvement. Summary of the Invention

[0004] In order to enable review rules to evolve automatically during operation and continuously improve review accuracy without human intervention, this application provides a multi-source feedback-driven self-evolution method and system for review rules.

[0005] Firstly, this application provides a multi-source feedback-driven self-evolutionary method for review rules, including: Collect multi-source feedback data generated after the execution of the review rules, wherein the multi-source feedback data includes at least review annotation data and user feedback data of the reviewed object; The decision on whether to trigger the corresponding review rule's evolution process is based on the feedback received for each review rule. When a target review rule triggers an evolutionary process, all negative feedback from the target review rule is extracted, and the negative feedback is analyzed to identify at least one problem pattern in the target review rule; wherein, the negative feedback refers to feedback data indicating that the review conclusion is incorrect; The rule content of the target review rule and the identified problem pattern are input into the large language model, and the large language model generates candidate rules to solve the problem pattern. The candidate rule is verified, and if the verification is successful, the candidate rule is used to replace the target review rule.

[0006] By adopting the above technical solution, feedback data generated after the review is executed is automatically collected, and an evolution process is automatically triggered based on the feedback. Problem patterns of incorrect review conclusions are identified, candidate rules are generated through a large language model, and the original rules are automatically replaced after verification, thereby realizing the self-optimization of review rules during the operation process.

[0007] Optionally, the step of analyzing the negative feedback to identify at least one problem pattern in the target review rule, inputting the rule content of the target review rule and the identified problem pattern into a large language model, and generating candidate rules for solving the problem pattern by the large language model, includes: All negative feedback is clustered according to the text similarity of the feedback content, and the problem pattern of each category is extracted. Map the corresponding atomic repair action to solve the problem pattern based on each problem pattern; All atomic repair actions are merged to generate a composite optimization instruction. The rule content of the target review rule and the composite optimization instruction are input into the large language model, which generates candidate rules to solve the problem pattern. The composite optimization instruction is a structured instruction described in natural language, which explicitly lists each problem pattern and its corresponding atomic repair action, and requires the large language model to generate candidate rules that simultaneously satisfy all atomic repair actions.

[0008] By adopting the above technical solution, common problem patterns can be extracted from scattered feedback by clustering negative feedback; by mapping atomic repair actions and generating composite optimization instructions, the repair requirements of multiple problem patterns can be merged into a unified instruction, enabling the large language model to generate candidate rules that solve multiple problems at the same time, reducing the cost of multiple iterations.

[0009] Optionally, the candidate rule is a composite rule, which includes: Multiple sub-rules, each sub-rule corresponding to a problem pattern combination, the problem pattern combination is divided according to the scenario affiliation tag of each problem pattern, and problem patterns belonging to the same review scenario are classified into the same problem pattern combination; The scenario activation condition configuration is used to define the applicable scenario for each sub-rule. The scenario activation condition is determined based on the matching relationship between the contextual features of the review object and the scenario features of the problem pattern rule. When the contextual features of the object under review match the scenario activation condition of a certain sub-rule, the corresponding sub-rule is activated and the review is performed; when the scenario activation conditions of multiple sub-rules are matched at the same time, the sub-rule to be executed or the output is merged according to the preset routing strategy.

[0010] By adopting the above technical solution, when multiple problem patterns belong to different review scenarios, the problem patterns can be combined according to the scenario, and sub-rules can be generated independently for each combination. Scenario activation conditions can be configured so that different sub-rules are executed only in their corresponding scenarios. When multiple sub-rules are activated simultaneously, the final output can be determined through routing strategies, avoiding logical conflicts or performance losses caused by forcibly merging incompatible repair logic into a single rule.

[0011] Optionally, the step of merging all atomic repair actions to generate a composite optimization instruction includes: After identifying the problem patterns and corresponding atomic repair actions of the target review rules, the problem patterns are first matched with existing atomic problem units. The atomic problem units are independent units that are pre-encapsulated problem patterns and corresponding atomic repair actions. Each atomic problem unit contains a feature description of the problem pattern and a corresponding atomic repair action. If a match is successful, a reference identifier is established between the target review rule and the matched existing atomic problem unit; if a match fails, a new atomic problem unit is created for the current problem mode, and a reference identifier is established between the target review rule and the newly created atomic problem unit. For other rules, compare the content of the rule with the feature description in the atomic problem unit referenced by the target review rule, determine other rules that match the atomic problem unit referenced by the target review rule, and actively establish a reference identifier between the determined other rules and the corresponding atomic problem unit; The atomic repair actions in the atomic problem units referenced by the target review rules are used to generate the composite optimization instructions; The method further includes: Once the target review rule has evolved and the corresponding candidate rule has passed verification, the atomic repair action corresponding to the candidate rule is stored as the updated atomic repair action in the corresponding atomic problem unit, thereby updating the atomic repair action and the atomic problem unit. Then, using the updated atomic repair action, other rules that reference the updated atomic problem unit, besides the target review rule, are input into the large language model to execute the process of generating candidate rules.

[0012] By adopting the above technical solution, the atomic problem unit enables the same problem pattern to be analyzed and repaired only once. When other rules have the same problem in the future, they can be directly matched and reused. It can actively find other rules with the same problem pattern and establish references to achieve preventive repair. When the atomic repair action is updated, it can automatically cascade and regenerate all candidate rules that reference the atomic problem unit, ensuring that all rules are optimized synchronously.

[0013] Optionally, the method further includes: When the same target atomic problem unit is referenced by multiple review rules, analyze the input data sources of all review rules referenced by the target atomic problem unit. The input data sources refer to the input fields that each review rule depends on when it is executed, the review conclusions or data tables generated after the execution of other review rules. If, among the input data sources of multiple review rules, there exists a review conclusion generated after the execution of a specific review rule that is used as input by other review rules, and the specific review rule itself contains the problem pattern corresponding to the atomic problem unit, then the specific review rule is identified as the source rule. If the source rule exists, the evolution process of the source rule is immediately triggered and is completed before other review rules that reference the same target atomic problem unit as the source rule. After the source rule evolution is completed, other review rules that reference the same target atomic problem unit as the source rule are re-evaluated: if the problem pattern of the evaluated review rule has disappeared with the evolution of the source rule, the evolution process of the evaluated review rule is canceled.

[0014] By adopting the above technical solution, when multiple rules reference the same atomic problem unit, the source rule that is the source of the problem pattern can be identified by analyzing the source of input data and the dependency graph; the evolution of the source rule can be triggered first to avoid invalid independent evolution of downstream rules; after the evolution is completed, the downstream rules are re-evaluated, and if the problem has disappeared, its independent evolution process is canceled, saving computing resources and manual review costs.

[0015] Optionally, the method further includes: A problem pattern propagation relationship library is pre-built. The propagation relationship library records the propagation relationship between the first problem pattern and the second problem pattern. The propagation relationship is defined as follows: when the first problem pattern appears in the first review rule, if the output of the first review rule is used as the input of the second review rule, then the first problem pattern has the risk of propagating to the second review rule and triggering the second problem pattern. If a first problem pattern is identified in the problem patterns of the target review rules, the transmission relationship database is queried to determine the second review rule with transmission risk and the corresponding second problem pattern; While generating candidate rules for the first issue pattern of the target review rule, a blocking strategy is deployed along the transmission path to prevent the first issue pattern from propagating to the second review rule, thus preventing the second issue pattern from being triggered.

[0016] By adopting the above technical solution and pre-building a problem pattern propagation relationship database, it is possible to identify the risk of problem patterns propagating between dependent rules; while fixing upstream problems, a blocking strategy is deployed to prevent problem patterns from spreading downstream and to avoid downstream rules from making misjudgments due to relying on upstream erroneous outputs.

[0017] Optionally, replacing the target review rule with the candidate rule includes: Based on the problem pattern propagation relation library, predict the set of review rules that will be affected after the candidate rule is replaced; Calculate the expected accuracy change range for each review rule in the set of review rules, generate risk warning information from the calculation results, and display the risk warning information to the auditor for review. If there is a review rule in the set of review rules whose expected accuracy change exceeds a preset threshold, the process of replacing the candidate rule of the corresponding review rule will be paused, and the decision on whether to execute the replacement process will be made based on the reviewer's review results; if the review is passed, the replacement process will be executed, and if the review is not passed, the replacement process will be terminated.

[0018] By adopting the above technical solution, before replacing the rules, it is possible to predict the impact of the replacement of candidate rules on downstream rules, calculate the expected change in accuracy of each affected rule, and display the risk information to the auditor. When there is a risk that the expected accuracy will drop beyond the threshold, the replacement will be automatically paused and executed again after the auditor confirms it, so as to avoid the overall performance of the system from declining due to rule evolution.

[0019] Secondly, this application provides a multi-source feedback-driven self-evolutionary review rule system, including: The feedback data collection module is used to collect multi-source feedback data generated after the execution of the review rules. The multi-source feedback data includes at least review annotation data and user feedback data of the reviewed object. The evolution trigger determination module is used to determine whether to trigger the evolution process of the corresponding review rule based on the feedback of each review rule; The evolutionary process execution module is used to extract all negative feedback of the target review rule when the target review rule triggers the evolutionary process, and analyze the negative feedback to identify at least one problem pattern of the target review rule; wherein, the negative feedback refers to feedback data indicating that the review conclusion is incorrect; The candidate rule generation module is used to input the rule content of the target review rule and the identified problem pattern into the large language model, and the large language model generates candidate rules to solve the problem pattern. The rule verification and update module is used to verify the candidate rules, and after the verification is passed, the candidate rules are used to replace the target review rules.

[0020] Thirdly, this application provides a multi-source feedback-driven self-evolving review rule apparatus, including a memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executed as described in any of the first aspects.

[0021] Fourthly, this application provides a computer-readable storage medium storing a computer program that can be loaded by a processor and executed as described in any of the first aspects.

[0022] In summary, this application includes at least one of the following beneficial technical effects: This application can automatically collect feedback data generated after the review process, automatically trigger the evolution process based on the feedback, identify problem patterns of incorrect review conclusions, generate candidate rules through a large language model, and automatically replace the original rules after verification, thereby realizing the self-optimization of review rules during the operation process. Furthermore, by clustering negative feedback, common problem patterns can be extracted from scattered feedback; by mapping atomic repair actions and generating composite optimization instructions, the repair requirements of multiple problem patterns can be merged into a unified instruction, enabling the large language model to generate candidate rules that solve multiple problems at once, reducing the cost of multiple iterations. Attached Figure Description

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

[0024] Figure 1 This is a flowchart illustrating a multi-source feedback-driven self-evolution method for review rules disclosed in an embodiment of this application.

[0025] Figure 2 This is a structural block diagram of a multi-source feedback-driven self-evolutionary review rule system disclosed in an embodiment of this application.

[0026] Figure labeling: 201, Feedback data acquisition module; 202, Evolution trigger determination module; 203, Evolution process execution module; 204, Candidate rule generation module; 205, Rule verification and update module. Detailed Implementation

[0027] The following is in conjunction with the appendix Figure 1-2 This application will be described in further detail.

[0028] This application discloses a multi-source feedback-driven self-evolution method for review rules (hereinafter referred to as the evolution method), the execution subject of which is a multi-source feedback-driven self-evolution system for review rules (hereinafter referred to as the evolution system). The following will combine... Figure 1 It elaborates on the execution process of evolutionary methods in an evolutionary system.

[0029] S101, Collect multi-source feedback data generated after the execution of the review rules. The multi-source feedback data includes at least the review annotation data and the user feedback data of the reviewed object. S102, determine whether to trigger the evolution process of the corresponding review rule based on the feedback of each review rule; S103, When the target review rule triggers the evolution process, extract all negative feedback of the target review rule, analyze the negative feedback to identify at least one problem pattern in the target review rule; where negative feedback refers to feedback data indicating that the review conclusion is incorrect; S104, Input the rule content of the target review rule and the identified problem pattern into the big language model, and the big language model generates candidate rules for solving the problem pattern; S105, validate the candidate rule, and if the validation is successful, replace the target review rule with the candidate rule.

[0030] Specifically, S103, "analyzing negative feedback to identify at least one problematic pattern in the target review rules," and S104 include the following sub-steps: S1031, cluster all negative feedback according to the text similarity of the feedback content, and extract the problem pattern for each category; S1032, Map the corresponding atomic repair action for solving the problem mode according to each problem mode; S1041, merge all atomic repair actions to generate composite optimization instructions, input the rule content of the target review rules and composite optimization instructions into the big language model, and the big language model generates candidate rules for the problem-solving mode; wherein, the composite optimization instructions are structured instructions described in natural language, which clearly list each problem mode and its corresponding atomic repair actions, and require the big language model to generate candidate rules that simultaneously satisfy all atomic repair actions.

[0031] In implementation, for S101, after any review rule completes the logical judgment of a reviewed object and outputs the review conclusion, the evolution system begins to collect two types of feedback data: review annotation data and user feedback data.

[0032] For review annotation data, the evolutionary system collects data as follows: Reviewers annotate the currently displayed review conclusion on the review annotation interface provided by the evolutionary system by clicking the "Correct" or "Incorrect" control. For each annotation operation, the evolutionary system directly generates a review annotation record and stores it in the review annotation data table of the evolutionary system's feedback database. The review annotation record contains at least the following fields: Rule ID (to identify the review rule being evaluated), Review Object (i.e., the specific content being reviewed, such as a contract text or a tender document), Review Conclusion (the judgment result output by the review rule, such as "exceeds the standard" or "does not exceed the standard"), Annotation Result (the reviewer's judgment result on whether the review conclusion is correct, i.e., "Correct" or "Incorrect"), Annotator (the reviewer's identification), and Annotation Time (the time when the annotation operation occurred).

[0033] The Evolution System collects user feedback data as follows: After viewing the review conclusion on the results display page provided by the Evolution System, relevant personnel of the reviewed entity (e.g., the contract submitter) can provide feedback by clicking the "Confirm" or "Objection" control. If the "Objection" control is clicked, the Evolution System displays a text input box on the results display page for the relevant personnel to fill in the specific reasons for their feedback. For each submission, the Evolution System directly generates a user feedback record and stores it in the user feedback data table of the Evolution System's feedback database. A user feedback record must contain at least the following fields: Rule ID, Review Entity, Review Conclusion, Feedback Type ("Confirm" or "Objection"), Feedback Reason (textual description provided by the relevant personnel), Feedback Provider, and Feedback Time.

[0034] The feedback database is deployed on the evolutionary system's storage server and implemented using a relational database management system (such as MySQL or PostgreSQL). Each feedback record stored in the feedback database uniformly includes the following fields: rule ID, feedback source (used to distinguish whether the record comes from reviewer annotation or user feedback), feedback signal (automatically generated by the evolutionary system based on the annotation result or feedback type: if the annotation result is "correct" or the feedback type is "confirmed," the feedback signal is "positive"; if the annotation result is "incorrect" or the feedback type is "dissent," the feedback signal is "negative"), specific content (the text of the annotation result or feedback reason), and timestamp. The evolutionary system indexes the rule ID field in the feedback database to enable efficient retrieval by rule ID.

[0035] For S102, the evolutionary system starts a background polling thread, which reads the feedback database every 10 seconds. For each review rule in the feedback database, the evolutionary system groups and statistically analyzes its current feedback data status by rule ID. The evolutionary system maintains the following statistics for each review rule: the total cumulative amount of feedback data (i.e., the total number of feedback records for this review rule in the feedback database), the review accuracy rate in the most recent M executions, and the timestamp of the most recent trigger of the evolutionary process. In this embodiment, the default value of M is 100, and its specific value can be adjusted manually.

[0036] The evolution system presets the following three trigger conditions. As long as any one of them is met, the corresponding review rule will be marked as the target review rule, and the subsequent evolution process will be started immediately.

[0037] The first triggering condition is cumulative triggering. The evolutionary system determines whether the total amount of accumulated feedback data for a certain rule has reached a preset threshold N. In this embodiment, the default value of N is 50, and its specific value can be adjusted manually. If it is reached, evolution is triggered. The purpose of this triggering condition is to ensure that evolutionary evaluation is carried out only after a sufficient number of statistical samples have been accumulated, avoiding interference from accidental factors in the statistical results due to data sparsity.

[0038] The second trigger condition is accuracy triggering. The evolutionary system calculates the review accuracy of a rule in the most recent M executions. The accuracy is calculated as follows: extract the most recent M feedback records for that rule from the feedback database, count the number of records with "positive" feedback signals, and divide the number of positive feedback records by M to obtain the accuracy. If the calculated accuracy is lower than a preset threshold T, evolution is triggered. In this embodiment, the default value of T is 85%, and its specific value can be adjusted manually.

[0039] The third trigger condition is manual triggering. The evolution system provides an administrator interface. After selecting any rule on the administrator interface, the administrator clicks the "Trigger Evolution" button, and the evolution system receives a manual trigger instruction. Based on the manual trigger instruction, the evolution system marks the rule selected by the administrator as the target review rule and immediately starts the evolution process, regardless of the two conditions mentioned above. This mechanism is used to deal with scenarios that require urgent handling, such as when business stakeholders report that a certain rule has been subject to batch misjudgments.

[0040] When any rule meets one of the three conditions mentioned above, the evolutionary system marks that rule as a target review rule and extracts all negative feedback records for that target review rule from the feedback database. Negative feedback refers to feedback records with a "negative" feedback signal, indicating that the review conclusion is incorrect. Specifically, for review-annotated data, records with a "mistake" annotation are considered negative feedback; for user feedback data, records with a "dissent" feedback type are considered negative feedback. The extracted negative feedback records will serve as input data for step S103.

[0041] For S103, the evolutionary system will extract all negative feedback records of the target review rule from the feedback database as the analysis object for this step. The "Specific Content" field in each negative feedback record (i.e., the explanation of the annotation results filled in by the reviewer, or the text of the feedback reason filled in by the user when submitting an objection) will be used as the text data to be analyzed. The evolutionary system will perform cluster analysis on all the above-mentioned text data to be analyzed, as follows: The first step is text vectorization. The evolutionary system takes the text of the "specific content" field of each negative feedback as input and calls a pre-built Chinese text vectorization model. This model uses the open-source Sentence-BERT model (a sentence-level semantic representation model based on BERT). The evolutionary system passes the input text to the model's encoder, which converts the text into a fixed-dimensional semantic vector. Specifically, the evolutionary system uses the model's "encode" method, taking a text string as input and outputting a 768-dimensional floating-point vector. Each negative feedback text corresponds to a 768-dimensional semantic vector.

[0042] The second step is similarity calculation. The evolutionary system uses the cosine similarity formula to calculate the similarity between any two semantic vectors. The cosine similarity formula is: cosine_similarity(A,B) = (A·B) / (||A||×||B||), where A and B are two semantic vectors, A·B represents the dot product of the vectors, and ||A|| and ||B|| represent the magnitudes of the vectors. The calculated result ranges from -1 to 1: the closer the value is to 1, the more consistent the directions of the two vectors, meaning the two texts are semantically similar; the closer the value is to 0, the weaker the semantic correlation; a negative value indicates opposite semantics. The evolutionary system presets a similarity threshold, with a default value of 0.75. When the cosine similarity between two texts is greater than 0.75, the evolutionary system determines that the two texts belong to the same type of problem; otherwise, they are determined to be different types.

[0043] The third step is clustering. The evolutionary system uses the DBSCAN clustering algorithm to divide all semantic vectors into several clusters. The DBSCAN algorithm uses the distance obtained by cosine similarity transformation calculated in the second step as the distance metric. The distance transformation formula is: distance = 1 - cosine similarity. When the cosine similarity of two texts is greater than 0.75, their corresponding distance is less than 0.25. In this embodiment, a preset similarity threshold (such as 0.75) is used as the cluster radius (eps parameter), and 5 is used as the minimum cluster size (min_samples parameter). The algorithm execution process is as follows: For each semantic vector, the evolutionary system calculates the number of other vectors within its cluster radius (i.e., cosine similarity greater than 0.75). If the number is greater than or equal to 5, then all vectors within the radius are grouped into the same cluster, with that vector as the core point; if the number is less than 5 but falls within the radius of a core point, then the vector is grouped into the cluster where that core point is located; if it is neither a core point nor within the radius of any core point, then the vector is marked as a noise point and discarded. After clustering, the semantic vectors within each cluster are similar to each other, while the semantic vectors between different clusters differ significantly. Each cluster corresponds to a type of problem pattern.

[0044] After clustering is complete, the evolutionary system generates a structured problem pattern for each cluster. Each problem pattern contains at least three elements: problem type, problem description, and frequency of occurrence.

[0045] The problem type is determined as follows: The evolutionary system counts the keywords in all negative feedback records within the cluster and calculates the frequency of each keyword. If the number of feedback records indicating "the rule is judged as non-compliant but is actually compliant" exceeds 50% of the total number of records in the cluster, the evolutionary system marks the problem type of the cluster as a false alarm. If the number of feedback records indicating "the rule is judged as compliant but is actually non-compliant" exceeds 50%, it is marked as a missed alarm. Whether a certain semantic pattern is specified is determined by a pre-set keyword set: the keyword set for false alarms includes "false alarm," "should not be judged as," "actually compliant," etc.; the keyword set for missed alarms includes "missed alarm," "should be detected," "actually non-compliant," etc. If neither of the above two categories exceeds 50%, and there are keywords in the cluster that match the pre-set defect description keyword set, it is marked as a logical problem. The defect description keyword set is pre-stored in the storage directory of the evolutionary system and contains at least the following keywords: "missing judgment conditions," "incorrect judgment order," "incomplete logic," "missing conditions," and "missing branches."

[0046] The problem description is generated as follows: the evolutionary system extracts common descriptive statements from the negative feedback records of the cluster. A summary generation algorithm based on text frequency statistics is used. The specific steps are as follows: Step 1: Word segmentation and stop word removal. The evolution system invokes a preset Chinese word segmentation tool (such as the jieba segmentation library) to perform word segmentation processing on the "specific content" text of each piece of negative feedback in the cluster. After word segmentation, the evolution system removes stop words (such as function words with no practical meaning like "de", "le", "shi", "zai", etc.), and retains content words (nouns, verbs, adjectives).

[0047] Step 2: Word frequency statistics. The evolution system counts the total occurrence frequency of all retained words in all texts within the cluster. The frequency of each word is equal to the sum of the number of times the word appears in all texts.

[0048] Step 3: Candidate phrase extraction. The evolution system traverses the word segmentation sequence of each text in the cluster, and extracts consecutive content word sequences therein as candidate phrases. The rules for extracting candidate phrases are as follows: the first word and the last word of a candidate phrase must be a noun, verb or adjective; the length of a candidate phrase ranges from 2 to 6 content words; a candidate phrase does not contain stop words. For example, after the text "the rule does not consider the amount of the supplementary agreement" is subjected to word segmentation and stop word removal, the word segmentation sequence "rule / not / consider / supplement / agreement / amount" is obtained, where "rule" is a noun, "not" is an adverb (retained), "consider" is a verb, "supplement" is a verb, "agreement" is a noun, and "amount" is a noun. Candidate phrases such as "not consider the amount of the supplementary agreement" (from "not" to "amount", with a length of 5), "consider the amount of the supplementary agreement" (from "consider" to "amount", with a length of 4), "supplementary agreement amount" (from "supplement" to "amount", with a length of 3) and the like can be extracted therefrom. The evolution system extracts all candidate phrases that meet the length requirement.

[0049] Step 4: Phrase scoring. The evolution system calculates a score for each candidate phrase. The calculation formula of the score is: Phrase Score = Sum of word frequencies of each word in the phrase × (Phrase Length) 2 . Herein, the sum of word frequencies is used to measure the importance of the words in the phrase within the cluster, and the square of the phrase length is used to encourage the extraction of longer phrases (longer phrases usually contain more complete information).

[0050] Step 5: Problem description selection. The evolution system sorts all candidate phrases in descending order of score, and selects the candidate phrase with the highest score as the problem description of the cluster. If there are multiple candidate phrases with the highest score, the one with the shortest length is selected (to avoid excessive redundancy).

[0051] For example, a cluster contains three negative feedback texts: "The rule did not consider the supplementary agreement amount," "The system did not include the supplementary agreement amount in the total," and "There is a lack of judgment on the supplementary agreement amount." After the above processing, the word frequency of "supplementary agreement amount" is 3, the word frequency of "did not consider" is 1, the word frequency of "included in the total" is 1, and the word frequency of "there is a lack of judgment" is 1. The score of the candidate phrase "did not consider the supplementary agreement amount" is calculated as: (1+3)×(5) 2 =4 × 25 = 100; The fractional calculation for "Supplementary Agreement Amount" is: 3 × (4 2 =3×16=48; The score for "lacking judgment on the amount of the supplementary agreement" is calculated as: (1+3+1)×(7 2 =5 × 49 = 245. The highest score is for "lacking judgment on the amount of the supplementary agreement," but this phrase is too long and contains the function words "of" and "right." In actual implementation, the function words at the beginning and end can be further removed after scoring to obtain "lacking judgment on the amount of the supplementary agreement" as the final problem description.

[0052] For S1031 and S1032, after extracting all problem patterns from the target review rules, the evolutionary system determines a corresponding atomic fix action for each problem pattern. An atomic fix action is an executable fix instruction described in natural language, used to guide the subsequent generation of specific rule modification code by the large language model. The evolutionary system pre-builds a mapping rule library from a problem pattern to a fix action. This mapping rule library is stored in the evolutionary system's storage directory as a JSON-formatted configuration file. Each mapping rule contains the following fields: applicable problem type (values ​​are "false positives," "false negatives," or "logical"), keyword matching pattern (written using regular expressions), and atomic fix action template (a string containing placeholders). The atomic fix action template varies depending on the problem type: For false positive issues, the atomic remediation action template is: "Add an exclusion condition to the current rule to exclude review objects that meet the following characteristics: [excluded characteristics]" or "Adjust the judgment threshold of the current rule from [original threshold] to [new threshold]". Here, [excluded characteristics], [original threshold], and [new threshold] are placeholders.

[0053] Example: Suppose the current issue pattern is described as "Incorrectly including supplementary agreement amount in the over-limit judgment." Here, "supplementary agreement amount" is the specific feature leading to the false positive. During mapping, the evolutionary system extracts "supplementary agreement amount" from the issue description as the replacement content for the [excluded feature]. Specifically, the extraction method is: using the regular expression "incorrectly include (.*)" to match the issue description, the captured content is "supplementary agreement amount". Replacing "supplementary agreement amount" with the [excluded feature] placeholder in the template generates the atomic repair action: "Add an exclusion condition to the current rule, excluding review objects that meet the following feature: supplementary agreement amount."

[0054] For issues involving missed reports, the atomic remediation action template is: "Add a coverage condition to the current rule, adding a judgment for the following scenarios: [New Scenario]" or "Adjust the judgment threshold of the current rule from [Original Threshold] to [New Threshold]".

[0055] Example: Suppose the current problem pattern is described as "Unprocessed foreign currency exchange rate conversion". Here, "foreign currency exchange rate conversion" is a missing condition. During mapping, the evolutionary system uses the regular expression "unprocessed (.*)" to match the problem description, and the captured content is "foreign currency exchange rate conversion". Replacing "foreign currency exchange rate conversion" with the placeholder in the template's [Add Scenario] generates the following atomic repair action: "Add a coverage condition to the current rule, adding a judgment that the foreign currency amount is included in the calculation after conversion at the exchange rate."

[0056] For logic-related problems, the atomic repair action template is: "Modify the judgment logic of the current rule from [original logic description] to [target logic description]".

[0057] Example: Suppose the current problem pattern is described as "Check only the main contract amount, not the supplementary agreement amount". Here, "Check only the main contract amount" is the original logic, and "Check the sum of the main contract amount and the supplementary agreement amount" is the target logic. During mapping, the evolutionary system uses the regular expression "Check only (.), not checked (.)" to match the problem description, where the first "(.)" matches "main contract amount", and the second "(.)" matches "supplementary agreement amount". The first capture group captures "main contract amount", and the second capture group captures "supplementary agreement amount". The evolutionary system fills the content of the first capture group into the [original logic description] placeholder in the template, and concatenates "check" + the first capture group + "AND" + the second capture group + "sum" into the [target logic description] placeholder. The generated atomic repair action is: "Modify the current rule's judgment logic from 'Check only the main contract amount' to 'Check the sum of the main contract amount and the supplementary agreement amount'."

[0058] It should be noted that the keyword matching patterns (regular expressions) in the mapping rule base are preset according to the common feedback description language patterns in service scenarios. Specifically, before different service scenarios go online, operation and maintenance personnel of the evolution system will analyze the language habits of feedback texts that may be submitted by examiners and users in such scenarios, summarize several typical description sentence patterns therefrom, and write corresponding regular expressions for each sentence pattern. For example, in the contract review scenario, "XXX not processed", "judgment on XXX is missing", and "XXX is not considered" are common sentence patterns for describing missing report problems; "XXX is incorrectly included", "XXX is misjudged", and "XXX should not be included" are common sentence patterns for describing false report problems.

[0059] To improve the success rate of mapping and matching, when the evolution system collects review annotation data and user feedback data, it may provide structured feedback options or input prompts to the feedback submitter in the feedback interface, so as to guide the feedback submitter to fill in the feedback reason according to the preset sentence pattern template. For example, the evolution system may display prompt text below the feedback text input box: "Please describe the problem in the following format: the judgment on [specific content] is missing" or "[specific content] is not processed". When the feedback submitter fills in according to the above template, the filled text will naturally conform to the matching pattern of the corresponding regular expression in the mapping rule base, thereby ensuring that the mapping and matching can be performed successfully.

[0060] The specific execution process of mapping is as follows: The evolution system traverses each problem pattern extracted in step S103. For the currently processed problem pattern, the evolution system first reads its problem type field, and then filters out all mapping rules applicable to this type in the mapping rule base. For each filtered mapping rule, the evolution system uses the keyword matching pattern (regular expression) in the rule to match the problem description of the current problem pattern. The criterion for a successful match is that the regular expression can match at least one non-empty capture group in the problem description string. If the matching is successful, the evolution system selects the mapping rule, replaces the specific content in the matching result with the corresponding placeholder in the atomic repair action template, and generates a complete atomic repair action.

[0061] The matching rule of the regular expression is as follows: the regular expression engine scans the problem description string from left to right, and tries to match each element in the regular expression with the characters in the string. Ordinary characters in the regular expression (such as "not", "consi", "der") can be matched only if they are completely the same as the corresponding characters in the string; the special character "." matches any single character; "*" indicates that the preceding element can be repeated 0 or more times; the parentheses in "(.*)" represent a capture group, and ".*" in the parentheses indicates that any sequence of characters of any length is matched.

[0062] For example, the problem type of the current problem pattern is "missing report type", and the problem description is "the amount of the supplementary agreement is not considered". There is a mapping rule for the missing report type in the mapping rule base, whose keyword matching pattern is "not consider (.)", and the atomic repair action template is "add a coverage condition to the current rule, and add judgment for [new scenario]".

[0063] When the evolutionary system uses this regular expression to perform a matching operation on the problem description "the amount of the supplementary agreement is not considered", the specific operations are as follows: The first character "not" of the regular expression is successfully matched with the first character "not" of the problem description.

[0064] The second character "consider" of the regular expression is successfully matched with the second character "consider" of the problem description.

[0065] The third character "consider" of the regular expression is successfully matched with the third character "consider" of the problem description.

[0066] The "(.)" part of the regular expression starts matching: since "(.)" can match any sequence of characters of any length, the regular engine will try to match as many characters as possible. Starting from the fourth character "supplement" of the problem description, it matches all the way to the end of the string "amount", and the content captured by the capture group is "the amount of the supplementary agreement".

[0067] Since the capture group successfully captures "the amount of the supplementary agreement" (non-empty), the evolutionary system determines that the matching is successful. The captured "the amount of the supplementary agreement" is used to replace the corresponding placeholder in the atomic repair action template. The atomic repair action is generated: "add a coverage condition to the current rule, and add judgment for the amount of the supplementary agreement".

[0068] If the current problem pattern does not match any mapping rule in the mapping rule base, the evolutionary system calls a large language model (i.e., the same large language model used in subsequent S1041) for online generation. Specifically, the evolutionary system sends a prompt to the large language model, and the content of the prompt is: "Please generate an atomic repair action for the following problem pattern: [problem description of the problem pattern]". The large language model returns a piece of natural language text, and the evolutionary system takes the text as the atomic repair action of the problem pattern. At the same time, for subsequent reuse, the evolutionary system calls the large language model to generate a new mapping rule online. Specifically, the evolutionary system sends a prompt to the large language model, and the content of the prompt is: "Please generate a mapping rule for the following problem pattern. The problem type is: [problem type of the current problem pattern]; the problem description is: [problem description of the current problem pattern]. Please output a mapping rule in JSON format, including the following three fields: problem_type: the problem type (the same as the input problem type); keyword_pattern: A regular expression used to match text that describes similar questions; action_template: An atomic repair action template, where the specific content is represented by placeholders [replacement content]; Example output: {"problem_type": "Missed report class", "keyword_pattern": "Not considered (.*)", "action_template": "Add coverage condition to the current rule, add judgment for [new scenario]"}.

[0069] The large language model returns a JSON-formatted string. The evolutionary system parses this string, extracts three fields: problem_type, keyword_pattern, and action_template, and stores these three fields as a new mapping rule in the mapping rule library.

[0070] For S1041, the evolutionary system collects all atomic repair actions generated in step S1032 into a list and sorts them from highest to lowest frequency according to the occurrence of the corresponding problem mode. The higher the frequency, the more severe the problem mode, and it should be listed in the composite optimization instructions first.

[0071] After sorting, the evolutionary system concatenates all atomic repair actions into a piece of natural language text according to a preset template. The content of the preset template is as follows: "Please complete all of the following fixes in addition to the current review rules:" [List each atomic repair action in order, one line per action] Please generate a new rule that retains the original review functions of the current review rule while also fulfilling all the above-mentioned remediation actions. The output format should be consistent with the type of the current rule. The natural language text obtained after the above concatenation is the composite optimization instruction.

[0072] Next, the evolutionary system merges the current rule content of the target review rule with the composite optimization instruction to construct an API request. The API request uses the HTTP POST method, with a Content-Type field in the request header, set to "application / json". The request body is in JSON format and contains at least the following fields: "model" field: specifies the name of the large language model used, such as "gpt-4". "messages" field: an array where each element contains a "role" field (with values ​​"system" or "user") and a "content" field. The evolutionary system uses the composite optimization instruction as the value of the "content" field and places it into a message object with "role" set to "user"; simultaneously, the evolutionary system can use the current rule content as a system prompt word and place it into a message object with "role" set to "system". "temperature" field: controls the randomness of the generated text; the evolutionary system sets it to 0.2 by default to reduce the randomness of the output and ensure that the generated candidate rules are stable and predictable.

[0073] The evolutionary system sends the constructed request body to the API endpoint provided by the large language model service provider via an HTTP POST request. Upon receiving the request, the large language model's API calls the model to perform calculations based on the parameters in the request body and returns the calculation results in the form of an HTTP response. A 200 status code in the HTTP response indicates a successful request, and the response body is in JSON format. The evolutionary system extracts candidate rule text from the response body; the specific extraction method is described in step S105. The large language model can be any of the GPT series models (e.g., GPT-4), LLaMA series models, Wenxin Yiyan, or Tongyi Qianwen, as long as it provides the aforementioned standard API interface.

[0074] For S105, after receiving the HTTP response from the large language model, the evolutionary system parses the response body. The response body is in JSON format. Different large language model APIs may use different field names to represent the generated text content. The evolutionary system has a pre-defined response parsing configuration table, which records the field paths containing the generated text content in the API response for each large language model type.

[0075] For example, for the API of the OpenAI GPT series models, the path to generate the text content in the response body is: "choices[0].message.content". After the evolutionary system parses the response body into a JSON object, it accesses it step by step according to the path "choices" → the first element of the array → "message" → "content", and the string read is the candidate rule text.

[0076] For other large language models (such as Wenxin Yiyan and Tongyi Qianwen), the response format may be that the "result" field directly contains text, or "output.text" contains text. The evolutionary system dynamically extracts candidate rule text based on the field paths recorded in the configuration table.

[0077] If the candidate rule text cannot be extracted from the response body (e.g., the response body format does not match the configuration table), the evolution system records an error log and terminates the current evolution process.

[0078] Before a candidate rule can be officially launched to replace the current rule, it must undergo two stages: backtesting and manual review.

[0079] The specific process of backtesting is as follows: The evolutionary system extracts the historical review dataset corresponding to the target review rule from the historical database. The historical database and the feedback database are independent of each other and are used to store the review objects that have been reviewed in the past and their corresponding review conclusions. The review conclusion refers to the conclusion that the reviewer, after retrospectively annotating and confirming the historical review conclusions, believes should have been reached when reviewing the object using the specified review rule (hereinafter referred to as the correct conclusion). Each data entry in the historical review dataset contains at least the following fields: the original content of the review object, the correct conclusion (already annotated), and the actual conclusion at the time of rule execution.

[0080] The evolutionary system extracts the most recent 500 historical review records by default. If there are fewer than 500 historical records for a given rule in the historical database, all available data is extracted. After extraction, the evolutionary system uses candidate rules to re-examine each review object in the historical review dataset, obtaining the review conclusion of the candidate rule for that object. Then, the evolutionary system compares this review conclusion with the correct conclusion for that data: if they match, it is counted as correct; otherwise, it is counted as incorrect. After comparing all review objects, the evolutionary system counts the number of correct candidate rules and divides the number of correct rules by the total number of rules to obtain the accuracy of the candidate rule.

[0081] Simultaneously, the evolutionary system needs to obtain the baseline accuracy of the current target review rule on the same historical review dataset. If the historical database already stores the historical execution results of the current rule, the evolutionary system reads them directly; if not, the evolutionary system first performs a review on the historical review dataset using the current target review rule to obtain the baseline accuracy. The evolutionary system compares the accuracy of the candidate rule with the baseline accuracy of the current rule. If the accuracy of the candidate rule is greater than or equal to the baseline accuracy of the current target review rule minus 2 percentage points (i.e., candidate rule accuracy ≥ baseline accuracy - 2%), the evolutionary system determines that the candidate rule passes backtesting; otherwise, the evolutionary system eliminates the candidate rule and terminates the current evolutionary process.

[0082] Candidate rules that pass backtesting enter the manual review process. The evolution system displays rule comparison information on the reviewer's interface. This comparison information includes at least: the content of the current target review rule, the content of the candidate rule, a comparison of backtesting results (including the change in accuracy of the candidate rule compared to the current target review rule), and a summary of feedback data analysis (including a list of problem patterns targeted by this evolution, and negative feedback examples for each problem pattern). After reviewing the above information, the reviewer clicks the "Approve" or "Reject" control.

[0083] If the reviewer clicks the "Approve" button, the evolution system performs a replacement operation: It writes the candidate rule to the rule repository, overwriting the current version rule; simultaneously, it archives the current version rule as a historical version and records the version number, evolution time, triggering conditions (cumulative trigger / accuracy trigger / manual trigger), feedback data analysis results, optimization content (i.e., the list of atomic fixes), backtesting results (accuracy change value), and review result (approved / rejected). This information is stored in the version management data table for future traceability or rollback.

[0084] If the reviewer clicks the "Reject" button, the evolution system will discard the candidate rule directly, the current target review rule will remain unchanged, and the result of this evolution being rejected will be recorded in the version management data table.

[0085] After the replacement is complete, the target review rules enter a new operating cycle. Each subsequent review execution will use the new version of the rules. If the new version of the rules accumulates enough negative feedback in subsequent runs, the evolutionary system will start a new round of evolution from step S102, forming a continuously optimizing closed loop.

[0086] Optionally, candidate rules can be composite rules, which include: Multiple sub-rules, each sub-rule corresponds to a problem pattern combination. Problem pattern combinations are divided according to the scenario affiliation tags of each problem pattern. Problem patterns belonging to the same review scenario are grouped into the same problem pattern combination. The scenario activation condition configuration is used to define the applicable scenario for each sub-rule. The scenario activation condition is determined based on the matching relationship between the contextual characteristics of the review object and the scenario characteristics of the problem pattern rule. When the contextual features of the object under review match the scenario activation condition of a certain sub-rule, the corresponding sub-rule is activated and the review is performed; when the scenario activation conditions of multiple sub-rules are matched at the same time, the sub-rule to be executed or the output is merged according to the preset routing strategy.

[0087] In implementation, during step S1041, when the evolutionary system generates candidate rules, it can generate a candidate rule with a special structure: a composite rule, based on the correlation between multiple problem patterns of the target review rules.

[0088] Composite rules are suitable for scenarios where multiple problem patterns in a target review rule do not simultaneously appear on all review objects, but rather appear separately on different types of review objects or in different review scenarios. For example, a contract review rule might have the following two problem patterns: Problem pattern P1 is "Supplementary agreement amount not considered" (appearing in contracts containing supplementary agreements), and problem pattern P2 is "Foreign currency exchange rate conversion not processed" (appearing in contracts involving foreign currency). These two problem patterns will not appear simultaneously on the same contract (a contract either has a supplementary agreement, involves foreign currency, or both, but with a low probability). Simply merging two atomic repair actions into one rule might cause the rule to execute unnecessary judgment logic in a single scenario, increasing computational overhead or even introducing new misjudgments. To solve the above problems, evolutionary systems can generate composite rules.

[0089] Before generating composite rules, the evolutionary system first needs to perform scenario affiliation analysis on the identified multiple problem patterns, classifying problem patterns belonging to the same review scenario into the same problem pattern combination.

[0090] The evolutionary system assigns a scenario-attribution label to each problem pattern. The scenario-attribution label is determined as follows: The evolutionary system pre-builds a contextual feature lexicon, which is stored in the system's storage directory as a JSON-formatted configuration file. The contextual feature lexicon contains multiple feature categories, and each feature category contains several feature words. Feature categories include, but are not limited to: The types of objects to be reviewed include those containing keywords such as "purchase contract", "sales contract", "tender document", "bid document", "financial statement", and "product manual".

[0091] Key field categories: Includes keywords such as "supplementary agreement", "foreign currency", "exchange rate", "framework agreement", "annex", "supplementary clauses", "penalty", and "tax rate".

[0092] Structural feature categories: Includes keywords such as "includes attachments", "includes supplementary clauses", "includes framework agreement", and "involves foreign currency".

[0093] The evolutionary system extracts the review object associated with each negative feedback record from the feedback database. For each review object, the evolutionary system takes it as text input and iterates through all feature words in the context feature word library, checking whether the review object contains these feature words. The matching method is string inclusion matching (i.e., checking whether the feature word string appears in the text content of the review object). If a feature word is matched, it is treated as a context feature of the review object and recorded in the context feature set of the negative feedback record.

[0094] For example, if a contract text contains the word "supplementary agreement", the evolutionary system adds the feature "contains supplementary agreement" to the context feature set of the negative feedback record; if the contract text also contains the word "foreign currency", then the feature "involves foreign currency" is added at the same time.

[0095] For a given problem pattern, the evolutionary system aggregates the contextual feature set of all negative feedback records corresponding to that problem pattern, counts the frequency of each feature word (i.e., how many negative feedback records the feature word appears in for that problem pattern), and selects the feature word with the highest frequency as the scene feature for that problem pattern. If there are multiple feature words with the highest frequency (i.e., tied for the highest), the one that ranks highest in the context feature word library is selected, or the priority rule preset by the administrator is used.

[0096] For example, there are 100 negative feedback records for problem pattern P1 "Supplementary agreement amount not considered". Among them, 90 records contain the "includes supplementary agreement" feature in their context feature set, and 10 records contain the "includes attachment" feature. Therefore, "includes supplementary agreement" has the highest frequency (90 times), and the evolutionary system determines the scenario feature of this problem pattern as "includes supplementary agreement". There are 50 negative feedback records for problem pattern P2 "Foreign currency exchange rate conversion not processed". Among them, 45 records contain the "involves foreign currency" feature in their context feature set, and 5 records contain the "includes supplementary agreement" feature. Therefore, the evolutionary system determines the scenario feature of this problem pattern as "involves foreign currency". There are 30 negative feedback records for problem pattern P3 "Framework agreement amount not considered". Among them, 25 records contain the "includes framework agreement" feature in their context feature set, and 5 records contain the "includes attachment" feature. Therefore, the evolutionary system determines the scenario feature of this problem pattern as "includes framework agreement".

[0097] After obtaining the scene features (feature words) for each problem pattern, the evolutionary system groups problem patterns with the same scene features into the same problem pattern group. A scene feature is a string of feature words, so determining whether they are identical only requires a complete string match: if two problem patterns have completely identical scene feature strings, they are grouped into the same group; otherwise, they are grouped into different groups.

[0098] For example, if the scenario feature of problem pattern P1 is "includes supplementary agreement", and the scenario feature of problem pattern P4 is also "includes supplementary agreement" (e.g., P4 is "supplementary agreement amount calculation error"), then P1 and P4 have the same scenario feature and belong to the same review scenario. The evolutionary system classifies them into the same problem pattern combination. The review scenario corresponding to this combination is represented by the scenario feature word, namely the "includes supplementary agreement" scenario.

[0099] If the scenario feature of problem pattern P1 is "includes supplementary agreement" and the scenario feature of problem pattern P2 is "involves foreign currency", and the two strings are different, then the evolutionary system divides them into two different problem pattern combinations, corresponding to the "includes supplementary agreement" review scenario and the "involves foreign currency" review scenario, respectively.

[0100] Each question pattern combination corresponds to a review scenario, which is uniquely identified by the common scenario feature words of the combination.

[0101] For each problem pattern combination, the evolutionary system independently generates a sub-rule according to the method in step S1041 (i.e., generating composite optimization instructions and calling the large language model). Each sub-rule corresponds to a problem pattern combination and is used to solve the defects described by all problem patterns within that problem pattern combination.

[0102] The sub-rule generation process is as follows: The evolutionary system collects all problem patterns and their corresponding atomic repair actions within the problem pattern combination, generates a composite optimization instruction for the combination according to step S1041, inputs the composite optimization instruction into the large language model, and generates a candidate rule, which is the sub-rule corresponding to the problem pattern combination. Sub-rules have the same format and structure as ordinary rules (they can be keyword matching rules, AI prompt word rules, script rules, or algorithm rules), the difference being that sub-rules are only activated and executed in their corresponding review scenario.

[0103] The evolutionary system configures a scenario activation condition for each sub-rule. The scenario activation condition is a logical expression that defines the applicable scenario for that sub-rule. The scenario activation condition is generated as follows: the evolutionary system generates a Boolean expression based on the scenario characteristics of the problem pattern combination corresponding to the sub-rule. This Boolean expression contains one or more conditional terms, connected by "AND" or "OR".

[0104] For example, for a question pattern combination with the scenario feature "includes supplementary agreements", the generated scenario activation condition is: "whether the object being examined contains the 'supplementary agreement' field". For a question pattern combination with the scenario feature "involves foreign currency", the generated scenario activation condition is: "whether the object being examined contains the 'foreign currency' field or the 'exchange rate' field".

[0105] The specific method for determining scenario activation conditions depends on the data format of the object being reviewed. If the object being reviewed is structured data (e.g., contract fields in JSON format), the evolutionary system determines this by checking if the specified field exists or is not empty; if the object being reviewed is unstructured text, the evolutionary system determines this by keyword matching (i.e., checking if the text contains specified keywords) or regular expression matching. The evolutionary system embeds scenario activation conditions into composite rules in the form of code snippets or configuration parameters.

[0106] Composite rules are formed by combining all the above sub-rules and their corresponding scene activation conditions by the evolutionary system. The data structure of a composite rule can be an ordered list, where each element contains two fields: a "sub-rule" field (storing the executable code or rule content of the sub-rule) and a "scene activation condition" field (storing the scene activation condition expression of the sub-rule).

[0107] In composite rules, the evolutionary system also configures a routing strategy. The routing strategy defines how the evolutionary system should determine the final review conclusion when the context features of the reviewed object simultaneously match the scene activation conditions of multiple sub-rules. The evolutionary system uses one of the following routing strategies by default; the specific strategy can be selected by the administrator in the configuration interface: Strategy 1 (Priority Routing): The evolutionary system pre-determines a priority for each sub-rule, based on the frequency of occurrence or severity of the problem pattern corresponding to that sub-rule. When the activation conditions of multiple sub-rules are met simultaneously, the evolutionary system selects the sub-rule with the highest priority for execution, ignoring the others. Priorities can be automatically calculated by the evolutionary system during the generation of composite rules (higher frequency, higher priority), or manually adjusted by the reviewer during manual review.

[0108] Strategy Two (Weighted Fusion Routing): The evolutionary system presets a reliability weight for each sub-rule. The reliability weight is determined based on the historical verification results of the problem pattern corresponding to that sub-rule. Specifically, for a problem pattern, the evolutionary system records the number of times it was confirmed as valid (i.e., the number of times the reviewer clicked "Approved") and the number of times it was rejected (i.e., the number of times the reviewer clicked "Rejected") after it was identified and manually reviewed in step S105. The reliability weight of this problem pattern = number of times it was confirmed as valid / (number of times it was confirmed as valid + number of times it was rejected). If the problem pattern has not yet undergone manual review, the reliability weight defaults to 0.5.

[0109] When the scenario activation conditions of multiple sub-rules are simultaneously met, the evolutionary system executes all sub-rules that meet the conditions in parallel. After each sub-rule is executed, it outputs a review conclusion (e.g., "exceeds the standard" or "does not exceed the standard") and its execution confidence score. The execution confidence score is the decision confidence generated internally during the execution of the sub-rule, and its source depends on the implementation method of the sub-rule: if the sub-rule is a large language model rule, and the large language model API called provides a confidence parameter in the response (e.g., logprobs or token-level probabilities in the OpenAI GPT series APIs), then the evolutionary system parses the confidence parameter from the response body as the execution confidence score; if the large language model API called does not provide a confidence parameter, then the evolutionary system sets the execution confidence score to 1.0 by default. If the sub-rule is a script rule or a keyword matching rule, the evolutionary system uses the matching score during rule execution (e.g., the ratio of the number of matched keywords to the total number of keywords) as the execution confidence score, and this score ranges from 0 to 1.

[0110] Then, the evolutionary system merges multiple conclusions according to a weighted voting mechanism: for each review conclusion, its weighted score is calculated, which is the sum of (the reliability weight of the sub-rule × the execution confidence score of the sub-rule's output) of each sub-rule corresponding to that conclusion. The review conclusion with the highest weighted score is selected as the final output. If there are multiple review conclusions with the highest weighted scores, the conclusion corresponding to the one with the highest execution confidence score is selected.

[0111] Strategy 3 (Manual Adjudication Routing): When the scenario activation conditions of multiple sub-rules are met simultaneously, the evolutionary system does not automatically make a judgment. Instead, it marks the review task of the object to be reviewed as "pending manual review" and displays the review conclusions of all sub-rules to the reviewer, who then makes the final decision. This strategy is suitable for scenarios where there may be conflicts between problem patterns and the risk of automatic fusion is high.

[0112] When an evolutionary system uses composite rules to review an object, the execution flow is as follows: The first step is for the evolutionary system to extract the contextual features of the object under review. The extraction method is as follows: The evolutionary system takes the object under review as text input, iterates through all feature words in a pre-built contextual feature vocabulary, and checks whether the object under review contains these feature words. The matching method is string inclusion matching. All matched feature words are then used as the contextual feature set for the object under review.

[0113] The second step is for the evolutionary system to traverse all sub-rules in the composite rule and determine whether the contextual features of the reviewed object meet the scene activation conditions of the sub-rule.

[0114] Third, the evolution system collects all sub-rules that meet the scene activation conditions. If the number of collected sub-rules is 0, the evolution system outputs a default review conclusion (e.g., "Cannot be determined") or triggers a fallback rule. The fallback rule refers to the current version of the target review rule before this evolution (i.e., the rule before it was replaced by the composite rule). This rule is used to review the object and output a conclusion. If the current version of the rule does not exist (e.g., this evolution is the first evolution of the rule), the evolution system directly assigns the review task to a reviewer for manual review.

[0115] Fourth, if the number of sub-rules collected is 1, the evolution system directly executes the sub-rule and uses its output as the final review conclusion.

[0116] Fifth step: If the number of collected sub-rules is greater than 1, the evolution system determines the final review conclusion according to the preset routing strategy (as described in step (iv)) and outputs the conclusion.

[0117] For example, taking contract review rules as an example, suppose that after evolutionary analysis, two problem patterns are identified: P1 is "Supplementary agreement amount not considered," the scenario characteristic of which is "the review object includes a supplementary agreement"; P2 is "Foreign currency exchange rate conversion not processed," the scenario characteristic of which is "the review object includes a foreign currency amount." The evolutionary system generates a composite rule, which includes two sub-rules: Sub-rule R1, the scenario activation condition is "the object under review contains the keyword 'supplementary agreement'", the sub-rule content is: "Check whether the sum of the main contract amount and the sum of all supplementary agreement amounts exceeds 1 million yuan".

[0118] Sub-rule R2, the scenario activation condition is "the review object contains the keywords 'foreign currency' or 'exchange rate'", the sub-rule content is: "convert the foreign currency amount into RMB at the current exchange rate, add it to the main contract amount, and determine whether it exceeds RMB 1 million".

[0119] The routing policy is set to priority routing, and P1 appears more frequently (100 times) than P2 (50 times), therefore R1 has a higher priority than R2.

[0120] When the evolutionary system receives a contract for review, contract A, which includes a supplementary agreement but does not involve foreign currency, the system extracts contextual features and finds that contract A satisfies the activation condition of R1 (containing "supplementary agreement") but does not satisfy the activation condition of R2 (not containing "foreign currency" or "exchange rate"). Therefore, the system executes R1 and outputs the review conclusion.

[0121] When the evolutionary system receives Contract B, which includes a supplementary agreement and a foreign currency amount, it extracts contextual features and finds that the activation conditions for both R1 and R2 are met. Since R1 has higher priority than R2, the evolutionary system executes R1 and outputs the review conclusion (ignoring R2).

[0122] If the routing strategy is set to weighted fusion routing, and the weight of R1 is 0.6 and the weight of R2 is 0.8 (for example, P2 has a higher confidence level), then the evolutionary system executes R1 and R2 in parallel, obtains two conclusions and their confidence scores, and outputs the final conclusion after weighted fusion.

[0123] Through the aforementioned composite rule structure, the evolutionary system can apply different repair logic to different review scenarios, avoiding logical conflicts or performance losses caused by forcibly merging multiple incompatible repair actions into a single rule.

[0124] Optionally, the step "merge all atomic repair actions to generate a composite optimization instruction" in S1041 includes the following sub-steps: After identifying the problem patterns and corresponding atomic repair actions of the target review rules, the problem patterns are first matched with existing atomic problem units. An atomic problem unit is an independent unit that is pre-encapsulated with a problem pattern and its corresponding atomic repair action. Each atomic problem unit contains a feature description of the problem pattern and its corresponding atomic repair action. If a match is successful, a reference identifier is established between the target review rule and the matched existing atomic problem unit; if a match fails, a new atomic problem unit is created for the current problem pattern, and a reference identifier is established between the target review rule and the newly created atomic problem unit. For other rules, compare the content of the rule with the feature description in the atomic problem unit referenced by the target review rule to determine other rules that match the atomic problem unit referenced by the target review rule, and actively establish reference identifiers between the determined other rules and the corresponding atomic problem units; The atomic repair actions in the atomic problem units referenced by the target review rules are used to generate composite optimization instructions; The evolutionary approach also includes the following steps: S301, after the target review rule has completed its evolution and the corresponding candidate rule has passed the verification, the atomic repair action corresponding to the candidate rule is stored as the updated atomic repair action in the corresponding atomic problem unit, thereby updating the atomic repair action and the atomic problem unit. Then, using the updated atomic repair action, other rules that reference the updated atomic problem unit, except for the target review rule, are input into the large language model to execute the process of generating candidate rules.

[0125] S401, When the same target atomic problem unit is referenced by multiple review rules, analyze the input data sources of all review rules referenced by the target atomic problem unit. The input data sources refer to the input fields that each review rule depends on when it is executed, the review conclusions or data tables generated after the execution of other review rules. S402, If among the input data sources of multiple review rules, there is a review conclusion generated after the execution of a specific review rule that is used as input by other review rules, and the specific review rule itself has a problem pattern corresponding to an atomic problem unit, then the specific review rule is determined as the source rule; S403 If a source rule exists, the evolution process of the source rule is immediately triggered and it completes the evolution process before other review rules that refer to the same target atomic problem unit as the source rule. S404: After the source rule has evolved, re-evaluate other review rules that reference the same target atomic problem unit as the source rule. If the problem pattern of the review rule being evaluated has disappeared with the evolution of the source rule, then cancel the evolution process of the review rule being evaluated.

[0126] In implementation, before the evolutionary system generates composite optimization instructions in step S1041, the matching and reuse process of atomic problem units can be executed. An atomic problem unit is a data structure that encapsulates a problem pattern and its corresponding atomic repair action, enabling it to be shared and reused by multiple review rules. Through the atomic problem unit mechanism, the same problem pattern only needs to be analyzed and repaired once, and all review rules with the same problem pattern can reuse the repair solution, avoiding redundant analysis and repair. The specific implementation plan is as follows: The evolutionary system pre-maintains a library of atomic problem units in the storage directory. This library is stored as a JSON-formatted configuration file, where each atomic problem unit is an object containing the following fields: Unit ID: A globally unique identifier that is automatically generated by the evolutionary system when creating a new atomic problem unit (e.g., using the UUID algorithm or an auto-incrementing integer).

[0127] Feature Description: A text string used to describe the core features of the problem pattern corresponding to this atomic problem unit. The feature description is generated in the same way as the problem description in S103, that is, common descriptive statements are extracted from the negative feedback records corresponding to this problem pattern.

[0128] Atomic Repair Action: A text string describing the repair instructions to resolve the problem pattern. The format of the atomic repair action is the same as that generated in S1032.

[0129] Reference rule list: An array that records the rule IDs of all review rules that reference this atomic problem unit.

[0130] Creation time: The timestamp of the creation of this atomic problem unit.

[0131] Last Update Time: The timestamp of the most recent update of this atomic problem unit.

[0132] For example, the JSON representation of an atomic problem unit is as follows: Unit ID: "APU-001"; "Characteristic Description": "Supplementary agreement amount not considered"; "Atomic Repair Action": "Add coverage conditions to the current rules and add a judgment on the amount of the supplementary agreement"; "List of Reference Rules": ["RULE-001", "RULE-003", "RULE-005"]; Creation Time: "2025-01-15T10:30:00Z"; "Last Update Time": "2025-01-15T10:30:00Z".

[0133] After the evolutionary system generates atomic repair actions for the current problem mode in step S1032, before executing step S1041 to generate composite optimization instructions, the evolutionary system first attempts to match the problem mode with existing atomic problem units in the atomic problem unit library.

[0134] The specific matching process is as follows: The first step is for the evolutionary system to read the “characteristic description” field of all existing atomic problem units from the atomic problem unit library.

[0135] The second step involves the evolutionary system comparing the problem description of the current problem pattern with the feature description of that atomic problem unit using string similarity. The similarity comparison employs the Levenshtein distance algorithm, where edit distance refers to the minimum number of single-character editing operations (including insertion, deletion, and replacement) required to transform one string into another. After calculating the edit distance, the evolutionary system calculates the similarity using the following formulas: Difference = Edit Distance / max(Length of String A, Length of String B); Similarity = 1 - Difference. The max function takes the maximum of the two string lengths; for example, string A is "Supplementary Agreement Amount Not Considered," with a length of 9; string B is "Supplementary Agreement Amount Not Included in Judgment," with a length of 11. The minimum edit distance between the two strings is 3 (by inserting "will" after "Not Considered" in A, and "included in judgment" after "amount," or an equivalent sequence of editing operations). Difference = 3 / 11 ≈ 0.27, Similarity = 1 - 0.27 = 0.73.

[0136] The evolutionary system presets a similarity threshold, which is 0.8 in this embodiment. This similarity threshold is an empirical value and can be adjusted by the administrator based on actual matching results: if mismatches frequently occur (i.e., dissimilar questions are judged as similar), the threshold should be appropriately increased (e.g., 0.85); if missed matches frequently occur (i.e., similar questions are not matched), the threshold should be appropriately decreased (e.g., 0.75). When the length difference between two strings is extremely large (e.g., one string is less than 1 / 3 the length of the other), the evolutionary system can directly determine that the similarity is below the threshold without calculating the edit distance, thus improving matching efficiency.

[0137] The third step is to select the atomic problem unit with the highest similarity as the matching result if there is an atomic problem unit with a similarity greater than or equal to 0.8, and determine that the matching is successful; otherwise, the matching is determined to be unsuccessful.

[0138] For example, the current problem pattern is described as "supplementary agreement amount not considered," and there is an atomic problem unit in the atomic problem unit library with the feature description "supplementary agreement amount not included in the judgment." The two are semantically similar, and the calculated similarity is approximately 0.85, which is greater than the threshold of 0.8, therefore the match is successful.

[0139] If a match is successful, the evolutionary system does not create a new atomic problem unit. Instead, it establishes a reference identifier between the current target review rule and the matched existing atomic problem unit. Specifically, the evolutionary system reads the "Reference Rule List" field of the matched atomic problem unit, adds the rule ID of the current target review rule to this array (if it already exists, it is not added again), and then writes the updated array back to the atomic problem unit library. Simultaneously, the evolutionary system records the unit ID of the atomic problem unit in the metadata of the current target review rule, serving as the basis for obtaining atomic repair actions when generating composite optimization instructions later.

[0140] If a match fails, the evolutionary system creates a new atomic problem unit. The creation process is as follows: The evolutionary system generates a new unique unit ID; the problem description of the current problem pattern is used as the value of the "Feature Description" field; the atomic repair action generated in step S1032 is used as the value of the "Atomic Repair Action" field; the rule ID of the current target review rule is added to the "Reference Rule List" array; the current timestamp is filled into the "Creation Time" and "Last Update Time" fields; the above fields are combined into a JSON object and appended to the configuration file of the atomic problem unit library. Simultaneously, the evolutionary system records the unit ID of the newly created atomic problem unit in the metadata of the current target review rule.

[0141] After establishing atomic unit references for the target review rule, the evolutionary system proactively searches for other review rules that share the same problem pattern as the current atomic problem unit, and establishes reference identifiers for these review rules for that atomic problem unit. The purpose of this step is to achieve preventative repair of problem patterns: proactively associating repair solutions with them before other review rules trigger evolution, thus avoiding the same misjudgments in the future.

[0142] The specific process of cross-rule matching is as follows: The first step is for the evolutionary system to read the contents of all review rules from the rule repository. The rule repository is the data storage location for all review rule definitions.

[0143] The second step involves the evolutionary system checking each other review rule (i.e., review rules other than the current target review rule) to see if its content contains keywords or logical structures related to the feature description of the atomic problem unit. Specifically, the system segments the feature description of the atomic problem unit into words, removes stop words (such as function words like "not," "consider," "of," and "already"), and retains nouns and verbs as core keywords. For example, the feature description "not considered supplementary agreement amount" is segmented into ["not," "consider," "supplementary," "agreement," "amount"]. After removing the stop words "not" and "consider," the remaining core keywords are ["supplementary," "agreement," "amount"], which are further combined into "supplementary agreement amount." If these are present, the review rule is determined to match the atomic problem unit.

[0144] Third, for all other successfully matched review rules, the evolutionary system adds the rule IDs of these review rules to the "reference rule list" array of the atomic problem unit. Simultaneously, the evolutionary system records the unit ID of the atomic problem unit in the metadata of these rules.

[0145] For example, the current target review rule RULE-001 references the atomic problem unit APU-001 (characteristic description: "Supplementary agreement amount not considered"). The evolutionary system traverses the rule repository and finds that rule RULE-003 contains the keyword "supplementary agreement amount," and rule RULE-005 contains both the keywords "supplementary agreement" and "amount." The evolutionary system adds the rule IDs of RULE-003 and RULE-005 to the "reference rule list" of APU-001 and records the reference identifiers of RULE-003 and RULE-005 to APU-001.

[0146] After completing the matching and reference establishment described above, the evolutionary system uses the atomic repair actions in the atomic problem units referenced by the target review rules to generate composite optimization instructions. Specifically, the evolutionary system reads the content of the "atomic repair action" field from the atomic problem unit and uses the atomic repair action as one of the inputs to the composite optimization instructions in step S1041. If the atomic repair action stored in the atomic problem unit is completely consistent with the atomic repair action mapped to the current problem mode, it is used directly; if they are inconsistent (for example, the atomic repair action in the atomic problem unit is left over from a previous version), the evolutionary system takes the atomic repair action mapped to the current problem mode as the standard and updates the atomic problem unit in subsequent steps.

[0147] For S301, once the target review rule completes its evolutionary process and its candidate rules pass the backtesting verification and manual review in step S105, the evolutionary system executes the update operation for the atomic problem unit. The specific process of the update operation is as follows: The first step is for the evolutionary system to read the cell IDs from the problem cell that the target review rules reference from the metadata.

[0148] The second step involves the evolutionary system extracting the atomic repair actions corresponding to the candidate rules generated and verified during this evolutionary process. The extraction method involves the evolutionary system comparing the candidate rules with the target review rules to identify the modification points in the candidate rules and summarizing these modification points into a single atomic repair action text. The specific method of difference comparison depends on the type of review rule. In this embodiment, rule types include, but are not limited to, keyword matching rules, AI prompt word rules, and script rules. The difference comparison method differs for different types of rules. For keyword matching rules: Essentially, a keyword matching rule is a list of keywords. Each review rule contains a set of keywords and logical combinations (e.g., "contains keyword A and contains keyword B"). The evolutionary system compares the keyword list of the current rule with the keyword lists of candidate rules, using a set difference algorithm (i.e., calculating the added elements in the candidate rule keyword list relative to the current rule keyword list, and the deleted elements in the current rule keyword list relative to the candidate rule keyword list) to identify the added and deleted keywords. The added keyword is obtained by calculating the difference between the candidate rule keyword list and the current rule keyword list (candidate list - current list); the deleted keyword is obtained by calculating the difference between the current rule keyword list and the candidate rule keyword list (current list - candidate list). The identification result of the modification point is: "Added keyword: X" or "Deleted keyword: Y".

[0149] For AI prompt word rules: The essence of an AI prompt word rule is a piece of natural language text. The evolutionary system compares the prompt word text of the current rule with the prompt word text of the candidate rules, and uses the Myers difference algorithm (text difference algorithm) to find the differences between the texts. The identification result of the modification point is: text difference fragment (e.g., "inserted 'and all supplementary agreement amounts' after 'check contract amount' in the original prompt word").

[0150] For script rules: A script rule is essentially a piece of executable code (e.g., Python, JavaScript, or a domain-specific language). The evolutionary system compares the script code of the current rule with the script code of candidate rules, using the Myers difference algorithm to compare line by line and identify modified, added, or deleted lines of code. The identification result of the modification point is: the specific code difference (e.g., "change '>100' in the conditional statement to '>50'").

[0151] After identifying the modification points, the evolutionary system converts them into atomic repair actions described in natural language, according to a pre-defined inductive template. The inductive template is preset based on the type of modification point, for example: For modification points of the "Add Keyword" type, the template is summarized as: "Add keyword [keyword] to the current target review rules".

[0152] For modification points of the "delete keywords" type, the template is summarized as: "Delete the keyword [keyword] in the current target review rule".

[0153] For modification points of the "text insertion" type, the template is summarized as: "Insert [content to be inserted] at [location] within the prompt words of the current target review rule." The [location] is determined as follows: if the insertion point is at the beginning of the prompt word, the [location] value is "beginning"; if it is at the end, the value is "end"; if it is after a keyword, the [location] value is "after '[keyword]'". The evolutionary system analyzes the difference fragments output by the Myers difference algorithm to identify the context in which the insertion operation occurs and determine the specific value of [location].

[0154] For modification points of the "condition modification" type, the template is summarized as: "Modify the judgment condition of the current target review rule from [original condition] to [new condition]".

[0155] The evolutionary system selects a template that matches the modification point type, fills the placeholders in the template with the specific content of the modification point, and generates atomic repair action text. For example, the keyword list of the current target review rule is ["exceeding the limit", "1 million"], and the keyword list of the candidate rules is ["exceeding the limit", "supplementary agreement", "1 million"]. The evolutionary system identifies the newly added keyword "supplementary agreement", selects the "Add Keyword" template, and generates the atomic repair action: "Add the keyword 'supplementary agreement' to the current rule".

[0156] For example, the current rule's script code contains the conditional statement "if total_amount>100:", which is modified in the candidate rule to "if total_amount+supplementary_amount>100:". The evolutionary system recognizes the modification of the expression in the conditional statement, selects the "condition modification" template, and generates an atomic repair action: "Modify the current rule's condition from 'total_amount>100' to 'total_amount + supplementary_amount>100'".

[0157] Third, the evolutionary system extracts the atomic repair actions as the updated content and writes them into the "Atomic Repair Action" field of the atomic problem unit, overwriting the original atomic repair actions. At the same time, the evolutionary system updates the "Last Update Time" field to the current timestamp.

[0158] In the fourth step, the evolutionary system reads all rule IDs referencing the atomic problem unit from its "reference rule list," excludes the current target review rule itself, and then iterates through the remaining rules. For each other review rule, the evolutionary system regenerates candidate rules using the updated atomic repair action, following the method in step S1041 (i.e., generating composite optimization instructions and calling the large language model). After generation, the evolutionary system performs backtesting verification and manual review processes in step S105 on these candidate rules.

[0159] Through the aforementioned update and cascading regeneration mechanism, once the solution for an atomic problem unit is optimized, all rules referencing that atomic problem unit can be automatically upgraded without triggering an evolution process for each review rule separately.

[0160] For S401 and S402, during the maintenance of atomic problem units, the evolutionary system monitors the list of reference rules for each atomic problem unit. When the same atomic problem unit is referenced by multiple review rules, the evolutionary system performs a source tracing process to identify whether a "source rule" exists among these rules as the origin of the problem pattern. The specific process of the source tracing is as follows: The first step is for the evolutionary system to read all rule IDs that reference the atomic problem unit from the "reference rule list" of the atomic problem unit, denoted as the rule set R.

[0161] The second step involves the evolutionary system analyzing the source of input data for each review rule in the rule set R. The source of input data refers to where the input data for this review rule is obtained during execution. The specific analysis method is as follows: the evolutionary system reads the "Input Source" field from the configuration metadata of the review rule. In the implementation of the review rule system, the input source for each review rule can be one of the following three types: Direct Input: Review rules read review objects directly from the business database or user-submitted documents, without relying on the output of other review rules. The "Input Source" field for this type of review rule is marked as "Direct".

[0162] Rule Dependency: The input of an audit rule depends on the audit conclusions generated by the execution of one or more other audit rules. The "Input Source" field of such an audit rule records a list of rule IDs it depends on, such as "Dependency Rules: [RULE-001, RULE-002]".

[0163] Data table dependency: The input to an audit rule depends on a specific data table or data view. The "Input Source" field of this type of rule records the name of the data table.

[0164] It should be noted that the input source configuration is manually set by the administrator when the review rule is created, or it can be automatically extracted by the evolution system through static code analysis (e.g., parsing database query statements or function calls in the rule script and automatically identifying the rule ID it depends on).

[0165] The third step involves the evolutionary system pre-constructing a dependency graph. This dependency graph is a directed graph where nodes are rule IDs and edges represent dependencies: if the input source of rule B records a dependency on rule A, then a directed edge is drawn from rule A to rule B, indicating that the output of A is used as input by B.

[0166] The fourth step involves the evolutionary system searching the dependency graph for a specific rule that satisfies the following conditions: the specific rule exists in the rule set R (i.e., the specific rule also references the same atomic problem unit), and the specific rule has at least one outgoing edge (i.e., its output is used as input by at least one other rule). If such a rule exists, it is identified as a candidate source rule.

[0167] Fifth, if multiple candidate source rules exist, the evolutionary system selects the rule at the highest level of the dependency hierarchy as the final source rule. The dependency hierarchy is determined by traversing downstream along the directed edges from the candidate source rule. The more rules that can be reached, the larger their influence range, and the more likely they are to be the source rule.

[0168] For example, rules RULE-001, RULE-002, and RULE-003 all reference the atomic problem unit APU-001. Evolutionary system analysis reveals that the input source for RULE-001 is "direct," the input source for RULE-002 is "dependency rule: [RULE-001]," and the input source for RULE-003 is "dependency rule: [RULE-002]." Therefore, the dependency graph is: RULE-001 → RULE-002 → RULE-003. Since RULE-001 itself references APU-001, and its output is used by RULE-002 and RULE-003, RULE-001 is identified as the source rule.

[0169] For S403 and S404, if the source tracing process determines the source rule, the evolutionary system performs the following operations: Step 1 (Priority Evolution): The evolution system immediately triggers the evolution process for the source rule, prioritizing its evolution over other rules referencing the same atomic problem unit. "Priority" means that when the evolution system's resources (such as large language model API call quotas and manual review resources) are limited, the evolution request for the source rule is given the highest priority, while the evolution requests for other review rules are queued. Simultaneously, the candidate rules for the source rule are prioritized for presentation to the reviewer during the manual review phase of step S105.

[0170] The second step (post-evolution evaluation): After the source rule has evolved (i.e., its candidate rules have been verified and deployed online to replace it), the evolutionary system re-evaluates other review rules that reference the same atomic problem unit. For ease of description, this embodiment denotes the source rule as rule A, and other review rules that reference the same atomic problem unit as rule B, rule C, etc. Rule B, rule C, etc., are collectively referred to as "downstream rules," meaning that in the dependency graph constructed by the evolutionary system, any rule that can be reached from rule A along the direction of the directed edge (i.e., the direction in which the output is depended) is a downstream rule of rule A.

[0171] The specific evaluation method is as follows: The evolutionary system extracts historical review data for the downstream rule (e.g., rule B) from the historical database. This historical review data records the review objects that rule B has historically reviewed, as well as the correct conclusions subsequently marked by the reviewers. For each piece of historical review data, the evolutionary system performs the following operations: First, the evolutionary system re-executes the review on the same review object using the evolved source rule (a new version of rule A), obtaining a new output result from rule A. Second, the evolutionary system uses this new output result as input for rule B, re-executes the review on the same review object using rule B, obtaining a new review conclusion from rule B. Then, the evolutionary system compares the new review conclusion of rule B with the correct conclusion in the historical review data. If the new review conclusion of rule B matches the correct conclusion, but the review conclusion of the old version of rule B before evolution (i.e., the review conclusion recorded in the historical review data where rule B was executed at that time) does not match the correct conclusion, it indicates that the previous error in rule B was due to relying on the incorrect output of rule A, rather than a defect in rule B itself. In this case, the evolutionary system determines that the problem pattern of rule B has disappeared with the evolution of rule A. If the new review conclusion of Rule B is still inconsistent with the correct conclusion, it indicates that Rule B itself has independent defects, and its problem pattern has not disappeared with the evolution of Rule A, so it needs to be dealt with separately.

[0172] Step 3 (Cancel Evolution): For other rules whose problem patterns have been determined to have disappeared, the evolutionary system cancels the independent evolutionary process for these rules. "Cancellation" means that the evolutionary system removes the marker for evolution from the metadata of these rules and deletes them from the evolutionary task queue. These rules do not need to be regenerated as candidate rules, nor do they need to undergo backtesting or manual review again. However, the reference relationship between these rules and the atomic problem unit remains unchanged, so that they can still be automatically updated when the atomic problem unit is updated in the future.

[0173] If the problem patterns of the evaluated rules do not disappear as the source rules evolve (i.e., the new conclusions are still inconsistent with the correct conclusions), then the evolutionary system retains the independent evolutionary process of these rules and processes them according to the normal process.

[0174] Through the aforementioned source tracing mechanism, the evolutionary system can identify the true source of problem patterns, avoiding ineffective independent evolution of downstream rules and saving computational resources and manual review costs. Furthermore, due to the existence of atomic problem units, all rules share a unified repair scheme, ensuring consistency in the repair process.

[0175] Optionally, the evolutionary approach may also include the following steps: S501, a problem pattern propagation relationship library is pre-built. The propagation relationship library records the propagation relationship between the first problem pattern and the second problem pattern. The propagation relationship is defined as follows: when the first problem pattern appears in the first review rule, if the output of the first review rule is used as the input of the second review rule, then the first problem pattern has the risk of propagating to the second review rule and triggering the second problem pattern. S502, if a first problem pattern is identified in the problem patterns of the target review rules, then query the transmission relationship database to determine the second review rule with transmission risk and the corresponding second problem pattern; S503, while generating candidate rules for the first problem pattern of the target review rule, deploys blocking strategies along the transmission path. The blocking strategies are used to block the first problem pattern from propagating to the second review rule along the transmission path, so that the second problem pattern cannot be triggered.

[0176] The "Replace the target review rule with a candidate rule" step in S105 also includes the following sub-steps: S1051, Based on the problem pattern propagation relation library, predict the set of review rules that will be affected after the candidate rule is replaced; S1052, calculate the expected accuracy change of each review rule in the review rule set, generate risk warning information from the calculation results, and display the risk warning information to the auditor for review; S1053 If there is a review rule in the review rule set whose expected accuracy change exceeds a preset threshold, the process of replacing the candidate rule of the corresponding review rule is suspended, and the replacement process is determined based on the reviewer's review results; if the review is passed, the replacement process is executed, and if the review is not passed, the replacement process is terminated.

[0177] In implementation, for S501, the evolutionary system pre-constructs a problem pattern propagation relationship library. This library is stored in the evolutionary system's storage directory as a JSON-formatted configuration file, used to record the propagation relationships between different problem patterns. The propagation relationship is defined as follows: when a first problem pattern appears in a first review rule, if the output of the first review rule (i.e., the review conclusion obtained after the execution of the first review rule) is used as input by a second review rule, then the first problem pattern risks propagating to the second review rule and triggering a second problem pattern. "Triggering a second problem pattern" means that because the output of the first review rule is incorrect, the second review rule makes a judgment based on this incorrect output, resulting in the second review rule also generating an incorrect review conclusion. This incorrect conclusion is formally represented as a problem pattern of the second review rule.

[0178] The construction method of the transmission relationship database is as follows: The first method is manual configuration. The system administrator manually adds transmission relationship entries through the management interface provided by the evolution system. Each transmission relationship entry must contain at least the following fields: Upstream Problem Pattern ID: The problem pattern identifier of the upstream rule.

[0179] Downstream Problem Pattern ID: Identifier of the problem pattern that may be triggered by downstream rules.

[0180] The second approach is automatic learning. After each evolutionary process, the evolutionary system analyzes the problem patterns involved and their impact scope, automatically identifying and recording transmission relationships. Specifically, if rule A corrects a problem pattern and the accuracy of rule B (which depends on the output of rule A) automatically increases, and rule B itself has not been modified, then the evolutionary system determines that there is a transmission relationship between the problem patterns of rule A and rule B, and adds a record to the transmission relationship database.

[0181] For example, rule RULE-001 has a problem pattern P1 "Misreport: Supplementary agreement amount not checked". The output of RULE-001 is used as input by rule RULE-002. RULE-002 itself has a problem pattern P2 "False alarm: Misjudgment based on upstream erroneous output". The evolutionary system adds a transmission relationship record to the transmission relationship database: P1 (upstream) → P2 (downstream)".

[0182] For S502, in the evolutionary process of the target review rule, after the evolutionary system identifies a problem pattern in the target review rule (i.e., after completing step S103), the evolutionary system performs a risk identification operation. The specific process is as follows: The first step is for the evolutionary system to obtain all the problem patterns of the target review rules, denoted as the problem pattern set P_set.

[0183] The second step is to treat each problem pattern in the problem pattern set P_set as an upstream problem pattern and query the problem pattern propagation relation library.

[0184] The third step involves the evolutionary system searching the transmission relationship database for all records that originate from the upstream problem pattern. The query method is as follows: iterate through each record in the transmission relationship database and check if the "upstream problem pattern ID" field of the record matches the identifier of the current problem pattern.

[0185] Fourth, if a matching transmission relationship record is found, the evolutionary system reads the "downstream problem pattern ID" field from that record to determine the downstream problem pattern that may be triggered. Simultaneously, the evolutionary system searches for a second review rule containing that downstream problem pattern based on the dependency graph (as described in S401).

[0186] Fifth, the evolutionary system aggregates the query results to generate a transmission risk list. Each record in the transmission risk list contains the following fields: upstream rule ID (i.e., the ID of the target review rule), upstream problem pattern ID, downstream problem pattern ID, and downstream rule ID.

[0187] For example, the target review rule is RULE-001, and its problem pattern is P1 "Misreporting: Supplementary agreement amount not checked". The evolutionary system queries the propagation relationship database and finds a propagation relationship record: P1 → P2 (downstream problem pattern). According to the dependency graph, the evolutionary system finds that the input source of RULE-002 depends on the output of RULE-001, and RULE-002 has a problem pattern P2. Therefore, the evolutionary system determines that the second review rule with propagation risk is RULE-002, and the corresponding second problem pattern is P2.

[0188] For S503, after identifying the propagation risk, the evolutionary system generates candidate rules for the first problem pattern targeting the review rule while simultaneously deploying blocking strategies along the propagation path. Here, "while generating candidate rules" means that the deployment of blocking strategies is performed in parallel during the process of the evolutionary system executing step S1041 to generate composite optimization instructions and calling the large language model to generate candidate rules. The execution order of these two steps is not important and can be performed synchronously.

[0189] The goal of the blocking strategy is to prevent the first problem pattern from propagating along the transmission path to the second review rule, thus preventing it from triggering the second problem pattern. The specific form of the blocking strategy depends on the characteristics of the transmission path and the implementation method of the second review rule. The evolutionary system supports the following three blocking strategies. The administrator can select which strategy to use in the configuration interface, or the evolutionary system can automatically select one based on the level of transmission risk: Strategy 1: Input Validation Filtering. This strategy is suitable for scenarios where the input source of the second review rule is the output of the first review rule, and the logic of the second review rule itself is sound. The evolutionary system automatically inserts a validation filter at the input front of the second review rule. The specific implementation is as follows: When each review rule is created, the expected format and value range of its output are configured as metadata in the rule definition. Specifically: If the output of a rule is an enumeration value (e.g., "compliant" / "non-compliant"), then the metadata records the output type as "enumeration" and records a list of enumeration values ​​(e.g., ["compliant", "non-compliant"]).

[0190] If the rule output is a numerical value (e.g., "Amount exceeding the limit: 1.5 million"), the metadata records the output type as "numerical value" and records the value range (e.g., real numbers greater than 0).

[0191] The evolution system reads the above configuration information from the rule metadata as the basis for verification and filtering. For example, for a rule whose output result is "compliant" or "non-compliant", its value range is recorded as {"compliant", "non-compliant"}; for a rule whose output result is "excess amount", its value range is recorded as a real number greater than 0.

[0192] If the administrator does not configure the expected format and value range, the evolutionary system defaults to strict mode: all output results are judged as verification failures, triggering "pending manual review". This design is to ensure that the system does not automatically allow suspicious results when the configuration is incomplete. The administrator can also adjust this default behavior in the system configuration.

[0193] The execution logic of the validation filter is as follows: After the first review rule outputs its result, before passing the result to the second review rule, the validation filter performs the following checks: The first step is to determine the expected format based on the type of the output result: if the output result is an enumeration value (e.g., "compliant" / "non-compliant"), the expected format is a string; if the output result is a number (e.g., "excess amount: 1.5 million"), the expected format is a numeric. Check if the data type of the output result matches the expected format. If the expected format is a string, check if the output result is a string; if not, the validation fails.

[0194] The second step is to check if the output result is within the value range. If the value range is {"compliant", "non-compliant"}, then check if the output result is equal to "compliant" or "non-compliant"; if not, the verification is considered to have failed.

[0195] If both checks pass, the validation filter will normally pass the output to the second review rule. If either check fails, the validation filter will block the output, preventing it from entering the second review rule. Simultaneously, the evolution system will mark the review object as "awaiting manual review" and display the output and the reason for blocking on the reviewer's interface for manual judgment.

[0196] For example, the output of the first review rule RULE-001 should be one of two strings: "compliant" or "non-compliant". Due to a malfunction in RULE-001, it outputs an empty string ("") or an outlier (such as "unknown"). The validation filter detects that the output is neither "compliant" nor "non-compliant", determines that the validation has failed, blocks the output, and transfers the contract to manual review.

[0197] Strategy Two: Output Compensation Correction. This strategy is suitable for scenarios where corrections can be made at the output of the first review rule. The evolutionary system automatically inserts a compensation corrector at the output of the first review rule. The compensation corrector is constructed as follows: The first step is for the evolutionary system to determine compensation rules based on the characteristics of the first problem pattern. The characteristics of the first problem pattern refer to the key information in its problem description. For example, the problem description of the first problem pattern P1 is "Misreporting: Supplementary agreement amount not checked," and its characteristic is "supplementary agreement amount." The evolutionary system extracts the core elements of the compensation rules from this characteristic: the object to be checked is "supplementary agreement amount," and the action to be performed is "if a supplementary agreement amount exists, then correct the output of the first rule from compliant to non-compliant."

[0198] The second step involves the evolutionary system converting the compensation rules into executable logic code or configuration parameters. The compensation rules can take one of two forms: Simple rule form: A conditional expression, formatted as "If [condition] is met, then the output will be corrected from [original value] to [corrected value]". Here, [condition] can be a keyword existence check (e.g., "The object under review contains keyword X"), a numerical comparison (e.g., "The amount is greater than Y"), or a regular expression match.

[0199] Mapping table format: A key-value pair mapping table that maps the possible output values ​​of the first rule to the corrected output values. For example, the mapping table is {"compliant": "pending review", "non-compliant": "non-compliant"}.

[0200] The execution logic of the compensation corrector is as follows: After the first review rule outputs its result, before passing that result to the second review rule, the compensation corrector performs the following operations: The first step is to read the output of the first review rule.

[0201] The second step is to determine, based on the compensation rules, whether the output needs to be corrected. The method of determination depends on the form of the compensation rules: If the compensation rule is a simple rule, the conditional judgments within that rule are executed. For example, the compensation rule might be "If the reviewed object contains 'supplementary agreement,' then the output will be corrected to 'non-compliant.'" The compensation corrector checks whether the reviewed object contains the keyword "supplementary agreement." If it does, correction is required; otherwise, no correction is needed.

[0202] If the compensation rule is in the form of a mapping table, then check if there is an entry in the mapping table corresponding to the current output result. If it exists, then it is determined that correction is needed, and the correction value is the corresponding value in the mapping table; if it does not exist, then it is determined that no correction is needed.

[0203] Third, if it is determined that correction is needed, the compensation and correction unit will replace the output with the correction value; if it is determined that no correction is needed, the original output will remain unchanged.

[0204] The fourth step is for the compensation corrector to pass the corrected (or unchanged) output to the second review rule.

[0205] It should be noted that the construction of compensation rules can be automatic or manual. The automatic construction method involves the evolutionary system calling the large language model (the same model used in S1041), taking the problem description of the first problem pattern as input, and requesting the large language model to output compensation rules. The specific calling method is the same as the large language model API calling method described in S1041, and will not be repeated here. For example, sending a prompt to the large language model: "Please generate a compensation rule based on the following problem pattern: Missed Report: Supplementary Agreement Amount Not Checked. Output format: If the reviewed object contains [keyword], then correct the output to [correction value]." The large language model returns: "If the reviewed object contains 'Supplementary Agreement Amount', then correct the output from 'compliant' to 'non-compliant'." The manual construction method involves the administrator manually inputting the conditions and correction values ​​of the compensation rule through the configuration interface provided by the evolutionary system.

[0206] Example: The first review rule, RULE-001, has a false negative issue, frequently misclassifying contracts containing supplementary agreement amounts as "compliant" (when they should actually be "non-compliant"). The characteristic of this first problem pattern is "supplementary agreement amount." The evolutionary system automatically generates a compensation rule using a large language model: "If the review object contains the keyword 'supplementary agreement amount,' then the output will be corrected from 'compliant' to 'non-compliant.'" When the compensation corrector executes, it checks whether the review object contains the keyword "supplementary agreement amount." If it does, the output "compliant" of RULE-001 is corrected to "non-compliant," and the corrected "non-compliant" is then passed to the downstream rule RULE-002; if it does not contain the keyword, the original output "compliant" remains unchanged and is directly passed to RULE-002.

[0207] The blocking strategy is embedded into the rule execution engine as a configuration parameter. Specifically, the evolutionary system adds a "blocking strategy" metadata field to the rule repository for affected rules. The value of this field is a JSON object containing the strategy type ("validation filtering" or "compensation correction") and strategy parameters (such as filtering conditions and correction rules). When the rule execution engine loads a rule, it reads this metadata field and automatically invokes the corresponding blocking strategy logic before or after rule execution.

[0208] For S1051 to S1053, the evolutionary system predicts the set of review rules that may be affected after the candidate rule replacement based on the problem pattern propagation relation library and dependency graph. The specific process is as follows: The first step is for the evolutionary system to obtain the rule ID of the target review rule and its set of problem patterns.

[0209] The second step is to query the problem pattern propagation relationship database for each problem pattern and find all propagation relationship records that start from that problem pattern.

[0210] The third step involves the evolutionary system identifying all review rules (i.e., downstream rules of the target review rule) that are directly or indirectly dependent on the target review rule, based on the dependency graph. The query method is as follows: starting from the target review rule node, traverse downstream along the directed edges of the dependency graph, recording all reachable rule nodes.

[0211] The fourth step is for the evolutionary system to aggregate and deduplicat all the downstream rules mentioned above, forming a set of affected review rules.

[0212] For each rule in the affected set of review rules, the evolutionary system calculates the expected change in accuracy. The calculation is as follows: The evolutionary system extracts historical review data for the affected rule from the historical database. For each piece of historical review data, the evolutionary system performs the following simulation operation: First, candidate rules of the target review rule are applied to the review object to obtain a simulated output. Then, this simulated output is used as input to the affected rule, and the current version of the affected rule is used to perform a review on the same review object to obtain a simulated review conclusion. Finally, this simulated review conclusion is compared with the correct conclusions in historical data. After simulating all historical data, the evolutionary system calculates the simulation accuracy of the affected rule. The difference between this simulated accuracy and the current accuracy is the expected change in accuracy. This change can be positive (accuracy increase), negative (accuracy decrease), or zero (no change).

[0213] The evolutionary system will generate a risk warning message based on the calculation results. The risk warning message will include at least the following: a list of affected rules, the expected change in accuracy for each affected review rule, a list of rules whose changes exceed a threshold, and a suggested review action (e.g., "Recommend Approval," "Recommend Rejection," or "Manual Confirmation Required"). The risk warning message will be generated in JSON format and displayed in a table or list format on the reviewer's interface.

[0214] The evolutionary system presets a risk threshold, which in this embodiment defaults to -5% (i.e., the expected decrease in accuracy exceeds 5 percentage points). This risk threshold can be adjusted by the administrator based on the business scenario. The evolutionary system checks whether there are any review rules in the affected review rule set whose expected accuracy change is less than this threshold (i.e., a decrease of more than 5 percentage points): If there is no rule whose expected accuracy decrease exceeds the threshold, the evolutionary system continues to execute the manual review process in step S105. Once the reviewer approves the candidate rule itself, the replacement can be performed.

[0215] If a rule's expected accuracy decrease exceeds a threshold, the evolutionary system pauses the replacement process and prominently displays a risk warning on the reviewer's interface (e.g., highlighting the affected rule in red). The reviewer must read the risk warning and then click the "Approve" or "Reject" button. If the reviewer clicks "Approve," the evolutionary system continues the replacement process; if the reviewer clicks "Reject," the evolutionary system terminates the replacement process, the current rule remains unchanged, and the reason for the rejection (risk threshold triggered) is recorded in the version management data table.

[0216] This application also discloses a multi-source feedback-driven self-evolutionary review rule system. (Refer to...) Figure 2 ,include: The feedback data acquisition module 201 is used to collect multi-source feedback data generated after the execution of the review rules. The multi-source feedback data includes at least review annotation data and user feedback data of the reviewed object. The evolution trigger determination module 202 is used to determine whether to trigger the evolution process of the corresponding review rule based on the feedback of each review rule; The evolution process execution module 203 is used to extract all negative feedback of the target review rule when the target review rule triggers the evolution process, and analyze the negative feedback to identify at least one problem pattern of the target review rule; wherein, the negative feedback refers to feedback data indicating that the review conclusion is incorrect; The candidate rule generation module 204 is used to input the rule content of the target review rule and the identified problem pattern into the large language model, and the large language model generates candidate rules to solve the problem pattern. The rule verification and update module 205 is used to verify the candidate rule, and after the verification is passed, the candidate rule is used to replace the target review rule.

[0217] This application also discloses a multi-source feedback-driven review rule self-evolution device, which includes a memory and a processor. The memory stores a computer program that can be loaded by the processor and executed as described above for the multi-source feedback-driven review rule self-evolution method.

[0218] This application also discloses a computer-readable storage medium that stores a computer program that can be loaded by a processor and executed as described above in the multi-source feedback-driven self-evolution method for review rules. The computer-readable storage medium includes, for example, various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0219] It should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0220] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit the scope of protection of the application. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on these embodiments, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

Claims

1. A self-evolutionary method for review rules driven by multi-source feedback, characterized in that, include: Collect multi-source feedback data generated after the execution of the review rules, wherein the multi-source feedback data includes at least review annotation data and user feedback data of the reviewed object; The decision on whether to trigger the corresponding review rule's evolution process is based on the feedback received for each review rule. When a target review rule triggers an evolutionary process, all negative feedback from the target review rule is extracted, and the negative feedback is analyzed to identify at least one problem pattern in the target review rule; wherein, the negative feedback refers to feedback data indicating that the review conclusion is incorrect; The rule content of the target review rule and the identified problem pattern are input into the large language model, and the large language model generates candidate rules to solve the problem pattern. The candidate rule is verified, and if the verification is successful, the candidate rule is used to replace the target review rule.

2. The multi-source feedback-driven self-evolutionary review rule method according to claim 1, characterized in that, The process involves analyzing the negative feedback to identify at least one problem pattern in the target review rule, inputting the rule content of the target review rule and the identified problem pattern into a large language model, and generating candidate rules for resolving the problem pattern, including: All negative feedback is clustered according to the text similarity of the feedback content, and the problem pattern of each category is extracted. Map the corresponding atomic repair action to solve the problem pattern based on each problem pattern; All atomic repair actions are merged to generate a composite optimization instruction. The rule content of the target review rule and the composite optimization instruction are input into the large language model, which generates candidate rules to solve the problem pattern. The composite optimization instruction is a structured instruction described in natural language, which explicitly lists each problem pattern and its corresponding atomic repair action, and requires the large language model to generate candidate rules that simultaneously satisfy all atomic repair actions.

3. The multi-source feedback-driven self-evolution method for review rules according to claim 2, characterized in that, The candidate rule is a composite rule, and the composite rule includes: Multiple sub-rules, each sub-rule corresponding to a problem pattern combination, the problem pattern combination is divided according to the scenario affiliation tag of each problem pattern, and problem patterns belonging to the same review scenario are classified into the same problem pattern combination; The scenario activation condition configuration is used to define the applicable scenario for each sub-rule. The scenario activation condition is determined based on the matching relationship between the contextual features of the review object and the scenario features of the problem pattern rule. When the contextual features of the object under review match the scenario activation condition of a certain sub-rule, the corresponding sub-rule is activated and the review is performed; when the scenario activation conditions of multiple sub-rules are matched at the same time, the sub-rule to be executed or the output is merged according to the preset routing strategy.

4. The multi-source feedback-driven self-evolutionary review rule method according to claim 1, characterized in that, The process of merging all atomic repair actions to generate a composite optimization instruction includes: After identifying the problem patterns and corresponding atomic repair actions of the target review rules, the problem patterns are first matched with existing atomic problem units. The atomic problem units are independent units that are pre-encapsulated problem patterns and corresponding atomic repair actions. Each atomic problem unit contains a feature description of the problem pattern and a corresponding atomic repair action. If a match is successful, a reference identifier is established between the target review rule and the matched existing atomic problem unit; if a match fails, a new atomic problem unit is created for the current problem mode, and a reference identifier is established between the target review rule and the newly created atomic problem unit. For other rules, compare the content of the rule with the feature description in the atomic problem unit referenced by the target review rule, determine other rules that match the atomic problem unit referenced by the target review rule, and actively establish a reference identifier between the determined other rules and the corresponding atomic problem unit; The atomic repair actions in the atomic problem units referenced by the target review rules are used to generate the composite optimization instructions; The method further includes: Once the target review rule has evolved and the corresponding candidate rule has passed verification, the atomic repair action corresponding to the candidate rule is stored as the updated atomic repair action in the corresponding atomic problem unit, thereby updating the atomic repair action and the atomic problem unit. Then, using the updated atomic repair action, other rules that reference the updated atomic problem unit, besides the target review rule, are input into the large language model to execute the process of generating candidate rules.

5. The multi-source feedback-driven self-evolutionary review rule method according to claim 4, characterized in that, The method further includes: When the same target atomic problem unit is referenced by multiple review rules, analyze the input data sources of all review rules referenced by the target atomic problem unit. The input data sources refer to the input fields that each review rule depends on when it is executed, the review conclusions or data tables generated after the execution of other review rules. If, among the input data sources of multiple review rules, there exists a review conclusion generated after the execution of a specific review rule that is used as input by other review rules, and the specific review rule itself contains the problem pattern corresponding to the atomic problem unit, then the specific review rule is identified as the source rule. If the source rule exists, the evolution process of the source rule is immediately triggered and is completed before other review rules that reference the same target atomic problem unit as the source rule. After the source rule evolution is completed, other review rules that reference the same target atomic problem unit as the source rule are re-evaluated: if the problem pattern of the evaluated review rule has disappeared with the evolution of the source rule, the evolution process of the evaluated review rule is canceled.

6. The multi-source feedback-driven self-evolution method for review rules according to claim 1 or 2, characterized in that, The method further includes: A problem pattern propagation relationship library is pre-built. The propagation relationship library records the propagation relationship between the first problem pattern and the second problem pattern. The propagation relationship is defined as follows: when the first problem pattern appears in the first review rule, if the output of the first review rule is used as the input of the second review rule, then the first problem pattern has the risk of propagating to the second review rule and triggering the second problem pattern. If a first problem pattern is identified in the problem patterns of the target review rules, the transmission relationship database is queried to determine the second review rule with transmission risk and the corresponding second problem pattern; While generating candidate rules for the first issue pattern of the target review rule, a blocking strategy is deployed along the transmission path to prevent the first issue pattern from propagating to the second review rule, thus preventing the second issue pattern from being triggered.

7. The multi-source feedback-driven self-evolutionary review rule method according to claim 6, characterized in that, The step of replacing the target review rule with the candidate rule includes: Based on the problem pattern propagation relation library, predict the set of review rules that will be affected after the candidate rule is replaced; Calculate the expected accuracy change range for each review rule in the set of review rules, generate risk warning information from the calculation results, and display the risk warning information to the auditor for review. If there is a review rule in the set of review rules whose expected accuracy change exceeds a preset threshold, the process of replacing the candidate rule of the corresponding review rule will be paused, and the decision on whether to execute the replacement process will be made based on the reviewer's review results; if the review is passed, the replacement process will be executed, and if the review is not passed, the replacement process will be terminated.

8. A multi-source feedback-driven self-evolving review rule system, characterized in that, include, The feedback data collection module is used to collect multi-source feedback data generated after the execution of the review rules. The multi-source feedback data includes at least review annotation data and user feedback data of the reviewed object. The evolution trigger determination module is used to determine whether to trigger the evolution process of the corresponding review rule based on the feedback of each review rule; The evolutionary process execution module is used to extract all negative feedback of the target review rule when the target review rule triggers the evolutionary process, and analyze the negative feedback to identify at least one problem pattern of the target review rule; wherein, the negative feedback refers to feedback data indicating that the review conclusion is incorrect; The candidate rule generation module is used to input the rule content of the target review rule and the identified problem pattern into the large language model, and the large language model generates candidate rules to solve the problem pattern. The rule verification and update module is used to verify the candidate rules, and after the verification is passed, the candidate rules are used to replace the target review rules.

9. A multi-source feedback-driven self-evolutionary review rule device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executed as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer program is stored that can be loaded by a processor and executed as described in any one of claims 1 to 7.

Images