Building engineering quality examination intelligent contract automatic generation and execution method and system based on large language model

Abstract

The application belongs to the technical field of blockchains, and discloses a building engineering quality examination intelligent contract automatic generation and execution method and system based on a large language model, the intelligent contract generation method comprising: intelligently analyzing construction quality acceptance specification provisions by using a large language model to output structured quality examination logical rules; matching an intelligent contract initial template from a quality examination intelligent contract template library according to a rule label feature set in the quality examination logical rules; filling corresponding content in the quality examination logical rules into corresponding positions according to a data structure of the matched intelligent contract initial template to obtain an intelligent contract; examining the security and compliance of the obtained intelligent contract, and deploying the examined intelligent contract to a blockchain. The above process forms an automated implementation from specification analysis, contract generation to security deployment, and greatly improves the intelligent contract generation efficiency.

Description

Technical Field

[0001] This invention belongs to the field of blockchain-related technology, and more specifically, relates to a method and system for automatically generating and executing smart contracts for building engineering quality review based on a large language model. Background Technology

[0002] In blockchain technology, smart contracts, as automatically executed programs without intermediaries, have been widely applied in various industries, such as cryptocurrency, supply chain management, and financial services. Smart contracts allow complex rules to be encoded on the blockchain, and once these rules are triggered, the relevant contracts execute automatically. However, current smart contract development heavily relies on programming expertise, while quality inspection in construction engineering involves numerous professional specifications described in natural language, and manually translating these into executable code is inefficient and error-prone.

[0003] Therefore, there is an urgent need for an automated conversion method to accurately convert natural language engineering specifications into executable code for smart contracts, in order to improve the efficiency of smart contract generation. Summary of the Invention

[0004] In view of the above-mentioned defects or improvement needs of the existing technology, the present invention provides a method and system for automatic generation and execution of smart contracts for construction engineering quality review based on a large language model. Its purpose is to realize the automatic conversion of natural language engineering specifications into executable code of smart contracts, thereby improving the efficiency of smart contract generation.

[0005] To achieve the above objectives, the following technical solution is proposed.

[0006] According to a first aspect of the present invention, a method for automatically generating smart contracts for construction engineering quality review based on a large language model is provided, comprising:

[0007] The large language model is used to intelligently parse the clauses of the construction quality acceptance specification and output structured quality review logic rules. The quality review logic rules include a set of rule label features, and the rule label features are the key engineering features for initial template matching.

[0008] The initial template of the smart contract is obtained by matching the rule tag feature set in the quality review logic rules from the quality review smart contract template library. The template library contains the initial templates of smart contracts corresponding to different engineering scenario types.

[0009] Based on the data structure of the initial template of the smart contract obtained by matching, the corresponding content in the quality review logic rules is filled into the corresponding positions to obtain the smart contract;

[0010] The security and compliance of the obtained smart contracts are reviewed, and the smart contracts that pass the review are deployed to the blockchain.

[0011] According to a second aspect of the present invention, a method for executing a smart contract for quality review of construction projects is provided, comprising:

[0012] The above-mentioned method for automatically generating smart contracts for construction engineering quality review based on a large language model is used to deploy smart contracts to the blockchain.

[0013] After privacy protection processing of on-site sensor data via an oracle relay network, the data is uploaded to the blockchain, triggering a quality review by the deployed on-chain smart contract and generating an immutable blockchain certificate.

[0014] According to a third aspect of the present invention, an automatic generation system for smart contracts for construction engineering quality review based on a large language model is provided, comprising:

[0015] The natural language processing module is used to intelligently parse the clauses of the construction quality acceptance specification using a large language model and output structured quality review logic rules. The quality review logic rules include a set of rule label features, and the rule label features are key engineering features for initial template matching.

[0016] The smart contract initial template matching module is used to match the smart contract initial template from the quality review smart contract template library according to the rule tag feature set in the quality review logic rules. The template library contains smart contract initial templates corresponding to different engineering scenario types.

[0017] The smart contract activation module is used to fill in the corresponding content in the quality review logic rules into the corresponding positions according to the data structure of the matched smart contract initial template, so as to obtain the smart contract.

[0018] The deployment module is used to review the security and compliance of the obtained smart contracts and deploy the smart contracts that pass the review to the blockchain.

[0019] In summary, compared with the prior art, the technical solutions conceived in this invention have the following main advantages:

[0020] 1. In this invention, a large language model is first used to realize the intelligent parsing of construction specifications into structured rules. Then, semantic features are combined to match the initial template from the template library. Subsequently, the structured rules are filled into the initial template to form the executable code of the smart contract. After security and engineering compliance review, it is deployed to the blockchain. The above process forms an automated implementation from specification parsing, contract generation to secure deployment, which greatly improves the efficiency of smart contract generation.

[0021] 2. In some embodiments, templates covering the core features of rule tags are first selected as candidate templates. Then, a knowledge graph in the field of construction engineering is used to calculate the semantic relevance between tags to compensate for the bias of literal mismatch. An analysis of the complexity of the rule logic conditions is introduced to evaluate the adaptability with the logical support capability of the template. Finally, the semantic relevance and logical adaptability scores are combined and weighted to obtain the final matching degree. Based on the above methods, the most suitable smart contract template can be accurately selected.

[0022] 3. In some embodiments, the quality review logic rules record the rule ID, specification metadata, review parameter matrix, logical condition expression, dependent data source, rule tag feature set and participants in the form of key-value pairs. By structuring the above content, it is easy to map the rule content to the smart contract initial template one by one to form the smart contract executable code.

[0023] 4. In some embodiments, a fourth-order dynamic filling method is used to fill the initial template of the smart contract. This allows for the execution of corresponding operations on different types of data in the quality review logic rules before inserting the template. This standardizes the insertion rules and enables a fast and accurate mapping from rules to executable code of the smart contract.

