An explainable building contract risk review method and system with a mechanism layer knowledge graph

Abstract

The application provides an interpretable building contract risk review method and system with a mechanism layer knowledge graph, which comprises: receiving registered contract basis and a contract to be reviewed, and obtaining a standardized clause unit set; obtaining an executable mechanism library based on a large language model (LLM); inputting and analyzing and normalizing values in the contract to be reviewed according to the mechanism, compiling and executing mechanism formulas, obtaining mechanism output results and risk node aggregation probabilities; constructing a structured evidence package and driving a knowledge graph to generate a risk level, a reason chain and a supplementary suggestion; assembling the clause unit, the mechanism node and the risk node into a knowledge graph export to generate an explanation path score for review and LLM reference. The application introduces a mechanism layer in the knowledge graph clause layer and the risk layer, explicitly represents the causal chain between the clause parameters and the risk trigger logic, and at the same time, the mechanism node is managed with formulas and versioned metadata, so that the model does not need to be retrained or the rule library does not need to be modified on a large scale when market parameters change.

Description

Technical Field

[0001] This invention belongs to the interdisciplinary field of computer science and engineering management, and in particular relates to an interpretable construction contract risk review method and system with a mechanism-layer knowledge graph. Background Technology

[0002] Traditional knowledge graphs typically distinguish between a data layer (entities and attributes) and a schema layer (ontology and relations / rules), and are widely used in general search and semantic retrieval. However, in the context of construction contract review, the current static mapping of "clause → risk category" is insufficient to explain how clause parameters trigger risks through the mediation process, leading to insufficient causal explanation. Furthermore, changes in market parameters require large-scale modifications to external rules or model retraining, resulting in high maintenance costs and difficulty in reflecting recent disputes and changes in contract regulations, as well as the timely retrieval and reproduction of the decision-making chain. While the "clause layer—risk layer—outcome layer" causal chain expression that has emerged in recent years provides a more complete logic from clause to risk to outcome, the "risk generation mechanism" is usually implicit in the rule base or external model, lacking a formulaic, executable, and auditable first-class object expression. Therefore, it is necessary to introduce a mechanism layer between clauses and risks as a clear, computable, and versioned mediation expression. Summary of the Invention

[0003] To address the shortcomings of existing technologies in the field of construction contract risk review based on large language models, such as the lack of causal explanation capabilities and the difficulty in continuously updating risk patterns, this invention provides an interpretable construction contract risk review method and system with a mechanism-layered knowledge graph. By introducing a mechanism layer between the clause layer and the risk layer in the knowledge graph, the implicit links previously hidden between the two layers are transformed into explicit nodes. Compared with the existing static mapping mode that only relies on "clause → risk category", this invention, through the setting of the mechanism layer, can explicitly represent the causal chain between clause parameters and risk triggering logic, solving the problem of insufficient causal explanation. At the same time, the mechanism nodes are managed with formulas and versioned metadata. When market parameters change, there is no need to retrain the entire model or make large-scale modifications to the rule base. Only the threshold needs to be updated or the mechanism formula needs to be replaced to quickly achieve recalculation, reducing maintenance costs and supporting the retrospective and reproduction of historical versions. In addition, the mechanism layer decouples the risk generation mechanism from implicit black-box rules or external models, transforming it into a formulaic, executable, and auditable first-class object expression, meeting the needs of compliance auditing and tracking.

[0004] The present invention achieves the above-mentioned technical objectives through the following technical means.

[0005] An interpretable construction contract risk review method with a mechanism-layer knowledge graph includes the following process:

[0006] Step 1: Receive and register two types of PDF documents: the contract basis and the contract to be reviewed. Perform text extraction, clause segmentation, and terminology and unit standardization processing to obtain a standardized clause unit set. The standardized clause unit set includes the original text. Normalized text (text_norm) and clause unit location information;

[0007] Step 2: Based on the standardized set of clause units, use the Large Language Model (LLM) from the contract basis document to express the logic of how the clause unit triggers a certain type of risk in a formulaic form, forming mechanism nodes, and perform standardized verification and deduplication to finally obtain an executable mechanism library.

[0008] Step 3: Based on the executable mechanism library, parse and normalize the values ​​of the mechanism input in the contract to be reviewed, compile and execute the three types of mechanism formulas including Logistic family, Noisy-OR class, and piecewise linear class, and obtain the mechanism output results and risk node aggregation probability;

[0009] Step 4: Construct a structured evidence package containing key contract information, clause reference information, mechanism information, risk node aggregation probability and Top-K interpretation path, and drive the knowledge graph to generate risk level, reasoning chain and supplementary evidence suggestions;

[0010] Step 5: Assemble the clause units, mechanism nodes, and risk nodes into a single knowledge graph, export it into two different standard format files, save it as a version snapshot, generate and maintain the interpretation path score for relevant personnel to review and for LLM reference.

[0011] Furthermore, the specific process of step 1 is as follows:

[0012] Step 1.1: Document registration and directory initialization;

[0013] The two types of PDF documents, namely the contract basis and the contract to be audited, are placed in the corresponding directories. A unique document identifier is generated for each document, and the file name, unique file code, and page number data are recorded. These are then written into a list file as the sole data source for subsequent processing and the starting point for audit trail.

[0014] Step 1.2: Text extraction and clause segmentation;

[0015] Extract text and formatting from scanned PDFs; parse paragraphs and headings from text-based PDFs; segment clauses into structured objects.

