A method and system for conflict detection and merging of construction engineering data

Abstract

This invention discloses a method and system for conflict detection and merging of construction engineering data. Under a global multi-active architecture, this invention determines concurrent causal relationships using version vectors, locates differences using content hash trees, and filters out pseudo-conflicts through normalization pre-filtering. It utilizes a domain-wide large language model combined with a knowledge graph and semantic vector model for business semantic analysis, classifying conflicts into three types: contradictory, complementary, or semantically equivalent, and matching them with differentiated merging strategies. Through multi-factor confidence scoring and hierarchical routing, high-confidence data is automatically merged, while low-confidence data is manually reviewed. The merged results are stored on a dual-track system with the original versions. The manual review conclusions feed back into the knowledge base for continuous iteration. This invention achieves intelligent semantic detection and differentiated merging of conflicts in construction engineering data, balancing efficiency with security and traceability.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, specifically to a method and system for conflict detection and merging of construction engineering data. Background Technology

[0002] In a single-machine or master-slave architecture, the MVCC mechanism can resolve concurrent read-write conflicts within the same node through transaction isolation levels. However, in a Geo-Distributed Multi-Active architecture, data centers in different regions can accept writes simultaneously, and data is synchronized between nodes through asynchronous replication. When two regions initiate modifications to the same data object within the same time window, a concurrent write conflict will occur. MVCC cannot determine the causal relationship across nodes and can only rely on timestamps for Last-Write-Wins (LWW) fallback, resulting in the earlier written valid business data being crudely overwritten.

[0003] Some existing distributed databases have introduced conflict-free replication data types (CRDT) to support automatic merging. However, CRDT is only applicable to simple data structures such as counters and sets. It cannot handle structured composite data commonly found in the construction engineering field (such as BIM component attribute tables, contract clause trees, and construction plan documents), and it cannot understand differences in expression such as concrete strength grade C30 and C30 concrete, which are different but semantically equivalent in business.

[0004] Furthermore, existing general conflict resolution mechanisms typically employ precise comparison (ExactMatch) of field-level numerical values ​​or strings, meaning they only determine whether the values ​​of the same field are consistent between two versions; if they are inconsistent, they are marked as conflicting. This approach has two major drawbacks: First, it cannot identify non-essential conflicts such as differences in expression habits or units of measurement, leading to a large number of differences that could be automatically merged being misjudged as conflicts and transferred to manual processing, resulting in high review costs. Second, it cannot identify genuine contradictions at the business logic level (such as the same component being labeled with mutually exclusive material specifications in different versions), causing data that appears to have different values ​​but can actually be merged to be incorrectly marked, while conflicts that truly pose business risks are buried among a large number of false alarms. Summary of the Invention

[0005] To address this, embodiments of the present invention provide a method and system for conflict detection and merging of construction engineering data, thereby solving the technical problems of existing technologies that rely solely on precise comparison at the character or numerical level, which fails to perceive the semantics of construction engineering business, resulting in a large number of non-essential differences being misjudged as conflicts, real business contradictions being submerged, and a lack of differentiated merging strategies.

[0006] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions:

[0007] According to a first aspect of the present invention, a method for conflict detection and merging of construction engineering data is provided, the method comprising:

[0008] Data write operations are captured in real time by data change capture components deployed in data centers in various regions, and a change record carrying a version vector is generated for each change record;

[0009] Compare the version vectors of concurrent versions to determine causal relationships. For versions determined to be concurrent, use a content hash tree to locate differences and extract conflict candidate groups.

[0010] Field-level normalization pre-filtering is performed on the conflict candidates to remove pseudo-conflicts that are consistent after normalization, and the remaining substantive conflict candidates are input into the large model processing layer.

[0011] Using a professional domain language model trained with architectural industry terminology and historical audit cases, the cause of conflict is classified and identified through structured prompts. In conjunction with the architectural industry knowledge graph and domain semantic vector model, business semantic analysis is conducted to determine the conflict into three semantic types: contradiction, complementarity, or semantic equivalence.

[0012] Based on semantic type matching and differentiated merging strategies, the merging schemes are divided by multi-factor confidence scores. High-confidence schemes are automatically merged, while low-confidence schemes are manually reviewed. The merged results and the original versions are stored in a dual-track system.