[0024] 5. In some embodiments, when conducting a compliance review of the resulting smart contract, the compliance of the smart contract can be quickly determined by comparing the hash fingerprints corresponding to the logical condition expressions. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating the steps of an automatic generation method for smart contracts for building engineering quality review based on a large language model, according to an embodiment of the present invention.

[0026] Figure 2 This is a flowchart of matching the initial template of a smart contract according to a set of rule tag features in one embodiment of the present invention;

[0027] Figure 3 This is a flowchart of the steps of a construction project quality review method according to an embodiment of the present invention;

[0028] Figure 4 This is a framework diagram of a smart contract generation system for construction engineering quality review according to an embodiment of the present invention. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0030] Example 1

[0031] This invention proposes an automatic generation method for smart contracts for construction engineering quality review based on a large language model, such as... Figure 1 The diagram shows a flowchart of the automatic generation method for smart contracts for building engineering quality review based on a large language model according to an embodiment of the present invention. The following is a summary of the steps. Figure 1 The method is explained in detail.

[0032] S1. Utilize a large language model to intelligently parse the clauses of the construction quality acceptance specification and output structured quality review logic rules. The quality review logic rules contain a set of rule label features, and the rule label features are the key engineering features for initial template matching.

[0033] Understandably, to make the large language model applicable to the construction engineering field, it is necessary to fine-tune the basic large language model using LoRA (Local Relational Analysis) based on knowledge of the construction engineering domain. This involves optimizing the model's professional understanding capabilities around tasks such as material properties, construction techniques, testing methods, and acceptance standards, enabling it to parse construction quality acceptance specifications and output quality review rules according to a defined format. LoRA fine-tuning is a lightweight fine-tuning method that freezes the weights of the pre-trained model and injects a trainable low-rank matrix to achieve efficient adaptation to downstream tasks. In this step, the fine-tuning strategy designs training tasks around four key dimensions: material properties, construction techniques, testing methods, and acceptance standards. The focus is on strengthening the model's understanding and reasoning capabilities regarding construction engineering terminology, quality acceptance specifications, and engineering quality assessment logic. The final result is a quality review rule LLM model optimized for the construction engineering domain, responsible for transforming construction quality review specifications into structured quality review logic rules.

[0034] For example, the Qwen2.5 model is selected as the basic large language model. Qwen2.5 is an open source large language model (LLM) series launched by the Alibaba Cloud Tongyi Qianwen team, covering parameter sizes from 0.5B to 72B.

[0035] First, data on national building construction quality acceptance standards and historical project acceptance cases were collected. The collected standard data included national standards such as the "Unified Standard for Acceptance of Construction Quality of Building Engineering" (GB50300) and the "Code for Acceptance of Construction Quality of Concrete Structure Engineering" (GB50204), as well as industry standards and local standards of various provinces and cities. The collected project case data included historical acceptance records, quality inspection reports, construction logs and quality defect cases of more than 5,000 projects.

[0036] A domain-specific training dataset was constructed after data cleaning and structured preprocessing. During cleaning, irrelevant formatting tags were removed, professional terminology was standardized, and recognition errors were corrected. In the structured extraction process, standard provisions were organized according to provision number, content, explanation, and inspection methods; acceptance cases were structured according to project information, inspection items, inspection results, and judgment criteria. Data was categorized and labeled according to project type, professional division of labor, quality level, and acceptance stage. The data was converted into a standard instruction-input-output format, with each data entry containing specific acceptance instructions, engineering inspection input information, professional analysis output results, and corresponding standard basis.

[0037] Then, Qwen2.5 was trained for domain adaptation based on LoRA (Low-Rank Adaptation) fine-tuning technology. When configuring LoRA parameters, the rank was set to 64, the scaling parameter to 128, and key modules such as query projection, key projection, value projection, and output projection were selected as target modules, with a dropout rate of 0.1. A multi-dimensional training strategy was designed. Training tasks were designed around four key dimensions: material performance, construction technology, testing methods, and acceptance standards. The material performance dimension focused on training the ability to interpret material parameters and evaluate performance; the construction technology dimension focused on training the ability to check process compliance; the testing methods dimension focused on training the ability to formulate testing plans and analyze results; and the acceptance standards dimension focused on training the ability to guide acceptance procedures and determine compliance.

[0038] The training process is multi-stage. The first stage involves training the model to understand standard texts, enabling it to master architectural engineering terminology and the meaning of standard clauses. The second stage trains the model's case analysis and reasoning abilities, strengthening its understanding of engineering quality assessment logic. The third stage involves multi-task joint optimization training, comprehensively improving the model's professional understanding across four dimensions. The training process uses a learning rate of 1e-4, a batch size of 8, and a total of 6 training rounds.

[0039] Finally, the trained model was validated and tested. Performance was evaluated by the accuracy of technical terminology recognition and the accuracy of standard clause matching to ensure that the model can accurately understand architectural engineering knowledge and correctly apply acceptance standards for quality review. The model outputs a domain-optimized LLM model of quality review rules, completing the task of transforming architectural quality review standard clauses into structured quality review logic rules.

[0040] In one embodiment, the quality review logic rules are recorded in key-value pairs as follows:

[0041] Rule ID, which is a unique identifier for the corresponding rule;

[0042] Specification metadata records the location and content of the summary of the original specification text;

[0043] The review parameter matrix records the engineering review parameter entries and their review reference values ​​in an array structure.

[0044] The logical condition expression records the Boolean logic corresponding to the review conditions; this field supports complex operator combinations to ensure the precise expression of the review conditions.

[0045] It relies on data sources, specifically the field sensor data sources required for record review;

[0046] The tag feature set records the key engineering features used for initial template matching;

[0047] The participants whose records involve the review process.

[0048] In one embodiment, structured quality review logic rules can be generated using a standardized JSON format, which means converting engineering quality specifications described in natural language into a standardized JSON data format that can be executed by machines.

[0049] Taking the acceptance of rebar anchorage length in concealed works as an example, the "Unified Standard for Acceptance of Construction Quality of Building Engineering" (GB) is input into the large language model, and the JSON-formatted quality review logic rules for the acceptance of rebar anchorage length in concealed works are output. The specific content of the rules is as follows:

