Method and device for checking rationality of construction parameters of technical bid of building engineering

Abstract

The application discloses a construction engineering technical bid construction parameter rationality checking method and device. The method comprises the following steps: analyzing technical bid data to be checked, and converting text, table and graphic content into content blocks with identification, text and position information; identifying construction objects according to the content blocks, and generating checking items according to preset constraint rules and the construction objects; extracting parameter entities from the content blocks, and standardizing the values and units of the parameter entities; determining target parameter entities matched with the checking items according to the construction objects and parameter types, jointly substituting parameter values of the target parameter entities into applicable constraint rules for calculation, and generating risk items when the calculation results do not satisfy the constraint rules; determining evidence positions according to the content block identification in the risk items, and outputting the risk items and the evidence positions. The application can perform associated checking on construction parameters, reduce parameter mismatch, and improve checking accuracy, coverage, traceability and review efficiency.

Description

Technical Field

[0001] This application relates to the field of information technology and data processing in building engineering, and in particular to a method and device for verifying the rationality of construction parameters in building engineering technical specifications. Background Technology

[0002] The technical tender for a construction project is a crucial document outlining the bidder's construction organization, schedule, and resource allocation plan. It typically includes various construction parameters such as quantities, construction period, machinery and equipment, labor, material supply, construction sections, and construction methods. The rationality of these parameters affects the feasibility of the construction plan and the quality of the technical tender's response to the tender requirements.

[0003] Currently, technical specifications for construction projects are typically reviewed manually by the drafters or reviewers, with the aid of general text checking tools and schedule planning software. While these tools can perform some text checks, schedule planning, and data verification, their effectiveness in comprehensively identifying the rationality of construction parameters within the technical specifications remains insufficient.

[0004] In the actual preparation and review process, technical bids may contain issues such as missing construction parameters, inconsistencies in records at different locations, unreasonable schedules for sub-items, and mismatches between resource allocation and construction tasks. For technical bids that are lengthy and involve many construction objects, the efficiency and coverage of manual verification are easily limited, making it difficult to discover the rationality issues of some parameters in a timely and complete manner, and the convenience of reviewing the verification results also needs to be improved.

[0005] Therefore, how to improve the accuracy, completeness, and efficiency of verifying the rationality of construction parameters in building engineering technical specifications has become a technical problem that needs to be solved in this field. Summary of the Invention

[0006] This application provides a method and apparatus for verifying the rationality of construction parameters in building engineering technical specifications, aiming to improve the accuracy, completeness, and efficiency of verifying the rationality of construction parameters in building engineering technical specifications.

[0007] Firstly, this application provides a method for verifying the rationality of construction parameters in a building engineering technical bid, comprising: parsing the technical bid data to be verified, converting the parsed text, table, and graphic content into content blocks, each content block recording a content block identifier, text content, and the position information of the content block in the technical bid data; identifying the construction object based on the text content of the content block; generating verification items based on preset constraint rules and the construction object, the verification items including the construction object to which they point, the required parameter type, and the applicable constraint rules; extracting parameter entities from the content blocks, and standardizing the values ​​and units of the parameter entities, the parameter entities including parameter type, belonging to The construction object, the standardized parameter values, and the content block identifier from which they originate are defined. For each verification item, a target parameter entity is determined from the parameter entities. The construction object to which the target parameter entity belongs is the same as the construction object to which the verification item points, and the parameter type of the target parameter entity is the parameter type required by the verification item. The parameter values ​​of each target parameter entity are substituted into the constraint rules applicable to the verification item for calculation. If the calculation result does not meet the constraint rules, a risk item is generated. The risk item includes the construction object to which the verification item points, the calculation result, the benchmark value determined according to the constraint rules and compared with the calculation result, and the content block identifier from which each target parameter entity originates.

[0008] The location information corresponding to each content block identifier in the risk item is used as the evidence location of the risk item, and the risk item and its evidence location are output.

[0009] Secondly, this application provides a device for verifying the rationality of construction parameters in building engineering technical specifications, comprising:

[0010] The data parsing module is used to parse the technical bid data to be verified, and convert the parsed text content, table content and graphic content into content blocks. Each content block records a content block identifier, text content and the position information of the content block in the technical bid data.

[0011] An object recognition module is used to identify construction objects based on the text content of the content block;

[0012] The verification item generation module is used to generate verification items based on preset constraint rules and the construction object. The verification item includes the construction object it points to, the required parameter type, and the applicable constraint rules.

[0013] The parameter extraction module is used to extract parameter entities from the content block and standardize the values ​​and units of the parameter entities. The parameter entity includes parameter type, the construction object to which it belongs, the parameter value obtained after standardization, and the identifier of the content block from which it originates.

[0014] The parameter alignment module is used to determine a target parameter entity from the parameter entities for the verification item, wherein the construction object to which the target parameter entity belongs is the same as the construction object pointed to by the verification item, and the parameter type of the target parameter entity belongs to the parameter type required by the verification item.

[0015] The risk calculation module is used to substitute the parameter values ​​of each of the target parameter entities into the constraint rules applicable to the verification item for calculation, and generate a risk item when the calculation result does not meet the constraint rules. The risk item includes the construction object to which the verification item points, the calculation result, the benchmark value determined according to the constraint rules and compared with the calculation result, and the content block identifier from which each of the target parameter entities originates.

[0016] The evidence location module is used to take the location information corresponding to each content block identifier in the risk item as the evidence location of the risk item, and output the risk item and its evidence location.

[0017] Thirdly, this application provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, it implements the method for verifying the rationality of construction parameters in building engineering technical standards as described in the first aspect.

[0018] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method for verifying the rationality of construction parameters in building engineering technical specifications as described in the first aspect.

[0019] Beneficial Effects: This application's embodiments unify the text, table, and graphic content in technical bid documents into content blocks that record content block identifiers, text content, and location information. Using the identified construction object as the association basis, verification items are generated according to preset constraint rules. Parameter entities are extracted from the content blocks, and the values ​​and units of these parameter entities are standardized. Then, target parameter entities matching the verification items are determined according to the construction object and parameter type. This allows construction parameters from different sources and with different expressions to accurately enter the corresponding constraint rules for association calculation, reducing parameter mismatches between different construction objects or parameter types. It also identifies risks in project schedule or resource allocation that are not easily detected when observing individual parameters but do not meet constraint rules when multiple parameters are combined, thereby improving the accuracy, coverage, and efficiency of verifying the rationality of construction parameters in building engineering technical bids. Simultaneously, by recording the calculation results, benchmark values, and the content block identifiers from which the parameter entities originate in the risk items, and outputting the corresponding location information as evidence, risk conclusions can be traced back to the original content involved in the calculation, improving the traceability and review efficiency of the verification results. Attached Figure Description

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

[0021] Figure 1 A schematic diagram illustrating an application scenario for the method for verifying the rationality of construction parameters in architectural engineering technical specifications provided in this application embodiment;

[0022] Figure 2 A flowchart illustrating the method for verifying the rationality of construction parameters in architectural engineering technical specifications provided in this application embodiment;

[0023] Figure 3 This is a flowchart illustrating the process of parsing effective data, as provided in an embodiment of this application.

[0024] Figure 4 A schematic diagram illustrating the process of obtaining graphic content provided in this application embodiment;

[0025] Figure 5 This is a schematic diagram of the verification item generation process across construction objects provided in an embodiment of this application;

[0026] Figure 6 A schematic diagram of the on-demand triggered calculation provided in the embodiments of this application;

[0027] Figure 7 A schematic block diagram of a construction engineering technical specification rationality verification device provided in the embodiments of this application;

[0028] Figure 8 A schematic block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0030] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0031] It should also be understood that the terminology used in this application specification is for the purpose of describing particular embodiments only and is not intended to limit the application. As used in this application specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0032] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0033] The method provided in this embodiment of the invention is executed by a computer device. This computer device can be a single server, a server cluster consisting of multiple servers, or a combination of a terminal and a server. The terminal is responsible for receiving the technical specification data to be verified and displaying the verification results, while the server is responsible for parsing, calculating, and locating the data. See also... Figure 1 In a terminal-server configuration, terminal 101 sends the received technical specification data to server 102, and server 102 returns the obtained risk items and their evidence locations to terminal 101. The computer device includes a processor and a memory. The memory stores a computer program executable by the processor, which executes the program to implement the methods described in the following embodiments. The deployment configuration of the computer device does not affect the implementation of the embodiments of the present invention.

[0034] In the preparation of technical bids for construction projects, there are numerous implicit constraints among the construction period, machinery, labor, materials, work sequence, and construction methods. Existing auxiliary tools struggle to assess these constraints. General text checking tools focus on the correctness of the text itself, such as typos, grammatical errors, and formatting. They do not extract numerical values ​​from the document for calculation. Therefore, no matter how strong their error-checking capabilities, they cannot answer questions like whether the sum of the individual work periods exceeds the total construction period or whether the number of equipment units can support the lifting volume. While schedule planning software has the ability to estimate the construction period, its data entry is structured task and date fields. The construction deployment descriptions, score point response commitments, and resource plans presented in tables and Gantt charts in the technical bid text are not entered into the software in this structure. There is a lack of connection between the two, resulting in a disconnect between the software-calculated plan and the commitments recorded in the text. As for manual verification, technical specifications can easily be hundreds of pages long, and the same parameter is often scattered across multiple parts of the text, tables, and drawings. Implicit constraints also require pairwise comparisons across chapters. It is unrealistic to exhaust all these combinations within the limited bidding time, so the verification results are highly dependent on the personal experience of the reviewers.

[0035] For a machine to determine the calculation logic between engineering parameters, two conditions must be met simultaneously: it must know which parameters should be verified and according to what rules, and it must also know which parameters are actually specified in the technical specifications, their values, and their attributions. Existing solutions often only address one of these conditions—solutions that only extract parameters don't know what to compare them to, while solutions that only list checklists cannot automatically retrieve the values ​​being checked. Even if both conditions are met, it's still insufficient to complete the calculation: parameters scattered across different chapters need to be matched one-to-one with the inspection requirements, and only parameters of the same construction object and parameter type can be included in the same rule for calculation; otherwise, the steel structure's quantity will be subtracted from the earthwork duration, rendering the calculated conclusion meaningless.

[0036] Based on this, in one embodiment of the present invention, the technical specification data to be verified is first uniformly converted into locatable content blocks. Then, on one side, verification items are generated according to preset constraint rules and identified construction objects. On the other side, parameter entities are extracted from the content blocks, and their values ​​and units are standardized. Then, the two sides are matched according to the construction object and parameter type. The corresponding parameter values ​​are substituted into the constraint rules applicable to the verification item for calculation. If the calculation result does not meet the constraint rules, a risk item is generated, and the position in the original technical specification is traced back by the content block identifier from which the parameter entity originates. The method provided by this embodiment uses content blocks as a unified carrier of heterogeneous data and completes quantitative calculation by listing verification items and parameter entities on both sides and then aligning them. This overcomes the problem in the prior art that it is impossible to determine the calculation logic between engineering parameters, and improves the coverage and verifiability of technical specification construction parameter verification.

[0037] See Figure 2 The method for verifying the rationality of construction parameters in building engineering technical specifications provided in one embodiment of the present invention includes steps S201 to S207.

[0038] Step S201: Parse the technical data to be verified, and convert the parsed text, table and graphic content into content blocks.

[0039] After receiving the technical bid documents to be verified, the computer equipment parses them one by one. The technical bid documents may include the main body of the technical bid prepared by the bidder, the construction organization design section, the schedule Gantt chart or network diagram, the labor plan, the machinery and equipment plan, the material arrival plan, the bill of quantities, the construction deployment diagram, the flow section division diagram, and special construction plans, etc. The specific types of documents included depend on the bidding requirements of the bidding project and do not affect the implementation of the embodiments of the present invention.

[0040] During parsing, the above data is read piece by piece and processed according to the form of its content: paragraphs and headings, and lists are read as text content; tables are read cell by cell to obtain table content; and data that expresses information graphically, such as Gantt charts, network diagrams, and construction deployment diagrams, extracts the parts containing text and relationships from the image to obtain graphical content. These three types of content are then segmented and encapsulated into content blocks. A content block is the smallest locatable unit obtained after heterogeneous data has been uniformly processed; a paragraph, a table cell, or a task bar on a Gantt chart can each constitute a content block.

