A contract intelligent auditing method and system
Patent Information
- Application Number
- CN202611076225.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-20
- Publication Date
- 2026-10-16
AI Technical Summary
现有智能审核系统通常将审核规则硬编码于程序代码中,当业务需求变化需要新增审核维度或修改审核逻辑时,必须修改源代码并重新编译部署,导致系统灵活性差、维护成本高、响应速度慢
[0082] (1) Zero-code update and conflict self-resolution of review rules: Through a pluggable kernel architecture and JSON-driven strategy configuration, adding a new review dimension only requires adding a JSON configuration file and the corresponding Kernel implementation class, without modifying the core code. More importantly, through dependency graph construction, circular dependency detection, and rule logic conflict detection, configuration errors can be automatically detected and blocked during the rule loading stage, avoiding review failures or system anomalies caused by rule conflicts or dependency deadlocks, which greatly improves the reliability and maintainability of the system.
Smart Images

Figure CN122927259A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the technical field of artificial intelligence and natural language processing, specifically to a method and system for intelligent contract review, and more particularly to a method and system for intelligent contract review based on a pluggable kernel strategy and dynamic semantic perception. Background Technology
[0002] Contract review is a core task for corporate legal, business, and risk control departments, requiring a comprehensive examination of the legality, compliance, risk points, and balance of rights and obligations of contract terms. With the development of artificial intelligence technology, intelligent contract review systems are gradually replacing traditional manual review methods; however, the following technical issues still exist in practical applications:
[0003] (1) Hard-coding problem of audit rules. Existing intelligent audit systems usually hard-code audit rules into the program code. When business needs change and new audit dimensions need to be added or audit logic needs to be modified, the source code must be modified and recompiled and deployed, resulting in poor system flexibility, high maintenance costs and slow response speed. In particular, for contracts of different industries (such as construction engineering, IT services, finance, etc.), the audit points are significantly different, and the fixed rule system is difficult to adapt to the diverse audit needs.
[0004] (2) Issues with conflicting audit rules and dependency deadlocks. Contract auditing involves multi-dimensional and multi-level audit rules, with complex logical dependencies (defined through combineKeys) and business constraints between different audit items. Existing systems lack effective conflict detection and dependency analysis mechanisms when dynamically loading audit rules, and cannot automatically identify logical contradictions between rules (e.g., rule A requires "tax rate > 13%" to pass, while rule B requires "tax rate < 10%" to pass, and the two are logically mutually exclusive) and circular dependencies (e.g., audit item A depends on B, B depends on C, and C depends on A). When rule configuration is incorrect, the system may produce invalid audit results or enter an infinite loop, seriously affecting audit reliability and system stability.
[0005] (3) Insufficient accuracy in text semantic matching. Quality clauses and regulatory references in contracts are often flexibly worded, frequently exhibiting text variations such as synonym substitution, word order adjustments, and partial omissions. Existing review systems mostly employ exact matching, regular expressions, or fuzzy matching algorithms based on edit distance (such as Longest Common Subsequence (LCS) and SequenceMatcher). These methods only perform character-level or word-frequency-level similarity calculations and cannot perceive the deeper semantic information of the text. Especially for clauses containing negative words (such as "not less than" or "prohibited from use") or conditional adverbs (such as "only under the condition of..."), character-level matching is prone to misjudgment. For example, "The wall thickness of the upright pipe must be greater than 3.2mm" and "The wall thickness of the upright pipe must not be greater than 3.2mm" have extremely high character similarity but completely opposite semantics. Existing algorithms cannot distinguish between them, resulting in a persistently high misjudgment rate during review.
[0006] (4) AI review results lack interpretability. Existing intelligent review systems typically only output "pass / fail" conclusions and simple modification suggestions, operating in a black-box or semi-white-box manner. When review results are incorrect or business personnel have doubts about the review conclusions, operators find it difficult to quickly pinpoint whether the problem stems from incorrect rule configuration, NER extraction errors, or misjudgments by the matching algorithm. Especially in the field of legal compliance, review conclusions directly affect contract signing and business operations. The lack of traceable and interpretable review process information severely restricts the credibility and adoption rate of AI review systems in actual business. Furthermore, existing systems cannot provide the ability to predict "how the review result will change if a certain clause is modified," failing to assist users in making decisions regarding contract clause revisions. Summary of the Invention
[0007] In view of the above-mentioned technical problems in related technologies, the present invention provides a contract intelligent review method and system that can solve the above problems.
[0008] To achieve the above-mentioned technical objectives, the technical solution of the present invention is implemented as follows:
[0009] A smart contract review method includes the following steps:
[0010] S1. Contract Document Acquisition and Preprocessing: Acquire contract documents to be reviewed, supporting automatic recognition and conversion of PDF and Word (.doc / .docx) formats, and uniformly converting non-docx format documents to docx format;
[0011] S2. Contract Text Structured Parsing: A custom Word document parser is used to perform structured parsing on the docx document, extracting document elements such as paragraphs, tables, images, and table of contents, and constructing a WordDocEntity structured document object; the structured document object contains full text strings, unindexed text strings, and table text strings;
[0012] S3. Named Entity Recognition and Extraction: Employing a Master-Worker model NER strategy engine, the engine performs named entity recognition and extraction on structured document objects based on the extraction strategy configured in the JSON, generating an EntityResult list. The extraction strategies include various scopeTypes such as paragraph extraction, single-row table extraction, multi-row table extraction, and full-table extraction. Each strategy is configured with regular expression patterns and entity boundaries. The NER strategy engine supports synonym mapping, uniformly mapping synonyms in the text to standard entity names.
[0013] S4. Dynamic loading and rule conflict resolution of review strategies: Review entities are loaded from the JSON configuration file through the review strategy factory, managed according to contract type, and a review entity mapping table is constructed. The review entity includes review strategy type, review answer, review suggestion, composite key, review data, enterprise information mapping, dictionary list and sorting field. During the loading process, the logical dependency graph of the review entity is constructed and rule conflict detection and circular dependency detection are performed. If a conflict or dependency abnormality is detected, loading is automatically blocked and an alarm message is generated.
[0014] S5. Pluggable Audit Kernel Execution: The kernel factory dynamically obtains the corresponding audit kernel based on the policy type of the audit entity, and performs multi-dimensional intelligent auditing; the kernel factory maintains a kernel registry, and if the kernel corresponding to the policy type has not yet been created, it is dynamically created and cached; the audit kernel includes the following nine types:
[0015] (a) Amount capitalization verification kernel: Parses Chinese uppercase amounts using AmountExtractorAndComparator and compares them with Arabic numerals;
[0016] (b) Existence check kernel: checks whether a specified entity exists in the contract text;
[0017] (c) Non-existence check kernel: checks whether the specified entity does not exist in the contract text;
[0018] (d) Enterprise Information Verification Kernel: Parse the structured enterprise information in the contract and compare it field by field with the pre-stored enterprise information;
[0019] (e) Enterprise Blacklist Screening Kernel: Matching and screening enterprise names in contracts with blacklists;
[0020] (f) Core of goods price review: Analyze the contract details table, extract fields such as material name, specifications, unit price including tax, and tax rate, and compare them with the guidance price to judge the reasonableness of the price;
[0021] (g) Quality Clause Review Core: Employs a multi-strategy fuzzy matching and dynamic semantic perception algorithm to intelligently compare the key points of quality review with the text of the contract quality clauses. The algorithm includes a two-level structure of character-level fuzzy matching layer and semantic verification layer.
[0022] (h) Section content includes kernel check: Check whether the contract section contains specified content based on Jaccard similarity;
[0023] (i) Chapter content exclusion check kernel: Check whether the contract chapters contain content that should not appear based on dictionary regular expression matching;
[0024] S6. Composite Key Dependency Review Processing: For review entities configured with composite keys, the dependent sub-review items are recursively processed based on the dependency graph constructed in step S4, and the sub-review results are summarized to generate a joint review judgment; each review result is associated with its data source tag, which includes rule source tag, entity source tag and algorithm source tag;
[0025] S7. Summary of Audit Results and Generation of Explanability Report: Summarize the execution results of all audit kernels and generate a structured audit report according to the sorting, department, location, and other fields configured for the audit entities. The report includes audit conclusions, audit opinions, risk location markings, and modification suggestions. For items that fail the audit, counterfactual explanations are automatically generated. These counterfactual explanations explain how the audit conclusions would change if specific modifications were made to the contract terms.
[0026] It also includes object pooling engine management steps: the auditing engine and NER engine can be managed through Apache Commons Pool2's GenericObjectPool. Engine instances are borrowed from the object pool when an auditing task starts and returned to the object pool after the task is completed. Auditing tasks are executed asynchronously through a thread pool with a timeout set.
[0027] Furthermore, the specific methods for rule conflict detection and circular dependency detection described in step S4 are as follows:
[0028] (a) Construction of the dependency graph of the audit entity: Traverse all audit entities, take the unique identifier (name) of each audit entity as the node, and take the dependencies in the combineKeys list configured for the audit entity as the directed edges, and construct the logical dependency graph G(V,E) of the audit entity, where V is the set of audit entity nodes, E is the set of dependency relationship edges, and the edge direction is from the dependent party to the dependent party; at the same time, attach semantic attributes to each edge, including the dependency type (pre-dependency, header key item dependency, ordinary dependency).
[0029] (b) Circular dependency detection: The logical dependency graph G is traversed using a depth-first search algorithm. For each unvisited node, a DFS recursive search is performed, and the current recursive call stack path is maintained. If a node already in the current recursive stack is encountered during the search, a circular dependency is determined. The complete path of the circular dependency (e.g., A→B→C→A) is recorded, a circular dependency alarm is generated, and the loading of all audit entities under this audit scheme is blocked.
[0030] (c) Rule Logic Conflict Detection: For the audit answer and audit policy type configured in the audit entity, extract the judgment condition range for each audit rule. The judgment condition range includes a numerical range (e.g., tax rate > 13%), existence conditions (should exist / should not exist), and an enumerated value set; detect logic conflicts through the following sub-steps:
[0031] (c1) For multiple audit items of the same target entity (such as "tax-inclusive unit price"), extract their numerical judgment intervals and use the interval intersection algorithm to determine whether there is an intersection; if the interval intersection is empty (such as rule A requires ">13%" and rule B requires "<10%", the intersection is empty), then it is determined to be a numerical interval conflict;
[0032] (c2) If the inclusion check (existence check) and exclusion check (non-existence check) of the same contract clause are both for the same entity name and have the same scope of review, they are determined to be mutually exclusive rules in conflict.
[0033] (c3) Summarize all detected rule conflicts, generate a conflict list, block them during the loading phase, and record alarm logs.
[0034] (d) Rule Priority and Conflict Resolution Strategy: For non-fatal conflicts (such as partially overlapping but not completely contradictory numerical ranges), automatic resolution is performed according to preset rule priorities. The priority rules are (from high to low): industry mandatory normative rules > enterprise internal control rules > general rules; or the priority is automatically determined based on the sort field of the audit entity. The resolved rules participate in subsequent audit execution as effective rules; the resolved rules are recorded in the resolution log and included in the interpretability information of the audit report.
[0035] Furthermore, the quality clause review kernel described in step S5 employs a multi-strategy fuzzy matching and dynamic semantic awareness algorithm, specifically including a two-level structure of a character-level fuzzy matching layer and a semantic verification layer:
[0036] (a) Character-level fuzzy matching layer: This layer is the first level of matching and includes the following sub-steps:
[0037] (a1) Text preprocessing: Normalize Chinese punctuation, merge whitespace, and convert to lowercase for the input target text (audit standard clauses) and source text (contract quality clauses);
[0038] (a2) Quick judgment: If the two preprocessed texts are completely identical or the source text contains the target text, the matching is returned directly and the similarity is assigned a value of 1.0, without entering the semantic verification layer;
[0039] (a3) Multi-strategy fuzzy matching comprehensive score:
[0040] Sentence splitting and matching: The source text is split into sentences according to punctuation marks, and the SequenceMatcher similarity is calculated for each sentence, with the highest value being taken;
[0041] Sliding window matching: Slide the window in the source text at a size of 0.8 to 1.2 times the length of the target text, calculate the SequenceMatcher similarity between the window substring and the target text, and take the highest value;
[0042] LCS Coverage: The coverage is calculated by dividing the length of the longest common subsequence between the target text and the source text by the length of the target text.
[0043] Overall character similarity S char = max(sentence split matching similarity, sliding window matching similarity, LCS coverage);
[0044] (a4) If S char >High threshold TH high (Default 0.92), directly judged as a successful match, without needing to enter the semantic validation layer; if S char <low threshold TH low (Default 0.60), directly judged as a matching failure, no need to enter the semantic validation layer; if S char Located in [TH low ,TH high If the range is specified, it will proceed to the semantic verification layer for in-depth adjudication.
[0045] (ii) Semantic Validation Layer: This layer is the second level of validation, triggered only when the character-level matching is in a critical uncertainty range, and includes the following sub-steps:
[0046] (b1) Logical polarity perception: Dependency parsing is performed on the target text and the source text respectively to extract the core predicates of the sentences and their logical polarities; the logical polarities include affirmative polarity and negative polarity, which are determined by identifying the dependency relationship between negative words (not, not, not, not, do not, other, no, non, prohibit, not allowed, strictly prohibited, etc.) and the core predicates;
[0047] (b2) Polarity Comparison: If the logical polarity of the target text is inconsistent with that of the source text (e.g., the target text is "must be greater than" for affirmation, while the source text is "not greater than" for negation), then it is directly determined as a semantic mismatch, even if S char Even higher values will result in a match failure.
[0048] (b3) Semantic similarity calculation: If the polarities are consistent, a lightweight pre-trained language model is used to encode the semantic vectors of the target text and the source text, and the cosine similarity S is calculated. semantic The lightweight pre-trained language model is a small BERT model fine-tuned with legal domain corpus, with no more than 30M parameters.
[0049] (b4) Comprehensive semantic judgment: Calculate the comprehensive semantic score S final =α×S char +β×S semantic , where α+β=1, and α and β are configurable weights (default α=0.4, β=0.6); if S final ≥Semantic threshold TH semantic If the value is 0.75 (default), it is considered a successful semantic match; otherwise, it is considered a failed match.
[0050] Furthermore, the specific method for generating the data lineage tracing and interpretability report of the audit results in step S7 is as follows:
[0051] (I) Generation and Association of Data Source Tags: During the execution of the audit engine, the following three types of data source tags are associated and recorded for each audit result:
[0052] (a1) Rule source tag (rule) source ): Records the JSON configuration file path, audit entity name, policy type, and rule priority level that triggered the audit item; for composite key dependent audit items, additionally records their dependency chain path;
[0053] (a2) Entity source tag source ): Records the original document location corresponding to the NER entity extraction result on which the review item depends, including the paragraph number, table number, row number, column number, and the scopeType and regular expression pattern used during extraction;
[0054] (a3) Algorithm source tags (algorithm) source ): Records the execution results of each level of the fuzzy matching algorithm during the quality clause review, including character-level similarity S. char Whether the semantic verification layer is triggered, the logical polarity comparison result, and the semantic similarity S. semantic Comprehensive semantic score S finalAnd the final judgment criteria (threshold comparison details);
[0055] (ii) Generation of the Explanatory Audit Report: After summarizing all audit results, generate the explanatory audit report according to the following structure:
[0056] (b1) Overview of Audit Conclusions: Displays statistics on the pass / fail status of all audit items;
[0057] (b2) Item-by-item review details: For each review item, the review conclusion, review comments, risk location markings, and modification suggestions are displayed, and an interactive "view source traceability" entry is provided. After expansion, the complete data source tag information of the review item is displayed;
[0058] (b3) Rule loading and conflict resolution log: Displays the list of rule conflicts detected in step S4 and their resolution results, including the name of the resolved rule, the reason for resolution, and the priority rule that took effect;
[0059] (III) Generation of Counterfactual Explanation Information: For items that fail the review, counterfactual explanation information is automatically generated:
[0060] (c1) For audit items that fail the existence check (the entity required to exist does not exist), the counterfactual explanation is: "If the relevant content of '[entity name]' is added to the contract [location], the item will pass";
[0061] (c2) For audit items that fail the numerical judgment (such as price exceeding the limit), the counterfactual explanation is: "If the [field name] is changed from [current value] to [threshold], the item will pass"; where [threshold] is calculated based on the judgment boundary value in the audit rules;
[0062] (c3) For audit items that fail the fuzzy matching of quality clauses, the counterfactual explanation is: "If the contract clause [original text fragment] is modified to achieve a similarity of [required threshold] with the audit standard '[standard clause]', the item will pass"; where the [required threshold] is calculated based on the difference between the current similarity and the judgment threshold.
[0063] (c4) For items whose composite key dependencies fail the audit, the counterfactual explanation information summarizes the counterfactual suggestions of all dependent sub-items and presents them in the order of the dependency chain.
[0064] Furthermore, the counterfactual explanation information is generated using a template-filling method. The system extracts structured information such as the current value, threshold, and position from the review results and fills it into a preset counterfactual explanation template to generate counterfactual suggestions in natural language.
[0065] Furthermore, the specific method for the composite key dependency auditing process described in step S6 is as follows:
[0066] (a) For an audit entity that has been configured with combineKeys, obtain the dependency graph structure corresponding to the audit scheme;
[0067] (b) Iterate through each key in the list of composite keys and check whether the audit result corresponding to the key already exists in the result mapping table;
[0068] (c) If it does not exist, determine the processing order according to the dependency graph (sorted by topology), recursively call the doWork method to process the audit entity of the dependency first, and obtain its audit result;
[0069] (d) If a key combination begins with a specific prefix (such as "+TABHead+:"), it is marked as a header key.
[0070] (e) Summarize the audit results corresponding to all combination keys. If any key item in the header fails the audit, the entire audit fails and a preliminary suggestion is returned. Otherwise, summarize all failed items and generate a joint audit opinion based on the suggestion template of the audit entity. If all sub-audit items pass, the overall audit passes.
[0071] A contract intelligent review system includes a software system and a cloud server, wherein the cloud server is connected to the software system, and the software system is capable of implementing the steps of the above-described method; the software system includes the following modules:
[0072] The document acquisition and preprocessing module is used to acquire contract documents to be reviewed and perform format conversion.
[0073] The document structuring parsing module is used to extract document elements such as paragraphs, tables, images, and tables of contents using a custom Word document parser, and to construct structured document objects.
[0074] The NER strategy engine module adopts the Master-Worker mode and performs named entity recognition and extraction on structured documents according to the extraction strategy configured in JSON.
[0075] The module for dynamically loading audit strategies and resolving rule conflicts is used to load audit entities from JSON configuration files, build a dependency graph, and perform circular dependency detection and rule logic conflict detection. After the detection is passed, audit rules are managed according to contract type.
[0076] The pluggable audit kernel execution module dynamically obtains the audit kernel based on the policy type through the kernel factory and performs multi-dimensional intelligent auditing. The quality clause audit kernel includes a two-level structure of character-level fuzzy matching layer and semantic verification layer.
[0077] The composite key dependency audit module is used to process the logical dependencies between audit entities based on the dependency graph.
[0078] The audit results summary and interpretability report generation module is used to summarize audit results and generate a structured audit report that includes data lineage information and counterfactual explanations.
[0079] The object pooling management module is used to manage the reuse and recycling of audit engine and NER engine instances.
[0080] Furthermore, the cloud server adopts a Spring Cloud microservice architecture, including gateway services, system services, business services, scheduled task services, file services, and common modules. The service registry center uses Nacos, which supports horizontal scaling and load balancing of services. The common modules include three core AI sub-modules: an audit engine, a NER engine, and a text processing tool.
[0081] The beneficial effects of this invention are:
[0082] (1) Zero-code update and conflict self-resolution of review rules: Through a pluggable kernel architecture and JSON-driven strategy configuration, adding a new review dimension only requires adding a JSON configuration file and the corresponding Kernel implementation class, without modifying the core code. More importantly, through dependency graph construction, circular dependency detection, and rule logic conflict detection, configuration errors can be automatically detected and blocked during the rule loading stage, avoiding review failures or system anomalies caused by rule conflicts or dependency deadlocks, which greatly improves the reliability and maintainability of the system.
[0083] (2) Significantly improved text semantic matching accuracy: A two-level matching architecture of "character-level multi-strategy fuzzy matching + semantic verification layer" is adopted. When the character-level matching is in the critical uncertainty range, the logical polarity (positive / negative) of the sentence is perceived through dependency parsing, effectively distinguishing semantically opposite expressions such as "must be greater than" and "not greater than". Combined with a lightweight legal domain pre-trained model for semantic similarity calculation, the technical bottleneck of traditional edit distance algorithm being unable to perceive deep semantics is solved while ensuring computational efficiency.
[0084] (3) Significantly enhanced interpretability of AI audit results: By associating each audit result with three types of data lineage information—rule source tags, entity source tags, and algorithm source tags—complete traceability of audit conclusions is achieved. Business personnel can clearly understand the generation path of audit conclusions, locate the root cause of problems, and greatly improve the credibility of the system. At the same time, through the counterfactual interpretation mechanism, the system can automatically generate predictive information on "how the audit conclusion will change if a certain clause is modified," effectively assisting users in making decisions to revise contract terms and filling the gap in decision support of existing AI audit systems.
[0085] (4) Significantly improved audit flexibility: Through a pluggable kernel architecture and JSON-driven strategy configuration, it can adapt to the personalized audit needs of different industries and enterprises. Attached Figure Description
[0086] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the 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.
[0087] Figure 1 This is a flowchart of a contract intelligent review method according to an embodiment of the present invention;
[0088] Figure 2 This is a schematic diagram of the pluggable audit kernel architecture described in an embodiment of the present invention;
[0089] Figure 3 This is a flowchart of the NER strategy engine workflow as described in an embodiment of the present invention;
[0090] Figure 4 This is a flowchart of the rule conflict detection and circular dependency detection process described in the embodiments of the present invention;
[0091] Figure 5 This is a flowchart of the multi-strategy fuzzy matching and dynamic semantic perception algorithm described in the embodiments of the present invention;
[0092] Figure 6 This is a flowchart of the composite key dependency audit mechanism described in an embodiment of the present invention;
[0093] Figure 7 This is a flowchart illustrating the data lineage tracing and counterfactual interpretation generation process described in this embodiment of the invention. Detailed Implementation
[0094] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention are within the scope of protection of the present invention.
[0095] Example 1 (System Overall Architecture):
[0096] This invention relates to an intelligent contract review system, comprising a software system and a cloud server, with the cloud server connected to the software system. The software system includes: a document acquisition and preprocessing module, a document structured parsing module, a NER strategy engine module, a dynamic loading and rule conflict resolution module for review strategies, a pluggable review kernel execution module, a composite key dependency review module, and a review result aggregation and interpretability report generation module. The cloud server adopts a Spring Cloud microservice architecture, and the service registry uses Nacos. The system includes the following microservice modules: a gateway service responsible for request routing and load balancing; a system service providing user permission management; a business service carrying the core business logic of contract review; a scheduled task service handling asynchronous review tasks; a file service managing contract document storage; and a common module including three core AI sub-modules: ai-audit-engine (review engine), ai-ner-engine (NER engine), and ai-text-commons (text processing tools).
[0097] like Figure 1 As shown, the software system performs the following steps: S1, contract document acquisition and preprocessing; S2, contract text structured parsing; S3, named entity recognition and extraction; S4, dynamic loading of audit strategies and resolution of rule conflicts; S5, execution of pluggable audit kernel; S6, composite key dependency audit processing; S7, summary of audit results and generation of interpretability report.
[0098] Example 2 (Contract Document Acquisition and Preprocessing):
[0099] In this application, contract document acquisition and preprocessing are implemented by the AppMainCustom class. The system supports automatic recognition and conversion of PDF and Word (.doc / .docx) formats. For .doc format documents, the LibreOffice command-line conversion method is used to convert them to .docx format; if the first conversion fails, a backup conversion method is used. For .pdf format documents, the pdfConversionDocx method is used to convert them to .docx format. The converted .docx documents then proceed to subsequent processing.
[0100] Example 3 (Document Structure Parsing):
[0101] In this application, document structure parsing is implemented by the WordDocParserCustom class. This parser performs deep parsing on docx documents, extracting the following document elements: paragraphs, tables, images, table of contents, etc., and constructing them into WordDocEntity structured document objects, which contain preprocessed fields such as full text strings, unindexed text strings, and table text strings.
[0102] Example 4 (NER Strategy Engine):
[0103] like Figure 3 As shown, the NER strategy engine in this application adopts a Master-Worker model. The MasterCustom strategy scheduler loads named entity definitions from a JSON configuration file. Each NameEntity contains one or more ExtractionStrategies, including configurations such as scopeType, extractPatternList, entityBoundaryList, refine, partition, and extractChapter. MasterCustom creates a Worker executor for each regular expression pattern of each strategy, selecting either a table scanning strategy or a regular expression matching strategy based on the scopeType. After execution, the Merger merges the extracted results by entity name. The NER engine supports synonym mapping, uniformly mapping synonyms to standard entity names.
[0104] Example 5 (Dynamic Loading of Audit Strategies and Resolution of Rule Conflicts):
[0105] like Figure 4 As shown, the dynamic loading and rule conflict resolution of this application's review strategy are implemented by the AuditStrategyFactory class. During system initialization, the review entity configuration is loaded from the JSON configuration file, and the following process is executed:
[0106] (I) Dependency Graph Construction and Circular Dependency Detection:
[0107] The system iterates through all audited entities, using the entity's name as a node and the dependencies in the combineKeys list as directed edges, constructing a logical dependency graph G(V,E). For example, if audited entity A (goods price audit) is configured with combineKeys as ["material name extraction", "tax-inclusive unit price extraction"], then directed edges A→material name extraction and A→tax-inclusive unit price extraction are constructed.
[0108] A depth-first search (DFS) algorithm is used to detect cycles in the dependency graph: an access status array is maintained (unvisited / accessed / visited), and DFS recursion is performed on each unvisited node. If a node with the status "accessed" is encountered during the recursion, a circular dependency is determined. For example, if audit item A depends on B, B depends on C, and C depends on A, a circular dependency A→B→C→A is detected. The system generates an alarm message and blocks the loading of all audit entities under this audit scheme.
[0109] (ii) Rule logic conflict detection:
[0110] For the audit answer and audit policy type configured in the audit entity, the system extracts the judgment conditions for each audit rule:
[0111] For numerical judgment rules (such as price verification and tax rate verification), extract numerical comparison operators and boundary values to construct numerical judgment intervals. For example, rule A requires "unit price including tax > 100 yuan", and rule B requires "unit price including tax < 80 yuan". The system detects that the intersection of the two intervals (100, +∞) and (-∞, 80) is empty, determines that there is a numerical interval conflict, and generates an alarm.
[0112] For existence / non-existence check rules, if two audit entities have policies of check_exist and check_not_exist respectively, and their targetEntity is the same, then it is determined that there is a conflict between mutually exclusive rules.
[0113] (III) Rule Priority and Conflict Resolution:
[0114] For non-fatal conflicts, the system automatically resolves them according to preset rule priorities. The priority order is (from highest to lowest): industry-mandatory regulatory rules > enterprise internal control rules > general rules. If the priorities of two conflicting rules are comparable, the higher-priority rule is retained, and the lower-priority rule is automatically marked as invalid and a resolution log is recorded. This resolution log will be included in the interpretability information of the final audit report.
[0115] After conflict detection and circular dependency detection pass, the audit strategy factory builds an audit entity mapping table and caches the corresponding dependency graph structure for each audit scheme.
[0116] Example 6 (Pluggable Audit Kernel Architecture):
[0117] like Figure 2 As shown, this application's KernelFactoryCustom kernel factory maintains a kernel registry of type ConcurrentHashMap, and obtains the corresponding audit kernel instance based on the policy type using the obtainKernel method. The specific implementations of the nine audit kernel types are as follows:
[0118] (a) Amount case verification kernel: Extract Arabic numeral amount and Chinese capital amount through regular expression, call parseChineseAmount method to convert Chinese capital amount to double value, and compare within the tolerance range of epsilon=0.001.
[0119] (b) Enterprise Information Verification Core: Parse the enterprise's structured information from the first chapter of the contract and compare it field by field with the pre-stored enterprise information.
[0120] (c) Enterprise blacklist screening kernel: Match enterprise names with blacklists.
[0121] (d) Goods price audit core: Analyze the goods details table and compare the contract price with the guidance price.
[0122] (e) Quality Clause Review Core: Employs multi-strategy fuzzy matching and dynamic semantic perception algorithms.
[0123] (f) The existence check kernel, the non-existence check kernel, the chapter content inclusion check kernel, and the chapter content exclusion check kernel shall be audited according to their respective policies.
[0124] Example 7 (Multi-strategy fuzzy matching and dynamic semantic awareness algorithm):
[0125] like Figure 5 As shown, the multi-strategy fuzzy matching and dynamic semantic awareness algorithm used in this application adopts a two-level matching structure:
[0126] Level 1: Character-level fuzzy matching layer
[0127] (1) Text preprocessing: Normalize Chinese punctuation, merge consecutive whitespace, and convert the input text to lowercase.
[0128] (2) Quick judgment: If the two preprocessed texts are completely identical or the latter contains the former, return a successful match directly;
[0129] (3) Multi-strategy comprehensive scoring: The highest value S among the three strategies of sentence splitting and matching, sliding window matching, and LCS coverage is selected. char ;
[0130] (4) Hierarchical decision-making: If S char >0.92 indicates a successful match; if S char If the value is less than 0.60, the match fails directly; otherwise, proceed to the second-level semantic verification layer.
[0131] Level 2: Semantic Validation Layer
[0132] (1) Logical polarity perception: The target text and source text are segmented and dependency parsed respectively to extract the core verbs and their logical polarities. For example, in "the wall thickness of the pole is not less than 3.2mm", the core verb is "less than", the negative word "not" points to "less than" through the negation, and the polarity is marked as "negation", which is semantically equivalent to "≥3.2mm". However, "the wall thickness of the pole must be greater than 3.2mm" has no negative word, and the polarity is "affirmative".
[0133] (2) Polarity comparison: If the target polarity is inconsistent with the source polarity, it is directly judged as semantic mismatch, effectively avoiding misjudgment of "greater than" and "not greater than".
[0134] (3) Semantic similarity calculation (triggered when polarity is consistent): The semantic vector is encoded using the Legal-Tiny-BERT model (approximately 22M parameters), and the cosine similarity S is calculated. semantic Model instances are dynamically loaded and reused through an object pool.
[0135] (4) Comprehensive judgment: S final = 0.4×S char +0.6×S semantic If the value is ≥0.75, it is considered a successful semantic match.
[0136] During algorithm execution, the results (S) at each level char Whether the semantic layer is triggered, polarity comparison results, S semantic S final All of these are recorded as algorithm source tags for use in generating subsequent interpretability reports.
[0137] Example 8 (Combination Key Dependency Audit Mechanism):
[0138] like Figure 6 As shown, in the composite key dependency audit mechanism, the `doWork` method of `AuditMainCustom` first obtains the dependency graph structure corresponding to the audit scheme, determines the processing order by topological sorting, and then traverses the composite key list, recursively processing dependencies. If the composite key starts with the prefix "+TABHead+:", it is marked as a header key item. All sub-audit results are summarized; if the header key item fails, the entire audit fails and a preliminary suggestion is returned; otherwise, all failed items are summarized to generate a joint audit opinion.
[0139] After each audit item is completed, the system records three types of data source tags associated with it:
[0140] Rule source tags: Record the JSON configuration file path, audit entity name, policy type, rule priority level, and dependency chain path;
[0141] Entity source tags: Record the original document location (paragraph number, table number, row number, column number) and extraction strategy information corresponding to the NER extraction results;
[0142] Algorithm source tags: Record quality terms under review S char Whether the semantic layer is triggered, polarity comparison results, S semantic S final wait.
[0143] Example 9 (Data lineage tracing and counterfactual interpretation generation):
[0144] like Figure 7 As shown, the specific process for summarizing the review results and generating the interpretability report for this application is as follows:
[0145] (a) Organization of data lineage tracing information:
[0146] After the audit engine completes its execution, the system collects the data source tags for all audit items and organizes them into lineage traceability information according to the audit item dimension. Business personnel can view the complete data source chain through the "View Source" entry in the audit report, for example:
[0147] "This audit item is executed in accordance with the 'Goods Price Audit' rule in the rule file 'audits / entity / gaozhimo_20250303 / price_check.json'";
[0148] “The NER entity ‘Tax-inclusive unit price’ was extracted from the 5th row and 3rd column of Table 2 on page 3 of the document, using the table_line_single extraction strategy”;
[0149] "Quality clause matching process: Character similarity 0.78 → trigger semantic verification layer → logical polarity consistent → semantic similarity 0.92 → comprehensive score 0.864 → match successful."
[0150] (ii) Generation of counterfactual information:
[0151] For items that fail the review, the system automatically generates counterfactual explanations:
[0152] (1) Existence check failed: "If the relevant content 'the wall thickness of the pole shall not be less than 3.2mm' is added to the 'Quality Standards' section of the second paragraph on page 3 of the contract, this item will be approved."
[0153] (2) Price exceeding the standard will not pass: "If the 'tax-inclusive unit price' is changed from 320 yuan / ton to no more than 300 yuan / ton, this item will pass."
[0154] (3) Quality clause fuzzy matching fails: "If the contract clause 'the wall thickness of the pole reaches 3.2mm or more' is modified to have a similarity of 0.75 or more with the audit standard 'the wall thickness of the pole is not less than 3.2mm' (current similarity is 0.68), this item will pass."
[0155] (4) Composite key dependency review failed: Summarize all counterfactual suggestions for dependency sub-items and present them in the order of dependency chain.
[0156] (iii) Output of the interpretability audit report:
[0157] The final audit report includes: an overview of the audit conclusions (statistics of pass / fail), detailed audit items (including conclusions, comments, location markers, modification suggestions, and source information), and a rule loading and conflict resolution log (displaying a list of rule conflicts and their resolution results).
[0158] Example 10 (Object Pooling Engine Management):
[0159] The object pooling management module is implemented based on Apache Commons Pool2, managing AuditMainCustom and AppMainCustom instances respectively. Instances are borrowed from the object pool during audit task execution and returned in the finally block upon completion. Audit tasks are executed asynchronously via ThreadPoolTaskExecutor with a set timeout.
[0160] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A method for intelligent contract review, characterized in that, Includes the following steps: S1. Contract document acquisition and preprocessing: Acquire contract documents to be reviewed, support automatic recognition and conversion of PDF and Word formats, and convert non-docx format documents to docx format. S2. Structured Parsing of Contract Text: The docx document is structured and parsed using a custom Word document parser to extract document elements, including paragraphs, tables, images, and table of contents, and to construct a structured document object. S3. Named Entity Recognition and Extraction: The NER strategy engine adopts the Master-Worker mode and performs named entity recognition and extraction on structured document objects according to the extraction strategy configured in JSON. The extraction strategy includes multiple scopeTypes such as paragraph extraction, single row extraction of table, multi-row extraction of table, and full table extraction. S4. Dynamic loading of review strategies and resolution of rule conflicts: Review entities are loaded from JSON configuration files through the review strategy factory, a logical dependency graph of review entities is constructed, and circular dependency detection and rule logic conflict detection are performed. After the detection is passed, the review entities are classified and managed according to contract type and a mapping table is constructed. S5. Pluggable Audit Kernel Execution: The kernel factory dynamically obtains the corresponding audit kernel based on the strategy type of the audit entity, and performs multi-dimensional intelligent auditing. The audit kernel includes a amount case verification kernel, an enterprise information verification kernel, an enterprise blacklist screening kernel, a goods price audit kernel, a quality clause audit kernel, an existence check kernel, a non-existence check kernel, a chapter content inclusion check kernel, and a chapter content exclusion check kernel. The quality clause audit kernel adopts a multi-strategy fuzzy matching and dynamic semantic perception algorithm. S6. Composite Key Dependency Review Processing: For review entities configured with composite keys, the dependent sub-review items are recursively processed based on the dependency graph constructed in step S4, and the sub-review results are summarized to generate a joint review judgment; each review result is associated with the record data source tag; S7. Summary of Audit Results and Generation of Explainability Report: Summarize the execution results of all audit kernels and generate a structured audit report; For items that fail the review, counterfactual explanations are automatically generated. These counterfactual explanations explain how the review conclusion would change if specific modifications were made to the contract terms.
2. The intelligent contract review method according to claim 1, characterized in that, The specific method for detecting circular dependencies in step S4 is as follows: Iterate through all audited entities, using the unique identifier of each audited entity as a node and the dependencies in the composite key list as directed edges, to construct a logical dependency graph of the audited entities; The logical dependency graph is traversed using a depth-first search algorithm. The current recursive call stack path is maintained. If a node already in the current recursive stack is encountered during the search, a circular dependency is determined, the complete path of the circular dependency is recorded, a circular dependency alarm is generated, and loading is blocked.
3. The intelligent contract review method according to claim 1, characterized in that, The specific method for detecting rule logic conflicts in step S4 is as follows: Extract the judgment condition range for each review rule, wherein the judgment condition range includes a numerical range, an existence condition, and an enumerated set of values; For multiple audit items of the same target entity, the numerical judgment intervals are compared using the interval intersection algorithm. If the interval intersection is empty, it is determined that the numerical intervals conflict. If the inclusion review and exclusion review of the same contract clause both target the same entity name and have the same scope of review, they are deemed to be in conflict of mutually exclusive rules. Summarize all detected rule conflicts and generate a conflict list.
4. The intelligent contract review method according to claim 3, characterized in that, The dynamic loading of the audit strategy and the resolution of rule conflicts also include a rule conflict resolution step: for detected rule conflicts, they are automatically resolved according to the preset rule priority, which is from high to low as: industry mandatory normative rules > enterprise internal control rules > general rules; or the priority is automatically determined according to the sorting field of the audit entity; the resolved rules are used as effective rules in subsequent audit execution, and the resolved rules are recorded in the resolution log.
5. The intelligent contract review method according to claim 1, characterized in that, The multi-strategy fuzzy matching and dynamic semantic awareness algorithm described in step S5 includes a character-level fuzzy matching layer and a semantic verification layer: The character-level fuzzy matching layer includes: text preprocessing, fast judgment, sentence segmentation and matching, sliding window matching, and LCS coverage calculation. The highest value of these steps is taken as the character similarity S. char If S char If the value is higher than the first threshold, a match is directly determined to be successful. char If the value is below the second threshold, the matching is directly determined to be a failure; otherwise, the semantic verification layer is entered. The semantic verification layer includes: performing dependency parsing on the target text and source text, extracting logical polarity and comparing polarities; if the polarities are inconsistent, it is directly determined as a semantic mismatch; if the polarities are consistent, a lightweight pre-trained language model is used to calculate the semantic similarity S. semantic S in summary char and S semantic Calculate the final score and compare it with the semantic threshold to determine whether there is a match.
6. The intelligent contract review method according to claim 5, characterized in that, The method for extracting logical polarity is as follows: perform word segmentation and dependency parsing on the input text, extract the core verb of the sentence, identify the negative word that has a negative dependency relationship with the core verb, and mark the logical polarity of the sentence as negative if a negative word exists, otherwise mark it as positive.
7. The intelligent contract review method according to claim 1, characterized in that, The data source tags include: The rule source tag records the path to the JSON configuration file that triggered the audit item, the name of the audit entity, the strategy type, the rule priority level, and the dependency chain path. The entity source tag records the location of the original document and extraction strategy information corresponding to the NER entity extraction results on which this review item depends; The algorithm source tags record character-level similarity, semantic verification layer trigger status, logical polarity comparison results, semantic similarity, and comprehensive semantic score during the quality clause review process.
8. The intelligent contract review method according to claim 1, characterized in that, The method for generating counterfactual explanation information in step S7 is as follows: For audit items that fail the existence check, the generated counterfactual explanation is: "If the '[entity name]' related content is added to the contract [location], this item will pass." For audit items that fail the numerical judgment, the generated counterfactual explanation is: "If [field name] is changed from [current value] to [threshold], the item will pass"; where the threshold is calculated based on the judgment boundary value in the audit rules. For audit items that fail the fuzzy matching of quality clauses, the generated counterfactual explanation is: "If the contract clause [original text fragment] is modified to achieve a similarity of [required threshold] with the audit standard '[standard clause]', the item will pass"; wherein the required threshold is calculated based on the difference between the current similarity and the judgment threshold.
9. A contract intelligent review system, characterized in that, The system includes a software system and a cloud server, wherein the cloud server is connected to the software system, and the software system is used to perform the method as described in any one of claims 1-8; the software system includes: The document acquisition and preprocessing module is used to acquire contract documents to be reviewed and perform format conversion. The document structuring parsing module is used to extract document elements and construct structured document objects using a custom Word document parser; The NER strategy engine module adopts the Master-Worker mode and performs named entity recognition and extraction on structured documents according to the extraction strategy configured in JSON. The module for dynamically loading and resolving rule conflicts in the review strategy is used to load review entities from JSON configuration files, build a dependency graph, and perform circular dependency detection and rule logic conflict detection. A pluggable audit kernel execution module dynamically obtains the audit kernel based on the policy type through the kernel factory and performs multi-dimensional intelligent auditing. The composite key dependency audit module is used to process the logical dependencies between audit entities based on the dependency graph. The audit results summary and interpretability report generation module is used to summarize audit results and generate a structured audit report that includes data lineage information and counterfactual explanations. The object pooling management module is used to manage the reuse and recycling of audit engine and NER engine instances.
10. A contract intelligent review system according to claim 9, characterized in that, The cloud server adopts the Spring Cloud microservice architecture, including gateway service, system service, business service, scheduled task service, file service and public module. The service registry center adopts Nacos, which supports horizontal scaling and load balancing of services. The public module includes three core AI sub-modules: audit engine, NER engine and text processing tool.