[0013] Furthermore, for versions determined to be concurrent, content hash trees are used for differential location, including:

[0014] The data objects are divided into layers and blocks according to the semantic structure of the construction engineering data. The hash value of each semantic unit is calculated as a leaf node, and the hash of the parent node is calculated layer by layer upwards until the root hash is reached. When comparing, the root hash is compared first. If they are inconsistent, the hashes of the child nodes are compared layer by layer from top to bottom. Only the inconsistent subtrees are recursively compared downwards until the semantic unit with the difference is located.

[0015] Furthermore, field-level normalization pre-filtering is performed on conflict candidates to eliminate pseudo-conflicts that are consistent after normalization, including:

[0016] Numeric fields are uniformly parsed as floating-point numbers, and date fields are uniformly parsed as standard date formats; the unit conversion factor table is queried to convert values ​​of different units to the base unit; the construction industry thesaurus is queried to replace non-standard terms with standard terms; fields with consistent values ​​after normalization are judged as non-substantial conflicts and skipped, while fields with differences are marked as candidates for substantial conflicts.

[0017] Furthermore, the causes of conflict are categorized and identified through structured suggestion engineering, including:

[0018] For each candidate of substantial conflict, a structured prompt word is constructed, which includes a system instruction segment, a conflict content segment, a version metadata segment, a domain knowledge injection segment, a few-sample example segment, and an output format definition segment. The few-sample example is obtained by retrieving similar cases from the historical review knowledge base using the nearest neighbor algorithm. Based on the prompt word, the large model outputs a structured result containing the cause type, confidence level, judgment reason, and supporting evidence, and performs majority voting multiple times in parallel for the same conflict to improve stability.

[0019] Furthermore, the business semantic analysis adopts a joint analysis mechanism of knowledge graph, semantic vector and large model: first, entity recognition and term linking are performed on the values ​​of the conflicting parties and mapped to knowledge graph nodes; second, the cosine similarity of the domain semantic vectors of the values ​​of the two parties is calculated; finally, the content of the two parties, the knowledge graph linking results and the similarity score are input into the domain large model and it gives the final semantic relationship determination.

[0020] Furthermore, the method also includes:

[0021] The decision records reviewed by the human reviewer are accumulated as labeled samples in the training set. When the number of new samples reaches a preset threshold or when the time since the last fine-tuning exceeds a preset time, fine-tuning is triggered. The low-rank adaptation method is used to efficiently fine-tune the parameters of the domain-wide model. The newly labeled synonym pairs are added to the comparative learning sample set to retrain the semantic vector model.

[0022] According to a second aspect of the present invention, a conflict detection and merging system for construction engineering data is provided, the system comprising:

[0023] The data access layer module is used to track data version changes and locate conflict locations in a global multi-active architecture;

[0024] The large model processing layer module is used to identify conflict causes, analyze business semantics, and determine semantic types using a domain-wide large language model.

[0025] The result execution layer module is used to split the execution of the merging scheme based on the confidence score and implement dual-track storage.

[0026] Furthermore, the data access layer module includes a data change capture component deployed in data centers in various regions, used to monitor write operations of the local database in real time and generate change records carrying version vectors; the data access layer module also includes a hash tree difference location unit, used to construct a content hash tree for building engineering data objects in a hierarchical and block manner according to semantic structure, and to locate the difference semantic unit by comparing the root hash of the hash tree with the hash of the child nodes.

[0027] Furthermore, the large model processing layer module executes five stages in a serial pipeline: conflict location, conflict cause identification, business semantic analysis, semantic type judgment, and merging strategy generation; the business semantic analysis relies on the construction industry knowledge graph and the domain semantic vector model for joint analysis; the semantic type judgment adopts a hybrid mechanism that combines rule pre-filtering and large model fine judgment.

[0028] Furthermore, the result execution layer module includes a confidence scoring unit, an automatic merging unit, a manual review queue unit, and a dual-track storage unit. The confidence scoring unit calculates the comprehensive confidence score obtained by weighted summation of four factors: the confidence score of the large model output, semantic vector similarity, knowledge graph matching strength, and consistency with historical cases. Based on a threshold, the merging task is distributed to the automatic merging unit or the manual review queue unit. The dual-track storage unit writes the merging result into the main data table as the active version, writes each original version into the conflict archive table as an independent record, and generates an immutable version operation log.