[0041] Each content block records a content block identifier, text content, and its location information within the technical specification document. The content block identifier is used to distinguish each content block from another in subsequent processing, ensuring that each content block can be identified one-to-one. It can be an auto-incrementing sequence number, a string composed of the file number and the block's internal sequence number, or other forms that serve the same distinguishing function. The text content is the readable text contained within the content block; for example, the text content of a table cell is the text within that cell, and the text content of a task bar on a Gantt chart can be the name and date of that task. The location information records the content block's position within the original document, such as page number, page layout coordinates, character offset range, or table cell identifier. In addition to the above three items, the content block may further record its parent file's number, content type, style information, and original document checksum. These additional records are helpful for subsequent grouping and tracing, but are not essential to the embodiments of this invention.

[0042] The reason for grouping the three different types of content into content blocks first, instead of processing them separately in their original formats, is that subsequent parameter extraction and evidence backtracking require a unified working object: during extraction, there's no need to distinguish whether the number comes from the main text or a table; during backtracking, only the content block identifier needs to be used to retrieve location information. Through this process, the technical specification data is transformed from several documents with different formats into a set of content blocks with location records, becoming the common working template for subsequent steps.

[0043] Step S202: Identify the construction object based on the text content of the content block.

[0044] Once the content blocks are complete, the construction objects described in the technical specifications can be identified from their text content. Identification can be accomplished using engineering terminology dictionaries and naming rules. For example, when the text content contains descriptions consisting of sub-item names and work actions, such as steel structure hoisting, basement excavation, and roof waterproofing construction, it can be registered as a construction object. Alternatively, it can be determined by considering the chapter affiliation; work names located under the construction deployment or overall construction schedule chapters are more likely to be registered as construction objects.

[0045] The construction object is the basic unit upon which this method organizes parameters and verifies data. It can be a unit project, sub-project, construction section, flow section, construction procedure, or key node. It should be noted that although resource items in the technical specifications often appear alongside the aforementioned objects in a list format, in this embodiment of the invention, resource items are typically processed as parameters of the construction object—what is being verified is whether the number of tower cranes configured for a particular construction object is commensurate with its workload, rather than the tower cranes themselves. Of course, registering the resource item itself as a construction object and generating verification items based on it does not affect the implementation of this embodiment of the invention.

[0046] Once a construction object is identified, both subsequent processing lines in this method will be based on it: the verification item must point to a specific construction object, and the parameter entity must belong to a specific construction object; ultimately, the two are linked by the construction object. Because of this pivotal role, the granularity of the construction object identified in this step should be commensurate with the granularity of the technical specifications. Identification that is too coarse will result in parameters that shouldn't be calculated together being mixed under the same object name; identification that is too fine will cause parameters that should participate in the same rule to be placed under different objects.

[0047] Step S203: Generate verification items based on preset constraint rules and the construction object.

[0048] This step, along with step S204, constitutes two separate processing lines in this method, addressing what needs to be verified. By retrieving the preset constraint rules and combining them with the construction objects identified in step S202, verification items can be generated one by one. The preset constraint rules are the basis for this method to determine whether parameters are reasonable. Their sources can be national or industry quotas, enterprise resource allocation experience databases, parameter databases of similar historical projects, mandatory requirements in bidding documents, response requirements of scoring items, or thresholds configured separately by reviewers. The form in which constraint rules are stored, such as as rule tables, rule scripts, or rule templates, is not limited in this embodiment of the invention.

[0049] During generation, applicable constraint rules are matched based on the category of the construction object: for construction objects like steel structure hoisting, where hoisting volume and equipment capacity are key, constraint rules related to equipment configuration are matched; for construction objects where the construction period is key, constraint rules related to the rationality of the construction period are matched. Each match generates a validation item—the matched construction object becomes the construction object to which the validation item points, the matched rule becomes the applicable constraint rule, and the types of parameters that need to be taken in the formula of the rule constitute the parameter types required for the validation item, such as quantity of work, duration, and resource allocation. These three items are determined together in the same match and then circulate with the validation item, respectively indicating who it applies to, which types of parameters to take, and what to use to judge the rationality after calculation.

[0050] The form in which the verification item exists is also open. It can be a record in a database, an object in memory, or an instantiated rule. This embodiment of the invention does not require it to be a persistent ledger. It is particularly noteworthy that the generation of the verification item does not depend on the parameter values ​​in the technical specification—during generation, it is only necessary to know which types of parameters to use, without needing to know what these parameters are written as in the technical specification; even if parameter values ​​are read during generation, as long as the verification item itself does not change due to whether the technical specification specifies the parameter, it still belongs to the implementation of this embodiment of the invention. It is precisely this point that allows this step and step S204 to be performed independently of each other, and also ensures that the focus of the verification is not affected by what is actually written in the technical specification: if the technical specification omits a certain type of parameter, the verification item still exists, and thus the omission itself can be detected.

[0051] Step S204: Extract parameter entities from the content block and standardize the values ​​and units of the parameter entities.

[0052] The other processing line addresses what is actually written in the technical specification. It iterates through the content blocks obtained in step S201, extracting parameter entities from their text content. Extraction can be accomplished using named entity recognition, regular expression matching, table structure recognition, or by a constrained large language model extraction method. This method can be implemented regardless of the extraction method used.

[0053] The parameters described in technical specifications are often inconsistent. Phrases like "thirty calendar days," "approximately 1,200 tons," and "eight people per shift, two shifts" use a mix of units and colloquialisms, making direct calculation impossible. Therefore, after extraction, the numerical values ​​and units of the parameters must be standardized: numerically, Chinese numerals, approximate numbers, and range expressions are unified into operable numbers; in terms of units, different units of the same physical quantity are converted to default units, such as tons and kilograms, calendar days and working days; for resource quantities expressed in combination with shifts and number of people, they are converted into resource input quantities with a standardized caliber. After this processing, the originally inconsistent parameter expressions become quantities that can be directly used in calculations.

[0054] Each parameter entity includes a parameter type, the construction object to which it belongs, the standardized parameter value, and the identifier of the content block from which it originates. The parameter type indicates which category the parameter belongs to, and its value can be, for example, quantity of work, duration, resource allocation, or number of work surfaces. The construction object to which the parameter belongs links the parameter to a specific construction object identified in step S202, so that it can correspond to the verification item pointing to the same object in the future. The parameter value is the result after standardization. The identifier of the content block from which the parameter originates indicates which content block the parameter was extracted from. The parameter entity can also further record the parameter name, original unit, time interval, and extraction confidence level, etc. These records help to judge the reliability of the parameter during manual review, but are not necessary for the embodiments of this invention.

[0055] Of the four records, the source content block identifier deserves special mention. It ensures that the object traced back by this method is the number that participated in the calculation, rather than a passage of text that is literally similar to a certain keyword. It is precisely because the parameter is bound to its source during the extraction stage that the subsequent step S207 can accurately point the risk conclusion back to the location of that number in the technical specification.

[0056] Step S205: For the verification item, determine the target parameter entity from the parameter entity.

[0057] At this point, one side has the verification items, and the other side has the parameter entities; this step connects the two sides. Each verification item is retrieved, and a matching entity is searched among all parameter entities. The search is based on two conditions: the construction object to which the target parameter entity belongs is the same as the construction object pointed to by the verification item, and the parameter type of the target parameter entity is the parameter type required by the verification item. Parameter entities that meet both conditions are identified as the target parameter entities for that verification item.

[0058] The two conditions each serve different purposes. The condition that the construction object is the same prevents parameter mismatch across objects; the quantity of steel structure hoisting work will not be included in the calculation along with the duration of earthwork excavation. The condition that the parameter type belongs to the required parameter type ensures that each parameter is in its proper place: a verification item usually requires more than one type of parameter. For example, a verification item that calculates the number of equipment units based on the hoisting quantity and planned duration requires both quantity and duration parameters. For the machine to correctly place the extracted number into the formula, it must first know whether it is a quantity or a duration parameter.

[0059] The term "belonging to" here refers to the fact that the parameter type of a single parameter entity falls within the parameter types required by the validation item. It does not require that every required parameter type has a corresponding target parameter entity. Therefore, there can be one or more target parameter entities. The reason why completeness is not required is that the omission of a certain type of parameter in the technical specification is itself a situation that needs to be detected. If completeness of parameters were required to continue at this step, omissions would cause the validation item to stop processing without any prompt.

[0060] When multiple parameter entities are extracted under the same construction object and the same parameter type, and their values ​​are different, it is necessary to make a selection. The handling method for this situation will be discussed separately later.

[0061] Step S206: Substitute the parameter values ​​of each of the target parameter entities into the constraint rules applicable to the verification item for calculation, and generate a risk item when the calculation result does not meet the constraint rules.

[0062] Once the target parameter entities are determined, their respective parameter values ​​are extracted and substituted into the constraint rules applicable to the verification item for calculation. The calculation results are then checked against the criteria set by the constraint rules themselves. If the calculation results do not meet the constraint rules, a risk item is generated.

[0063] The key to this step is the common substitution. The parameter values ​​of each target parameter entity are entered into the same calculation, rather than being compared with each threshold individually. The implicit constraints between engineering parameters exist precisely in the interrelationships between them—looking at the lifting volume of a construction object alone, there seems to be nothing unreasonable, and the truck crane it is equipped with seems to conform to the standard configuration. However, if the lifting volume, planned duration, and equipment shift efficiency are calculated together, it will be found that this equipment cannot complete the lifting volume within the planned construction period. Comparing each threshold individually cannot detect this kind of problem because no single parameter exceeds the limit.

[0064] The generated risk item includes the construction object to which the verification item points, the calculation result, the benchmark value determined according to the constraint rule for comparison with the calculation result, and the content block identifier from which each target parameter entity originates. These four items answer three questions. What is calculated? The calculation result includes the calculated quantity used for direct comparison with the benchmark value and the derived evaluation index formed by the calculated quantity and the benchmark value. The calculated quantity and the benchmark value use the same dimension; the calculated quantity can be directly taken from the target parameter entity, or it can be obtained by aggregating and converting several parameter values ​​according to time windows or construction objects. Compared with what? The benchmark value is a reference quantity determined according to the constraint rule and using the same dimension as the calculated quantity. Its value can be, for example, the benchmark duration calculated based on the unit project capacity, the resource requirement calculated based on the consumption quota, the value of the same parameter written elsewhere in the technical bid, or the node value required by the tender documents. Whom does this conclusion apply to, and on what basis can it be reviewed? The construction object it points to indicates which work object this conclusion applies to, while the content block identifier from which each target parameter entity originates links the risk item with the source of the numbers that generated it, becoming a clue for subsequent location.

[0065] Therefore, the benchmark values ​​recorded in this method are not limited to the situation of demand versus supply. Inconsistencies in the same parameter in two chapters, or key milestones being later than the total project duration required by the tender, can all be expressed by comparing the corresponding benchmark values ​​with the calculation results. Thus, this method can not only verify whether the configuration is sufficient, but also verify whether it is consistent before and after, and whether it exceeds the mandatory requirements.

[0066] Step S207: Use the location information corresponding to each content block identifier in the risk item as the evidence location of the risk item, and output the risk item and its evidence location.

[0067] Extract the identifiers of each content block recorded in the risk item, locate the corresponding content block, read the location information recorded in step S201, and use this location information as the evidence location of the risk item. Then, output the risk item and its evidence location together. Since the content block identifier and location information are recorded in the same content block, the corresponding location information can be obtained by using the identifier, without the need to maintain a separate comparison relationship.

[0068] The granularity of evidence location depends on how the location information is recorded: when the location information is recorded at the page number, the evidence location points to a specific page; when recorded at the page coordinate frame, it points to a specific area on that page; when recorded at the table cell identifier, it can directly point to a specific cell in the resource plan table. Compared to copying entire sections of the original text into risk items, using location information for positioning has its unique advantages: the same text in a technical bid often appears repeatedly in multiple chapters, and copying the fragment cannot specify exactly where it is located, while the location information itself points to a definite location; spanning tables and drawing areas are also difficult to express with text fragments, but coordinate frames and cell identifiers can directly define them.