[0016]

[0017] in, Indicates the first Each clause unit; Indicates a unique identifier for the document; This indicates a unique number representing a clause within a document; This represents the original text string of the terms; Indicates the page range of the terms in the PDF; Used to pinpoint the precise location of clause units within the original text; while preserving the original text. Two representations are provided: the normalized text and the text_norm representation.

[0018] Step 1.3: Terminology and Unit Standardization: Establish a domain terminology glossary to unify synonymous expressions.

[0019] Furthermore, the specific process of step 2 is as follows:

[0020] Step 2.1: Mechanism node structure setting;

[0021] The single mechanism node is defined using the unified lightweight data exchange format JSON. The mechanism node is represented as follows:

[0022]

[0023] in, Risk contribution to the mechanism's output; The input vector has dimensions of . ; The values ​​to be taken for each input field; The input vector is defined. The validation rules for each field, i.e., input guard conditions, ensure that the formula can only be executed after the input value is valid. ; For mechanism version;

[0024] Step 2.2: Structured extraction based on the terms;

[0025] The standardized text of the clauses in the contract basis catalog after normalization. Construct candidate functions containing family of functions The prompts for field constraints and target risk label sets explicitly specify the mechanism node structure, field requirements, and domain-specific language (DSL) syntax specifications, ensuring that the LLM outputs a structure that meets the requirements. The threshold value indicates when the input value exceeds or falls below a certain fixed threshold, triggering a risk. for function; For the Noisy-OR function; It is a piecewise linear function.

[0026] Furthermore, the specific process of step 3 is as follows:

[0027] Step 3.1: Clause value analysis and evidence binding;

[0028] For each contract in the pending contract catalog, a parsing clause unit is defined according to the mechanism node. Within the contract clause and its adjacent clause windows, regular expression matching and keyword matching are performed according to a pre-set pattern to determine whether the clause is "hit". If no pattern matching is found, a prompt word containing the target field definition, context clause text, and output format requirements is constructed to limit the LLM to extract or infer the value of the specified field only from the provided clause text, and a structured result containing the field value, source clause ID, and key original text fragments is returned. Furthermore, the unstandardized numerical or Boolean expressions parsed from the pending contract clauses are unified into standard units to form the mechanism instance input vector.

[0029]

[0030] in, For the first The input vector of each mechanism instance; For the first The first mechanism instance The values ​​of each input field, ; This represents the number of input fields for the mechanism.

[0031] Step 3.2: Compilation and calculation of the mechanism formula;

[0032] The mechanism instance input vector parsed from the contract under review is substituted into the mechanism node formula described by the DSL to evaluate the value; for different scenarios, three types of formulas are used to describe various mechanisms: Logistic family, Noisy-OR class, and piecewise linear class.

[0033] The Logistic family mechanism formula is applicable to scenarios with continuous variables, gradually changing risk, and output as a smooth curve probability function. Its evaluation formula is as follows:

[0034]

[0035] in, For the first Each mechanism outputs; For bias terms; For the first The weights of each input; For input transformation specified by DSL, For the Sigmoid function, For the first The first mechanism instance The values ​​of each input field;

[0036] The Noisy-OR mechanism formula is applicable to scenarios where multiple factors trigger risks in parallel, each factor alone can cause risk, and the trigger probabilities can be rolled up in parallel. Its evaluation formula is as follows:

[0037]

[0038] in, For the first Normalized values ​​of each potential triggering factor; For the first Triggering strength parameters for each potential triggering factor;

[0039] Piecewise linear mechanism formulas are applicable to scenarios where risk levels are presented in intervals, and the risk changes linearly with the input variable within these intervals. The evaluation formula is as follows:

[0040]

[0041] in, For indicator functions; For the first The criteria for determining each segment; This is the segment coefficient vector; The segment intercept; It is an inner product, and only takes effect when the condition in this section is met. Input values ​​for the mechanism.

[0042] Calculate input sensitivity and log it while evaluating:

[0043]

[0044] in, For mechanism output For input Local sensitivity;

[0045] Step 3.3: Multi-mechanism parallel aggregation for risk: using Noisy-OR aggregation:

[0046]

[0047] in, Risk Node The aggregation probability; The set of indexes for the mechanisms driving this risk node; For the first The weights of each mechanism involved in aggregation.

[0048] Furthermore, the specific process of step 4 is as follows:

[0049] Step 4.1: Constructing the evidence package;

[0050] The key contract information, clause reference information, mechanism information, risk node aggregation probability, and the Top-K interpretation path and sensitivity of "clause → mechanism → risk" are all packaged into evidence packages in both JSON and tabular formats.

[0051] Step 4.2: Generation of enhanced map results;

[0052] The evidence package encapsulated in step 4.1 is submitted to the LLM using a three-stage prompting approach, generating a risk level assessment, a chain of reasons, and supplementary evidence suggestions outside the knowledge graph. The three-stage prompting approach includes a system stage, a context stage, and an instruction stage.

[0053] System section: Defines contract risk review experts, task objectives, output format requirements, and adjudication basis and standards;

[0054] Contextual Section: Embed the contents of the structured evidence package in a clear, unambiguous text description or formatted data block format, providing LLM with all the quantitative results, interpretation paths, original references to key clauses, and details of mechanism calculations required for judgment;

[0055] Command segment: Explicitly specifies the content to be output by LLM.