[0029] The embodiments of the present invention have the following advantages:

[0030] This invention, in a global multi-active architecture, determines the causal relationship of concurrent writes through version vectors. It employs a content hash tree to hierarchically segment and block construction engineering data according to semantic structure for difference localization. Field-level normalization pre-filtering is performed on located conflict candidates to eliminate pseudo-conflicts caused by unit differences and synonym differences. A professional domain language model trained with construction industry terminology and historical review cases is used to classify and identify conflict causes through structured engineering prompts. Business semantic analysis is conducted in conjunction with a construction industry knowledge graph and a domain semantic vector model, classifying conflicts into three types: contradictory, complementary, or semantically equivalent, and matching differentiated merging strategies accordingly. Merging schemes are graded and routed through multi-factor confidence scoring: high-confidence schemes are automatically merged, while low-confidence schemes are manually reviewed. The merged results and the original version are stored in a dual-track system. This invention achieves intelligent semantic detection and differentiated merging of construction engineering data conflicts, maximizing the automatic merging rate while ensuring data security and traceability. Attached Figure Description

[0031] To more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely exemplary, and those skilled in the art can derive other embodiments based on the provided drawings without creative effort.

[0032] The structures, proportions, sizes, etc. illustrated in this specification are only for the purpose of assisting those skilled in the art in understanding and reading the content disclosed herein, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0033] Figure 1 A schematic diagram of the overall technical process of a conflict detection and merging system for building engineering data provided in an embodiment of the present invention;

[0034] Figure 2 This is a schematic diagram of the logical architecture of a conflict detection and merging system for building engineering data provided in an embodiment of the present invention. Detailed Implementation

[0035] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0036] The conflict detection and merging system for construction engineering data of this invention is deployed in a global multi-active architecture, meaning that at least two regional data centers simultaneously provide data writing services, and data synchronization between regional data centers is achieved through asynchronous replication links. The system is generally divided into three layers: a data access layer, a large model processing layer, and a result execution layer. The data access layer is deployed in each regional data center, using a ChangeDataCapture (CDC) component to monitor write operations in the local database in real time. The large model processing layer is deployed on a central server or a primary data center is selected as the processing node, receiving conflict candidate data from various regional data centers and performing semantic analysis. The result execution layer receives the output results from the large model processing layer and performs merging, storage, and distribution operations. The three layers are connected through standardized data interfaces, forming a complete closed loop of conflict perception, semantic analysis, differentiated handling, and feedback iteration.

[0037] Before the system goes live, the following preparations must be completed: Deploy data change capture components and configure database connections in each data center; build a construction industry terminology database, using a graph database to store standard construction terms and their synonym entries, and establish hierarchical, compositional, and normative clause reference relationships between nodes; build a historical review knowledge base, storing historical review cases in the form of sample pairs of conflict feature vectors and manual decision labels; deploy a domain-specific large language model, which is based on a general pre-trained large model, using construction industry standard and normative corpora, BIMIFC pattern definition documents, construction plan texts, and contract clause texts for domain-adaptive training, and supervised fine-tuning through labeled samples in the historical review knowledge base; deploy a domain-specific semantic vector model, which is based on the Sentence-BERT architecture and fine-tuned on the construction industry corpus using a contrastive learning method.

[0038] refer to Figure 1 and Figure 2 This invention discloses a conflict detection and merging system for construction engineering data. The system includes: a data access layer module, used to track data change versions and locate conflict locations under a global multi-active architecture;

[0039] The large model processing layer module is used to identify conflict causes, analyze business semantics, and determine semantic types using a domain-wide large language model.

[0040] The result execution layer module is used to split the execution of the merging scheme based on the confidence score and implement dual-track storage.

[0041] The following example, using the detection and merging of BIM component attribute conflicts in an overseas port construction project, illustrates the specific implementation process of the method of this invention.

[0042] The international engineering contracting company has data nodes in its Asian data center (Node A) and European data center (Node B). An engineer from the design institute at Node A changed the material specification field of a retaining wall component from C30 concrete to C35 concrete because a design change increased the strength grade requirement for the component. At Node B, the construction company's data clerk changed the same material specification field of the same component from C30 concrete to C30 concrete within the same time window, because the data clerk habitually uses industry abbreviations. When the changes from both locations reached the other node via asynchronous replication, the system detected two concurrent versions of the same component and the same field.