[0069] At this point, a risk conclusion and its source in the original technical document have been generated and output. The form in which the verification result is output—for example, as a verification report, sent to the technical document's chapter rewriting module via an interface, or pushed to a manual review dashboard—does not affect the implementation of this embodiment of the invention.

[0070] The main advantage of this embodiment lies in making the computational logic between engineering parameters a verifiable object. Parameters in technical specifications are originally scattered across three forms: text, tables, and graphics. Existing text checking tools treat the text itself as the object of processing, failing to consider numbers in the document as calculable quantities. Schedule planning software only receives structured task and date fields and cannot read commitments in the text and tables. Neither can detect situations where individual parameters are within limits but their interrelationships are invalid. This embodiment first unifies the content of the three forms into a locationable content block, allowing data scattered across different carriers to enter the same calculation. Then, the parameter values ​​of each target parameter entity are collectively substituted into the constraint rules applicable to the verification item. Since the implicit constraints between engineering parameters exist within their interrelationships, collective substitution makes these constraints calculable objects, thus overcoming the deficiency of existing technologies in determining the computational logic between engineering parameters.

[0071] Furthermore, the verification items are not lost due to the writing of the technical specifications. Since the verification items and parameter entities are generated separately on two separate processing lines, the side that should be verified is no longer constrained by what is actually written in the technical specifications. Compared with the existing technology that simply extracts parameters from the document and does not know what to compare them with, this embodiment can still retain the corresponding verification items when parameters are missing, and the situation where key parameters are omitted from the technical specifications can also be detected. Moreover, since both sides are ultimately matched according to the construction object and parameter type, the parameters participating in the same calculation must belong to the same construction object and each be in its type position, thus avoiding meaningless calculations caused by cross-object mismatch and parameter misalignment.

[0072] The effect also lies in the verifiability of the conclusions. The risk item records the source content block identifiers of the parameter entities involved in the calculation. Therefore, the object traced back in this embodiment is the operand itself, rather than a text fragment that is similar in wording to a certain keyword. Combined with location information, it can be accurate to the page coordinate frame and table cell. Based on this, the reviewer can directly turn to the location of the number in the technical specification for verification, thus improving the situation where manual verification relies on personal experience to repeatedly search through hundreds of pages of text. The above effects work together to make the verification of construction parameters in technical specifications, which originally relied on expert experience, have a machine-executable and verifiable implementation path.

[0073] The above description is only one embodiment of the present invention. Those skilled in the art can also achieve the above effects by making adjustments to the specific implementation of each step based on it.

[0074] It should be noted that in the above embodiments, steps S203 and S204 are on two separate processing lines, which are independent of each other. Their execution order can be interchanged, or the two steps can be executed simultaneously. The embodiments of the present invention do not limit the execution order of steps S203 and S204.

[0075] In the above embodiments, several judgment and generation actions can be performed by a large language model, with one or more steps being handled by the large language model. For example, the large language model can directly generate verification items based on bidding requirements and construction objects; it can extract parameter entities from the text content of content blocks; or it can make a reasonableness judgment on the parameter values ​​of target parameter entities based on constraint rules. When a certain step is implemented using a large language model, the processing methods of the other steps of this method remain unchanged. This embodiment of the invention does not limit which step is implemented using a large language model.

[0076] In the above embodiments, in addition to outputting the risk item and its evidence location, the verification result can also output the corresponding modification suggestions, risk level, or review status. The output carrier can be a verification report document, or structured data sent to the technical specification chapter rewriting module, manual review dashboard, or technical specification testing platform via an interface. Outputting the risk item and its evidence location is a processing step of this method; while maintaining this output content, the output carrier and specific presentation format can be determined according to the deployment environment.

[0077] The object of analysis in the aforementioned process refers to all received technical bid documents. However, in the actual bidding process, the tendering party often issues clarifications and addenda documents successively, and the bidder's own technical bid may be revised several times during the preparation period. Therefore, multiple copies of the same type of document often coexist. If these documents are analyzed indiscriminately, expired project milestones, outdated quantities, and obsolete construction plans will all be included as parameter entities in subsequent calculations, making it impossible to determine which version the calculated risk conclusion refers to. For this situation, see [link to relevant documentation]. Figure 3 Another embodiment of the present invention adds a determination of data validity before parsing, which includes steps S301 to S303.

[0078] Step S301: Obtain the release time and document type of each document in the technical specification document.

[0079] Read the attribute information of each technical bid document to obtain its publication time and document type. The publication time can be taken from the creation or modification time in the file attributes, or from the date field in the filename, the date of writing on the first page of the main text, or the registration time of receipt; if multiple times exist for the same document, the one that reflects the point when the document was issued should be used. The document type indicates the role of this document in the technical bid system, such as the main text of the technical bid, construction organization design, schedule plan, labor plan, machinery and equipment plan, or special construction plan. The document type can be determined based on keywords in the filename, the first page title, or characteristic fields appearing in the document—tables with columns for job type and number of workers are mostly labor plans.

[0080] In addition to the publication time and data type, file hash, version number, receipt time, data source, and professional category can also be registered to form a data ledger. The file hash is used to identify duplicate submissions with the same content but different filenames, while the version number and receipt time can be used as substitutes when the publication time is missing or obviously incorrect. The above-mentioned additional registration items help improve the accuracy of validity determination, but are not necessary for the embodiments of this invention.

[0081] Step S302: When there are multiple documents of the same type in the technical bid documents, the effective document shall be determined from the multiple documents according to the rule that the document with the later publication time covers the document with the earlier publication time.

[0082] Data is grouped by type. If there is only one data item in a group, that data item is considered valid. If there are multiple data items in a group, their publication times are compared, with the later publication time overriding the earlier one. The data item with the latest publication time is taken as the valid data item for that type. "Overriding" means that the overridden data item is no longer used as a parsing object, not that it is deleted from the data ledger—it remains in the ledger for future investigation into why a parameter was not used.

[0083] Using the order of publication as the basis for coverage is based on the fact that the preparation process of tender documents involves successive revisions: later versions have already incorporated previous content, and when multiple copies of the same type of document exist, the latest one represents the bidder's current true intention. Besides publication time, other criteria can be introduced for judgment, such as supplementary documents covering corresponding clauses of the tender document, manually confirmed versions taking precedence over unconfirmed versions, or, when publication times are the same, the version number with the higher number prevailing. The choice of which criterion(s) to use depends on the order in which the documents are submitted, and this embodiment of the invention does not impose any restrictions on this.

[0084] Step S303: Parse the effective data.

[0085] Once the effective data is determined, the parsing described in step S201 is performed on it, converting the parsed text, table, and graphic content into content blocks. Subsequent steps such as object identification, verification item generation, parameter extraction, alignment, calculation, and positioning are performed as described in the aforementioned embodiment and will not be repeated here. After this processing, the parameters used in subsequent calculations all originate from the currently effective version of the data.

[0086] This approach addresses the issue of data timeliness before parsing. Without this determination, the duration of the same construction task might be derived from different versions of the schedule, with one value extracted from the old version and another from the new version. These differing values ​​would be treated as parameter conflicts and generate a risk item in subsequent processing. However, this risk item is actually an illusion caused by version discrepancies, not a defect in the technical specification itself. Because this embodiment groups data by type and selects effective data before parsing, such false risks arising from version coexistence are avoided. Reviewers therefore no longer need to repeatedly check the data list to determine which version the risk item originates from.

[0087] The analysis described in step S201 is relatively straightforward for text and table content. However, for graphical representations of information such as schedule charts and network diagrams, the information is not contained within paragraphs or cells, but rather distributed through text labels on the elements and the lines connecting them. Therefore, the method for obtaining this information deserves separate explanation. See also... Figure 4 The graphic content can be obtained in the manner described in steps S2011 to S2012.

[0088] Step S2011: When the technical specification data includes schedule graphic data, extract the task name, node text, date, and connection relationship between tasks from the schedule graphic data.

[0089] First, determine if the document is a graphical schedule: Gantt charts typically have a timeline and rows of horizontal bars, while network diagrams usually have node boxes and arrowed lines, which can distinguish them from ordinary illustrations. After identifying it as a graphical schedule, extract four types of information from the diagram: Task names are taken from the text labels next to the bars or node boxes; node text is taken from the text at the milestone markers and critical path markers; dates are taken from the timeline scale and the corresponding scale values ​​at both ends of the bars; the scale values ​​corresponding to the start and end points of the bars on the Gantt chart are the planned start and end dates of the task; the connection relationship between tasks is taken from the direction of the arrows between nodes, with the arrow pointing from task A to task B, indicating that task B is contingent on the completion of task A.

[0090] When graphic data is provided in an editable vector format, the above four types of information can be directly read from the primitive attributes. When provided as scanned documents or bitmaps, image denoising, tilt correction, and layout detection are performed first, followed by text recognition to obtain the text portion and line detection to obtain the connecting portion. In addition to the above four types of information, the figure title, figure number, figure legend, and the page number position of the figure can also be extracted. This information is helpful in indicating which figure and which part a certain parameter comes from in the future, but it is not necessary for the embodiments of this invention.

[0091] Step S2012: The extracted task name, node text, date, and connection relationship are used as the graphic content.

[0092] After the four types of information are extracted, they are all treated as graphic content and processed in step S201 to be converted into content blocks. During the conversion, one task bar can correspond to one content block. Its text content consists of the task name and start and end dates, while the location information records the coordinate frame of the task bar on the drawing. The connection relationship between tasks can be recorded in the corresponding content block or saved separately as an association record between content blocks.

[0093] Because the graphic content is transformed into content blocks, the planned duration on the Gantt chart can be included in the subsequent extraction and calculation along with the duration commitment in the main text. This is crucial for this method: the duration data of the technical specifications is often written in one place in the main text and drawn in another place on the Gantt chart. Inconsistency between the two is a common compilation oversight. If the graphic data cannot be converted into calculable content, such inconsistencies will always be outside the scope of verification.

[0094] The granularity of the location information recorded in the content block can be determined according to the document format: location information includes at least one of the following in the technical specification: page number, page coordinate frame, character offset range, and table cell identifier. For main text paragraphs, page number and character offset range are sufficient for location; for table content, table cell identifiers are the most direct, precisely pointing to a specific row and column; for graphic data, page coordinate frame is preferable to allow the area containing the task bar to be circled on the drawing. Only one of these four granularities can be used, or several can be used together—when recording page number and coordinate frame simultaneously, it allows both navigating to the page and circling a specific area within that page.

[0095] The technical tender itself has a well-structured chapter structure, which can be used to narrow down the scope of the construction targets. Simply matching the engineering terminology dictionary with naming rules can easily lead to the inclusion of work names scattered throughout sections such as the project overview and tender commitments as construction targets. These names are often merely mentions, not the actual objects of construction deployment; this is more common in longer technical tenders. The above step S202 is elaborated as follows.

[0096] Step S2021: Based on the title number in the text content of the content block and the position information of the content block, determine the chapter hierarchy relationship between each content block to obtain a chapter tree.

[0097] Identify heading numbers from the text content of each content block, such as chapter number, time, circled numbers, or Chinese numerical serial numbers; then combine this with the content block's position information to determine its order and indentation within the document. A content block numbered like 3.2 is lower in level than and subordinate to the content block numbered 3; content blocks with later page numbers and deeper indentations are usually sub-items under the previous heading. Based on this, organize all content blocks into a chapter tree, where each node corresponds to a chapter, and the content blocks contained within that chapter are attached to the node.

[0098] In addition to title numbering and position information, font size hierarchy, table of contents anchor points, page number continuity, and keyword trigger words can also participate in hierarchy determination: titles with the same font size mostly belong to the same level; the table of contents at the beginning of the document itself gives the chapter hierarchy and page number correspondence; when a fixed chapter name such as construction deployment appears in the main text, it can be directly identified as a chapter node. Which criteria are used depends on the neatness of the technical subject's layout and does not affect the implementation of the embodiments of this invention.

[0099] Step S2022: Determine the target chapter from the chapter tree that matches the preset construction organization chapter name.