[0056] Furthermore, the specific process of step 5 is as follows:

[0057] Step 5.1: Graph structure assembly and backup export;

[0058] By assembling clause units, mechanism nodes, and risk nodes into a single knowledge graph, the node set... , This represents the set of contract clause nodes, derived from the standardized clause units of step 1. This represents the set of mechanism nodes, derived from the executable mechanism library in step 2. The risk node set represents the structured risk quantification result from step 3, i.e., the risk node aggregation probability; edge set The edge attribute carries specific reference information pointing to the source data. The edge contains the clause ID that triggers the mechanism and the specific input field that is bound to the evidence anchor. The edge includes the weights and version information used by the risk aggregation mechanism; the assembled knowledge graph is exported and a timestamped snapshot package is output for offline archiving and multi-version retrieval;

[0059] Step 5.2: Explanation of path generation and scoring;

[0060] Paths within a knowledge graph Calculate and rank the contribution scores as follows:

[0061]

[0062] in, For path Contribution score; To trigger the clause node; For the first Each mechanism node; Risk nodes; For path The output of the mechanism; The weight of the mechanism in the corresponding risk aggregation;

[0063] After calculating the contribution score of the explanatory path, compare the mechanism output obtained in step 3 with the risk layer aggregation result and the risk level judgment generated in step 4 to check whether they corroborate each other; at the same time, check the consistency between the structured evidence package and the knowledge graph structure item by item; correct and record the problems found; after the verification is completed, export the updated knowledge graph file and generate a quality report; the quality report clearly states the mechanisms or thresholds that need to be adjusted and the reasons, and registers the new version in the executable mechanism library accordingly.

[0064] A system for implementing the aforementioned interpretable construction contract risk review method with a mechanism-layer knowledge graph includes:

[0065] Document standardization module: Used to receive and register contract basis documents and contract documents to be reviewed, and to perform text extraction, clause segmentation, terminology and unit standardization processing on the documents, and output a set of standardized clause units;

[0066] Mechanism library generation module: Based on the LLM self-contract basis document, the logic of how the clause unit triggers a certain type of risk is expressed in a formulaic form to form mechanism nodes. The nodes are then standardized and deduplicated according to a unified JSON+DSL to finally obtain an executable mechanism library.

[0067] Risk calculation module: Based on the executable mechanism library, it parses and normalizes the values ​​of the mechanism input in the contract under review, binds evidence, compiles and executes the mechanism formula, and outputs the mechanism output results and the aggregated probability of the risk nodes.

[0068] Evidence Package and Judgment Module: Construct a structured evidence package containing key contract information, clause reference information, mechanism information, risk node aggregation probability and Top-K interpretation path, and drive the knowledge graph to generate risk level, reasoning chain and supplementary evidence suggestions;

[0069] The graph assembly and traceability module is used to assemble clause units, mechanism nodes, and risk nodes into a single knowledge graph, export it as a corresponding standard format file, save it as a version snapshot, and generate and maintain interpretation path scores for relevant personnel to review and for LLM reference.

[0070] The present invention has the following beneficial effects:

[0071] 1. This invention introduces a mechanism layer between the traditional "clause-risk" link, unifying clause evidence, mechanism calculation, and risk aggregation into the same graph, and describing them with a formulaic DSL and versioned metadata. This achieves a replayable link from clause value to risk outcome, providing causal explanations at the path and variable levels. Furthermore, when market parameters change, only the threshold needs to be updated or the mechanism formula version needs to be replaced to quickly complete recalculation and comparison, avoiding overall retraining or large-scale rule modification, significantly reducing maintenance costs, and supporting the traceability and reproduction of historical versions.

[0072] 2. This invention extracts the risk triggering logic from the black-box model and transforms it into an explicit expression of the mechanism node. The mechanism node embeds input guards, evidence pointers, and calculation logs, which can be directly executed and verified, ensuring that each risk judgment has a complete chain of evidence and calculation process, meeting the needs of compliance auditing and accountability tracing. At the same time, this integrated mechanism layer is compatible with various calculation kernels such as threshold, logistic, Noisy-OR, piecewise linear, and Bayesian / fuzzy, which can flexibly adapt to different contract scenarios and risk types, further improving the interpretability, auditability, and reproducibility of the review conclusions. Attached Figure Description

[0073] Figure 1 This is a flowchart of the interpretable construction contract risk review method with mechanism layer knowledge graph described in this invention. Detailed Implementation

[0074] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, but the scope of protection of the present invention is not limited thereto.

[0075] The interpretable construction contract risk review method with mechanism layer knowledge graph described in this invention is as follows: Figure 1 As shown, the relationships between the steps are as follows:

[0076] Step 1: Normalization of the original corpus and unitization of clauses;

[0077] Collect two types of PDF documents: the contract basis (containing contract requirements, customer requirements, funding requirements, etc.) and the contract to be reviewed. Complete text extraction, clause segmentation, and terminology / unit standardization to form reusable standard clause units. At the same time, register metadata such as file name, MD5 (unique file code), and page number into a unified list.

[0078] Step 1.1: Document registration and directory initialization;

[0079] Place the PDF document representing the contract in the contract basis directory (denoted as basis_dir), place the PDF document representing the contract to be reviewed in the contract to be reviewed directory (denoted as contracts_dir), and generate a unique document identifier for each document. It also registers metadata such as file name, file unique code, and page number, and writes them into a unified manifest file as the sole data source for subsequent processing and the starting point for audit trail.