[0050] "Rule ID":"REBAR_ANCHOR_001";

[0051] "Standard Metadata":{"Standard Number":"GB50204-20235.3.2","Original Abstract":"Design value of anchorage length of HRB400 grade steel bars ≥35d, allowable negative deviation ≤10mm"};

[0052] "Review Parameter Matrix":[{"Parameter Name":"Rebar Grade","Design Value":"HRB400","Unit of Measurement":"N / A"},{"Parameter Name":"Rebar Diameter (d)","Design Value":32,"Unit of Measurement":"mm"},{"Parameter Name":"Design Value of Anchorage Length","Design Value":1120,"Unit of Measurement":"mm"},{"Parameter Name":"Allowable Negative Deviation","Threshold Specification":"≤10","Unit of Measurement":"mm"}];

[0053] Logical condition expression: "Measured anchorage length ≥ (Design value of anchorage length - Allowable negative deviation)";

[0054] "Dependency on data source":["Reinforcement sensor on the west side of floor slab #3_Anchorage length"];

[0055] "Rule Tag Feature Set":["Reinforcement Engineering", "Anchorage Length Inspection", "Hidden Works Acceptance", "Supervision Spot Check"];

[0056] "Party involved": ["Construction party", "Supervision party"].

[0057] S2. Based on the rule tag feature set in the quality review logic rules, the initial template of the smart contract is obtained from the quality review smart contract template library. The template library contains the initial templates of smart contracts corresponding to different engineering scenario types.

[0058] Specifically, the template library develops initial smart contract templates based on the review rules in existing general engineering quality review standards. It can build dedicated initial smart contract templates for core acceptance scenarios in construction projects. These initial smart contract templates are semi-finished contracts optimized for specific scenarios, and can be developed based on Solidity security standards. When new quality acceptance process rules emerge or existing review processes are updated, the template library will also be updated after re-auditing the contracts. The initial smart contract template is a semi-finished product; it sets corresponding data structures for different scenarios. Specific contract content needs to be filled into the initial template to form a complete smart contract.

[0059] When each smart contract initial template is created and added to the database, it is already clearly labeled with corresponding template tag features based on its core functions and application scenarios. These template tag features are semantic representations of the template's capabilities and scope of application.

[0060] In one embodiment, the smart contract initial template includes initial templates for four types of engineering scenarios: material arrival and acceptance scenario, concealed works acceptance scenario, sub-item works acceptance scenario, and final acceptance scenario. Examples of their applicable scenarios and data structures are shown in Table 1 below:

[0061]

[0062] Taking the initial template of the smart contract for the acceptance of the anchorage length of the steel bars in concealed works as an example, it has a pre-set basic structural framework, but key parameters such as allowable deviation values ​​and detection points are reserved in the form of variable slots. These slots are not simple placeholders, but structured interfaces with type constraints and semantic tags. At the same time, it integrates a pre-formed machine call interface, and fills the content of the quality review logic rules and sensor data into the corresponding positions of the template through the set structure.

[0063] In one embodiment, such as Figure 2 The diagram shows a flowchart of matching the initial template of a smart contract according to a set of rule tag features in one embodiment of the present invention, which includes the following process.

[0064] S21. Using the G rule label features with the highest weights in the rule label feature set as initial screening features, all initial templates with arbitrary initial screening features are initially screened from the template library and used as candidate templates to form a candidate template set, where G is a positive integer and the weight of each rule label feature represents the importance of that rule label feature.

[0065] Specifically, regarding the weight settings, the weights of engineering scenario features, task features, and participant features decrease sequentially.

[0066] Taking the acceptance of concealed works—reinforcing bar anchorage length as an example, its rule label feature set includes four rule label features: "reinforcing bar engineering", "anchorage length inspection", "concealed works acceptance", and "supervisor spot check".

[0067] "Hidden works acceptance" is a characteristic of the engineering scenario, which determines the basic architecture of the template. Its weight can be set to W. 场景 =0.5;

[0068] "Reinforcement engineering" and "anchorage length inspection" are task characteristics that determine the core business logic, and their weights can be set to W. 任务 =0.3;

[0069] "Supervision spot checks" belong to the characteristics of participating parties, that is, attribute characteristics, which affect the collaborative process rather than the main function. Therefore, it has the lowest weight and can be set to W. 属性 =0.2.

[0070] In this step, the G rule label features with the highest weights are selected as initial screening features. All initial templates with arbitrary initial screening features are initially screened from the template library and used as candidate templates to form a candidate template set. The larger G is, the more candidate templates are obtained, and the greater the workload of subsequent further screening. Therefore, G can be set according to the actual computing resources.

[0071] For example, in this embodiment, using "concealed works acceptance" and "reinforcement engineering" as initial screening features, initial templates with the features of "concealed works acceptance" or "reinforcement engineering" are selected from the template library to obtain a candidate template set. Assuming that template A for rebar tying inspection and template B for anchorage length are initially screened out, they constitute the candidate template set {template A, template B}, where...

[0072] Template A's template label feature set ["Rebar Binding", "Concealed Works"];

[0073] Template B's template label feature set ["anchoring length", "reinforcement engineering", "sensor data"].

[0074] S22. For each rule label feature in the rule label feature set, calculate its semantic relevance score with each candidate template. Based on the normalized weight of each rule label feature, perform a weighted sum of its semantic relevance scores with the candidate template to obtain the semantic relevance score between the quality review logic rule and the candidate template. The process of calculating the semantic relevance score between the rule label feature and the candidate template includes: calculating the semantic relevance score between the rule label feature and each template label feature in the candidate template, and taking the largest semantic relevance score as the semantic relevance score between the rule label feature and the candidate template. The semantic relevance score between two label features is inversely correlated with the distance between the two label features in the knowledge graph of the construction engineering field.