[0100] The pre-defined list of construction organization chapter names is used to define the scope of identification. Its contents include, for example, project overview, construction deployment, overall construction schedule, critical path, resource allocation plan, labor plan, major machinery and equipment plan, material supply plan, work sequence division, specialized construction plans, and overall site layout. The names of each node in the chapter tree are compared with this list; nodes with the same name or containing keywords from the list are the target chapters; sub-chapters under the target chapters are also included.

[0101] The reason for identifying the target chapters first is that the defining descriptions of the construction objects are concentrated in these chapters. Although chapters such as bidding commitments and company performance may mention the names of sub-items, those names do not include quantities, schedules, or resource allocations. Registering them as construction objects will only generate a batch of empty objects from which no parameters can be obtained. Subsequently, each empty object will generate a verification item, and each verification item will be counted as a missing critical parameter due to missing parameters, thus obscuring the real problem.

[0102] Step S2023: Identify the construction object based on the text content of the content blocks contained in the target chapter.

[0103] Within the content blocks contained in the target chapter, construction objects are identified in accordance with the method described in step S202 above. Since the identification scope has been narrowed, the granularity of the construction object can be further determined by the chapter name itself: names located under the section division chapter tend to be registered as construction sections or sections; names located under the overall construction schedule chapter tend to be registered as construction procedures or key nodes. Each identified construction object can also record its chapter, which can be directly used when determining the affiliation of parameter entities later.

[0104] By narrowing the scope, the identification results of the construction objects are consistent with the compilation structure of the technical specifications. Since the identification scope is narrowed down to the relevant chapters of construction organization, the names of tasks that are only mentioned but not deployed are no longer included in the list of construction objects, thus avoiding the generation of a batch of empty objects from which no parameters can be obtained; and since the chapter names themselves participate in the granularity judgment, the work objects at different levels in the same technical specifications can be classified according to their position in the chapter structure, thus alleviating the situation of overly coarse or overly fine identification mentioned in step S202 above.

[0105] The pre-defined constraint rules in the above embodiments serve directly as the basis for generating verification items. Their content comes from quotas, experience bases, and historical projects, and is a common component across projects. However, each bid has its specific requirements: the technical requirements in the tender documents often mandate specific timelines, equipment configurations, and material brands, while the scoring criteria indicate which parameters will be of particular interest to the evaluators. These requirements vary from project to project and cannot be pre-defined into general rules. Therefore, the generation of verification items must incorporate the specific provisions of this bid, as follows.

[0106] Step S2031: Obtain the tender documents corresponding to the technical bid information, and extract at least one of the technical requirements and scoring criteria from the tender documents to obtain the verification requirements.

[0107] The bidding documents for computer equipment must be obtained in accordance with the requirements of this tender. It should be noted that the bidding documents, clarifications, and addenda are all issued by the tendering party and are not the technical bid documents prepared by the bidders. In this method, they belong to different sources, and obtaining the bidding documents is therefore a separate action, not a selection from the technical bid documents. The correspondence between the bidding documents can be determined based on the tender project number, the bidding project name, or as designated by the reviewer.

[0108] After obtaining the tender documents, extract the technical requirements and scoring criteria. Technical requirements are typically found in the technical specifications and construction requirements sections, and their content includes, for example, requirements that the total construction period should not exceed a certain number of calendar days, that key milestones should be completed before a certain date, that a minimum number of tower cranes should be deployed, and that the main structure concrete should reach a certain strength grade. Scoring criteria are typically found in the scoring tables within the evaluation methods section, and their content includes, for example, the rationality of the construction schedule and the feasibility of resource allocation. During extraction, either one or both can be selected—if the tender documents do not specify scoring criteria, only the technical requirements can be selected, and subsequent processing can still be completed. The extracted content constitutes the verification requirements.

[0109] Step S2032: Generate verification items based on the verification requirements, the preset constraint rules, and the construction object.

[0110] The generation process is based on three factors: the construction object determines which verification item pertains to, the pre-defined constraint rules provide a universally applicable basis for judgment across projects, and the verification requirements incorporate the specific provisions of this tender. This incorporation can be supplementary, for example, if the tender document specifies a node not covered in the general rules, a new verification item with that node as the benchmark value can be added; it can also be a substitution, for example, if the general rules provide a lenient threshold for the time reduction rate, but the tender document has stricter provisions for that item, then the provisions in the tender document shall prevail; or it can be weighted, for example, parameters with higher scores in the scoring criteria will have their corresponding verification items assigned higher weights in subsequent risk grading.

[0111] Therefore, the same construction object will generate different verification items in different projects: for example, for steel structure hoisting, the verification items generated in projects where the construction period accounts for a high percentage of the score will focus on the reasonableness of the construction period, while in projects with mandatory equipment configuration requirements, the focus will be on whether the number of equipment units meets the standards. The focus of verification thus shifts with the evaluation focus of this bid, so that the verification results are commensurate with the actual gains and losses of this bid, rather than applying the same checklist to all projects.

[0112] In the aforementioned embodiments, the verification item refers to a single construction object, and the parameters participating in the same calculation also belong to that object. There is another type of implicit constraint in the technical specifications that spans two construction objects: whether the overlap time between preceding and following processes is sufficient, whether the cycle time between adjacent work sections matches, and whether resource conflicts occur when two parallel construction objects share a tower crane. This type of constraint cannot be calculated under a single object name because both sides of the formula come from two separate objects. See also... Figure 5 In response to this situation, another embodiment of the present invention includes steps S501 to S503.

[0113] Step S501: Determine the temporal dependencies and resource occupancy relationships between the construction objects based on the text content of the content block.

[0114] Identify two types of relationships between construction objects from the text content of the content blocks. Temporal dependencies indicate the sequence and connection of two objects in time. This can be identified through statements in the text, such as sentences like "The upper steel structure will be hoisted after the basement roof concrete reaches its design strength," indicating that the latter depends on the former. Alternatively, it can be identified through the connections extracted in step S2011; an arrow pointing from object A to object B on the network diagram represents a temporal dependency. Resource occupancy relationships indicate the shared need for the same resource between two objects. This is identified when their resource plans include the same equipment number, the same work team, or the same site.

[0115] Both types of relationships can also have attributes: time-series dependencies can record the required technical interval time, and resource occupancy dependencies can record the name and quantity of the resources occupied. These attributes can serve as the source of benchmark values ​​when generating validation items later.

[0116] Step S502: Construct a parameter relationship graph with each construction object as a node and the temporal dependency relationship and the resource occupation relationship as edges.

[0117] Treat each construction object as a node, and each relationship determined in the previous step as an edge connecting the corresponding two nodes, thus constructing a parametric relationship graph. The edges in the graph can be distinguished by type: edges formed by temporal dependencies record the order in which they point, and edges formed by resource occupancy relationships record the shared resources; when two types of relationships exist between two objects, two edges can coexist, or they can be combined into one edge with dual attributes.

[0118] Organizing these relationships in the form of a graph has the advantage of making cross-object constraints enumerable: traversing each edge in the graph yields a pair of construction objects that need to be verified together, eliminating the need to repeatedly search the text for possible relationships between objects. The graph can also further record rule edges to indicate whether the constraint rules applicable to a particular edge originate from quotas, bidding requirements, or historical project samples; however, this layer of recording is not essential to the embodiments of this invention.

[0119] Step S503: Merge two construction objects connected by edges in the parameter relationship graph into a combined construction object. Generate a verification item according to the preset constraint rules and the combined construction object. The construction object pointed to by the verification item is the combined construction object.

[0120] Traverse each edge in the parameter relationship graph and merge the two construction objects connected by that edge into a combined construction object. Merging does not change the original two construction objects themselves; they still exist independently and participate in the verification process referred to as a single object in the aforementioned embodiments. The combined construction object is a newly added verification unit used to bear cross-object constraints. Subsequently, verification items are generated using this combined construction object as a reference, following the method described in step S203. The required parameter types for the generated verification items are taken from the constraint rules corresponding to the edge. For example, the verification item corresponding to a time-dependent edge requires the planned start and end dates and technical intervals of both objects.

[0121] The introduction of combined construction objects is to allow cross-object verification to utilize the existing alignment and calculation mechanisms of the aforementioned embodiments. A combined construction object records the identifiers of two member construction objects connected by an edge, as well as the role of each member construction object within that edge. In step S205, when performing parameter alignment for the combined construction object, parameter entities of the required parameter types under the member construction object are mapped to the combined construction object, and the identifiers and roles of the original member construction objects are retained in the mapped parameter entities. Thus, the construction object to which the resulting target parameter entity belongs is the combined construction object, satisfying the condition in step S205 that the construction object to which the target parameter entity belongs is the same as the construction object pointed to by the verification item. The parameter entities of the two member construction objects can therefore participate in the same calculation in step S206, and the preceding and following processes can be distinguished based on the retained roles, ensuring that the completion date of the preceding process and the start date of the following process are located in the corresponding positions of the formula.

[0122] The value of this approach lies in bringing implicit constraints across objects into the computable scope. Even if each construction object in the aforementioned embodiments is verified individually, the overlaps and resource conflicts between two objects still cannot be detected because such problems are not reflected in the parameters of any single object. However, by extracting related objects in pairs and merging them into combined construction objects through the parameter relationship graph, these constraints and single-object constraints are processed along the same path, and the mechanism of common substitution can be directly used.

[0123] The extraction of parameter entities is explained in step S204 using named entity recognition and regular expression matching as an example. The writing format of parameters in technical specifications is quite scattered, and it is difficult to obtain all of them by relying on only one or two methods. Furthermore, the extracted parameters must be accurately assigned to the corresponding construction object names; otherwise, incorrect attribution will occur during subsequent alignment.

[0124] Multiple extraction methods can be used in combination. Named entity recognition is used to extract combinations of parameter names and values ​​from continuous text, suitable for handling narrative expressions in the main text; regular expression matching is used to extract quantities with fixed writing formats, such as numbers with units, date ranges, and percentages; table structure recognition is used to handle situations where parameters are expressed in row-column relationships, first determining the parameter type of each column by the table header, and then extracting values ​​row by row, thus corresponding the job type column and the number of people column in a labor plan table; cross-paragraph reference resolution is used to handle expressions such as the construction period of a sub-project being a certain value, where pronouns refer back to the preceding object; synonym normalization and engineering terminology dictionaries are used to unify synonymous expressions such as calendar days and natural days, concrete and concrete, under the same terminology; in addition, extraction can also be undertaken by a constrained large language model, that is, given a list of parameter types to be extracted and an output format, the model directly returns structured parameter records from the text content of the content block. The above methods can be used individually, or several can be used together and their intersection or union taken. The combination used does not affect the implementation of the embodiments of the present invention.

[0125] The construction object to which the parameter entity belongs can be determined not only by the context at the time of extraction, but also in the following ways.

[0126] Step S2041: Determine the construction object to which the parameter entity belongs based on the chapter path relationship between the content block from which the parameter entity originates and the content block of the identified construction object.

[0127] The content block from which the parameter entity originates and the content block identifying a construction object each have their own position in the document's chapter structure. The path from the root node to their respective nodes constitutes their chapter paths. These two chapter paths can be derived from the chapter tree obtained in step S2021, or, if a chapter tree has not been constructed, directly from the title number hierarchy string in the text content of each content block, or from the hierarchy sequence given in the document outline. Both methods can be used for subsequent path overlap comparisons. The overlap between two chapter paths is compared as follows: if the content block containing the parameter is located below the chapter containing a construction object, the parameter belongs to that construction object; if the content block containing the parameter has no affiliation with any of the chapters containing multiple construction objects, the chapter path with the highest overlap is selected. For example, if the construction object of steel structure hoisting is identified from a subsection under the construction deployment chapter, and a hoisting quantity value appears in a table within the same subsection, their chapter paths overlap to that subsection, and the hoisting quantity belongs to steel structure hoisting.

[0128] The rationale for determining attribution based on chapter-based path relationships is that the technical specifications are organized by chapter: texts, tables, and drawings describing the same construction object are usually arranged in adjacent positions, making the proximity of chapters a reliable clue to object attribution. Besides chapter-based path relationships, attribution can also be determined based on semantic similarity, keyword overlap, overlapping time intervals, or the degree of page proximity between evidence blocks. These criteria can be used individually or in combination, and this embodiment of the invention does not limit their application.