[0080] Step 1.2: Text extraction and clause segmentation;

[0081] Extract text and formatting from scanned PDFs; parse paragraphs and headings from text-based PDFs; segment clauses into structured objects.

[0082]

[0083] in, Indicates the first Each clause unit; This represents a unique document identifier used for audit trails and cross-step association; A unique number representing a clause within a document, used to precisely locate that clause within the same document; This represents the original text string of the terms; Indicates the page range of the terms in the PDF; Used to mark the precise location information of the clause unit in the original text (such as the starting line number, keyword position, etc.), to serve the subsequent evidence binding and interpretability;

[0084] At the same time, the original text is retained. The two representations are the cleaned and normalized text_norm (e.g., the original text). The text is: "The employer shall pay an advance payment of not less than 10% within thirty (30) days."; text_norm is: "The employer shall pay an advance payment of not less than 0.10 within 30 days.". (The original text is retained.) The purpose is to use the contract-side value parsing in the subsequent step 3.1. The cleaned and normalized text_norm is retained for the candidate extraction based on the side mechanism in the subsequent step 2.

[0085] Step 1.3: Terminology and Unit Standards;

[0086] Establish a domain-specific terminology glossary to unify synonyms, standardize time as "day," and standardize proportions to... The normalization rule for the interval is as follows:

[0087]

[0088] in, This is the normalized proportion; The percentage is the value given in the original text (if it is a percentage, take the value before the percentage sign).

[0089] Step 2: Structured generation based on large language models (LLM);

[0090] Based on the contract document processed in step 1 using LLM, the logic of how the clause unit triggers a certain type of risk is represented in a formulaic and computable form to form a mechanism node. This node is then standardized using a unified JSON+DSL to obtain an executable mechanism library (containing input vectors, guard conditions, mechanism node formulas, and versions). This library is used for contract-side value retrieval, mechanism execution, and risk aggregation in subsequent step 3.

[0091] Step 2.1: Mechanism node structure setting;

[0092] The mechanism node is standardized using a unified lightweight data exchange format (JavaScript Object Notation, JSON). This means that the inputs, conditions, formulas, and other content of a mechanism node are represented in a standardized JSON format. The mechanism node is represented as follows:

[0093]

[0094] in, Risk contribution to the mechanism's output; The input vector has dimensions of . ; The values ​​to be taken for each input field; The input vector is defined. The validation rules for each field (such as range checks and type checks), i.e., input guard conditions, ensure that the input value is valid before the formula can be executed. ; Metadata for mechanism version and applicable jurisdiction.

[0095] Step 2.2: Structured extraction based on the terms;

[0096] The standardized text of the clauses in the contract basis catalog after normalization. Construct candidate functions containing family of functions The prompt words for the set of field / unit constraints and target risk labels should explicitly specify the mechanism node structure, field requirements and Domain-Specific Language (DSL) syntax specifications in the prompt words, and require the LLM to strictly follow the structure output;

[0097] in, The threshold value indicates when the input value exceeds or falls below a certain fixed threshold, triggering a risk. for The function represents a smooth increase in risk as the input value gradually increases; The Noisy-OR function indicates that when multiple independent risk factors are connected in parallel, the overall risk will increase significantly if any one of the factors is triggered. For piecewise linear functions, it means that the input interval is divided into several segments, and different linear formulas are used to calculate the risk in different intervals.

[0098] Step 3: Contractual value extraction, mechanism execution, and risk aggregation;

[0099] For each contract awaiting review, the clause units are parsed and normalized according to the mechanism node definition; the mechanism formula is compiled and executed to obtain the mechanism output. Then, the aggregation probability of risk nodes is aggregated using the Noisy-OR aggregation function. Following the chain of "term value determination → mechanism execution → risk aggregation", the formula is run directly on the knowledge graph to calculate the probability until a quantitative result is obtained at the risk layer. This result is used for the construction of the evidence package in step 4 and serves as the quantitative basis for the final judgment of LLM.

[0100] Step 3.1: Clause value analysis and evidence binding;

[0101] For each contract in the pending contract catalog, a parsing clause unit is defined according to the mechanism node. Within the contract clause and its adjacent clause windows, regular expression matching and keyword matching are performed according to a pre-defined pattern to determine if the clause is "hit". If no match is found through pattern matching, a hint is constructed containing the target field definition, the context clause text (text or text_norm), and strict output format requirements ({"value": , "clause_id": , "quote":}). This restricts the LLM to extract or infer the value of the specified field only from the provided clause text, and returns a structured result containing the field value (value), the source clause ID (clause_id), and the key original text fragment (quote). The obtained raw values ​​(referring to unstandardized numerical or Boolean expressions parsed from the pending contract clauses, such as "30 days", "10%", "yes / no") are standardized into standard units (time → day, percentage → ). Boolean: Yes / Yes / Include / Use → 1, No / No / Not Applicable → 0), Formation Mechanism Instance Input Vector:

[0102]

[0103] in, For the first The input vector of each mechanism instance; For the first The first mechanism instance The values ​​of each input field, ; This represents the number of input fields for this mechanism.

[0104] Step 3.2: Compilation and calculation of the mechanism formula;