[0075] For example, the rule label feature set R is ["reinforcing steel engineering", "anchorage length detection", "concealed works acceptance", "supervisor spot check"], the template label feature set of template A is ["reinforcing steel binding", "concealed works"], and the template label feature set of template B is ["anchorage length", "reinforcing steel engineering", "sensor data"]. It is necessary to calculate the semantic correlation score between each rule label feature and template A and template B.

[0076] The process of calculating the semantic relevance score between arbitrary rule label features and arbitrary candidate templates includes:

[0077] Calculate the distance between the rule label feature and each template label feature in the candidate template in the knowledge graph of the construction engineering field. Determine the semantic relevance score between the two based on the distance between them. The smaller the distance, the larger the semantic relevance score. Select the maximum semantic relevance score between the rule label feature and the template label feature as the semantic relevance score between the rule label feature and the candidate template.

[0078] Among them, the knowledge graph in the field of construction engineering is a pre-constructed knowledge graph. Its entities contain all the labeled features, such as features of various engineering scenarios, features of various construction tasks, features of various testing items, roles of various participants, etc. Entities are connected through relationships such as "inclusion" and "parallel".

[0079] In one embodiment, the relationship between the semantic relevance score Y between two label features and the distance d between the two label features in the knowledge graph of the construction engineering field can be expressed as: Y = 1 / (1+d).

[0080] For example, when calculating the semantic association score between "reinforced concrete engineering" in the rule label feature set R and "anchorage length" of formwork B, the calculation process is as follows:

[0081] Based on the knowledge graph path, "reinforced concrete engineering" includes "reinforced concrete structure," and "reinforced concrete structure" includes "anchorage length." Therefore, the path distance d between "reinforced concrete engineering" and "anchorage length" is 2. Substituting this into Y=1 / (1+d), we get the semantic relevance score between them as 1 / (1+d)=0.333. By analogy, we can obtain the semantic relevance score between "reinforced concrete engineering" and each template label feature in template B, and take the highest semantic relevance score as the semantic relevance score between "reinforced concrete engineering" and template B.

[0082] Based on the above process, the semantic relevance scores between "reinforcing steel engineering", "anchorage length detection", "concealed works acceptance", and "supervision spot check" in the rule label feature set R and template B are calculated respectively, for example:

[0083] The semantic relevance score between "reinforced concrete engineering" and formwork B is 0.333;

[0084] The semantic relevance score between "anchoring length detection" and template B is 0.5;

[0085] The semantic relevance score between "concealed works acceptance" and template B is 0.2;

[0086] The semantic relevance score between "Supervision Spot Check" and Template B is 0.1.

[0087] After obtaining the semantic relevance scores between each rule label feature in the rule label feature set R and the candidate template B, the semantic relevance scores between each rule label feature and the candidate template are weighted and summed based on the normalized weights of each rule label feature to obtain the semantic relevance score between the quality review logic rule and the candidate template B. For example, the weights of "reinforcing steel engineering", "anchorage length detection", "concealed works acceptance", and "supervision spot check" are 0.3, 0.3, 0.5, and 0.2, respectively. Their normalized weights are 0.3 / 1.3, 0.3 / 1.3, 0.5 / 1.3, and 0.2 / 1.3. Based on this, the semantic relevance score between the quality review logic rule and template B is calculated as: normalized_semantic=(0.3*0.333+0.3*0.5+0.5*0.2+0.2*0.1) / 1.3≈0.287.

[0088] Similarly, the semantic relevance scores between "reinforcing steel engineering", "anchorage length detection", "concealed works acceptance", and "supervision spot check" in the rule label feature set R and template A can be calculated separately, and the semantic relevance score between the quality review logic rule and template B can be calculated based on this.

[0089] S23. Calculate the logical fit score between the complexity of the logical condition expressions in the quality review logic rules and the logical processing capability of each candidate template.

[0090] Specifically, when building the template library, each template can be given a score for its logical processing capability based on its review function. For example, the complexity of the logical condition expressions in the quality review logic rules and the logical processing capability of the candidate templates can be evaluated by the types of logical operations involved. The more types of logical operations involved and the higher the complexity of the logical condition expressions, the stronger the logical processing capability of the candidate templates.

[0091] For example, the logical conditional expression "actual anchorage length ≥ (anchorage length design value - allowable negative deviation)" involves arithmetic and comparison operations, and its complexity score is rule_complexity=0.7. Template A is used for rebar tying inspection, mainly involving existence checks, and its logical processing capability score is template_support_score=0.4. Template B is used for anchorage length inspection, involving multiple operations such as numerical comparison and threshold judgment, and its logical processing capability score is template_support_score=0.9. It can be seen that the logical conditional expression matches template B better, and its logical fit score is higher.

[0092] In one embodiment, the formula for calculating the logic compatibility score is:

[0093] logic_compatibility=1.0-abs(rule_complexity-template_support_score);

[0094] In the formula, abs() is the absolute value, rule_complexity is the complexity score of the logical conditional expression, and template_support_score is the logical processing capability score of the candidate template.

[0095] Based on the formula for calculating the logical fit score, the following can be obtained:

[0096] Template B has a logical fit score of 0.8;

[0097] Template A has a logical fit score of 0.7.

[0098] S24. For each candidate template, the semantic relevance score and logical fit score between the quality review logic rule and the candidate template are weighted and summed to obtain the comprehensive score of the candidate template. The candidate template with the highest comprehensive score is used as the initial smart contract template matched according to the rule label feature set.

[0099] The semantic relevance score and logical fit score of the quality review logic rules and the candidate template are weighted and summed, with the semantic relevance score having a higher weight than the logical fit score. For example, the former weight can be set to 0.7, and the latter weight can be set to 0.3. The comprehensive score of candidate template B is: final_score_B = 0.7 * 0.287 + 0.3 * 0.8 ≈ 0.441. Similarly, the comprehensive score of candidate template B can be calculated to be 0.312. Therefore, template B (anchoring length dedicated template) has the highest comprehensive matching degree (0.408), and this template is automatically selected to proceed to the subsequent filling configuration step.