[0043] Data access layer processing:

[0044] At the data access layer, the system captures change records of this component by nodes A and B through a data change capture component. Each write operation generates a change record, and each change record carries a version vector. The version vector is a mapping from node identifiers to logical counters, in the form of {NodeA:12, NodeB:8}, where the counter value represents the transaction count value that the node has confirmed up to the current write operation. Node A's change record carries a version vector VVA={NodeA:12, NodeB:8}, and node B's change record carries a version vector VVB={NodeA:10, NodeB:9}.

[0045] The system performs version vector causality determination: it iterates through the union of all node identifiers in the two version vectors, and compares the corresponding count values ​​in the two version vectors for each node. At node A, the counter value of VVA (12) is greater than the counter value of VVB (10); at node B, the counter value of VVA (8) is less than the counter value of VVB (9). Both flags, greater and less, are True, indicating a partial order incomparable relationship between the two versions. That is, the two versions originate from a common ancestor but evolve independently, without a direct causal relationship. The system determines this as a concurrent write conflict, triggering the subsequent large-scale model semantic analysis process.

[0046] The system then divides the BIM component attribute table into blocks according to IFC entity type and component identifier, with each IFC entity and its attribute set as a semantic unit. For each semantic unit, the SHA-256 hash value of its content is calculated as a leaf node. The hash values ​​of child nodes are then concatenated upwards layer by layer to obtain the parent node hash, ultimately yielding the root hash. The system compares the root hashes of the content hash trees of node A and node B, finding inconsistencies. It then compares the hashes of child nodes layer by layer from top to bottom, recursively tracing down only the inconsistent subtrees, eventually pinpointing the difference to the material specification field. The system extracts conflict candidate groups: version A has a value of C35 concrete, while version B has a value of C30 concrete.

[0047] Field-level normalization pre-filtering:

[0048] The system performs field-level normalization pre-filtering on conflict candidates. First, type normalization is performed; since the field is text-based, no conversion is needed. Next, the unit conversion factor table is queried; both fields express concrete strength grades, with no unit difference. Finally, the construction industry thesaurus is queried to pre-map concrete to C30 concrete, normalizing C30 concrete to C30 concrete while leaving C35 concrete unchanged. After normalization, version A (C35 concrete) and version B (C30 concrete) have inconsistent values, indicating a substantial conflict, which is then processed by the large model layer. This normalization pre-filtering mechanism can filter out approximately 60% to 70% of non-essential conflicts, effectively reducing the load on the large model layer.

[0049] Large Model Processing Layer – Structured Cue Word Construction:

[0050] For substantial conflict candidates that have passed the normalized pre-filtering, the system constructs a structured cue word. This cue word contains the following components:

[0051] The system instruction segment declares that the current task being processed is a construction engineering data conflict detection task, and defines six types of conflict inducing labels: differences in expression habits (different terms or abbreviations for the same meaning), different data sources (different participants entering data, leading to version forks), missing information dimensions (one party supplements fields that the other party did not fill in), contradictory business logic (the values ​​of the two versions are mutually exclusive at the engineering physical or specification level), differences in measurement units (numerical equivalents but different units), and misaligned version timelines (one party modifies based on outdated reference data).

[0052] The conflict content section contains, in JSON format, the field name, material specifications, version A value of C35 concrete, version B value of C30 concrete, and the complete semantic unit context to which the field belongs (the component type is retaining wall, the discipline is structural engineering, and the associated fields include component size and reinforcement information).

[0053] The version metadata section, in JSON format, includes the source region of version A as Asia, the operator role as a design institute engineer, and the operation timestamp; and the source region of version B as Europe, the operator role as a construction party data clerk, and the operation timestamp.

[0054] The domain knowledge injection section retrieves standard terminology definitions and specification clauses related to concrete strength grades from the construction industry terminology database and injects them into the definitions and applicable conditions of C30 and C35 strength grades in the "Code for Design of Concrete Structures" GB 50010.

[0055] In the few-sample example section, the feature vector of the current conflict is used as the query. The nearest neighbor algorithm retrieves the three most similar historical cases from the historical review knowledge base. The feature vector is constructed by concatenating field name embedding vectors, semantic vectors of the conflicting parties' values, and metadata encoding vectors. Nearest neighbor retrieval is accelerated using a hierarchical, navigable small-world graph index. Each returned case includes a description of the conflict content, the type of trigger determined by human intervention, the reasoning behind the determination, and the merging process.