[0105] The mechanism node formulas described by the DSL are compiled into a secure, executable intermediate representation and evaluated. This involves substituting the mechanism instance input vector parsed from the contract under review into the mechanism node formulas described by the DSL for evaluation. In this invention, three types of formulas—Logistic family, Noisy-OR class, and piecewise linear class—are used to describe various mechanisms for different scenarios.

[0106] The Logistic family of mechanisms is suitable for scenarios involving continuous variables, where risk changes gradually with value, and the output is a smooth probability function curve (e.g., payment delay risk, where the risk is low initially, increases rapidly with the number of days, and approaches saturation after a certain number of days). Its evaluation formula is as follows:

[0107]

[0108] in, For the first Each mechanism outputs; For bias terms; For the first The weights of each input; Transform the input specified by the DSL (e.g., threshold bias, normalization, etc.); For the Sigmoid function, For the first The first mechanism instance The values ​​of each input field;

[0109] Noisy-OR mechanisms are suitable for scenarios where multiple factors trigger in parallel, each factor alone can lead to risk, and the trigger probabilities can be rolled up in parallel (e.g., contractor performance risk, where any one of the three factors "too short a construction period," "insufficient advance payment," or "unclear design conditions" may trigger risk; the trigger probabilities of different factors are aggregated into an overall risk through Noisy-OR, and as the number and intensity of factors increase, the risk rises but has an upper limit approaching 1). The calculation formula is as follows:

[0110]

[0111] in, For the first The normalized values ​​of a potential triggering factor (which can be obtained from several input transformations / indicators); For the first The trigger strength parameter of each potential triggering factor; the product of all triggering factors. The above calculation multiplies the contributions of all potential triggering factors one by one to obtain the overall probability of no triggering, and then the overall risk triggering probability is derived from this. This indicates the scope of the formula.

[0112] Piecewise linear mechanisms are suitable for scenarios where different risk levels are presented in intervals, and the risk changes linearly with the input variable within different intervals (e.g., default penalty ratio risk: when the ratio is < 5%, the risk increases linearly as the ratio decreases; the risk is low and stable in the 5%–20% interval; and after exceeding 20%, the risk increases linearly with the ratio again. This "low-stable-high" interval change can be clearly expressed using piecewise functions). The evaluation formula is as follows:

[0113]

[0114] in, For indicator functions; For the first The criteria for determining each segment; This is the segment coefficient vector; The segment intercept; It is an inner product and only takes effect when the conditions in this section are met.

[0115] Calculate input sensitivity and log it while evaluating:

[0116]

[0117] in, For mechanism output For input The local sensitivity (partial derivative) is used for explanation and counterfactual evaluation.

[0118] Step 3.3: Multiple mechanisms are aggregated in parallel to form risk (the final node of the knowledge graph reasoning path—the risk node, where the calculation results of all mechanisms are aggregated to form the risk probability). (and used as input for subsequent decisions).

[0119] Noisy-OR polymerization is used in this invention:

[0120]

[0121] in, Risk Node The probability / intensity of aggregation; A set of indexes for the mechanisms driving this risk; For the first The weights of each mechanism involved in aggregation.

[0122] Step 4: Construction of structured evidence packages and determination of LLM results outside the knowledge graph;

[0123] The key contract information, clause reference information, mechanism information, risk node aggregation probability, and Top-K interpretation path are encapsulated into a structured evidence package, which is submitted to the LLM to complete the final result judgment and chain reason generation outside the knowledge graph, and output uncertainty and supplementary evidence suggestions.

[0124] Step 4.1: Constructing the evidence package;

[0125] Include key contract information (including file name, unique file code, number of pages, contract type, etc.) and clause citation information. Mechanism Information Risk node aggregation probability The Top-K interpretation path and sensitivity of "Terms → Mechanisms → Risks" are encapsulated in evidence packages in both JSON and tabular formats. This ensures that all fields (especially input values, output values, clause references, and version numbers) can be accurately located to their source (such as specific mechanism instances, clause units, and versions). It also ensures data consistency within the evidence package and between the evidence package and the knowledge graph, serving traceability and auditing.

[0126] Among them, the Top-K interpretation path of "clause → mechanism → risk" refers to the top K representative paths selected in the knowledge graph from the clause node through the mechanism node to the risk node, sorted by the contribution of the mechanism, and used to show the main judgment basis to the LLM in the evidence package; The input values ​​for the representation mechanism are obtained by parsing or normalizing the contract terms; The output value represents the intermediate risk quantification result calculated by the formula; family represents the function family category to which the mechanism belongs, including threshold, logistic, noisy-or, and piecewise-linear; dsl represents the DSL expression of the mechanism formula, i.e., the executable computational logic description; version represents the version number of the mechanism node, used to distinguish different batches or updated mechanism definitions; guard represents the input guard condition, used to verify whether the input value is valid. This represents the formula for the compilation and calculation mechanism in step 3.2;

[0127] Step 4.2: Generation of enhanced map results;

[0128] The evidence package encapsulated in step 4.1 is submitted to the LLM using a three-stage prompt (system stage constrains the genre and adjudication standards, situation stage injects evidence package, and instruction stage clarifies the output result label / chain reason / suggestion for supplementary evidence). The final result judgment text and traceable reasons are generated outside the knowledge graph, namely risk level judgment + reason chain + suggestion for supplementary evidence.

[0129] System Section: Defines the LLM role as a contract risk review expert, task objectives (generating adjudication results, reasoning chains, and recommendations), output format requirements (JSON), and adjudication basis and standards (which contractual bases to cite and risk thresholds).