[0100] In the above embodiments, firstly, templates covering the core features of rule tags are selected as candidate templates. Then, a knowledge graph in the field of construction engineering is used to calculate the semantic relevance between tags to compensate for the deviation of literal mismatch. Furthermore, the complexity of the rule logic conditions is analyzed, and the adaptability of the template's logical support capability is evaluated. Finally, the semantic relevance and logical adaptability scores are combined and weighted to obtain the final matching degree, thereby accurately selecting the most suitable smart contract template.

[0101] S3. Based on the data structure of the initial template of the smart contract obtained by matching, fill in the corresponding content in the quality review logic rules into the corresponding positions to obtain the smart contract.

[0102] This process is a crucial step in activating the template. The obtained initial smart contract template is only a semi-finished product. It sets corresponding data structures for different scenarios, and specific contract content needs to be filled into the initial template to form a complete smart contract.

[0103] In one embodiment, when the quality review logic rules record the rule ID, specification metadata, review parameter matrix, logical condition expression, dependent data source, rule tag feature set, and participants in the form of key-value pairs, a fourth-order dynamic filling method can be used to fill the initial template of the smart contract. The fourth-order dynamic filling method includes filling variable declarations, inserting logical conditions, configuring data interfaces, and building a signature framework.

[0104] The variable declaration includes parsing the review parameter matrix in the quality review logic rules and filling it into the smart contract initial template, as well as injecting the specification metadata in it into the contract function of the smart contract initial template in a standardized annotation format; for example, the natural language description in the review parameter matrix can be converted into a strictly typed Solidity constant and then filled into the smart contract initial template, and the specification metadata field "GB50204-20235.3.2" can be injected into the Solidity function in the annotation form / / / @refGB50204-2023 5.3.2.

[0105] For example, before populating the variable declarations, the corresponding content in the initial template is:

[0106] .

[0107] After populating the variable declarations, the corresponding content in the template is:

[0108] .

[0109] Inserting logical conditions involves parsing the logical condition expressions in the quality review logical rules and inserting them into the smart contract initial template. For example, a dedicated DSL compiler can be used to decompose a complex condition such as "floor slab thickness ≥ design value - 5mm and ≤ design value + 8mm" in the logical condition expression into an AST syntax tree, and then convert it into a nested require statement to be inserted into the smart contract initial template.

[0110] For example, using a dedicated DSL compiler, the logical conditional expression "actual anchorage length ≥ (anchorage length design value - allowable negative deviation)" can be decomposed into an AST syntax tree:

[0111] ;

[0112] The AST syntax tree is shown in Table 2 below:

[0113]

[0114] Then convert it into a nested require statement in Solidity code and insert it into the template:

[0115] .

[0116] The configuration data interface includes parsing the dependent data sources in the quality review logic rules and configuring sensor addresses for the oracle call interface of the smart contract initial template. Specifically, each pre-built template has a pre-configured standardized Chainlink oracle call interface. During population, the interface is customized according to the data source specified in the rules. For example, when the rule requires obtaining "sensor data for floor #3", the corresponding sensor address will be automatically bound, and a data request function will be generated. Subsequently, when the quality review conditions are met, the smart contract sends an instruction to the Chainlink oracle through this data request function. When the oracle submits the data to the blockchain network through a callback function, the data is successfully uploaded to the chain.

[0117] For example, before configuring the data interface, the corresponding content in the initial template is:

[0118] .

[0119] After configuring the data structure, the corresponding content in the template is:

[0120] .

[0121] Building the signature framework involves parsing the participants in the quality review logic rules and dynamically constructing the signature framework in the smart contract initial template. The signature framework is used to logically trigger signature event requests according to the signature order to coordinate quality acceptance with each participant.

[0122] For example, before building the signature framework, the corresponding content in the initial template is:

[0123] .

[0124] After building the signature framework, the corresponding content in the template is:

[0125] ;

[0126] onlyRole(CONTRACTOR_ROLE): Access control restricts access by the construction party's role, ensuring that only certified construction personnel can operate it.

[0127] contractorSigned[msg.sender]=true: Status update, records signature status and basis for tracing responsibility for construction quality;

[0128] supervisorSigned[SUPERVISOR_ADDRESS]: Status check, verifies whether the supervisor has signed, and implements the "supervisor-construction" dual signature mechanism;

[0129] triggerInspection(): An internal call that triggers the quality inspection process and initiates on-site data collection and verification.

[0130] After the fourth-order dynamic filling template is completed, the initial code of the smart contract for the quality acceptance of the anchorage length of the steel bars in the concealed works is obtained.

[0131] S4. Review the security and compliance of the obtained smart contracts, and deploy the smart contracts that pass the review to the blockchain.

[0132] Specifically, a dual-track verification mechanism can be used to conduct in-depth reviews of the initial smart contract code. The dual-track verification mechanism includes blockchain security verification and engineering compliance verification. Under the condition that the smart contract is secure and compliant, it is deployed to the consortium blockchain. If the initial smart contract fails the review, a defect report is automatically generated and a smart repair process is triggered.

[0133] In one embodiment, blockchain security verification includes: scanning for reentrancy vulnerabilities using pre-defined static analysis tools, and performing security vulnerability scanning on the initial smart contract code using pre-defined dynamic testing methods to simulate attacks and check for the existence of security vulnerabilities. Static analysis tools, such as Mythril and Slither, are used to scan smart contract code. These tools can identify common security vulnerabilities, such as reentrancy attacks, integer overflows, and time-dependent errors. By analyzing the execution path and data flow of the contract code, static analysis provides a method to discover problems without actually executing the code. In addition to static analysis, dynamic testing can also be implemented to verify the behavior of the contract. By simulating transactions and contract execution in a sandbox environment, the actual performance of the contract under different conditions and inputs can be observed. This testing helps ensure the stability and security of the contract when running in a real-world blockchain network. Dynamic testing can reveal problems that may only appear under specific conditions.

