Spec parameter extraction structure vector model construction method and system
By constructing a multi-constraint international standard knowledge graph and a sub-project experience database, the problems of low parameter extraction efficiency and fragmented constraint relationships in SPEC documents have been solved, achieving efficient and accurate parameter extraction and cross-industry generalization, supporting intelligent compliance detection and parameter reuse in international projects.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA STATE CONSTR OVERSEAS DEV CO LTD
- Filing Date
- 2026-06-10
- Publication Date
- 2026-07-10
AI Technical Summary
Existing technologies suffer from low efficiency in parameter extraction from SPEC documents, fragmented constraint relationships, poor generalization of vector models, and a lack of experience systems for sub-projects. This results in large parameter extraction errors and the inability to identify parameter conflicts during cross-standard comparisons, making it difficult to meet the standardization needs of large-scale engineering projects.
A multi-constraint international standard knowledge graph module is constructed. A multi-source data fusion module matches synonymous parameters and completes constraint relationships. A SPEC file parameter intelligent extraction module is used to identify parameter entities and map constraint relationships. A multi-constraint structure vector model is constructed, and a sub-project experience database is established to achieve automated parameter extraction and complete preservation of constraint relationships.
It achieves an automated extraction accuracy of ≥95% for SPEC document parameters, reduces parameter extraction time from 8 hours to 40 minutes, improves SPEC document review efficiency by 60%, reduces cross-industry generalization error by 40%, improves conflict detection accuracy by 35%, increases the reuse rate of sub-project parameters by 50%, and reduces the design error rate by 25%.
Smart Images