[0130] Contextual Section: Embeds the contents of the structured evidence package in a clear, unambiguous text description or formatted data block (such as key-value pairs wrapped in XML / JSON tags, Markdown tables), providing all the quantification results required for LLM to make a judgment. Explanation path (Top-K) Key clauses quoted verbatim and mechanism calculation details (DSL, version, guard, sensitivity) (where DSL represents the domain-specific language expression of the mechanism formula, used to accurately describe the calculation logic; version represents the version number of the mechanism, used to distinguish and trace the update of the mechanism definition at different points in time; sensitivity represents sensitivity information, used to describe the degree of influence of the mechanism output on the input variables, explaining "which input contributes the most to the risk outcome").

[0131] Instruction Section: Clearly specify the specific content required for the LLM output, such as: 1) Final risk level or conclusion label ('High Risk', 'Needs Attention', 'Low Risk', 'No Risk'); 2) Chain-of-Reasoning, clearly explaining the logical chain from key clause evidence -> mechanism calculation process / result -> risk quantification value -> final conclusion; 3) Uncertainty assessment and supplementary evidence recommendations, clearly pointing out missing, conflicting, or low-confidence information in the evidence package, and proposing specific contract clauses or external information that need further verification.

[0132] Step 5: Graph assembly, path interpretation, and quality regression;

[0133] The assembled terms-mechanisms-risk knowledge graph is exported as JSON and GraphML files in both standard formats and saved as a version snapshot. An interpretation path score is generated and maintained for review by relevant personnel and reference by the LLM.

[0134] Step 5.1: Graph structure assembly and backup export;

[0135] The clause units, mechanism nodes, and risk nodes are assembled into a single graph, node set. , This represents the set of contract clause nodes, derived from the standardized clause units of step 1. This represents the set of mechanism nodes, derived from the executable mechanism library in step 2. This represents the set of risk nodes, derived from the structured risk quantification results in step 3, and the edge set. The edge attribute carries specific reference information pointing to the source data, such as... The edge contains the clause ID that triggered the mechanism and the specific input field bound to the evidence anchors. The edge includes this mechanism in aggregation risk Weights used at time Includes version information; exports KG.json as the main archive, and outputs KG.graphml and a timestamped snapshot package for offline archiving and multi-version retrieval.

[0136] Step 5.2: Explanation of path generation and scoring;

[0137] Paths within a knowledge graph Calculate and rank contribution scores, defined as follows:

[0138]

[0139] in, For path Contribution score; To trigger the clause node; For the first Each mechanism node; Risk nodes; For path The output of the mechanism; The weight of the mechanism in the corresponding risk aggregation.

[0140] After calculating the contribution score of the explanatory path, a small-scale regression and consistency check are conducted: the mechanism output obtained in step 3 is compared with the risk layer aggregation result and the risk level judgment generated in step 4 to check whether they corroborate each other; at the same time, the consistency between the structured evidence package and the knowledge graph structure is checked item by item, including clause citations (clause_id, quote), mechanism input / output and version, formula expression (dsl), input guard, sensitivity, Top-K explanatory path, and whether the evidence anchors and weights in the edge attributes are consistent with the calculation log; any problems found are corrected and recorded accordingly. After the check is completed, the updated KG.json is exported as the main archive, and KG.graphml and a timestamped snapshot package are output to generate a quality report; the quality report clearly states the mechanisms or thresholds that need to be adjusted and the reasons, and the new version is registered in the mechanism library accordingly (the old version is retained for multi-version retrieval and human review / LLM citation). Through the above small-scale regression and consistency check, the final "traceable multi-version KG and quality report" forms a closed-loop output, which is used to support subsequent mechanism or threshold version updates and ensure that historical judgments can be reproduced by snapshots and evidence packages.

[0141] This invention also provides a system for implementing the above-mentioned interpretable construction contract risk review method with a mechanism-layer knowledge graph, comprising:

[0142] Document standardization module: This module receives and registers contract basis documents and contract documents to be reviewed, and performs text extraction, clause segmentation, terminology and unit standardization processing on the documents, outputting a set of standardized clause units.

[0143] Mechanism library generation module: Based on the LLM self-contract basis document, the logic of how the clause unit triggers a certain type of risk is expressed in a formulaic form to form mechanism nodes. The nodes are then standardized and deduplicated according to a unified JSON+DSL to finally obtain an executable mechanism library.

[0144] Risk Calculation Module: Based on the executable mechanism library, it parses and normalizes the values ​​of the mechanism input in the contract under review, binds evidence, compiles and executes the mechanism formula (including three mechanism formulas: Logistic family, Noisy-OR class, and piecewise linear class), and outputs the mechanism output results and the aggregated probability of risk nodes.

[0145] Evidence Package and Judgment Module: Construct a structured evidence package containing key contract information, clause reference information, mechanism information, risk node aggregation probability and Top-K interpretation path, and drive the knowledge graph to generate risk level, reasoning chain and supplementary evidence suggestions.

[0146] The Graph Assembly and Traceability Module is used to assemble clause units, mechanism nodes, and risk nodes into a single knowledge graph, export them as standard JSON and GraphML files, save them as version snapshots, and generate and maintain interpretation path scores for review by relevant personnel and LLM reference.