[0129] Therefore, attribution determination has gained a way that does not rely on the written description of parameters. The tables in the technical bid often only indicate the project to which they belong in the header, and each row of the table body only lists the parameter values. The object names are not repeated in the rows. It is impossible to determine which value belongs to based on the context at the time of extraction. However, by using the chapter path relationship, the content block of each row of the table body can be attached to the corresponding construction object name through its chapter position. Therefore, the parameters in the table will not be discarded due to the lack of object names.

[0130] Step S205 maps the verification item side to the parameter entity side based on two conditions: construction object and parameter type. Regarding alignment itself, the available criteria are not limited to construction object: alignment can also be based on chapter paths, grouping verification items and parameter entities within the same chapter; alternatively, the semantic similarity, keyword overlap, time interval overlap, or page proximity listed in step S2041 can be used as criteria to group verification items and parameter entities with similar semantics, overlapping keywords, overlapping time periods, or page proximity. All of the above criteria can be used to achieve the mapping between the two sides, and this embodiment of the invention does not limit this.

[0131] Among these bases, using the construction object as the alignment key has a unique role in this method, which deserves further explanation.

[0132] The most direct benefit is that the organizational dimensions on both sides are thus aligned. The verification items are generated in step S203 based on the construction object; which object a verification item targets is determined during generation. If chapter path alignment were used instead, parameters under the same chapter would be obtained, but the verification items are not generated by chapter, and both sides would be organized according to different dimensions, making it impossible to establish a correspondence. The construction object, however, is a shared dimension on both sides. The parameter entity has already recorded its associated construction object in step S204, and the verification item also records the construction object it points to; this shared dimension allows for direct alignment.

[0133] The more fundamental reason lies in the fact that the engineering rules themselves apply to the construction objects. Judgments such as unit project quantity capacity, unit project quantity consumption quotas, and experience thresholds are all given for a specific type of construction operation—steel structure hoisting has its hoisting efficiency, earthwork excavation has its excavation and transportation capacity. Without considering the construction object, it's impossible to determine which quota value to use. Therefore, even if other criteria are used to achieve alignment, the calculation still requires revisiting which construction object these parameters belong to in order to obtain the corresponding rule parameters.

[0134] Another layer lies in the fact that the parameters that need to be calculated together are often not similar in wording. The amount of work and the duration used in the same calculation, one measured in tons or cubic meters and the other in calendar days, have very different names and expressions. Aligning them by semantic similarity or keyword overlap will separate them and group similar parameters of different objects together; their real commonality is that they belong to the same construction object. As for time interval alignment, it is only effective for parameters with time attributes. The amount of work and the amount of resource allocation do not have start and end times that can be compared. The proximity of evidence blocks depends on the layout. When the parameters of the same object are in the main text and in the table appendix, they are not close to each other on the page.

[0135] Therefore, this method uses the construction object as the alignment key and the parameter type as the second condition to ensure that each parameter is properly positioned in the formula. The other five criteria mentioned above are still useful in this method, but at a different stage—they are more suitable for determining the attribution of parameter entities, i.e., the situation described in step S2041 above, where the determination is made as to which object a parameter belongs to, rather than which check item a parameter matches.

[0136] When multiple parameter entities are extracted under the same construction object and parameter type, and their values ​​are all different, one needs to be selected. The selection of multiple values ​​of the same type can be carried out according to the following rules.

[0137] Step S2051: When there are at least two parameter entities whose respective construction objects are the same as the construction objects pointed to by the verification item, have the same parameter type, and whose parameter type belongs to the parameter type required by the verification item, and whose parameter values ​​are different, select one parameter entity from the at least two parameter entities according to the rule that content blocks from the table content take precedence over content blocks from the text content.

[0138] First, group the parameter entities according to the construction object and parameter type. If there are two or more parameter entities in the same group with different values, a value conflict occurs. In this case, the selection is made based on the content format of the content block from which each parameter entity originates: content blocks from table content take precedence over content blocks from text content. For example, if the duration of a construction object is written as approximately thirty days in the main text but as twenty-eight calendar days in the construction schedule table, the two values ​​are different, so the twenty-eight calendar days from the schedule table is selected.

[0139] Prioritizing tables is based on the conventions of technical specification compilation: the descriptions in the main text are mostly general descriptions, and they are often written first and not modified synchronously with plan adjustments; tables are the formal carriers of plan data, and they are used as the standard for compilation and review. Moreover, the values ​​in tables are constrained by row and column relationships, resulting in a higher degree of self-consistency.

[0140] In addition to content format, other priority rules can be introduced for selection: values ​​from construction plan documents take precedence over values ​​from other documents; bid commitments made in the main text take precedence over estimated values ​​in attachments; when combined with the aforementioned processing that uses effective documents as the parsing object, newer versions take precedence; when parameter entities record extraction confidence levels, those with higher confidence levels take precedence. These rules can be used individually or applied sequentially—first comparing content format, then comparing document types if the formats are the same, and finally comparing confidence levels if they are still the same. The choice of which rules to use and their order of application does not affect the implementation of this invention.

[0141] Step S2052: Select the chosen parameter entity as the target parameter entity.

[0142] The selected parameter entities are used as the target parameter entities for the verification item and are included in subsequent calculations. Parameter entities that are not selected in the same group are not used as the target parameter entities for the verification item, but are still included in the list of parameter entities. Their values ​​and sources can be recorded in the value conflict record for reviewers to see which places are inconsistent in the writing.

[0143] It should be noted that this step deals with value conflicts within the same parameter type, rather than cross-type selection. The simultaneous determination of the quantity and duration of work under the same construction object name as the target parameter entity is the normal state required by step S205 and does not constitute the conflict situation described in this step—the situation where one is chosen according to the above rules generally occurs between parameter entities of the same type but different values.

[0144] The aforementioned selection rules serve two purposes. Firstly, they ensure that the parameter values ​​used in the calculation are definite: if multiple values ​​of the same type are substituted without selection, the same verification item will yield multiple contradictory results due to different combinations of values, making it impossible to determine the risk. Secondly, the unselected parameter entities and their values ​​are retained, and the inconsistency in the wording of the same parameter across different parts of the technical specification becomes a verifiable record—such inconsistencies often stem from oversights in the technical specification preparation process. Their value lies not in which value is correct, but in reminding reviewers that consistency is needed in that area.

[0145] The calculations described in step S206 vary depending on the applicable constraint rules. The following describes two types of calculations: whether the construction period is excessively compressed, and whether resource allocation can support the corresponding workload. Both types of calculations share the same calculation framework: first, a baseline quantity is calculated from the parameter values ​​of the workload type and the preset quota or production capacity; then, the dimensionless parameter values ​​actually specified in the technical specifications are compared with this baseline quantity, and derived evaluation indicators are formed based on the two; this baseline quantity is the baseline value described in step S206. The calculation framework is the same, but the parameter types, quotas used, and the meanings of the derived evaluation indicators differ between the two.

[0146] Whether the construction period has been excessively compressed can be calculated as follows.

[0147] Step S2061: Substitute the parameter values ​​of the target parameter entity of the quantity of work and the unit quantity of work corresponding to the construction object into the constraint rules applicable to the verification item, and calculate the baseline duration of the construction object.

[0148] Take the parameter values ​​of the target parameter entities under the project quantity type of the construction object, such as the tonnage of steel structure hoisting or the volume of earthwork excavation; then take the unit project quantity capacity corresponding to the construction object, that is, the amount of work that can be completed per unit time. This value can come from national or industry quotas or from the company's historical project statistics. Divide the project quantity by the unit project quantity capacity to obtain the time required to complete the project under normal organizational conditions, which is the baseline duration.

[0149] The unit project capacity can be determined by the category of the construction object, or it can be determined by further distinguishing the working conditions—for example, the capacity of high-altitude operation and ground assembly differs even for steel structure hoisting, and the capacity also differs depending on the weight of the individual components. Whether to make this distinction in capacity value depends on the level of detail of the quota on which it is based, and does not affect the implementation of the embodiments of the present invention.

[0150] Step S2062: Calculate the construction period compression rate of the construction object based on the ratio of the parameter value of the target parameter entity of the duration type to the baseline duration.

[0151] The parameter value of the target parameter entity of the duration type under the name of the construction object is taken, that is, the planned duration arranged for the construction object in the technical bid, and the benchmark duration is used as the benchmark value for direct comparison. Both adopt the dimension of duration. The schedule compression rate is calculated by dividing the difference between the benchmark duration and the planned duration by the benchmark duration. The shorter the planned duration, the higher the schedule compression rate, indicating that the schedule arrangement of the construction object is more likely to exceed the extent that it can be completed under normal organizational conditions. The calculation results here include the planned duration used for direct comparison with the benchmark value and the schedule compression rate formed by the two. Criteria set in the constraint rules, such as the schedule compression rate not exceeding a certain threshold, generate a risk item if the schedule compression rate exceeds the threshold.

[0152] In addition to the above expressions, the degree of deviation from the schedule can also be represented by the normalized result that is consistent with the direction of the schedule compression rate. When other expressions are used, the calculation formula and judgment threshold should be determined in the corresponding constraint rules to keep the calculation scope consistent under the same constraint rules.

[0153] Building upon this, more detailed schedule calculations can be introduced: based on the dependencies between work processes and technical downtime, a topological sort is performed to estimate the earliest and latest start and completion times for each construction item. This identifies situations where a preceding process has not been completed but a subsequent process has already begun, key milestones are later than the overall schedule requirement, and the sum of the durations of all sub-items exceeds the total schedule. This type of calculation still deals with durations and dates, and belongs to the same schedule category as the two steps mentioned above, so it can be performed together in the same verification item.

[0154] Whether the resource allocation can support the corresponding workload shall be calculated in the following manner.

[0155] Step S2063: Substitute the parameter values ​​of the target parameter entity of the quantity of work, the unit quantity consumption quota of the target resource type corresponding to the construction object, and the parameter values ​​of the target parameter entity of the duration type into the constraint rules applicable to the verification item, and calculate the resource demand of the construction object for the target resource type within the set time window.

[0156] Three quantities are required here: the parameter value of the quantity type, which gives the total amount; the unit quantity consumption quota of the target resource type corresponding to the construction object, which gives the quantity of that type of resource required to complete one unit quantity of work (e.g., labor, tower crane, truck crane, welding machine, or temporary materials); and the parameter value of the duration type, which gives the time frame for completing the work. Multiplying the quantity by the consumption quota gives the total resource input required for the construction object, and dividing by the duration gives the quantity of resources required per unit time, which is the resource demand for that target resource type within the set time window.

[0157] The time window is defined as the statistical interval for resource demand, and its length can be a shift, a day, a week, or a construction phase. A window that is too long will dilute peak demand, while a window that is too short will render the demand meaningless due to schedule fluctuations. Shift coefficients and peak value coefficients can also be introduced into the calculation: the former is used to convert two-shift or three-shift work arrangements into a uniform input, and the latter is used to reflect situations where the construction intensity is higher than the average level within a certain period. Whether or not these two coefficients are introduced does not affect the implementation of this embodiment of the invention.

[0158] Step S2064: Calculate the resource satisfaction of the construction object with the target resource type based on the ratio of the parameter value of the target parameter entity of the resource configuration type of the target resource type to the resource demand.

[0159] Take the parameter value of the target parameter entity of the resource allocation type under the name of the construction object, that is, the quantity of this type of resource allocated for the construction object in the resource plan of the technical target, such as the number of team members listed in the labor plan table or the number of equipment units listed in the machinery and equipment plan table. Use this resource allocation quantity as the calculation quantity for direct comparison with the benchmark value, and use the resource demand quantity of the same dimension calculated in the previous step as the benchmark value. At the same time, calculate the resource satisfaction degree according to the ratio of the resource allocation quantity to the resource demand quantity. When the resource satisfaction degree is less than one, it indicates that the allocated resources are insufficient to support the completion of the project within the planned period. The calculation result here includes the resource allocation quantity and the resource satisfaction degree.