[0134] In one embodiment, when a structured quality review logic rule is output using a large language model, the quality review logic rule is stored in a rule base and the logical condition expression in the quality review logic rule is mapped to a hash as a canonical fingerprint of the quality review logic rule; when generating a smart contract, the logical condition expression in the smart contract is mapped to a hash value and recorded in the smart contract as an immutable contract fingerprint, and the smart contract records the rule ID of its quality review logic rule;

[0135] Engineering compliance verification includes:

[0136] Based on the rule ID recorded in the smart contract, locate the quality review logic rule with the same rule ID from the rule base and obtain its specification fingerprint;

[0137] The system determines whether the contract fingerprint recorded in the smart contract is the same as the obtained standard fingerprint. If they are the same, the contract is considered compliant; otherwise, it is considered non-compliant.

[0138] Specifically, in step S1, when the structured quality review logic rules are output using the large language model, the logical condition expressions are mapped to hashes as the canonical fingerprints of the quality review logic rules. In step S3, after the quality review logic rules are filled into the initial template, the filled logical condition expressions are also mapped to hashes as the contract fingerprints of the contract. In one embodiment, an 8-byte short hash can be generated using the Keccak-256 algorithm.

[0139] In one embodiment, if the initial smart contract fails the review, a defect report is automatically generated and a smart repair process is triggered.

[0140] To address security vulnerabilities, a pre-built smart contract security vulnerability knowledge base is invoked, along with CWE standards, to generate code patching solutions.

[0141] To address engineering compliance deviations, the system can locate the original quality review logic rule file with the same rule ID from the rule base, and then correct the smart contract based on the original file. For example, it compares whether the constant values ​​in the contract (e.g., designValue=1120, tolerance=10) are completely consistent with the design values ​​and threshold specifications defined in the acceptance parameter matrix of the original quality review logic rule file. For example, it checks whether the tolerance in the contract precisely corresponds to "≤10" in the rule. The conditional statements in the contract (e.g., require(measuredLength>=designValue-tolerance,"...")) are decompiled into an intermediate representation (IR), and compared with the logical conditional expression ("actual anchorage length ≥ (anchorage length design value - allowable negative deviation)") in the original quality review logic rule file using the same DSL compiler-generated IR. This process can identify logical deviations caused by code optimization or manual modifications, such as miswriting >= as >. For parameter deviations, the system directly extracts the correct value to overwrite the incorrect setting; for logical conflicts, the DSL compiler recompiles the specification clauses into an AST syntax tree to generate a new conditional expression that conforms to the standard. All fixes retain a complete version tracking history, generating change traceability markers in contract comments such as / / / @amended[GB50204-2023] instead of @ref[GB50204-2011]. The updated contract code automatically enters an iterative verification loop. If three consecutive fixes fail, a circuit breaker mechanism is triggered, freezing the deployment process and pushing a high-risk alert containing vulnerability details and fix blockage analysis to the management terminal, requiring manual intervention for debugging.

[0142] Example 2

[0143] This invention also provides a method for quality inspection of building construction projects, such as... Figure 3 The diagram shows a flowchart of a construction project quality review method according to an embodiment of the present invention, which includes:

[0144] The smart contract is deployed to the blockchain using the automatic generation method of building engineering quality review smart contract based on a large language model in Example 1.

[0145] After privacy protection processing of on-site sensor data via an oracle relay network, the data is uploaded to the blockchain, triggering a quality review by the deployed on-chain smart contract and generating an immutable blockchain certificate.

[0146] Specifically, by constructing a Zero-Knowledge Proof Oracle (ZKP Oracle) network with a layered architecture, dedicated hardware devices are deployed on edge computing nodes to collect sensor data in real time. The raw data is then compressed into lightweight proof packages using the zk-SNARK proof algorithm, and core computations are performed off-chain, achieving privacy protection and trusted on-chain uploading of engineering site data. For example, sensor devices deployed at construction sites transmit data to the nearest edge oracle node via MQTT or HTTPS protocols. Each node performs preliminary processing on the received data, including filtering and noise reduction, timestamp synchronization and format standardization, and AES-256-based data encryption. The standardized raw data is simultaneously written to a local secure storage area and the entry point for subsequent proof processes.

[0147] The oracle relay network plays a crucial role in trusted transmission and collaborative verification, serving as a key hub between the ZKP Oracle network and the blockchain. It employs a unique dual-channel architecture, with each channel performing different functions: the consensus channel is dedicated to broadcasting zero-knowledge proof packages generated by the ZKP Oracle and organizing multiple relay nodes off-chain for distributed pre-verification. This consensus mechanism quickly filters invalid proofs, significantly reducing subsequent on-chain verification costs. The data channel focuses on handling regulatory compliance requirements, encrypting the original data using the AES-256 algorithm and backing up the encrypted ciphertext to the decentralized storage system (IPFS), storing only the data fingerprint for audit traceability. For example, the construction party, supervisor, and auditor each hold one or more key fragments of the AES-256 encryption key. Before generating the data ciphertext and uploading it to IPFS, edge nodes use a threshold encryption algorithm to jointly sign the keys, ensuring that no single party can decrypt it independently and facilitating secure recovery of the original data during multi-party collaborative audits. Simultaneously, the resulting IPFS CID and data fingerprint are logged for subsequent off-chain decryption and compliance audits. The oracle generates zero-knowledge proofs based on predefined engineering quality review arithmetic circuits (such as rules for concrete strength, crack limits, and vibration frequency) and the Groth16 protocol. Lightweight proof packages and Merkle root digests are generated in parallel on edge nodes. The entire computation process is completed locally on the edge nodes, ensuring that the original data never leaves the local machine, thus fully protecting data privacy. Subsequently, the proof package and its data hash are pushed from the edge nodes to an oracle relay network composed of multiple nodes. The relay nodes verify the proof across nodes using a consensus protocol. Only after a majority of nodes unanimously confirm the proof is the valid proof and data hash packaged into a transaction and submitted to the consortium blockchain. This automatically triggers a predefined callback function in the on-chain smart contract, achieving "true proof driving true on-chain" while preventing the original data from being exposed on-chain or outside the relay network.