[0147] The embodiments described above are preferred embodiments of the present invention, but the present invention is not limited to the above embodiments. Any obvious improvements, substitutions or modifications that can be made by those skilled in the art without departing from the essence of the present invention shall fall within the protection scope of the present invention.

Claims

1. A method for interpretable construction contract risk review with a mechanism-layer knowledge graph, characterized in that, The process includes the following: Step 1: Receive and register two types of PDF documents: the contract basis and the contract to be reviewed. Then, extract the text, segment the clauses, and process the terminology and unit specifications to obtain a standardized clause unit set. The standardized clause unit set includes the original text text, the normalized text text_norm, and the clause unit location information. Step 2: Based on the standardized set of clause units, use the Large Language Model (LLM) from the contract basis document to express the logic of how the clause unit triggers a certain type of risk in a formulaic form, forming mechanism nodes, and perform standardized verification and deduplication to finally obtain an executable mechanism library. Step 3: Based on the executable mechanism library, parse and normalize the values ​​of the contract under review according to the mechanism input, and execute the three types of mechanism formulas, including Logistic family, Noisy-OR class, and piecewise linear class, to obtain the mechanism output results and the aggregation probability of risk nodes; Step 4: Construct a structured evidence package containing key contract information, clause reference information, mechanism information, risk node aggregation probability and Top-K interpretation path, and drive the knowledge graph to generate risk level, reasoning chain and supplementary evidence suggestions; Step 5: Assemble the clause units, mechanism nodes, and risk nodes into a single knowledge graph, export it into two different standard format files, save it as a version snapshot, generate and maintain the interpretation path score for relevant personnel to review and for LLM reference; The specific process of step 1 is as follows: Step 1.1: Document registration and directory initialization; The two types of PDF documents, namely the contract basis and the contract to be audited, are placed in the corresponding directories. A unique document identifier is generated for each document, and the file name, unique file code, and page number data are recorded. These are then written into a list file as the sole data source for subsequent processing and the starting point for audit trail. Step 1.2: Text extraction and clause segmentation; Extract text and formatting from scanned PDFs; parse paragraphs and headings from text-based PDFs; segment clauses into structured objects. C j ={doc_id,clause_id,text,page_span,anchors} Among them, C j This indicates the j-th clause unit; doc_id represents the document's unique identifier; clause_id represents the unique number of the clause within the document; text represents the original text string of the clause; page_span represents the page number range of the clause in the PDF; anchors are used to mark the precise location information of the clause unit in the original text; it also retains two representations: the original text text and the normalized text text_norm. Step 1.3: Terminology and Unit Standardization: Establish a domain terminology glossary to unify synonymous expressions; The specific process of step 2 is as follows: Step 2.1: Mechanism node structure setting; The single mechanism node is defined using the unified lightweight data exchange format JSON. The mechanism node is represented as follows: y=f(x;guard,version),y∈[0,1],x=[x1,…,x d ] Where y represents the risk contribution of the mechanism output; x is the input vector with dimension d; x1,…,x d The values ​​for each input field are defined; guard defines the validity rules for each field in the input vector x, i.e., the input guard conditions, ensuring that the input values ​​are valid before the formula f can be executed; version is the mechanism version. Step 2.2: Structured extraction based on the terms; For the standardized text_norm of the contract basis unit after normalization, a prompt word is constructed containing candidate function families {threshold, logistic, noisy_or_like, piecewise_linear}, field constraints, and a set of target risk labels. The prompt word explicitly specifies the mechanism node structure, field requirements, and domain-specific language (DSL) syntax specifications, so that the LLM follows the required structure output. Here, threshold is the threshold value, indicating that the risk is triggered when the input value exceeds or falls below a certain fixed threshold; logistic is the logistic function; noisy_or_like is the noisy-OR function; and piecewise_linear is a piecewise linear function.

2. The interpretable construction contract risk review method with mechanism-layer knowledge graph according to claim 1, characterized in that, The specific process of step 3 is as follows: Step 3.1: Clause value analysis and evidence binding; For each contract in the pending contract catalog, a parsing clause unit is defined according to the mechanism node. Within the contract clause and its adjacent clause windows, regular expression matching and keyword matching are performed according to a pre-set pattern to determine whether the clause is "hit". If no pattern matching is found, a prompt word containing the target field definition, context clause text, and output format requirements is constructed to limit the LLM to extract or infer the value of the specified field only from the provided clause text, and a structured result containing the field value, source clause ID, and key original text fragments is returned. Furthermore, the unstandardized numerical or Boolean expressions parsed from the pending contract clauses are unified into standard units to form the mechanism instance input vector. x i =[x i1 ,x i2 ,…,x id ] Where, x i x is the input vector for the i-th mechanism instance; ip Let be the value of the p-th input field of the i-th mechanism instance, where p∈[1,d]; d is the number of input fields of this mechanism; Step 3.2: Compilation and calculation of the mechanism formula; The mechanism instance input vector parsed from the contract under review is substituted into the mechanism node formula described by the DSL to calculate the value; for different scenarios, three types of formulas are used to describe various mechanisms: Logistic family, Noisy-OR class, and piecewise linear class. The Logistic family mechanism formula is applicable to scenarios with continuous variables, gradually changing risk, and output as a smooth curve probability function. Its evaluation formula is as follows: Among them, y i b is the output of the i-th mechanism; b is the bias term; w p The weight of the p-th input; g p (·) represents the input transform specified by the DSL, σ is the Sigmoid function, and x ip Let p be the value of the p-th input field for the i-th mechanism instance; The Noisy-OR mechanism formula is applicable to scenarios where multiple factors trigger risks in parallel, each factor alone can cause risk, and the trigger probabilities can be rolled up in parallel. Its evaluation formula is as follows: Among them, z m Let λ be the normalized value of the m-th potential triggering factor; m This is the triggering strength parameter for the m-th potential triggering factor; Piecewise linear mechanism formulas are applicable to scenarios where risk levels are presented in intervals, and the risk changes linearly with the input variable within these intervals. The evaluation formula is as follows: Where 1{·} is an indicator function; cond r (x i ) represents the determination condition for the r-th segment; a r b is the segment coefficient vector; r The segment intercept; It is an inner product, which only takes effect when the condition in this segment is met, x i Input values ​​for the mechanism; Calculate input sensitivity and log it while evaluating: Among them, s ip Output y for the mechanism i For input x ip Local sensitivity; Step 3.3: Multi-mechanism parallel aggregation for risk: using Noisy-OR aggregation: Among them, P(R) k ) is the risk node R k The aggregation probability; The set of indexes for the mechanisms driving this risk node; λ i Let be the weight of the i-th mechanism participating in the aggregation.