[0160] For different categories of resources, specific accounting criteria can be added beyond the aforementioned framework: for machinery and equipment, in addition to the number of units, the lifting weight, coverage radius, and vertical transportation capacity can be calculated to determine whether they match the working conditions of the construction object; for materials and turnover tools, supply delays can be calculated based on construction rhythm, arrival batches, and inventory cycles; for sites and work areas, the number of objects under concurrent construction can be calculated to determine whether it exceeds the available work area. These calculations each have their own parameters and criteria, but they can all be categorized into the form of comparing the configuration quantity with the demand quantity described in this step.

[0161] The two calculations above each have their own focus. The role of the duration calculation is that duration compression is often a commitment made in the technical bid to meet the tenderer's schedule requirements. Its unreasonableness is not reflected in any single value—the reported total duration is within the tender requirements, and the durations of each item are also common values. It only becomes apparent when the workload and production capacity are calculated together. Through the intermediate quantity of the baseline duration, the feasibility of such commitments can be quantified. The role of the resources calculation is that insufficient resource allocation usually stems from different personnel compiling different chapters of the technical bid—the workload comes from the quantity surveyor, and the resource plan comes from the equipment manager, lacking verification between the two. Through the intermediate quantity of resource demand, the matching relationship between allocation and workload can be revealed. Both calculations share the same framework, so they can be carried out by the same calculation process. It is only necessary to select the appropriate parameter type and quota according to the constraint rules applicable to the verification item.

[0162] The risk items output in the above embodiments are not differentiated in severity. A technical tender of several hundred pages, after full verification, can generate dozens or even hundreds of risk items, ranging from minor deviations such as a time reduction rate only slightly exceeding the threshold to issues such as missing key equipment that could affect the bid. In situations where review time is limited, it is necessary to prioritize the risk items, and therefore this method can further include steps S208 to S210.

[0163] Step S208: Determine the parameter deviation strength of the construction object based on the calculation results.

[0164] Take the calculation results obtained in step S206 and determine the parameter deviation intensity based on the degree of deviation from the constraint rule criteria. The greater the time reduction rate exceeds the threshold and the greater the resource satisfaction rate falls below one, the greater the deviation intensity. The deviation intensity can be taken as the ratio of the difference between the directly compared dimensional calculation quantity and the benchmark value to the benchmark value, or it can be taken as a level value according to a predefined interval based on derived evaluation indicators such as time reduction rate and resource satisfaction rate, or it can be given by the deviation function inherent in the constraint rule. When multiple verification items under the same construction object have calculated results, the largest deviation intensity can be taken, or the value can be taken after weighting according to the importance of each verification item.

[0165] Step S209: Filter out parameter types that do not correspond to target parameter entities from the parameter types required for the verification item, and determine the degree of missing key parameters of the construction object based on the filtered parameter types.

[0166] Examine each verification item corresponding to the construction object one by one, comparing the required parameter types with the parameter types of the actual determined target parameter entities. Any parameter type for which there is no corresponding target parameter entity is considered a missing parameter type. Determine the degree of missing critical parameters based on the selected parameter types: the more missing types and the more critical the missing type is in the verification item, the higher the degree of missing. Missing a single quantity of work often makes the entire verification impossible, and its weight is higher than missing a single work surface.

[0167] The reason for including missing parameters in the risk assessment is that omitting key parameters and writing incorrect key parameters are both compilation defects, and the former may not have a lighter consequence in the evaluation process—the evaluator cannot see the configuration quantity of a certain resource, which may be more detrimental to the judgment of the completeness of the response than seeing an unreasonable quantity. Because step S205 does not require all required parameter types to be complete before proceeding, the missing type can be identified and included in the risk assessment here, rather than stopping processing in the alignment stage even if the verification item is not prompted. For verification items with complete parameters, the rule calculation in step S206 continues; for verification items lacking the parameters necessary to perform the rule calculation, a key parameter missing risk item is directly formed, and this risk item serves as the carrier for subsequent risk classification, without forcibly generating a numerical calculation result.

[0168] Step S210: The weighted sum of the parameter deviation intensity and the degree of missing key parameters is calculated to obtain the comprehensive risk value of the construction object, and the risk level of the risk item is determined based on the comprehensive risk value.

[0169] For risk items with pre-defined numerical calculation results, weights are assigned to both the strength of parameter deviation and the degree of missing key parameters. These are then weighted and summed to obtain the comprehensive risk value for the construction object. For risk items directly resulting from the lack of necessary parameters for calculation, the strength of parameter deviation is marked as inapplicable, and the comprehensive risk value is obtained based on the degree of missing key parameters and their weights. Subsequently, the comprehensive risk value is mapped to a risk level according to a pre-defined interval. Risk levels can be divided into high, medium, and low, or a separate level requiring manual review can be set for situations where the comprehensive risk value falls near the criterion boundary. The weight values ​​reflect the focus of the verification: increasing the weight of deviation strength when emphasizing the discovery of unreasonable values, and increasing the weight of the degree of missing parameters when emphasizing the examination of response completeness; combined with the aforementioned processing of verification items generated based on the tender documents, verification items corresponding to parameters with higher scores in the scoring criteria can also receive additional weighting during the weighting process.

[0170] In addition to the two items mentioned above, the comprehensive risk value can also incorporate more factors for weighting, such as the intensity of conflict across chapters for the same parameter, the overall confidence level of parameter extraction and evidence matching, whether the risk item triggers the mandatory requirements of the bidding documents, and the scope of its impact involving several construction projects. Which factors are included and their respective weights depend on the focus of the review, and this embodiment of the invention does not limit this.

[0171] Once the risk level is determined, the output process is adjusted accordingly: the output of the risk item and its evidence location includes the output of the risk item, its risk level, and the location of the evidence for that risk item. Reviewers can then process these items sequentially from highest to lowest risk level, prioritizing issues with greater impact when time is limited. The risk level itself does not change the judgment result of any single risk item; it establishes the processing order among the determined risk items, ensuring a workable processing sequence for the large number of conclusions generated from full-scale verification.

[0172] After the risk items and their evidence locations are output, the accuracy of the parameters upon which they are based has not yet been verified. Errors may occur in the parameter extraction process: text recognition in scanned documents may misread numbers, parsing cross-page tables may result in misaligned rows, and dates on adjacent task bars in a Gantt chart may be misplaced. If extraction is flawed, the calculated risk items will be unsubstantiated, and if reviewers cannot find the corresponding values ​​when they flip to the evidence location, their trust in the entire verification result will be affected. Therefore, this method can further include steps S211 to S213.

[0173] Step S211: Determine whether the content at the evidence location is consistent with the target parameter entity corresponding to the evidence location.

[0174] Returning to the original text indicated by the evidence, read its content and compare it with the target parameter entity that generated the risk item to determine if they are consistent. Consistency can be determined by numerical equality, the presence of the parameter value in the content, or by allowing a certain tolerance—whether it's considered consistent if the original text states 1200 tons while the parameter entity records 1205 tons depends on the set tolerance. The strictness of the criterion can be set according to the parameter type: date-related parameters should be strictly equal, while minor differences due to rounding can be tolerated for quantity-related parameters.

[0175] Step S212: When there is inconsistency and the content at the evidence location contains a value corresponding to the parameter type of the target parameter entity, the target parameter entity is re-extracted and standardized. The parameter value obtained after re-standardization is substituted into the constraint rule applicable to the verification item and the calculation is performed again. If the calculation result obtained again does not meet the constraint rule, the risk item and the evidence location of the risk item are regenerated and output.

[0176] If the comparison is inconsistent, but a value matching the parameter type does exist at the evidence location, it indicates that a usable parameter existed at that location, but was previously extracted incorrectly. In this case, the target parameter entity is re-extracted and standardized—during re-extraction, the identification parameters can be adjusted, such as using a table parsing method more suitable for the layout, expanding the keyword matching range, calling adjacent content blocks for auxiliary judgment, or recalculating unit conversions. After obtaining the re-standardized parameter value, it is substituted into the constraint rules applicable to this verification item and the calculation is performed again; if the calculation result still does not meet the constraint rules, the risk item and its evidence location are regenerated and output based on the new parameter value.

[0177] It should be noted that the parameter values ​​should be updated during the re-extraction; otherwise, repeating the same calculation with the same input will inevitably result in the same outcome, leading to an invalid, repetitive calculation loop. Because this step redoes not only the calculation but also corrects the parameter values ​​beforehand, this loop is convergent: if the corrected parameters cause the calculation result to satisfy the constraint rules, the risk item is eliminated and no longer output.

[0178] Step S213: When there is inconsistency and the content at the evidence location does not contain a value corresponding to the parameter type of the target parameter entity, mark the risk item as pending manual confirmation and output it.

[0179] If the comparison is inconsistent, and there is no value matching the parameter type at the evidence location, the problem lies not in the accuracy of the extraction, but in the location itself or the original text description, which exceeds the capabilities of automatic processing—for example, the value is embedded in the text as an image, or written across multiple pages. In this case, automatic retry is not performed; instead, the risk item is marked for manual confirmation before output. It should be noted that this step involves marking and outputting the item; how the marked item is manually reviewed is not part of this method.

[0180] In cases other than the two branches mentioned above, i.e. when the comparison results are consistent, the risk item will be output as usual according to the aforementioned embodiment, without any further processing.

[0181] Compared to the aforementioned embodiments that directly output risk items, the added layer here prevents errors in the extraction process from occurring before output. The judgment is based precisely on the evidence location already recorded by the method itself—because the risk item records the content block identifier from which the parameter entity that generated it originates, it's possible to return to the exact location in the original text to verify the number. If the source object is merely a passage of text similar to the keyword, this verification would be impossible. After this processing, the output risk items are divided into three categories: those that match the verification, those that have been corrected and recalculated, and those requiring manual confirmation. The first two categories have eliminated the possibility of extraction errors, and the reviewers can directly accept their conclusions.

[0182] The output risk items indicate where things are unreasonable, but do not specify how to modify them. The reviewer still needs to determine which item to adjust and by how much, and the quantities required for this determination have already been generated during the calculation process. Therefore, this method can further include steps S214 to S215.

[0183] Step S214: Determine the parameter type to be adjusted from the parameter types of each of the target parameter entities.

[0184] Among the parameter types of each target parameter entity in this verification item, select one as the parameter type to be adjusted. The selection can be based on the adjustability of the parameter in the technical bid preparation: the quantity of work is taken from the drawings and is usually not arbitrarily changed; the duration and resource allocation are related to the construction organization and have more room for adjustment. Therefore, for risk items related to schedule compression, the parameter type to be adjusted can be the duration; for risk items related to insufficient resources, the resource allocation type can be selected. The same risk item can also provide two or more parameter types to be adjusted, each corresponding to a different rectification path—extending the schedule and adding equipment can both make the resource satisfaction standard meet the requirements, and the two can be given side by side, with the reviewer choosing one.

[0185] Step S215: Based on the difference between the dimensional calculation quantity used for direct comparison with the benchmark value in the calculation result and the benchmark value, determine the adjustment amount of the parameter type to be adjusted, and obtain a modification suggestion including the parameter type to be adjusted and the adjustment amount.

[0186] The adjustment amount is calculated based on the difference between the unitary calculated quantity used for direct comparison in the calculation results and the benchmark value: when the resource allocation quantity is one unit and the benchmark value (i.e., the resource requirement) is two units, the difference is one unit; if the parameter type to be adjusted is a resource allocation type, the adjustment amount is to add one unit; if the parameter type to be adjusted is a duration, the feasible duration is calculated based on the existing configuration, and the adjustment amount is the number of days to be extended. The parameter type to be adjusted and the adjustment amount together constitute a modification suggestion, which is output along with the risk item. That is, the output of the risk item and its evidence location includes the output of the risk item, the modification suggestion, and the evidence location of the risk item.

[0187] The proposed modifications can be further enriched based on the type of risk: For projects with shortened timelines, in addition to extending the duration, suggestions could include adding work surfaces, implementing expedited work measures, or adjusting the overall schedule accordingly; for projects with insufficient resources, suggestions could include increasing work teams, increasing the number of machines, increasing material supply batches, or adjusting the construction flow arrangement; for cases where the same parameter is inconsistent across chapters, it is recommended to unify the values ​​in the text, tables, and drawings to the selected values; for cases where key parameters are missing, it is recommended to supplement the relevant content in the corresponding chapters, tables, or figures. The wording and level of detail in the above suggestions do not affect the implementation of the embodiments of the present invention.