[0148] During the on-chain verification phase, the pre-compiled smart contract verifier ZkVerifier completes a single proof verification. Upon confirming the validity of the zero-knowledge proof, ZkVerifier directly invokes the deployed quality audit smart contract via a pre-defined callback interface. This triggering process is entirely event-driven, requiring no manual intervention; the quality audit contract then executes the pre-compiled engineering rule verification logic.

[0149] The evidence generation process employs a native blockchain security mechanism: First, the structured evidence data is used to generate a unique content fingerprint using the Keccak-256 algorithm. Then, this fingerprint is bound to the current block height and the initiator's digital signature, forming a triple tamper-proof protection layer. Finally, the evidence is written to the blockchain through both Ethereum log events (LOG) and the state root. The event log records a searchable evidence summary, while the state root persistently stores the complete evidence data package.

[0150] For example, after verifying the multi-party threshold signature, the corresponding decryption key is obtained, the IPFS ciphertext is decrypted, and a formatted public input (such as concrete strength 36.7 MPa) is output. Then, the smart contract ZkVerifier efficiently verifies the zk-SNARK proof using EVM native elliptic curve pairing pre-compilation instructions. After successful verification, the contract automatically loads the deployed quality review logic: for example, for the contract for concrete strength testing, the verifyConcreteStrength(36.7) function is called to compare it with the threshold in GB50204 and generate a digital signature review conclusion. The smart contract encapsulates the judgment result, review data hash, block height, timestamp, and other information into a structured evidence storage data package. This evidence storage data package is written to the blockchain through both Ethereum log events and state roots to ensure the immutability and traceability of the evidence storage data. The evidence storage summary is recorded through the event log, while the complete evidence storage data is stored on the blockchain through state variables, thereby providing verifiable evidence for subsequent audits and compliance checks, realizing an on-chain event-driven automated quality review closed loop. In subsequent retrospective audits, two audit paths are implemented based on the compliance needs of different roles: On the one hand, regulators or audit departments can directly verify the credibility of their review conclusions based solely on the zero-knowledge proofs contained in the evidence storage event, without needing to obtain or view any original quality data; on the other hand, for quality inspection agencies or expert groups that need to review the original quality data, a multi-party threshold signature mechanism can be used to jointly unlock the AES-256 encryption key, and then the encrypted evidence storage package can be retrieved and decrypted based on the IPFS Content Identifier (CID) recorded in the evidence storage event to obtain the complete original data. This "dual-track" audit model not only satisfies the strict protection of data privacy but also provides flexible traceability and review capabilities for different compliance entities, thereby truly building an end-to-end, fully reliable closed loop for construction project quality management.

[0151] In one embodiment, the oracle data on-chain process supports both timed trigger mode and event-triggered mode: the timed trigger mode is executed automatically according to a configurable period (e.g., every 1 hour or 24 hours); the event-triggered mode is executed immediately when a smart contract undergoes a specific state transition or when an external call is made.

[0152] Specifically, the timed trigger mode relies on a configurable periodic scheduling engine to achieve automated operation. Its core lies in driving a closed-loop process of data collection, verification, and on-chain data storage through preset time parameters (typically configured as 1 hour, 24 hours, or other commonly used engineering monitoring cycles). This mode is suitable for quality indicator monitoring scenarios in construction engineering with significant periodic patterns: for example, structural displacement data based on IoT sensors needs to be collected periodically according to construction safety specifications, and environmental monitoring parameters (temperature, humidity, PM2.5 concentration) need to meet the periodic reporting requirements of environmental regulations. In such scenarios, the system reduces the cost of repetitive configuration by fixing the collection cycle, while utilizing the timestamp characteristics of blockchain to ensure the continuity and auditability of data sequences, providing a structured data foundation for long-term quality trend analysis. The event-triggered mode achieves instant response through a smart contract event listening layer and external calling interfaces. When the smart contract state machine migrates to a preset key node (such as a material strength threshold exceeding the limit alarm), the contract's built-in event transmitter will generate a standardized event log, triggering the oracle to immediately start the target data source collection process.

[0153] Example 3

[0154] This invention also relates to a smart contract generation system for construction engineering quality review, such as... Figure 4 The diagram shown is a framework diagram of a smart contract generation system for construction project quality review according to an embodiment of the present invention, which includes:

[0155] The natural language processing module is used to intelligently parse the clauses of the construction quality acceptance specification using a large language model, and output structured quality review logic rules. The quality review logic rules contain a set of rule label features, and the rule label features are the key engineering features for initial template matching.

[0156] The smart contract initial template matching module is used to match the smart contract initial template from the quality review smart contract template library based on the rule tag feature set in the quality review logic rules. The template library contains smart contract initial templates corresponding to different engineering scenario types.

[0157] The smart contract activation module is used to fill in the corresponding content in the quality review logic rules into the corresponding positions according to the data structure of the matched smart contract initial template, so as to obtain the smart contract.

[0158] The deployment module is used to review the security and compliance of the obtained smart contracts and deploy the smart contracts that pass the review to the blockchain.

[0159] The smart contract generation system for building engineering quality review can be used to execute the automatic generation method for building engineering quality review smart contracts based on a large language model in Example 1. For details, please refer to the introduction of Example 1, which will not be repeated here.

[0160] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification. It should be noted that the terms "in one embodiment," "for example," and "again" are intended to illustrate the present invention and are not intended to limit the present invention.

[0161] The embodiments described above are merely examples of several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention.

Claims