[0056] The output format definition section specifies that the large model outputs a JSON structured result containing the fields cause_type (cause type), confidence (confidence level, value 0 to 1), reasoning (reason for judgment), and evidence (supporting evidence).

[0057] Majority voting mechanism:

[0058] The system sends three independent inference requests in parallel to the domain-wide model using the same structured prompts, with all three requests using the same model parameter settings. After receiving the three returned structured JSON results, the system performs a majority vote: it counts the frequency of each cause type in the three results and selects the type with the most occurrences as the candidate decision; if the type appears at least twice (i.e., majority agreement), the decision is adopted, and the average of the corresponding confidence scores is calculated as the final confidence score output by the large model; if the three results are different, the result with the highest confidence score is selected, and a discount factor of 0.8 is applied to this result to reflect the uncertainty caused by the voting inconsistency.

[0059] In this embodiment, the results of the three calls were consistent, all determining the cause type as a business logic contradiction, with confidence levels of 0.92, 0.91 and 0.93 respectively. The final output confidence level of the large model was 0.92. The reason for the determination was that C30 and C35 are different intensity levels and cannot be simultaneously established at the engineering physical level. They belong to a real contradiction rather than a difference in expression.

[0060] Business semantic analysis—knowledge graphs and semantic vectors:

[0061] The system performs business semantic analysis. First, it performs entity recognition and terminology linking on the conflicting values. A bidirectional long short-term memory network combined with a conditional random field model is used to identify terminology entity fragments from the text of the field values, and then searches for matches in the knowledge graph. The knowledge graph is stored in a graph database format, with node types including terminology nodes, material nodes, component nodes, specification clause nodes, and process node. Edge types include synonym relationships, hierarchical relationships, composition relationships, and reference relationships. Terminology linking uses a Trie tree index to accelerate prefix matching and supports fuzzy matching with an edit distance of no more than two. For each terminology fragment, the cosine similarity of its context with the semantic vector of the definition text of each candidate node in the knowledge graph is calculated, and the candidate with the highest similarity is selected as the link result. In this embodiment, C35 concrete and C30 concrete are linked to two different material strength grade nodes in the knowledge graph, and there is no synonym or hierarchical relationship between them.

[0062] Subsequently, the system inputs the complete text values ​​of both conflicting parties into the domain semantic vector model to obtain their respective high-dimensional semantic vectors and calculate their cosine similarity. The domain semantic vector model is based on the Sentence-BERT architecture and fine-tuned using a contrastive learning method on corpora of architectural industry standards and specifications, BIMIFC pattern definition documents, and construction scheme corpora. Training uses the InfoNCE loss function with a hyperparameter τ of 0.05, an AdamW optimizer, a learning rate of 2e-5, a batch size of 64, and is trained for 10 epochs until the accuracy on the validation set no longer improves. In this embodiment, the cosine similarity of the semantic vectors of C35 concrete and C30 concrete is 0.72, which is below the 0.80 threshold, indicating a significant semantic difference between the two.

[0063] Finally, the system inputs the content of both sides of the conflict, the knowledge graph linking results (the two nodes belong to different strength levels and have no synonym relationship), and the semantic vector similarity score (0.72) into the domain big model. The big model then combines the business context of construction engineering to give the final semantic relationship determination.

[0064] Semantic type determination – rule pre-filtering and large model fine-tuning:

[0065] This embodiment employs a hybrid mechanism combining rule-based pre-filtering and large-scale model-based fine-tuning. In the rule-based pre-filtering stage: after normalization, the values ​​of the two components (C35 concrete and C30 concrete) are inconsistent; the semantic vector similarity is 0.72, which is below the high similarity threshold of 0.95; and both components have the same set of fields (both are material specification fields with no inclusion relationship). Subsequently, the system queries the engineering physical constraint rule base, which stores the physical logic and specification requirements in the field of building engineering. When the system matches an engineering physical constraint where the material strength grade of the same component has a unique value, and the values ​​of both conflicting components violate this constraint, the rule-based pre-filter directly determines it as a contradiction type, without needing to proceed to the large-scale model-based fine-tuning stage.