[0188] This step fills the gap between the verification results and the technical specification revision process. The risk item itself only provides a conclusion; the reviewer still needs to recalculate to determine the necessary adjustments in order to apply those conclusions to the modifications. However, the difference used to base the adjustment is already determined in the calculation phase, so it can be recalculated here without needing a separate accounting system. Therefore, from identifying the problem to providing actionable modifications, everything is completed within the same processing path.

[0189] If the review conclusions are only used for this verification, their value is not fully utilized. The quotas, capacities, and thresholds in the constraint rules are mostly taken from general sources and may not be tailored to the company's construction organization level and local operating conditions. Therefore, the risk items calculated based on these may be deemed invalid by the reviewers. Such judgments themselves are feedback on the accuracy of the rules. Retaining these judgments and using them to revise the rules allows them to gradually become more realistic with project accumulation. Therefore, this method can further include steps S216 to S217.

[0190] Step S216: Record the risk item, the location of the evidence for the risk item, and the feedback results received for the risk item as review and audit data.

[0191] The computer equipment receives feedback results from reviewers via the review dashboard and records each risk item, along with its supporting evidence location, as review log data. The feedback indicates whether the risk item was confirmed or rejected after review, and records the corresponding review reasons. In addition to feedback from the review dashboard, the computer equipment can also use parameter changes before and after technical specification revisions as confirmation clues; however, parameter changes alone cannot constitute a confirmed risk item. The review log data also records the feedback time, review reasons, the project and engineering type to which the risk item belongs, the constraint rule identifier and rule version that triggered the risk item, enabling the log data to be retrieved by engineering type and rule entry.

[0192] Step S217: When the feedback result in the review and audit data indicates that the risk item has been rejected and the review reason indicates that the reason for rejection is related to the threshold, quota or capacity of a specific constraint rule, one or more parameter types to be adjusted are determined from the parameter types of each target parameter entity corresponding to the risk item, and the constraint rule corresponding to the determined parameter type to be adjusted is adjusted in the preset constraint rule according to the constraint rule identifier.

[0193] Reasons for rejecting risk items can include rule thresholds, quotas, or production capacity being inapplicable to the current project, as well as reasons such as parameter extraction, evidence location, construction object attribution, unit conversion, or project exceptions. Therefore, rejecting a risk item is not necessarily considered a rule being too strict. Only when the review reason clearly indicates that the rejection is due to the threshold, quota, or production capacity of a specific constraint rule, and the review record data can locate the corresponding rule entry based on the rule identifier and version, will one or more parameter types related to that reason be identified as parameter types to be adjusted, and the corresponding rules will be adjusted accordingly: for thresholds, the threshold can be adjusted based on the actual value confirmed by the review; for quotas or production capacity, the quota value can be corrected based on the actual completion status confirmed by the review. The adjustment range can be taken as the statistical value of rejected cases, or an upper limit can be set for a single adjustment to prevent the rule from fluctuating drastically due to individual cases; accumulating a certain number of rejections for the same rule before making an adjustment is also a feasible approach.

[0194] Confirmed risk items can also be recorded and used for rule maintenance, for example, to verify the appropriateness of the current thresholds; however, the feedback results of risk items marked as pending manual confirmation after the aforementioned evidence review should not be directly used to adjust the rules—the cause of such risk items lies in extraction or location, and is unrelated to the strictness of the rules themselves.

[0195] Thus, the constraint rules have a way to be gradually modified as they are used. When quotas and experience thresholds are taken from general sources, the deviation between them and the company's actual level can only be addressed by manually adjusting parameters one by one. However, by locating specific rule entries through rejected risk items in the audit data, the deviation can be converged in a targeted manner according to parameter type. Subsequently, false alarms caused by overly strict rules in similar projects will be reduced accordingly.

[0196] All the above embodiments complete all verifications at once upon receiving the technical bid documents. For lengthy technical bids, this approach may not be economical: a technical bid of several hundred pages can identify dozens of construction objects, generating hundreds of verification items. A full calculation requires considerable computational overhead, while reviewers often only focus on a few sections on the dashboard; furthermore, the technical bid may be revised several times during the bidding period, requiring a recalculation of all verification items after each revision, even though most of the inputs remain unchanged, resulting in the same results as before. See also... Figure 6Another embodiment of the present invention changes the timing of the calculation to on-demand triggering, and this embodiment includes steps S801 to S803.

[0197] Step S801: Receive a verification trigger instruction for a specified range, wherein the specified range includes a specified chapter or a specified construction object.

[0198] The computer equipment receives the verification trigger command. This command can be generated by the reviewer selecting a chapter or a construction object on the dashboard, or it can be automatically issued by the technical bid preparation system when a chapter is completed. The specified scope carried in the command can be a chapter name or chapter number, or it can be the name of a construction object. Regarding the aforementioned process of identifying construction objects using the chapter structure, a specified chapter and a specified construction object can be converted to each other—the identified construction objects under that chapter can be obtained from the chapter tree.

[0199] Step S802: Determine the construction objects related to the specified range, and extend them along the edges of the parameter relationship diagram to obtain a set of construction objects to be verified.

[0200] First, extract the construction objects contained within the specified range itself, and then extend one layer outward along the edges of the aforementioned parameter relationship diagram: adjacent objects that have temporal dependencies or resource occupancy relationships with these objects are also included. This extension is necessary because cross-object verification requires the parameters of both objects to participate; if only objects within the specified range are selected, the overlap and resource conflicts between them and adjacent objects cannot be calculated. The number of extension layers can be one, or two layers depending on the tightness of the relationship. A larger value results in more comprehensive coverage but also higher overhead. This embodiment of the invention does not limit the number of extension layers.

[0201] Step S803: Perform verification item generation, target parameter entity determination and calculation only for the set of construction objects to be verified, and use the existing verification results of the other construction objects.

[0202] For each object in the set of construction objects to be verified, the verification item generation, target parameter entity determination, and substitution calculation are performed according to the aforementioned embodiment to generate the corresponding risk items and their evidence locations. Construction objects outside the set are not recalculated; their risk items and evidence locations obtained in the previous verification are retained as is and output together. Thus, the output is still the complete verification conclusion of the entire technical specification, while only a part of it is actually involved in the calculation this time.

[0203] When used for incremental verification, the specified range can be automatically derived from changes in the technical specification data without manual selection. By comparing the revised and re-parsed content blocks with the previous content blocks, the parameter entities corresponding to the content blocks whose content has changed are the affected parameters. The construction objects to which these parameters belong constitute the specified range. Subsequently, the range is expanded one level along the parameter relationship diagram, and only this part is recalculated. When a chapter of the technical specification is rewritten, construction objects unrelated to that chapter do not need to be recalculated.

[0204] This change aligns the computational workload with the scope of the reviewer's focus. The full verification in the aforementioned embodiments has an overhead that is proportional to the size of the technical document and is independent of the reviewer's current focus. During the compilation process, the entire document is recalculated every time a change is made, and most of the calculation results are the same as the previous one. This embodiment only recalculates the affected objects and their adjacent objects. Therefore, in cases where the technical document is long and revisions are frequent, the computational steps required for a single verification are significantly reduced. The compiler can obtain the verification conclusion for a section after making a single revision, without having to wait for the entire document to be calculated.

[0205] The following example, taking the pre-bid self-inspection of a steel structure engineering technical tender, will further illustrate the above embodiments. For the equipment components involved in this scenario, please refer to [link to relevant documentation]. Figure 1 For the processing flow, please refer to Figure 2 The numbering of each step follows steps S201 to S207.

[0206] In this scenario, the bidder has completed the preparation of the technical bid and needs to verify the construction parameters within it before submission. The submitted technical bid documents consist of four copies: one main body of the technical bid, one Gantt chart of the overall construction schedule, and one... Figure 1 One copy of the plan, one copy of the main mechanical equipment plan, and one copy of the bill of quantities. All elements previously considered optional in other embodiments are now taken as specific practices in this scenario: location information is derived from page numbers, table cell identifiers, and page coordinate frames; the identification of construction objects is accomplished using the chapter structure; constraint rules are taken from the company's resource allocation experience database; in cases of conflicting values ​​for the same type, priority is given to the table source; calculations are performed using a resource allocation approach; and risk items include risk levels and modification suggestions.

[0207] During step S201, the four documents were parsed into content blocks. Chapter 5 of the technical bid document, "Construction Deployment," was divided into several paragraph content blocks. The machinery and equipment plan was converted into content blocks cell by cell, as was the bill of quantities. Each task bar on the Gantt chart was converted into a content block. The content block recording the steel structure hoisting quantity was identified as B-1201, located on page 12 of the bill of quantities, in the third row and fourth column. The content block recording the quantity of truck cranes was identified as B-1358, located on page 18 of the machinery and equipment plan, in the seventh row and third column.

[0208] When executing step S202, the construction object of steel structure hoisting is identified from the text content of the construction deployment section. When executing step S203, the rule corresponding to steel structure hoisting in the enterprise resource allocation experience base is matched, and a verification item is generated accordingly: the construction object is steel structure hoisting, the required parameter types are three categories: quantity of work, duration, and resource allocation, the applicable constraint rule is the rule of calculating the number of truck cranes based on the hoisting quantity and the planned construction period, and the criterion is that the resource satisfaction level must not be less than one.

[0209] When executing step S204, a parameter entity of the quantity type is extracted from B-1201. The original text states "steel structure approximately 1200 tons," and after standardization, the parameter value is 1200 tons. A parameter entity of the duration type is extracted from the content block corresponding to the steel structure hoisting task bar on the Gantt chart. The parameter value is 30 calendar days. A parameter entity of the resource allocation type is extracted from B-1358. The parameter value is 1, the unit is units, and the resource type is a truck crane. All three parameter entities belong to the same construction object: steel structure hoisting. The identifiers of the content blocks from which they originate are recorded separately.

[0210] When executing step S205, the construction objects of the three parameter entities mentioned above are the same as the steel structure hoisting to which the verification item points. Their parameter types belong to the three types of parameters required by the verification item, and therefore they are all identified as target parameter entities. When executing step S206, the parameter values ​​of the three are substituted into the constraint rules applicable to the verification item: multiplying 1,200 tons by the unit engineering quantity consumption quota of truck cranes in the experience database, and then dividing by 30 calendar days, it is calculated that two truck cranes are required within this planned construction period, that is, the resource requirement is two units; the technical specification actually configures one unit, and the resource satisfaction rate compared with the requirement is 0.5, which does not meet the criterion requirement of not less than one, so a risk item is generated. The risk item records: the construction object to which it points is steel structure hoisting, the calculation result includes the resource configuration quantity of one unit used for direct comparison with the benchmark value and the resource satisfaction rate of 0.5, the benchmark value is the resource requirement of two units, and the source content block identifiers are B-1201, B-1358 and the identifiers corresponding to the task bars of the Gantt chart.

[0211] When executing step S207, the location information of B-1201, B-1358, and the corresponding identifiers of the task bars in the Gantt chart are obtained respectively, and the above location information is used as the evidence location for this risk item. Among them, the location information corresponding to B-1358 points to the third column of the seventh row on page eighteen of the mechanical equipment plan, that is, the cell in the technical bid that specifies the configuration of one truck crane. After superimposing the risk classification, this risk item has a high comprehensive risk value due to the large deviation of the resource satisfaction criteria and the involvement of key lifting equipment, and the risk level is set as high. After superimposing the modification suggestion, the parameter type to be adjusted is the resource configuration type, and the adjustment amount is calculated by back-calculating the difference, which is to add one unit. The modification suggestion is to add one truck crane that meets the lifting radius and lifting capacity requirements, and at the same time, another rectification path is given, that is, to extend the duration of steel structure hoisting after back-calculating the required construction period based on the existing one piece of equipment and adjust the overall schedule accordingly.