3. The interpretable construction contract risk review method with mechanism-layer knowledge graph according to claim 2, characterized in that, The specific process of step 4 is as follows: Step 4.1: Constructing the evidence package; The key contract information, clause reference information, mechanism information, risk node aggregation probability, and the Top-K interpretation path and sensitivity of "clause → mechanism → risk" are all packaged into evidence packages in both JSON and tabular formats. Step 4.2: Generation of enhanced map results; The evidence package encapsulated in step 4.1 is submitted to the LLM using a three-stage prompting approach, generating a risk level assessment, a chain of reasons, and supplementary evidence suggestions outside the knowledge graph. The three-stage prompting approach includes a system stage, a context stage, and an instruction stage. System section: Defines contract risk review experts, task objectives, output format requirements, and adjudication basis and standards; Contextual Section: The content of the structured evidence package is embedded in a clear, unambiguous text description or formatted data block format, providing all the quantitative results, interpretation paths, original references to key clauses, and details of mechanism calculations required for LLM to make a judgment; Command segment: Explicitly specifies the content to be output by LLM.

4. The interpretable construction contract risk review method with mechanism-layer knowledge graph according to claim 3, characterized in that, The specific process of step 5 is as follows: Step 5.1: Graph structure assembly and backup export; By assembling clause units, mechanism nodes, and risk nodes into a single knowledge graph, the node set V = V C ∪V M ∪V R V C V represents the set of contract clause nodes, derived from the standardized clause units of step 1. M V represents the set of mechanism nodes, derived from the executable mechanism library in step 2. R The risk node set represents the structured risk quantification result from step 3, i.e., the risk node aggregation probability; the edge set E = E CM ∪E MR The edge attribute carries specific reference information pointing to the source data, E CM The edge contains the clause ID that triggers the mechanism and the specific input field that binds the evidence anchor, E MR The edge includes the weights and version information used by the risk aggregation mechanism; the assembled knowledge graph is exported and a timestamped snapshot package is output for offline archiving and multi-version retrieval; Step 5.2: Explanation of path generation and scoring; Paths within a knowledge graph Calculate and rank the contribution scores as follows: in, For path Contribution score; C is the trigger clause node; M i Let R be the i-th mechanism node; k Risk node; y i For path The output of the intermediate mechanism; λ i The weight of the mechanism in the corresponding risk aggregation; After calculating the contribution score of the explanation path, compare the mechanism output obtained in step 3 with the risk layer aggregation result and the risk level judgment generated in step 4 to check whether they corroborate each other; at the same time, check the consistency between the structured evidence package and the knowledge graph structure item by item; correct and record the problems found; after the verification is completed, export the updated knowledge graph file and generate a quality report; the quality report clearly states the mechanisms that need to be adjusted and the reasons, and registers the new version in the executable mechanism library accordingly.

5. A system for implementing the interpretable construction contract risk review method with mechanism layer knowledge graph as described in claim 1, characterized in that, include: Document standardization module: Used to receive and register contract basis documents and contract documents to be reviewed, and to perform text extraction, clause segmentation, terminology and unit standardization processing on the documents, and output a set of standardized clause units; Mechanism library generation module: Based on the LLM self-contract basis document, the logic of how the clause unit triggers a certain type of risk is expressed in a formulaic form to form mechanism nodes. The nodes are then standardized and deduplicated according to a unified JSON+DSL to finally obtain an executable mechanism library. Risk calculation module: Based on the executable mechanism library, it parses and normalizes the values ​​of the mechanism input in the contract under review, binds evidence, executes the mechanism formula, and outputs the mechanism output results and the aggregated probability of the risk nodes. Evidence Package and Judgment Module: Construct a structured evidence package containing key contract information, clause reference information, mechanism information, risk node aggregation probability and Top-K interpretation path, and drive the knowledge graph to generate risk level, reasoning chain and supplementary evidence suggestions; The graph assembly and traceability module is used to assemble clause units, mechanism nodes, and risk nodes into a single knowledge graph, export it as a corresponding standard format file, save it as a version snapshot, and generate and maintain interpretation path scores for relevant personnel to review and for LLM reference.

Images