[0066] Merge strategy generation:

[0067] Because the semantic type is contradictory, the system adopts a priority-based decision-making strategy. The system queries the construction engineering business priority rule base, which stores rules such as design phase data having higher priority than construction phase data, mandatory specification provisions having higher priority than recommended provisions, and supervision approval data having higher priority than construction self-reported data. In this embodiment, the system matches the rule that design phase data has higher priority than construction phase data and the rule that design change approval data has higher priority than daily construction reporting data. It determines that the value of node A, C35 concrete, is used as the merged result, with the selection criterion being that design changes take precedence over construction descriptions.

[0068] If the semantic types are semantically equivalent, the system will adopt a standardized merging strategy, query the terminology database, and uniformly express the merged results as standard and normative terms, recording the terminology mapping relationship; if they are complementary, the system will adopt a field-union-set merging strategy, taking the union of the unique fields of both parties and performing integrity verification.

[0069] Multifactor confidence scoring and triage:

[0070] The system calculates the overall confidence level, which is obtained by weighted summation of four factors.

[0071] The first factor is the confidence score P_llm of the large model output, which is 0.92 after majority voting in this embodiment, with a weight of 0.4.

[0072] The second factor is the semantic vector similarity S_embed, which is 0.72 in this embodiment, with a weight of 0.2.

[0073] The third factor is the knowledge graph matching strength K_kg. Both conflicting parties were successfully mapped to knowledge graph nodes, and the two nodes belong to different material strength levels. Although they have no synonym relationship, they were successfully mapped. The value is 1.0, and the weight is 0.2.

[0074] The fourth factor is historical case consistency (H_hist). The top five resolved cases most similar to the current conflict are retrieved from the historical audit knowledge base. All five cases support prioritizing design changes in their merged solutions, resulting in a consistency rate of 1.0 and a weight of 0.2.

[0075] The overall confidence level C = 0.4 × 0.92 + 0.2 × 0.72 + 0.2 × 1.0 + 0.2 × 1.0 = 0.368 + 0.144 + 0.2 + 0.2 = 0.912.

[0076] The system presets a high confidence threshold T_high of 0.85 and a low confidence threshold T_low of 0.60. In this embodiment, a comprehensive confidence score of 0.912, reaching or exceeding the high confidence threshold, triggers the automatic merging process. If the comprehensive confidence score is between T_low and T_high, it will enter the automatic merging process but be marked for post-event sampling; if it is below T_low, it will enter the manual review process. The thresholds can be dynamically adjusted according to the data's criticality level. Critical data (involving structural safety, fire protection design, etc.) is raised to a high confidence score of 0.90 and a low confidence score of 0.70, while general data is lowered to a high confidence score of 0.80 and a low confidence score of 0.50.

[0077] Dual-track storage:

[0078] The system employs a dual-track storage mechanism to guarantee atomicity within the same database transaction. First, the merged C35 concrete is written to the component material specification field of the master data table using UPSERT semantics, serving as the active version for use by the business system. Then, the original version A's C35 concrete and the original version B's C30 concrete are written separately to the conflict archive table. Each record includes a unique archive record identifier, a unique data object identifier, a snapshot of the original value, a source version vector, a source region node identifier, an operator identifier, an operation timestamp, a conflict type (contradictory), and a merge scheme identifier. Simultaneously, an immutable version operation log is generated using an append-only method, containing a unique log identifier, operation type (semantic merge), pre-operation value (original values ​​for both parties), post-operation value (C35 concrete), conflict type (contradictory), merge basis (design change takes precedence over construction description), overall confidence level (0.912), factor scores (0.92, 0.72, 1.0, 1.0), execution timestamp, and the associated conflict archive record identifier. If any of these three writes fails, the entire process is rolled back.

[0079] Manual review and feedback closed loop:

[0080] In this embodiment, the large model's judgment result is consistent with the human expectation (both agree that C35 concrete should be used), and this case is accumulated as a correctly labeled sample in the historical review knowledge base. If a conflict enters the manual review process due to a lower overall confidence level than the low confidence threshold, the system pushes the conflict details and the large model analysis results to the background manual review queue, where reviewers will make a final decision after review.