[0212] After reviewing the risk item on the dashboard, the reviewer clicked on its evidence location, which redirected to the corresponding cell in the equipment plan. Upon verification, it was confirmed that the technical specification only included one truck crane. The equipment was then added according to the suggested modifications, and the resource plan was revised. Previously, this issue was difficult to detect during manual review because the lifting capacity of 1200 tons, the 30-calendar-day construction period, and the configuration of one truck crane were listed in three separate documents. Individually, each value appeared common; only when all three were considered together did the discrepancy become apparent. Through the process demonstrated in this scenario, a single verification item and calculation pinpointed this configuration gap scattered across the three documents to the specific cell, providing the necessary rectification.

[0213] In one deployment method, this method is executed by the operator of the software or platform providing the technical bid verification function. The steps performed are steps S201 to S207 above: receiving the technical bid data uploaded by the bidder and parsing it into content blocks, identifying the construction object, generating verification items according to built-in rules, extracting and standardizing parameters, aligning them according to the construction object and parameter type, and then substituting them into the calculation to output risk items with evidence locations. This operational form can be a technical bid detection system deployed by the bidder itself, a bid review platform provided as a network service, or a compliance check module built into the bid document preparation software. When provided as a network service, the uploaded technical bid data is the bidder's trade secret and can be encrypted during transmission, retained for a limited time, and subject to access control. Such processing does not change the execution method of the above steps.

[0214] It should be noted that the values ​​assigned to the various optional implementations in this scenario are merely a set of specific values ​​for the purpose of illustration and are not intended to limit the scope of protection of this invention; the other value methods described in the foregoing embodiments are also applicable in this scenario.

[0215] SeeFigure 7 This figure is a schematic block diagram of a construction engineering technical parameter rationality verification device 900 provided in another embodiment of the present invention. Figure 7 As shown, the device 900 includes:

[0216] The data parsing module 901 is used to parse the technical bid data to be verified, and convert the parsed text content, table content and graphic content into content blocks. Each content block records a content block identifier, text content and the position information of the content block in the technical bid data.

[0217] The object recognition module 902 is used to identify construction objects based on the text content of the content block;

[0218] The verification item generation module 903 is used to generate verification items according to preset constraint rules and the construction object. The verification item includes the construction object it points to, the required parameter type, and the applicable constraint rules.

[0219] The parameter extraction module 904 is used to extract parameter entities from the content block and standardize the value and unit of the parameter entity. The parameter entity includes parameter type, the construction object to which it belongs, the parameter value obtained after standardization, and the content block identifier from which it originates.

[0220] The parameter alignment module 905 is used to determine a target parameter entity from the parameter entities for the verification item, wherein the construction object to which the target parameter entity belongs is the same as the construction object pointed to by the verification item, and the parameter type of the target parameter entity belongs to the parameter type required by the verification item.

[0221] The risk calculation module 906 is used to substitute the parameter values ​​of each of the target parameter entities into the constraint rules applicable to the verification item for calculation, and generate a risk item when the calculation result does not meet the constraint rules. The risk item includes the construction object to which the verification item points, the calculation result, the benchmark value determined according to the constraint rules and compared with the calculation result, and the content block identifier from which each of the target parameter entities originates.

[0222] The evidence location module 907 is used to take the location information corresponding to each content block identifier in the risk item as the evidence location of the risk item, and output the risk item and its evidence location.

[0223] The specific process by which each module in the above-mentioned device performs its corresponding function, as well as the further limitation of the function of each module, can be found in the corresponding descriptions in the aforementioned embodiments of the method for verifying the rationality of construction parameters in architectural engineering technical specifications, and will not be repeated here.

[0224] This invention also provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, it implements the method for verifying the rationality of construction parameters in the building engineering technical specifications described in the above embodiments.

[0225] See Figure 8 This figure is a schematic block diagram of the electronic device 1000 provided in an embodiment of the present invention. Figure 8 As shown, the electronic device 1000 includes a processor 1001, a memory 1002, and a bus 1003 connecting the processor 1001 and the memory 1002. It may also include a network interface 1004. The memory 1002 stores a computer program executable by the processor 1001. When the processor 1001 executes the computer program, it implements the methods described in steps S201 to S207, and can further implement the methods described in steps S208 to S217, S301 to S303, S501 to S503, and S801 to S803. The network interface 1004 is used to receive technical specification data to be verified and output risk items and their evidence locations.

[0226] The processor 1001 can be a central processing unit, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices. The memory 1002 can include volatile memory, such as random access memory (RAM); it can also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk, or solid-state drive (SSD). This electronic device can be a single server, a server in a server cluster, or a terminal device with corresponding processing capabilities; the form of the electronic device does not affect the implementation of the embodiments of the present invention.

[0227] This invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method for verifying the rationality of construction parameters in the building engineering technical specifications described in the above embodiments.

[0228] The computer-readable storage medium can be any medium capable of storing a computer program, such as a USB flash drive, external hard drive, read-only memory, random access memory, magnetic disk, optical disk, or storage space on a server for downloading the computer program.

[0229] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the method for verifying the rationality of construction parameters in the building engineering technical specifications described in the above embodiments.

[0230] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can implement the described functions using different methods for each specific application, but such implementations should not be considered beyond the scope of this application.

[0231] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of each unit is only a logical functional division, and other division methods can be used in actual implementation; multiple units or components can be combined with each other or integrated into another system, and some features can be omitted according to actual needs.

[0232] The steps in the methods of this application embodiment can be adjusted, merged, or deleted according to actual needs. The units in the apparatus of this application embodiment can be merged, divided, or deleted according to actual needs. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0233] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, terminal, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0234] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for verifying the rationality of construction parameters in building engineering technical specifications, characterized in that, include: The technical bid document to be verified is parsed, and the parsed text content, table content and graphic content are converted into content blocks. Each content block records a content block identifier, text content and the position information of the content block in the technical bid document. The construction object is identified based on the text content of the content block; Verification items are generated based on preset constraint rules and the construction object. The verification items include the construction object to which they are applied, the required parameter type, and the applicable constraint rules. Extract parameter entities from the content block and standardize the values ​​and units of the parameter entities. The parameter entity includes parameter type, the construction object to which it belongs, the parameter value obtained after standardization, and the content block identifier from which it originated. For the verification item, a target parameter entity is determined from the parameter entities. The construction object to which the target parameter entity belongs is the same as the construction object pointed to by the verification item, and the parameter type of the target parameter entity belongs to the parameter type required by the verification item. The parameter values ​​of each of the target parameter entities are substituted into the constraint rules applicable to the verification item for calculation. When the calculation result does not meet the constraint rules, a risk item is generated. The risk item includes the construction object to which the verification item points, the calculation result, the benchmark value determined according to the constraint rules and compared with the calculation result, and the content block identifier from which each of the target parameter entities originates. The location information corresponding to each content block identifier in the risk item is used as the evidence location of the risk item, and the risk item and its evidence location are output.

2. The method for verifying the rationality of construction parameters in building engineering technical specifications according to claim 1, characterized in that, The location information includes at least one of the following in the technical specification document: the page number of the content block, the page coordinate frame, the character offset range, and the table cell identifier; The parsing of the technical specification data to be verified includes: When the technical specification includes a schedule graphic, extract the task name, node text, date, and connection relationship between tasks from the schedule graphic. The extracted task name, node text, date, and connection relationship are used as the graphic content.

3. The method for verifying the rationality of construction parameters in building engineering technical specifications according to claim 1, characterized in that, The parameter entity extracted from the content block includes: Based on the chapter path relationship between the content block from which the parameter entity originates and the content block from which the construction object is identified, the construction object to which the parameter entity belongs is determined; Determining the target parameter entity from the parameter entity for the verification item includes: When there are at least two parameter entities whose respective construction objects are the same as the construction objects pointed to by the verification item, have the same parameter type, and whose parameter type belongs to the parameter type required by the verification item, and whose parameter values ​​are different, one parameter entity is selected from the at least two parameter entities according to the rule that content blocks from the table content take precedence over content blocks from the text content. The selected parameter entity is taken as the target parameter entity.

4. The method for verifying the rationality of construction parameters in building engineering technical specifications according to claim 1, characterized in that, The step of substituting the parameter values ​​of each of the target parameter entities into the constraint rules applicable to the verification item for calculation includes: Substitute the parameter values ​​of the target parameter entity of the quantity of work type and the unit quantity of work capacity corresponding to the construction object into the constraint rules applicable to the verification item to calculate the baseline duration of the construction object. The construction period compression rate of the construction object is calculated based on the ratio of the parameter value of the target parameter entity of the duration type to the baseline duration, and the calculation result includes the construction period compression rate.

5. The method for verifying the rationality of construction parameters in building engineering technical specifications according to claim 1, characterized in that, The step of substituting the parameter values ​​of each of the target parameter entities into the constraint rules applicable to the verification item for calculation includes: Substitute the parameter values ​​of the target parameter entity of the quantity of work, the unit quantity consumption quota of the target resource type corresponding to the construction object, and the parameter values ​​of the target parameter entity of the duration type into the constraint rules applicable to this verification item to calculate the resource demand of the construction object for the target resource type within the set time window. Based on the ratio of the parameter value of the target parameter entity of the resource configuration type of the target resource type to the resource demand, the resource satisfaction degree of the construction object with the target resource type is calculated, and the calculation result includes the resource satisfaction degree.

6. The method for verifying the rationality of construction parameters in building engineering technical specifications according to claim 1, characterized in that, Also includes: The parameter deviation strength of the construction object is determined based on the calculation results; Filter out parameter types that do not correspond to target parameter entities from the parameter types required for the verification items, and determine the degree of missing key parameters of the construction object based on the filtered parameter types; The comprehensive risk value of the construction object is obtained by weighted summation of the parameter deviation intensity and the degree of missing key parameters, and the risk level of the risk item is determined based on the comprehensive risk value. The output of the risk item and its evidence location includes: outputting the risk item, the risk level of the risk item, and the evidence location of the risk item.

7. The method for verifying the rationality of construction parameters in building engineering technical specifications according to claim 1, characterized in that, Also includes: The risk item, the location of the evidence for the risk item, and the feedback results received for the risk item are recorded as review and audit data. The feedback results include the conclusion that the risk item is confirmed or rejected and the reasons for the review. When the feedback result in the review record data indicates that the risk item is rejected, and the review reason indicates that the reason for rejection lies in the threshold, quota or capacity of the preset constraint rule, the constraint rule in the preset constraint rule corresponding to the parameter type is adjusted according to the parameter type of the target parameter entity corresponding to the risk item.

8. A device for verifying the rationality of construction parameters in building engineering technical standards, characterized in that, include: The data parsing module is used to parse the technical bid data to be verified, and convert the parsed text content, table content and graphic content into content blocks. Each content block records a content block identifier, text content and the position information of the content block in the technical bid data. An object recognition module is used to identify construction objects based on the text content of the content block; The verification item generation module is used to generate verification items based on preset constraint rules and the construction object. The verification item includes the construction object it points to, the required parameter type, and the applicable constraint rules. The parameter extraction module is used to extract parameter entities from the content block and standardize the values ​​and units of the parameter entities. The parameter entity includes parameter type, the construction object to which it belongs, the parameter value obtained after standardization, and the identifier of the content block from which it originates. The parameter alignment module is used to determine a target parameter entity from the parameter entities for the verification item, wherein the construction object to which the target parameter entity belongs is the same as the construction object pointed to by the verification item, and the parameter type of the target parameter entity belongs to the parameter type required by the verification item. The risk calculation module is used to substitute the parameter values ​​of each of the target parameter entities into the constraint rules applicable to the verification item for calculation, and generate a risk item when the calculation result does not meet the constraint rules. The risk item includes the construction object to which the verification item points, the calculation result, the benchmark value determined according to the constraint rules and compared with the calculation result, and the content block identifier from which each of the target parameter entities originates. The evidence location module is used to take the location information corresponding to each content block identifier in the risk item as the evidence location of the risk item, and output the risk item and its evidence location.

9. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a computer program, which, when executed by the processor, implements the method for verifying the rationality of construction parameters in building engineering technical specifications as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the method for verifying the rationality of construction parameters in building engineering technical specifications as described in any one of claims 1 to 7.

Images