1. A method for automatically generating smart contracts for construction project quality review based on a large language model, characterized in that, include: The large language model is used to intelligently parse the clauses of the construction quality acceptance specification and output structured quality review logic rules. The quality review logic rules include a set of rule label features, and the rule label features are the key engineering features for initial template matching. The initial template of the smart contract is obtained by matching the rule tag feature set in the quality review logic rules from the quality review smart contract template library. The template library contains the initial templates of smart contracts corresponding to different engineering scenario types. Based on the data structure of the initial template of the smart contract obtained by matching, the corresponding content in the quality review logic rules is filled into the corresponding positions to obtain the smart contract; The security and compliance of the obtained smart contracts are reviewed, and the smart contracts that pass the review are deployed to the blockchain; Each smart contract initial template has a corresponding set of template tag features. The process of matching the smart contract initial template according to the set of rule tag features includes: Using the G rule label features with the highest weights in the rule label feature set as initial screening features, all initial templates with any of the initial screening features are initially screened from the template library and used as candidate templates to form a candidate template set, where G is a positive integer and the weight of each rule label feature represents the importance of the rule label feature. For each rule label feature in the rule label feature set, calculate its semantic relevance score with each candidate template. Based on the normalized weight of each rule label feature, perform a weighted sum of its semantic relevance scores with the candidate template to obtain the semantic relevance score between the quality review logic rule and the candidate template. The process of calculating the semantic relevance score between the rule label feature and the candidate template includes: calculating the semantic relevance score between the rule label feature and each template label feature in the candidate template, and taking the largest semantic relevance score as the semantic relevance score between the rule label feature and the candidate template. The relationship between the semantic relevance score Y between two label features and the distance d between the two label features in the knowledge graph of the construction engineering field is: Y = 1 / (1+d). Calculate the logical adaptability score between the complexity of the logical condition expressions in the quality review logic rules and the logical processing capability of each candidate template. For each candidate template, the semantic relevance score and logical fit score between the quality review logic rule and the candidate template are weighted and summed to obtain the comprehensive score of the candidate template. The candidate template with the highest comprehensive score is used as the initial smart contract template matched according to the rule label feature set.

2. The method for automatically generating smart contracts for construction engineering quality review based on a large language model as described in claim 1, characterized in that, The template library contains initial templates for four types of engineering scenarios: material arrival and acceptance scenario, concealed works acceptance scenario, sub-item works acceptance scenario, and final acceptance scenario.

3. The method for automatically generating smart contracts for construction engineering quality review based on a large language model as described in claim 1, characterized in that, The quality review logic rules are recorded in key-value pairs as follows: Rule ID, which is a unique identifier for the corresponding rule; Specification metadata records the location and content of the summary of the original specification text; The review parameter matrix records the engineering review parameter entries and their review reference values ​​in an array structure. A logical conditional expression, which records the Boolean logic corresponding to the review conditions; It relies on data sources, specifically the field sensor data sources required for record review; The rule label feature set records the key engineering features used for initial template matching; The participants whose records involve the review process.

4. The method for automatically generating smart contracts for construction engineering quality review based on a large language model as described in claim 3, characterized in that, The initial template of the smart contract is populated using a fourth-order dynamic filling method, which includes filling variable declarations, inserting logical conditions, configuring data interfaces, and building a signature framework. The declaration of the populated variables includes parsing the review parameter matrix in the quality review logic rules and filling it into the smart contract initial template, as well as injecting the specification metadata therein into the contract function of the smart contract initial template in a standardized annotation format; The insertion logic condition includes parsing the logic condition expression in the quality review logic rule and inserting it into the smart contract initial template; The configuration data interface includes parsing the dependent data sources in the quality review logic rules and configuring sensor addresses for the oracle call interface of the smart contract initial template. The construction of the signature framework includes parsing the participants in the quality review logic rules and dynamically constructing the signature framework in the smart contract initial template. The signature framework is used to logically trigger signature event requests according to the signature order to coordinate quality acceptance with each participant.

5. The method for automatically generating smart contracts for building engineering quality review based on a large language model as described in claim 4, characterized in that, The insertion of logical conditions involves using a dedicated DSL compiler to decompose the logical condition expression into an AST syntax tree, then converting it into a nested require statement in Solidity code and inserting it into the initial template of the smart contract.

6. The method for automatically generating smart contracts for construction engineering quality review based on a large language model as described in claim 1, characterized in that, When using a large language model to output structured quality review logic rules, the quality review logic rules are stored in a rule base and the logical condition expressions in the quality review logic rules are mapped to hashes, which serve as the canonical fingerprints of the quality review logic rules. When generating a smart contract, the logical condition expressions in the smart contract are mapped to hash values ​​and recorded as immutable contract fingerprints in the smart contract, and the smart contract records the rule ID of its quality review logic rules. The resulting smart contracts undergo compliance review, including: Based on the rule ID recorded in the smart contract, locate the quality review logic rule with the same rule ID from the rule base and obtain its specification fingerprint; The system determines whether the contract fingerprint recorded in the smart contract is the same as the obtained standard fingerprint. If they are the same, the contract is considered compliant; otherwise, it is considered non-compliant.

7. A method for executing a smart contract for quality review of construction projects, characterized in that, include: The smart contract is deployed to the blockchain using the automatic generation method for building engineering quality review smart contracts based on a large language model as described in any one of claims 1 to 6. After privacy protection processing of on-site sensor data via an oracle relay network, the data is uploaded to the blockchain, triggering a quality review by the deployed on-chain smart contract and generating an immutable blockchain certificate.

8. A smart contract automatic generation system for construction engineering quality review based on a large language model, characterized in that, The method for automatically generating smart contracts for construction engineering quality review based on a large language model as described in any one of claims 1 to 6 includes: The natural language processing module is used to intelligently parse the clauses of the construction quality acceptance specification using a large language model and output structured quality review logic rules. The quality review logic rules include a set of rule label features, and the rule label features are key engineering features for initial template matching. The smart contract initial template matching module is used to match the smart contract initial template from the quality review smart contract template library according to the rule tag feature set in the quality review logic rules. The template library contains smart contract initial templates corresponding to different engineering scenario types. The smart contract activation module is used to fill in the corresponding content in the quality review logic rules into the corresponding positions according to the data structure of the matched smart contract initial template, so as to obtain the smart contract. The deployment module is used to review the security and compliance of the obtained smart contracts and deploy the smart contracts that pass the review to the blockchain.

Images