[0081] The accumulation of labeled samples supports continuous iterative optimization of the model. When the number of new samples reaches a preset threshold (e.g., 512) or exceeds a preset number of days since the last fine-tuning (e.g., 30 days), the fine-tuning process is automatically triggered. Fine-tuning uses the Low-Rank Adaptation (LoRA) method, freezing the basic parameters of the pre-trained model and updating only the parameters of the low-rank factorization matrix. The rank r is set to 8, the learning rate is 1e-4, and training lasts for 3 epochs. Simultaneously, newly labeled synonym pairs are added to the comparative learning sample set, and the semantic vector model is retrained. After fine-tuning, accuracy and F1 score are evaluated on the validation set. If the new model outperforms the current online model, a new version is released; otherwise, the old model is retained, and the reason for failure is recorded. The system retains a snapshot of the model for each fine-tuned version. If the online accuracy drops beyond a preset threshold after the new model is released, a rollback to the previous version is automatically triggered.

[0082] Through the above mechanism, the system has the ability to self-evolve, and the accuracy of judgment continues to improve with the increase of usage time, while the workload of manual review gradually decreases. It realizes intelligent semantic detection and differentiated merging of data conflicts in construction projects, and maximizes the automatic merging rate while ensuring data security and traceability.

[0083] Corresponding to the aforementioned conflict detection and merging system for construction engineering data, this invention also discloses a conflict detection and merging method for construction engineering data. The following details a conflict detection and merging method for construction engineering data disclosed in this invention, in conjunction with the aforementioned conflict detection and merging system for construction engineering data.

[0084] This invention discloses a conflict detection and merging method for construction engineering data. By using data change capture components deployed in data centers in various regions to capture data writing operations in real time, a change record carrying a version vector is generated for each change record.

[0085] Compare the version vectors of concurrent versions to determine causal relationships. For versions determined to be concurrent, use a content hash tree to locate differences and extract conflict candidate groups.

[0086] Field-level normalization pre-filtering is performed on the conflict candidates to remove pseudo-conflicts that are consistent after normalization, and the remaining substantive conflict candidates are input into the large model processing layer.

[0087] Using a professional domain language model trained with architectural industry terminology and historical audit cases, the cause of conflict is classified and identified through structured prompts. In conjunction with the architectural industry knowledge graph and domain semantic vector model, business semantic analysis is conducted to determine the conflict into three semantic types: contradiction, complementarity, or semantic equivalence.

[0088] Based on semantic type matching and differentiated merging strategies, the merging schemes are divided by multi-factor confidence scores. High-confidence schemes are automatically merged, while low-confidence schemes are manually reviewed. The merged results and the original versions are stored in a dual-track system.

[0089] Although the present invention has been described in detail above with general descriptions and specific embodiments, modifications or improvements can be made to it, which will be obvious to those skilled in the art. Therefore, all such modifications or improvements made without departing from the spirit of the present invention fall within the scope of protection claimed by the present invention.

Claims

1. A method for conflict detection and merging of construction engineering data, characterized in that, The method includes: Data write operations are captured in real time by data change capture components deployed in data centers in various regions, and a change record carrying a version vector is generated for each change record; Compare the version vectors of concurrent versions to determine causal relationships. For versions determined to be concurrent, use a content hash tree to locate differences and extract conflict candidate groups. Field-level normalization pre-filtering is performed on the conflict candidates to remove pseudo-conflicts that are consistent after normalization, and the remaining substantive conflict candidates are input into the large model processing layer. Using a professional domain language model trained with architectural industry terminology and historical audit cases, the cause of conflict is classified and identified through structured prompts. In conjunction with the architectural industry knowledge graph and domain semantic vector model, business semantic analysis is conducted to determine the conflict into three semantic types: contradiction, complementarity, or semantic equivalence. Based on semantic type matching and differentiated merging strategies, the merging schemes are divided by multi-factor confidence scores. High-confidence schemes are automatically merged, while low-confidence schemes are manually reviewed. The merged results and the original versions are stored in a dual-track system.

2. The method for conflict detection and merging of construction engineering data as described in claim 1, characterized in that, For versions identified as concurrent, a content hash tree is used for difference localization, including: The data objects are divided into layers and blocks according to the semantic structure of the construction engineering data. The hash value of each semantic unit is calculated as a leaf node, and the hash of the parent node is calculated layer by layer upwards until the root hash is reached. When comparing, the root hash is compared first. If they are inconsistent, the hashes of the child nodes are compared layer by layer from top to bottom. Only the inconsistent subtrees are recursively compared downwards until the semantic unit with the difference is located.