Figure CN122364231A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of knowledge engineering interdisciplinary technology, and in particular to a method and system for constructing a SPEC parameter extraction structure vector model. Background Technology
[0002] In the international engineering field (such as building, fire protection, and municipal engineering), SPEC documents (including international standards such as ISO, IEC, and ASTM) are the core basis for engineering design, construction, and acceptance. Determining the reasonable range of parameters in the SPEC has a significant impact on project cost and schedule. Currently, the review of SPEC documents in existing projects mainly relies on manual labor. While some existing technologies can review SPEC documents, these technologies have the following significant drawbacks:
[0003] 1. Low parameter extraction efficiency.
[0004] SPEC files have a complex format (a mix of text, PDF tables, and scanned documents), and the parameters are ambiguous in natural language (e.g., "should be ≥1.2MPa" and "must not be lower than 1.2MPa" are synonymous). Manually extracting a single 100-page file takes 8 hours and has an error rate of over 10%, making it difficult to meet the standardization needs of large-scale engineering projects.
[0005] 2. The constraint relationship is broken.
[0006] There are logical (e.g., "the wall thickness must be ≥5mm when the fire pipeline pressure is >1.0MPa"), dependent (e.g., "the thickness detection of fireproof coating depends on the rust removal grade of the substrate"), and version (e.g., "parameter A is only applicable to ISO 834:2020") constraints between parameters. Existing technologies only extract isolated parameters, which leads to "parameter conflicts cannot be identified" when comparing across standards (e.g., the same parameter has contradictory values in different standards).
[0007] 3. Vector models have poor generalization ability.
[0008] The existing structural vectors only contain the parameters' own attributes (such as values and units) and do not incorporate constraint information. When reused across different business formats (such as migrating from residential fire protection engineering to stadium fire protection engineering), the generalization error exceeds 30%, which cannot support intelligent conflict detection.
[0009] 4. Lack of experience system for sub-projects.
[0010] International engineering projects are divided into sub-projects (such as fire protection engineering including "fire hydrant system" and "automatic sprinkler system"), but there is a lack of structured experience databases. Parameter queries require consulting standard documents one by one, resulting in low efficiency in the review of SPEC documents (average time increase of 40%).
[0011] Therefore, there is a need to provide a method and system for constructing a SPEC parameter extraction structure vector model, which can solve the problems of low parameter extraction efficiency, fragmented constraint relationships, poor generalization of vector models, and lack of experience systems for sub-projects in the existing technology. Summary of the Invention
[0012] The purpose of this invention is to provide a method and system for constructing a SPEC parameter extraction structure vector model, which can solve the problems of low parameter extraction efficiency, fragmented constraint relationships, poor generalization of vector models, and lack of experience in sub-projects in the existing technology.
[0013] This invention is implemented as follows:
[0014] A SPEC parameter extraction structure vector model construction system, comprising:
[0015] The multi-constraint international standard knowledge graph module is used to define core entities and relationships;
[0016] The multi-source data fusion module is used to match synonymous parameters and complete constraint relationships;
[0017] The SPEC file parameter intelligent extraction module is used to identify parameter entities and map constraint relationships.
[0018] A multi-constraint structure vector model is used to map parameter attribute base vectors, fuse constraint relationship vectors, and optimize multi-constraint loss functions.
[0019] The database of experience in sub-projects is structured hierarchically and its content is stored accordingly.
[0020] The aforementioned multi-constraint international standard knowledge graph module includes an entity layer and a relation layer;
[0021] The relationship layer includes eight types of constraints: logical constraints (parameter-parameter), dependency constraints (parameter-parameter), version constraints (parameter-standard document), classification constraints (parameter-standard document), mandatory constraints (engineering specification), optional constraints (material standard), exclusive constraints (parameter-parameter), and time constraints (construction procedure).
[0022] The entity layer includes parameter entities, standard document entities, and associated entities;
[0023] The attributes of a parameter entity include: name, data type, value range, unit, precision, sub-item label, and mandatory type; the attributes of a standard document entity include: identifier, issuing organization, effective date, version number, and applicable project type; the attributes of an associated entity include: construction procedure, material standard, and engineering specification.
[0024] The relation layer defines constraints through triples, which include a head entity, a relation, and a tail entity.
[0025] A method for constructing a SPEC parameter extraction structure vector model using a SPEC parameter extraction structure vector model construction system includes the following steps:
[0026] Step 1: Construct a multi-constraint international standard knowledge graph;
[0027] Step 2: Intelligent extraction of SPEC file parameters based on multi-constraint graphs;
[0028] Step 3: Construct a multi-constraint structure vector model;
[0029] Step 4: Construct a database of experience for each sub-project and output the results of the multi-constraint structure vector model.
[0030] Step 1 includes the following sub-steps:
[0031] Step 1.1: Design a multi-constraint international standard knowledge graph ontology and define core entities and relationships;
[0032] Step 1.2: Match synonymous parameters and complete the constraint relationships using a multi-source data fusion algorithm.
[0033] Step 1.2 includes the following sub-steps:
[0034] Step 1.2.1: Determine whether the parameter names of the entities are similar. Similar parameter names account for 70% of the judgment weight.
[0035] Step 1.2.2: Determine whether the parameter attributes of the entities are consistent. The consistency of parameter attributes accounts for 30% of the judgment weight.
[0036] Step 1.2.3: When the combined score of parameters with similar names and identical attributes is ≥0.8, they are judged as synonymous parameters, and synonymous parameters are merged into the same entity;
[0037] Step 1.2.4: For the correlation of parameters, based on the correlation patterns of similar parameters in historical data, establish a correlation prediction model, predict the correlation of parameters through the correlation prediction model, and complete the constraint relationship of parameters.
[0038] Step 1.2.5: Continuously learn and optimize the association prediction model to ensure that the constraint relationship of the completed parameters matches the actual standard document by ≥90%.
[0039] Step 2 includes the following sub-steps:
[0040] Step 2.1: SPEC file preprocessing and corpus parsing;
[0041] Step 2.2: Construct a parametric entity recognition model;
[0042] Step 2.3: Define constraint mapping rules:
[0043] ① Explicit constraint extraction: based on keyword matching;
[0044] ② Implicit constraint reasoning: combining graph classification relationships.
[0045] Step 2.1 includes the following sub-steps:
[0046] Step 2.1.1: Convert the scanned PDF document into text;
[0047] Step 2.1.2: Parse the table content into structured data of "parameter name-value-unit-sub-item";
[0048] Step 2.1.3: The text is segmented using the NLTK tool. After removing stop words, a sentence-level corpus is generated, and keywords for each sub-project are annotated.
[0049] In the parametric entity recognition model, the input layer takes a corpus sentence plus multi-constraint graph parameter features as input; entity labels are predicted by adding a CRF layer using BERT, and the loss function is:
[0050]
[0051] Where, x i For the input sentence, y i The entity label sequence is θ, and the model parameters are θ.
[0052] The parameter entity recognition model uses NER technology to extract value ranges, units, etc., performs regular expression validation, and labels sub-projects.
[0053] Step 3 includes the following sub-steps:
[0054] Step 3.1: Map the parameter attribute base vector, which includes semantic vector, attribute vector and basic characteristic vector;
[0055] Semantic vector: Converts the parameter name into a set of numbers, the size of which represents the meaning of the name; Attribute vector: Converts the specific features of the parameter into a set of numbers; Basic feature vector: Combines the semantic vector and the attribute vector to form a combination of numbers that reflects both the parameter name and its specific features, serving as the basis for subsequent calculations.
[0056] Step 3.2: Merge the constraint relationship vector;
[0057] The final vector dimension formula is: Total dimension = Basic feature vector + Constraint extension vector;
[0058] Step 3.3: Optimize the multi-constraint loss function.
[0059] Step 3.3 includes the following sub-steps:
[0060] Step 3.3.1: The total loss function is: Total loss = 0.4 × constraint bias + 0.3 × attribute error + 0.2 × generalization difference + 0.1 × time bias;
[0061] Among them, 0.4, 0.3, 0.2, and 0.1 are all penalty item weights, and the sum of the weights of all penalty items is always 1;
[0062] Step 3.3.2: Constraint consistency penalty, i.e., constraint deviation:
[0063] Constraint deviation = ∑ | Actual correlation degree - Standard correlation degree |;
[0064] Standard correlation The following weighting function was used to calculate the result:
[0065]
[0066] in:
[0067] This indicates whether there are explicit constraint clauses in the standard document; 1 indicates the presence of such clauses, and 0 indicates the absence of such clauses.
[0068] The implicit constraints obtained from graph reasoning are represented by 1 if they exist and 0 if they do not exist.
[0069] Forced assignments based on constraint type, such as mandatory constraint = 1, logical / dependency constraint = 0.8, version constraint = 0.6, category constraint = 0.4, optional constraint = 0.2;
[0070] The co-occurrence frequency of the parameter in standard documents;
[0071] , , , The weights are adjustable and satisfy: ;
[0072] Actual correlation The calculation formula is as follows:
[0073]
[0074] Cosine similarity between two parameter vectors;
[0075] Indicates whether an explicit constraint clause appears in the text; 1 indicates its presence and 0 indicates its absence.
[0076] Indicates whether a dependency language pattern is matched;
[0077] The co-occurrence probability of the parameter in the same sentence or paragraph;
[0078] α, β, γ, and δ are adjustable hyperparameters that satisfy α + β + γ + δ = 1;
[0079] Step 3.3.3: Attribute matching penalty, i.e., attribute error:
[0080] Attribute error = the average deviation between the extracted attribute and the standard attribute;
[0081] Step 3.3.4: Generalization penalty, i.e., generalization difference:
[0082] Generalization difference = ∑ Vector difference of similar parameters;
[0083] Set a vector difference threshold; when the vector difference degree > the vector difference threshold, mark it as a conflict.
[0084] Step 3.3.5: Time constraint penalty, i.e., time deviation:
[0085] Time deviation = ∑ |Actual time - Standard time| / Standard time.
[0086] Step 4 includes the following sub-steps:
[0087] Step 4.1: Construct a sub-item project experience database by dividing the project into "sub-projects → sub-items → parameter groups" according to the hierarchy. The sub-item project experience database is used to store parameter vectors, constraint relationships, historical project cases, and compliance inspection records.
[0088] Step 4.2: Calculate the performance metrics of the multi-constraint structure vector model. The performance metrics of the multi-constraint structure vector model include parameter extraction accuracy, constraint recognition accuracy, and cross-industry generalization error.
[0089] Among them, the parameter extraction accuracy rate = (number of correctly extracted parameters / total number of parameters) × 100% ≥ 95%;
[0090] Accurate parameter extraction means that the parameter name, value range, unit, and other attributes all match the standard document exactly.
[0091] Constraint identification accuracy = (Number of correctly identified constraints / Total number of constraints) × 100% ≥ 90%;
[0092] Accurate constraint identification means that the constraint type and associated entities are completely consistent with the standard constraints in the knowledge graph.
[0093] Cross-industry generalization error: ≤15%, meaning that the vector difference of the same parameter in different engineering types does not exceed 15%;
[0094] Step 4.3: Output results of the multi-constraint structure vector model:
[0095] ① Structured parameter vector library;
[0096] ② The query system of the sub-project experience database supports searching by project type and parameter name;
[0097] ③ Interfaces: Constraint Query API, Model Deployment API.
[0098] Compared with the prior art, the present invention has the following advantages:
[0099] 1. This invention can automatically extract international engineering standard parameters from SPEC documents with an accuracy of ≥95%, and add metadata such as "sub-item project tags" and "mandatory / optional attributes" to the parameters. The parameter extraction time is reduced from the traditional 8 hours / 100 pages to 40 minutes, and the SPEC document review efficiency can be improved by 60%.
[0100] 2. This invention constructs a knowledge graph containing 8 types of constraint relationships, fully preserving the logical, dependency, and version association rules between parameters. The recognition coverage of the 8 types of constraint relationships is increased from the traditional 60% to 95%, solving the "parameter isolation" problem in the prior art.
[0101] 3. This invention transforms parameters and constraints into a structured vector model, which can reduce the generalization error across industries by more than 40%, and can support conflict detection and compliance verification, improving the conflict detection accuracy by 35% and enhancing the robustness of the model.
[0102] 4. This invention establishes a database of experience for sub-projects divided according to international engineering sub-items, enabling rapid querying and reuse of parameters and cases. The database of experience for sub-projects increases the reuse rate of international engineering parameters by 50%, reduces the design error rate by 25%, and saves costs. Attached Figure Description
[0103] Figure 1 This is a schematic diagram of the constraint relationship vector fusion of the multi-constraint structural vector model in the SPEC parameter extraction structural vector model construction method of the present invention;
[0104] Figure 2 This is an optimization curve of the multi-constraint loss function in the SPEC parameter extraction structure vector model construction method of this invention;
[0105] Figure 3 This is a schematic diagram of the application of Example 1. Detailed Implementation
[0106] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.
[0107] A SPEC parameter extraction structure vector model construction system, comprising:
[0108] The multi-constraint international standard knowledge graph module is used to define core entities and relationships.
[0109] The aforementioned multi-constraint international standard knowledge graph module includes an entity layer and a relation layer.
[0110] The relationship layer includes eight constraint types: logical constraints, with the associated entity being parameter-parameter, such as pressure > 1.0MPa → wall thickness ≥ 5mm; dependency constraints, with the associated entity being parameter-parameter, such as paint thickness detection depending on the substrate rust removal grade; version constraints, with the associated entity being parameter-standard document, such as parameter A only applicable to ISO 834:2020; classification constraints, with the associated entity being parameter-standard document, such as parameter B belonging to the fire protection system safety parameter category; mandatory constraints, with the associated entity being parameter-engineering specification, such as evacuation route width must be ≥ 1.1m (not exempt); optional constraints, with the associated entity being parameter-material standard, such as galvanized steel pipe or seamless steel pipe can be used; exclusive constraints, with the associated entity being parameter-parameter, such as system A and system B cannot be used simultaneously; and time constraints, with the associated entity being parameter-construction procedure, such as pipeline pressure testing must be completed within 24 hours after installation.
[0111] The entity layer includes parameter entities, standard document entities, and associated entities;
[0112] The attributes of the parameter entities (such as "fire pipeline working pressure", "fire retardant coating thickness", etc.) include: name (such as "fire pipeline pressure"), data type (such as numeric / Boolean), value range (such as 1.0 to 1.6MPa), unit (such as MPa or mm), accuracy (such as ±0.05mm), sub-item label (such as "fire hydrant system"), and mandatory type (such as mandatory / optional).
[0113] The attributes of the standard document entity (e.g., "ISO 834:2020 Fire Resistance Tests for Building Components") include: identifier (e.g., ISO 834:2000), issuing organization (e.g., ISO / IEC), effective date, version number, and applicable project type (e.g., "commercial buildings", "industrial plants").
[0114] The attributes of the associated entities include: construction procedures (e.g., pipeline pressure testing), material standards (galvanized steel pipe specifications), and engineering specifications (e.g., fire protection design specifications).
[0115] The relation layer defines constraints through triples, which include a head entity, a relation, and a tail entity. For example, "fire-fighting pipeline pressure" has a logical constraint: ">1.0MPa" → "wall thickness ≥5mm"; another example is "coating thickness detection" with a dependency constraint: "substrate rust removal grade Sa2.5".
[0116] The multi-source data fusion module is used to match synonymous parameters and complete constraint relationships.
[0117] The SPEC file parameter intelligent extraction module is used to identify parameter entities and map constraint relationships.
[0118] A multi-constraint structure vector model is used to map parameter attribute base vectors, fuse constraint relationship vectors, and optimize multi-constraint loss functions.
[0119] The database of experience in sub-projects is structured hierarchically and its content is stored accordingly.
[0120] A method for constructing a SPEC parameter extraction structure vector model includes the following steps:
[0121] Step 1: Construct a multi-constraint international standard knowledge graph.
[0122] Step 1 includes the following sub-steps:
[0123] Step 1.1: Design a multi-constraint international standard knowledge graph ontology and define core entities and relationships.
[0124] Step 1.2: Match synonymous parameters and complete the constraint relationships using a multi-source data fusion algorithm.
[0125] Step 1.2 includes the following sub-steps:
[0126] Step 1.2.1: Determine whether the parameter names of the entities are similar (e.g., "working pressure" and "operating pressure" are similar). Preferably, similar parameter names can account for 70% of the judgment weight.
[0127] The data fusion module includes an entity alignment algorithm and a relation completion algorithm. The entity alignment algorithm's judgment logic includes: name similarity accounting for 70% of the weight, attribute matching accounting for 30% of the weight, and a comprehensive score greater than or equal to 0.8 considered as synonymous parameters. The relation completion algorithm's prediction logic includes: learning from historical association patterns, automatic completion when the association probability is greater than 80%, and a match rate greater than or equal to 90%.
[0128] Step 1.2.2: Determine whether the parameter attributes (such as units, value ranges, etc.) of the entities are consistent (e.g., both are in the unit "MPa" and their value ranges overlap). Preferably, consistent parameter attributes can account for 30% of the judgment weight.
[0129] Step 1.2.3: When the combined score of parameters with similar names and consistent attributes is ≥0.8, they are judged as synonymous parameters, and synonymous parameters can be merged into the same entity.
[0130] Step 1.2.4: For the correlation of parameters (e.g., "whether parameter A and parameter B are related"), based on the correlation patterns of similar parameters in historical data (e.g., the parameter "pressure" and parameter "wall thickness" often have a dependency relationship), establish a correlation prediction model, predict the correlation of parameters through the correlation prediction model, and complete the constraint relationship of parameters (e.g., if "the correlation probability of two parameters is >80%", then automatically complete the constraint relationship of the two parameters, such as "parameter A depends on parameter B").
[0131] Preferably, the association prediction model can be built based on existing deep learning neural networks such as CNNs, with parameters as input and the completed constraint relationships of the parameters as output. Deep learning neural networks are commonly used model building and optimization methods in this field, and can adaptively build corresponding association prediction models according to actual parameter processing needs, enabling the prediction and completion of missing parameter constraints. The specific construction and processing process will not be elaborated here.
[0132] Step 1.2.5: Continuously learn and optimize the association prediction model to ensure that the constraint relationship of the completed parameters matches the actual standard document by ≥90%.
[0133] By completing the constraint relationships, the problem of fragmented constraint relationships in the existing technology is solved.
[0134] Step 2: Intelligent extraction of SPEC file parameters based on multi-constraint graphs.
[0135] Step 2 includes the following sub-steps:
[0136] Step 2.1: SPEC file preprocessing and corpus parsing.
[0137] SPEC files can be in various formats, such as scanned PDFs, text PDFs, tables, plain text, etc.
[0138] Step 2.1 includes the following sub-steps:
[0139] Step 2.1.1: Convert the scanned PDF document into text using Tesseract OCR (with a conversion accuracy of ≥98%).
[0140] Step 2.1.2: The table content is parsed into structured data of "parameter name - value - unit - sub - project" through PyPDF2.
[0141] By pre - processing SPEC files in formats such as PDF and tables, structured data with a unified format is formed, facilitating subsequent processing.
[0142] Step 2.1.3: For text clause segmentation, the NLTK tool is used. After removing stop words (such as "of", "in", etc.), a sentence - level corpus is generated, and keywords of sub - projects (such as "fire hydrant", "spray", etc.) are marked.
[0143] Step 2.2: Build a parameter entity recognition model.
[0144] Preferably, the parameter entity recognition model can be built based on the deep - learning neural network of the existing technology and fine - tuned through BERT (Bidirectional Encoder Representations from Transformers, a natural language processing technology), improving the recognition accuracy of the parameter entity recognition model for parameter entities and solving the problem of poor generalization of the vector model in the existing technology.
[0145] In the described parameter entity recognition model, the input of its input layer is the corpus sentence + multi - constraint graph parameter features (such as "pressure" + "MPa" + "fire pipeline" label). By adding a CRF (Conditional Random Field) layer through BERT to predict (output) entity labels (B - parameter, I - parameter, O - non - parameter), the loss function is:
[0146]
[0147] where x i is the input sentence, y i is the entity label sequence, and θ is the model parameter.
[0148] The CRF layer (Conditional Random Field layer) is a model layer in deep learning for sequence labeling and named entity recognition, mainly used to process the dependency relationships between elements. It is a commonly used technical means for model optimization in this field, and the specific operation steps of adding a CRF layer through BERT will not be elaborated here.
[0149] The parameter entity recognition model extracts the value range (such as "1.0~1.6MPa"), unit, etc. through the NER (Named Entity Recognition) technology of the existing technology, validates with regular expressions (such as the pressure unit must be "MPa", "bar"), and marks the sub - project label (such as "automatic sprinkler system").
[0150] Step 2.3: Define constraint mapping rules:
[0151] ① Explicit constraint extraction: Based on keyword matching, for example:
[0152] Mandatory constraints: "must be met", "cannot be exempted" → (parameters, mandatory constraints, engineering specifications).
[0153] Time constraint: "Within 24 hours after installation" → (Parameter, Time constraint: within 24 hours, Construction procedure).
[0154] ② Implicit constraint reasoning: Reasoning is performed by combining the classification relationships in the graph, for example:
[0155] If "parameter X belongs to the fire water system" and "the fire water system must comply with NFPA 13", then the inference constraint relationship is: X, version constraint, NFPA 13:2022.
[0156] The output after constraint mapping is: structured parameters (including attributes) and 8 types of constraint relationship tables.
[0157] Step 3: Construct a multi-constraint structure vector model.
[0158] Step 3 includes the following sub-steps:
[0159] Step 3.1: Map the base vector of parameter attributes.
[0160] The parameter attribute base vector includes semantic vector, attribute vector, and basic characteristic vector.
[0161] The semantic vector transforms parameter names (e.g., "working pressure" or "fire retardant coating thickness") into a set of 200 numbers, where the size of the set represents the meaning of the name. For example, "working pressure" and "operating pressure" have similar meanings, so their corresponding sets of numbers will also be very similar; while "temperature" and "humidity" have very different meanings, so their corresponding sets of numbers will also differ greatly.
[0162] Attribute vector: The specific characteristics of the parameters (such as the unit "MPa" or "mm", the value range "1.0~1.6MPa", and the sub-project belonging to "fire hydrant system") are also converted into a set of numbers (50 numbers in total).
[0163] For example: the unit "MPa" is assigned to one set of fixed numbers, and "mm" is assigned to another set of fixed numbers; the value range "1.0~1.6MPa" is converted into the corresponding number group according to its range size; and different number groups are used to distinguish between "fire hydrant system" and "automatic sprinkler system" according to the system they describe.
[0164] Basic feature vector: The semantic vector and attribute vector are merged to form a combination of 250 numbers, which can reflect both the name of the parameter and its specific features, and serve as the basis for subsequent calculations.
[0165] The number of numeric groups in semantic vectors and attribute vectors can be adjusted adaptively according to actual processing needs.
[0166] Step 3.2: Merge the constraint relation vectors, as shown in the appendix. Figure 1 As shown.
[0167] Final vector dimensions: A simplified formula is used to intuitively present the dimensional composition, clearly reflecting the vector proportion of each module.
[0168] Total dimension = basic feature vector + constraint expansion vector = 250 + 50 = 300 dimensions;
[0169] Among them, the basic feature vector (250 dimensions) includes a semantic vector (200 dimensions) and an attribute vector (50 dimensions, including units, value range, etc.); the constraint extension vector (50 dimensions) integrates the basic feature vector of 8 types of constraint relationships (including version identifier, time constraint, mandatory / optional identifier, etc., and the dimensions can be evenly distributed according to the constraint type).
[0170] Step 3.3: Optimize the multi-constraint loss function, as shown in the appendix. Figure 2 As shown.
[0171] Step 3.3 includes the following sub-steps:
[0172] Step 3.3.1: The total loss function is: Total loss = 0.4 × constraint bias + 0.3 × attribute error + 0.2 × generalization difference + 0.1 × time bias.
[0173] Among them, 0.4, 0.3, 0.2, and 0.1 are all penalty item weights, which can be adjusted according to actual processing needs. The sum of the weights of all penalty items is always 1.
[0174] Total loss function coordinates: horizontal axis: number of iterations 0-320, vertical axis: loss value 0-1.0.
[0175] Total loss function curve: starting at 0.8, converges to 0.025 after 320 rounds.
[0176] Constraint bias (penalty weight 0.4): starting point 0.3, ending point 0.01; Attribute error (penalty weight 0.3): starting point 0.25, ending point 0.005; Generalization difference (penalty weight 0.2): starting point 0.2, ending point 0.008; Time bias (penalty weight 0.1): starting point 0.15, ending point 0.002.
[0177] Step 3.3.2: Constraint Consistency Penalty (Constraint Deviation):
[0178] Constraint deviation = ∑ | Actual correlation degree - Standard correlation degree |.
[0179] Standard correlation is used to measure the actual constraint strength of two parameters in international standard documents (such as ISO, ASTM, NFPA, etc.). This invention, in constructing a multi-constraint international standard knowledge graph, obtains structured evidence through explicit constraint clauses, graph triple structures, and the classification relationships of parameters in standard documents. Standard Correlation The result consists of four parts: the existence of explicit constraints, the reasoning result of implicit constraints, the constraint type and strength, and the frequency of co-occurrence of parameters in standard documents. It is calculated using the following weighting function:
[0180]
[0181] in:
[0182] Indicates whether there are explicit constraint clauses in the standard document (1 for existence, 0 for non-existence);
[0183] This represents the implicit constraints obtained from graph reasoning (1 for existence, 0 for non-existence).
[0184] The mandatory assignment is based on the constraint type (e.g., mandatory constraint = 1, logical / dependency constraint = 0.8, version constraint = 0.6, category constraint = 0.4, optional constraint = 0.2).
[0185] The co-occurrence frequency of the parameter in standard documents;
[0186] , , , The weights are adjustable and satisfy: ;
[0187] Actual correlation is used to measure the strength of the actual correlation between parameters inferred by the model after parameter extraction and constraint identification of the SPEC document. The result is obtained by combining semantic similarity between parameter vectors, explicit constraint expression in the text, degree of dependency sentence matching, and parameter co-occurrence frequency. The specific calculation formula is as follows:
[0188]
[0189] Cosine similarity between two parameter vectors, used to reflect semantic proximity;
[0190] Indicates whether an explicit constraint clause appears in the text (1 if it exists, 0 if it does not).
[0191] Indicates whether it matches a dependency language pattern, such as "depends on" or "must satisfy".
[0192] The co-occurrence probability of the parameter in the same sentence or paragraph;
[0193] α, β, γ, and δ are adjustable hyperparameters that satisfy α + β + γ + δ = 1.
[0194] Constraint deviation is used to measure the degree of matching between constraints between parameters. The smaller the constraint deviation value, the more consistent the constraints are; conversely, the larger the constraint deviation value, the less consistent the constraints are.
[0195] Step 3.3.3: Attribute matching penalty (attribute error):
[0196] Attribute error = the average deviation between extracted attributes and standard attributes.
[0197] For example, deviations in units or value ranges; the smaller the attribute error value, the higher the accuracy of attribute extraction, and vice versa.
[0198] Step 3.3.4: Generalization penalty (generalization difference):
[0199] Generalization difference = ∑ Vector difference of similar parameters.
[0200] Vector variability is used to measure the degree of difference in the structural vector representation of the same type of parameter under different engineering types or standard environments. For parameters... In terms of project type and The corresponding structure vector and The vector dissimilarity is defined as a normalized measure of the distance between two vectors, and the formula is as follows:
[0201]
[0202] Cosine similarity, with a value ranging from 0 to 1, represents the consistency of the vector directions.
[0203] Therefore, vector dissimilarity It also falls within the interval [0,1]. The larger the value, the more significant the semantic or attribute differences of the parameter in different scenarios. The system sets a vector difference threshold based on the professional requirements of the parameter. ,when: If the parameter is found to have a significant conflict between different project types, an early warning or further manual review should be triggered.
[0204] A vector difference threshold can be set. When the vector difference degree is greater than the vector difference threshold, a conflict is marked.
[0205] Generalization variance is used to measure the consistency of the same parameters in different scenarios. The smaller the generalization variance value, the stronger the generalization ability. Conversely, the larger the generalization variance value, the weaker the generalization ability.
[0206] Step 3.3.5: Time Constraint Penalty (Time Deviation):
[0207] Time deviation = ∑ |Actual time - Standard time| / Standard time.
[0208] Time deviation is used to measure the proportion of deviation from time constraints. The smaller the time deviation value, the higher the time compliance. Conversely, the larger the time deviation value, the lower the time compliance.
[0209] Step 4: Construct a database of experience for each sub-project and output the results of the multi-constraint structure vector model.
[0210] Step 4 includes the following sub-steps:
[0211] Step 4.1: Construct an experience database for sub-projects by dividing them into "sub-projects → sub-items → parameter groups" according to their hierarchical structure. For example, "fire protection engineering → fire hydrant system → pipeline parameters". The experience database for sub-projects is used to store parameter vectors, constraint relationships, historical project cases (including "project type", "application effect", etc.), compliance inspection records, and other contents.
[0212] Step 4.2: Calculate the performance metrics of the multi-constraint structure vector model. The performance metrics of the multi-constraint structure vector model include parameter extraction accuracy, constraint recognition accuracy, and cross-industry generalization error.
[0213] The parameter extraction accuracy rate is calculated as follows: (number of correctly extracted parameters / total number of parameters) × 100% ≥ 95%.
[0214] Accurate parameter extraction means that the parameter name, value range, unit, and other attributes all match the standard document perfectly.
[0215] Constraint identification accuracy = (Number of correctly identified constraints / Total number of constraints) × 100% ≥ 90%.
[0216] Accurate constraint identification means that the constraint type and associated entities are completely consistent with the standard constraints in the knowledge graph.
[0217] Cross-industry generalization error: ≤15%, meaning that the vector difference of the same parameter in different engineering types does not exceed 15%.
[0218] Step 4.3: Output results of the multi-constraint structure vector model:
[0219] ① Structured parameter vector library (300-dimensional vector + constraint relationship table);
[0220] ② Query system for the sub-project experience database (supports searching by project type and parameter name);
[0221] ③ Interfaces: Constraint Query API, Model Deployment Interface (can be used to interface with existing BIM software and compliance testing systems).
[0222] This invention extracts standard parameters from international engineering technical specification documents (SPEC documents), integrates multi-dimensional constraint relationships from knowledge graphs to construct a structured vector model, and establishes a database of experience for sub-projects. It can be applied to multi-standard compliance testing, cross-industry parameter reuse, and intelligent decision support scenarios in the international engineering field.
[0223] For international engineering projects that need to meet multiple international standards (such as ISO, ASTM, NFPA, etc.), the system automatically detects the consistency of parameters in different standards, identifies conflicts, and issues warnings by using a multi-constraint international standard knowledge graph and a multi-constraint structural vector model.
[0224] For example, a multinational commercial complex project needs to comply with both ISO 834:2020 (fire resistance testing of building components) and NFPA 13:2022 (automatic sprinkler systems). The system can quickly locate the difference in the "pressure resistance value of fire protection pipes" between the two standards (for example, ISO requires the pressure resistance value of fire protection pipes to be ≥1.2MPa, while NFPA requires the pressure resistance value of fire protection pipes to be ≥1.5MPa), and mark the conflict through vector difference degree (vector difference degree > vector difference threshold).
[0225] Please see the appendix Figure 3 Example 1: Taking the SPEC document for fire protection engineering of international commercial buildings (compliant with ISO 834:2020 and NFPA 13:2022) as an example.
[0226] 1. Construction of multi-constraint international standard knowledge graph:
[0227] Integrate standard parameters, define logical constraints between "fire hydrant system" and "fire pipeline working pressure" (1.0~1.6MPa) (pressure > 1.0MPa → wall thickness ≥ 5mm), and associate them with the sub-project label "fire hydrant system".
[0228] 2. Intelligent parameter extraction from SPEC files based on multi-constraint maps:
[0229] • Enter the SPEC document for international commercial building fire protection engineering: "The working pressure of the fire hydrant system piping in commercial buildings should be 1.2 MPa, and the wall thickness should not be less than 5 mm (pressure testing should be completed within 24 hours after installation)."
[0230] • Entity recognition: Extracts "work pressure" and "wall thickness" with a 100% accuracy rate in attribute recognition.
[0231] • Constraint mapping: Explicitly extract logical constraints (1.2MPa→≥5mm), time constraints (pressure test within 24 hours), and implicit inference version constraints (compliant with NFPA 13:2022).
[0232] 3. Multi-constraint structure vector modeling:
[0233] • Base vector: "Work pressure" semantic vector + [1.0, 1.6]MPa normalized vector.
[0234] • Constraint Fusion: Introduce a logical constraint weight matrix to fix the cosine distance between the 1.2MPa pressure vector and the 5mm wall thickness vector at 0.85 (compliant with logical constraints), and the version matches NFPA 13:2022.
[0235] Detection logic: Identify conflicts based on vector distance deviation (actual distance < standard distance → trigger alarm).
[0236] • Optimization: After 320 iterations, the loss converged to 0.025.
[0237] 4. Application of experience database for sub-projects:
[0238] When users query "commercial building fire hydrant system piping parameters", the multi-constraint structural vector model outputs matching parameters and historical cases from the structured parameter vector library (such as the piping selection scheme of a fire protection project in a shopping mall in Dubai), which can be reused with one click.
[0239] 5. Collision detection verification:
[0240] When the SPEC document for fire protection engineering of international commercial buildings states "pressure of 1.2MPa corresponds to a wall thickness of 4mm", the multi-constraint structural vector model identifies conflicts through vector distance deviation (actual cosine distance 0.3 < standard vector cosine distance 0.85), with an accuracy of 100%.
[0241] Conflict case: Input parameters: pressure = 1.2MPa, wall thickness = 4mm.
[0242] Vector calculation: Cosine distance = 0.3 (deviation from vector cosine distance 0.85), violating "pressure > 1.0MPa → wall thickness ≥ 5mm".
[0243] Output of the multi-constraint structure vector model: Conflict alarm. Reason: Wall thickness 4mm < 5mm, it is recommended to adjust to ≥ 5mm.
[0244] The above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the invention. Therefore, any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A SPEC parameter extraction and structure vector model construction system, characterized by: include: The multi-constraint international standard knowledge graph module is used to define core entities and relationships; The multi-source data fusion module is used to match synonymous parameters and complete constraint relationships; The SPEC file parameter intelligent extraction module is used to identify parameter entities and map constraint relationships. A multi-constraint structure vector model is used to map parameter attribute base vectors, fuse constraint relationship vectors, and optimize multi-constraint loss functions. The database of sub-project experience is structured hierarchically and its content is stored accordingly. The aforementioned multi-constraint international standard knowledge graph module includes an entity layer and a relation layer; The relationship layer includes eight types of constraints: logical constraints (parameter-parameter), dependency constraints (parameter-parameter), version constraints (parameter-standard document), classification constraints (parameter-standard document), mandatory constraints (engineering specification), optional constraints (material standard), exclusive constraints (parameter-parameter), and time constraints (construction procedure). The entity layer includes parameter entities, standard document entities, and associated entities; The attributes of a parameter entity include: name, data type, value range, unit, precision, sub-item label, and mandatory type; the attributes of a standard document entity include: identifier, issuing organization, effective date, version number, and applicable project type; the attributes of an associated entity include: construction procedure, material standard, and engineering specification. The relation layer defines constraints through triples, which include a head entity, a relation, and a tail entity.
2. A method for constructing a SPEC parameter extraction structure vector model using the SPEC parameter extraction structure vector model construction system described in claim 1, characterized in that: Includes the following steps: Step 1: Construct a multi-constraint international standard knowledge graph; Step 2: Intelligent extraction of SPEC file parameters based on multi-constraint graphs; Step 3: Construct a multi-constraint structure vector model; Step 4: Construct a database of experience for each sub-project, and output the results using a multi-constraint structure vector model; Step 1 includes the following sub-steps: Step 1.1: Design a multi-constraint international standard knowledge graph ontology and define core entities and relationships; Step 1.2: Match synonymous parameters and complete the constraint relationships using a multi-source data fusion algorithm; Step 1.2 includes the following sub-steps: Step 1.2.1: Determine whether the parameter names of the entities are similar. Similar parameter names account for 70% of the judgment weight. Step 1.2.2: Determine whether the parameter attributes of the entities are consistent. The consistency of parameter attributes accounts for 30% of the judgment weight. Step 1.2.3: When the combined score of parameters with similar names and identical attributes is ≥0.8, they are judged as synonymous parameters, and synonymous parameters are merged into the same entity; Step 1.2.4: For the correlation of parameters, based on the correlation patterns of similar parameters in historical data, establish a correlation prediction model, predict the correlation of parameters through the correlation prediction model, and complete the constraint relationship of parameters. Step 1.2.5: Continuously learn and optimize the association prediction model to ensure that the constraint relationship of the completed parameters matches the actual standard document by ≥90%.
3. The method for constructing a structure vector model for SPEC parameter extraction according to claim 2, characterized in that: Step 2 includes the following sub-steps: Step 2.1: SPEC file preprocessing and corpus parsing; Step 2.2: Construct a parametric entity recognition model; Step 2.3: Define constraint mapping rules: ① Explicit constraint extraction: based on keyword matching; ② Implicit constraint reasoning: combining graph classification relationships.
4. The method for constructing a structure vector model for SPEC parameter extraction according to claim 3, characterized in that: Step 2.1 includes the following sub-steps: Step 2.1.1: Convert the scanned PDF document into text; Step 2.1.2: Parse the table content into structured data of "parameter name-value-unit-sub-item"; Step 2.1.3: The text is segmented using the NLTK tool. After removing stop words, a sentence-level corpus is generated, and keywords for each sub-project are annotated. In the parametric entity recognition model, the input layer takes a corpus sentence plus multi-constraint graph parameter features as input; entity labels are predicted by adding a CRF layer using BERT, and the loss function is: ; Where, x i For the input sentence, y i Here, θ represents the entity label sequence, and θ represents the model parameters. The parameter entity recognition model uses NER technology to extract value ranges, units, etc., performs regular expression validation, and labels sub-projects.
5. The method for constructing a structure vector model for SPEC parameter extraction according to claim 2, characterized in that: Step 3 includes the following sub-steps: Step 3.1: Map the parameter attribute base vector, which includes semantic vector, attribute vector and basic characteristic vector; Semantic vector: Converts the parameter name into a set of numbers, the size of which represents the meaning of the name; Attribute vector: Converts the specific features of the parameter into a set of numbers; Basic feature vector: Combines the semantic vector and the attribute vector to form a combination of numbers that reflects both the parameter name and its specific features, serving as the basis for subsequent calculations. Step 3.2: Merge the constraint relationship vectors; The final vector dimension formula is: Total dimension = Basic feature vector + Constraint extension vector; Step 3.3: Optimize the multi-constraint loss function.
6. The method for constructing a structure vector model for SPEC parameter extraction according to claim 5, characterized in that: Step 3.3 includes the following sub-steps: Step 3.3.1: The total loss function is: Total loss = 0.4 × constraint bias + 0.3 × attribute error + 0.2 × generalization difference + 0.1 × time bias; Among them, 0.4, 0.3, 0.2, and 0.1 are all penalty item weights, and the sum of the weights of all penalty items is always 1; Step 3.3.2: Constraint consistency penalty, i.e., constraint deviation: Constraint deviation = ∑ | Actual correlation degree - Standard correlation degree |; Standard correlation The following weighting function was used to calculate the result: ; in: This indicates whether there are explicit constraint clauses in the standard document; 1 indicates the presence of such clauses, and 0 indicates the absence of such clauses. The implicit constraints obtained from graph reasoning are represented by 1 if they exist and 0 if they do not exist. Forced assignments based on constraint type, such as mandatory constraint = 1, logical / dependency constraint = 0.8, version constraint = 0.6, category constraint = 0.4, optional constraint = 0.2; The co-occurrence frequency of the parameter in standard documents; , , , The weights are adjustable and satisfy: ; Actual correlation The calculation formula is as follows: ; Cosine similarity between two parameter vectors; Indicates whether an explicit constraint clause appears in the text; 1 indicates its presence and 0 indicates its absence. Indicates whether a dependency language pattern is matched; The co-occurrence probability of the parameter in the same sentence or paragraph; α, β, γ, and δ are adjustable hyperparameters that satisfy α+β+γ+δ=1; Step 3.3.3: Attribute matching penalty, i.e., attribute error: Attribute error = the average deviation between the extracted attribute and the standard attribute; Step 3.3.4: Generalization penalty, i.e., generalization difference: Generalization difference = ∑ Vector difference of similar parameters; Set a vector difference threshold; when the vector difference degree > the vector difference threshold, mark it as a conflict. Step 3.3.5: Time constraint penalty, i.e., time deviation: Time deviation = ∑ |Actual time − Standard time| / Standard time.
7. The method for constructing a structure vector model for SPEC parameter extraction according to claim 2, characterized in that: Step 4 includes the following sub-steps: Step 4.1: Construct a sub-item project experience database by dividing the project into "sub-projects → sub-items → parameter groups" according to the hierarchy. The sub-item project experience database is used to store parameter vectors, constraint relationships, historical project cases, and compliance inspection records. Step 4.2: Calculate the performance metrics of the multi-constraint structure vector model. The performance metrics of the multi-constraint structure vector model include parameter extraction accuracy, constraint recognition accuracy, and cross-industry generalization error. Among them, the parameter extraction accuracy rate = (number of correctly extracted parameters / total number of parameters) × 100% ≥ 95%; Accurate parameter extraction means that the parameter name, value range, unit, and other attributes all match the standard document exactly. Constraint identification accuracy = (Number of correctly identified constraints / Total number of constraints) × 100% ≥ 90%; Accurate constraint identification means that the constraint type and associated entities are completely consistent with the standard constraints in the knowledge graph. Cross-industry generalization error: ≤15%, meaning that the vector difference of the same parameter in different engineering types does not exceed 15%; Step 4.3: Output results of the multi-constraint structure vector model: ① Structured parameter vector library; ② The query system of the sub-project experience database supports searching by project type and parameter name; ③ Interfaces: Constraint Query API, Model Deployment API.