3. The method for conflict detection and merging of construction engineering data as described in claim 1, characterized in that, Perform field-level normalization pre-filtering on conflict candidates to eliminate pseudo-conflicts that are consistent after normalization, including: Numeric fields are uniformly parsed as floating-point numbers, and date fields are uniformly parsed as standard date formats; the unit conversion factor table is queried to convert values ​​of different units to the base unit; the construction industry thesaurus is queried to replace non-standard terms with standard terms; fields with consistent values ​​after normalization are judged as non-substantial conflicts and skipped, while fields with differences are marked as candidates for substantial conflicts.

4. The method for conflict detection and merging of construction engineering data as described in claim 1, characterized in that, The causes of conflict are categorized and identified through structured suggestion engineering, including: For each candidate of substantial conflict, a structured prompt word is constructed, which includes a system instruction segment, a conflict content segment, a version metadata segment, a domain knowledge injection segment, a few-sample example segment, and an output format definition segment. The few-sample example is obtained by retrieving similar cases from the historical review knowledge base using the nearest neighbor algorithm. Based on the prompt word, the large model outputs a structured result containing the cause type, confidence level, judgment reason, and supporting evidence, and performs majority voting multiple times in parallel for the same conflict to improve stability.

5. The method for conflict detection and merging of construction engineering data as described in claim 1, characterized in that, The business semantic analysis adopts a joint analysis mechanism of knowledge graph, semantic vector and big model: First, entity recognition and term linking are performed on the values ​​of the conflicting parties and mapped to knowledge graph nodes. Second, the cosine similarity of the domain semantic vectors of the values ​​of the two parties is calculated. Finally, the content of the two parties, the knowledge graph linking results and the similarity score are input into the domain big model and it gives the final semantic relationship judgment.

6. The method for conflict detection and merging of construction engineering data as described in claim 1, characterized in that, The method further includes: The decision records reviewed by the human reviewer are accumulated as labeled samples in the training set. When the number of new samples reaches a preset threshold or when the time since the last fine-tuning exceeds a preset time, fine-tuning is triggered. The low-rank adaptation method is used to efficiently fine-tune the parameters of the domain-wide model. The newly labeled synonym pairs are added to the comparative learning sample set to retrain the semantic vector model.

7. A conflict detection and merging system for construction engineering data, characterized in that, The system includes: The data access layer module is used to track data version changes and locate conflict locations in a global multi-active architecture; The large model processing layer module is used to identify conflict causes, analyze business semantics, and determine semantic types using a domain-wide large language model. The result execution layer module is used to split the execution of the merging scheme based on the confidence score and implement dual-track storage.

8. The conflict detection and merging system for construction engineering data as described in claim 7, characterized in that, The data access layer module includes a data change capture component deployed in data centers in various regions, used to monitor write operations in the local database in real time and generate change records carrying version vectors; the data access layer module also includes a hash tree difference location unit, used to construct a content hash tree by hierarchically dividing the construction engineering data objects into layers according to semantic structure, and to locate the difference semantic units by comparing the root hash and the child node hashes of the hash tree.

9. A conflict detection and merging system for construction engineering data as described in claim 7, characterized in that, The large model processing layer module executes five stages in a serial pipeline: conflict location, conflict cause identification, business semantic analysis, semantic type judgment, and merging strategy generation. The business semantic analysis relies on the construction industry knowledge graph and the domain semantic vector model for joint analysis. The semantic type judgment adopts a hybrid mechanism that combines rule pre-filtering and large model fine judgment.

10. A conflict detection and merging system for construction engineering data as described in claim 7, characterized in that, The result execution layer module includes a confidence scoring unit, an automatic merging unit, a manual review queue unit, and a dual-track storage unit. The confidence scoring unit calculates the comprehensive confidence score obtained by weighted summation of four factors: the confidence score of the large model output, the semantic vector similarity, the knowledge graph matching strength, and the consistency of historical cases. Based on the threshold, the merging task is diverted to the automatic merging unit or the manual review queue unit. The dual-track storage unit writes the merged result into the main data table as the active version, writes each original version into the conflict archive table as an independent record, and generates an immutable version operation log.

Images