Engineering problem response method, apparatus, and medium based on ai and traceable engineering document knowledge base

Abstract

Embodiments of the present application disclose an engineering problem response method and device based on AI and a traceable engineering document knowledge base, and a medium. The method comprises: obtaining an engineering problem response request including an engineering problem for an engineering document; determining a query intention based on the engineering problem, and determining one or more search topics based on the query intention; performing vector search and graph relationship query on the engineering document knowledge base based on the query intention and the search topics to obtain candidate search results; performing graph relationship verification and / or cross-document verification on the candidate search results to obtain verified search results; and generating an engineering response result based on the verified search results. The engineering document knowledge base comprises metadata records, content vector representations, graph entity relationships, and original document objects associated based on source document positioning information of a structured document unit, so that the engineering response result can be traced back to the corresponding original engineering document location.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence, data processing, knowledge graphs and construction project management, and in particular to engineering problem response methods, devices and media based on AI and a traceable engineering document knowledge base. Background Technology

[0002] In the management of curtain wall engineering, building engineering, and other engineering projects, engineering documents such as contracts, specifications, drawings, calculation sheets, design specifications, visa documents, and review comments are typically numerous, from diverse sources, and vary significantly in format. Some engineering documents are copyable text, while others are scanned copies, image files, or screenshots of drawings. Some documents also contain a mixture of tables, formulas, drawing annotations, title blocks, drawing frames, and comments. These engineering documents are likely to be frequently consulted and referenced in project design, construction management, specification review, contract performance, and technical verification.

[0003] In existing applications, the correspondence between the processed results and the original project document content may still be unstable after automatic processing. For project documents containing complex layouts, tables, formulas, drawing areas, or scanned content, the processed results may exhibit incomplete content presentation, difficulty in verifying chart and formula information, and discrepancies between drawing-related information and the textual basis. When reviewing search or processed results, engineers may still need to reopen the original document and manually verify the corresponding pages, clauses, drawing content, or calculation basis.

[0004] In engineering knowledge management scenarios, the same engineering problem often involves multiple documents, versions, clauses, or professional areas. For example, issues related to curtain wall fire protection, energy conservation, seismic resistance, and material performance may simultaneously involve project contracts, national regulations, industry standards, enterprise standards, and drawing specifications. Existing search or question-and-answer results may not adequately present the completeness, scope of application, version differences, duplicate conclusions, or conflicting content of the engineering basis. Engineering personnel still need to conduct manual judgment and verification by combining multiple original documents.

[0005] Furthermore, in actual engineering operations, users often raise questions about new engineering documents immediately after uploading them, or need to query newly uploaded documents along with existing project data. In such real-time processing scenarios, the timeliness and completeness of newly uploaded documents participating in the current problem-solving process together with existing engineering data may still be insufficient, and the engineering response results may not adequately highlight the differences between data from different sources.

[0006] Therefore, how to ensure that the engineering problem response process can simultaneously consider semantic retrieval results, structured relationships between engineering documents, cross-document basis verification, and backtracking of the original document location after complex engineering documents have been structured, thereby improving the reliability of engineering problem response results, the completeness of basis presentation, and the verifiability of results, has become a technical problem that needs to be solved in the field of intelligent engineering document processing. Summary of the Invention

[0007] This application provides an engineering problem response method, device, and medium based on AI and a traceable engineering document knowledge base, aiming to improve the reliability of engineering problem response results, the completeness of evidence presentation, and the traceability of results.

[0008] In a first aspect, embodiments of this application provide an engineering problem response method based on AI and a traceable engineering document knowledge base, comprising: obtaining an engineering problem response request, wherein the engineering problem response request includes an engineering problem concerning an engineering document; determining a query intent based on the engineering problem, and when the query intent indicates that the engineering problem requires multi-target retrieval, decomposing the engineering problem into multiple retrieval topics; otherwise, determining the engineering problem as a single retrieval topic; and performing vector retrieval and graph relationship query on the engineering document knowledge base based on the query intent and the retrieval topic to obtain candidate retrieval results; wherein the engineering document knowledge base includes metadata associated with structured document units. The system includes records, content vector representations, graph entity relationships, and original document objects, with the association between the structured document unit and the metadata records, content vector representations, graph entity relationships, and original document objects established based on the source document location information of the structured document unit; at least one verification process, namely graph relationship verification and cross-document verification, is performed on the candidate search results to obtain verified search results; an engineering response result is generated based on the verified search results; and based on the association relationships in the engineering document knowledge base, the engineering response result is associated with the corresponding source document location information and output, enabling the engineering response result to trace back to the corresponding original engineering document location.

[0009] In some implementations, the engineering document knowledge base is constructed through the following steps: acquiring the engineering document to be processed; performing layout recognition, character-level spatial correction, content block segmentation, and multimodal content recognition on the engineering document to be processed to obtain multiple structured document units; generating metadata records, content vector representations, and graph entity relationships corresponding to each structured document unit based on the multiple structured document units; and establishing association relationships between the metadata records, content vector representations, graph entity relationships, and original document objects corresponding to the same structured document unit based on the source document location information of each structured document unit, thereby forming the engineering document knowledge base.

[0010] In some implementations, the engineering problem response request is a composite processing request, which further includes the engineering document to be processed. Before performing vector retrieval and graph relationship query on the engineering document knowledge base, the method further includes: performing layout recognition, character-level spatial correction, content block segmentation, and multimodal content recognition on the engineering document to be processed to obtain multiple structured document units; updating the metadata records, content vector representations, graph entity relationships, and association relationships with the original document objects in the engineering document knowledge base based on the source document location information of the multiple structured document units; and performing vector retrieval and graph relationship query on the updated engineering document knowledge base based on the query intent and the search topic.

[0011] Secondly, embodiments of this application also provide a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect.

[0012] Thirdly, embodiments of this application also provide a storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, cause the processor to perform the method described in the first aspect.

[0013] The beneficial effects of the embodiments of this application are as follows:

[0014] In the engineering problem response process, the processing end determines the query intent and retrieval topic based on the engineering problem, and performs vector retrieval and graph relationship query based on the engineering document knowledge base. After performing at least one verification process, such as graph relationship verification and cross-document verification, on the candidate retrieval results, an engineering response result is generated. The engineering response result is then associated with the corresponding source document location information and output, ensuring that the engineering response result takes into account semantic relevance, engineering relationship constraints, and original evidence backtracking, thereby improving the reliability, evidence presentation completeness, and result traceability of the engineering problem response result. Furthermore, by performing layout recognition, character-level spatial correction, content block segmentation, and multimodal content recognition on the engineering document to be processed, structured document units carrying content data, block types, and source document location information are obtained. Based on these structured document units, corresponding metadata records, content vector representations, and graph entity relationships are generated. Then, using the source document location information as the association basis, association relationships are established between the metadata records, content vector representations, graph entity relationships, and original document objects corresponding to the same structured document unit, enabling the engineering document knowledge base to perform bidirectional backtracking between structured document units, content vector representations, graph entity relationships, and original document objects. For composite processing requests that include engineering documents to be processed and engineering problems, the system can also update the engineering document knowledge base based on newly acquired structured document units before responding to the current engineering problem. This allows newly uploaded engineering documents to participate in the retrieval, verification, and response output of the current engineering problem, thereby improving the timeliness and completeness of engineering response results in real-time processing scenarios. Attached Figure Description

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

[0016] Figure 1 A schematic diagram illustrating the construction steps of the engineering document knowledge base in the engineering problem response method based on AI and a traceable engineering document knowledge base provided in the embodiments of this application;

[0017] Figure 2 A flowchart illustrating the engineering problem response method based on AI and a traceable engineering document knowledge base provided in this application embodiment;

[0018] Figure 3 A flowchart illustrating a composite request scenario in the engineering problem response method based on AI and a traceable engineering document knowledge base provided in this application embodiment;

[0019] Figure 4This is a schematic block diagram of computer device hardware provided for an embodiment of this application. Detailed Implementation

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

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

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

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

[0024] In the management of curtain wall engineering, building engineering, and other engineering projects, engineering documents such as contracts, specifications, drawings, calculation sheets, design specifications, and visa documents often exist in various forms. Some engineering documents are copyable text, some are scanned copies or images, and some contain a mixture of tables, formulas, drawing annotations, title blocks, drawing frames, and commentary information. Existing document processing methods typically only perform single-point recognition on a certain type of content, or simply convert the entire document into plain text for the retrieval model to use. This results in a lack of stable correlation between spatial locations, drawing areas, table structures, clause levels, and original document objects within the document. When it is necessary to subsequently search for a specific specification clause, verify a design conclusion, locate a specific original text position, or review a certain engineering basis, the system often can only provide similar results at the text level, making it difficult to return to the specific page number, area, clause, or image location of the original engineering document.

[0025] Based on the above findings, one embodiment of this application provides an engineering problem response method based on AI and a traceable engineering document knowledge base. This method performs engineering problem retrieval, verification, response generation, and original text backtracking output based on the engineering document knowledge base. For ease of understanding, the construction method of the engineering document knowledge base will be explained below.

[0026] like Figures 1 to 3 As shown, in some embodiments, the engineering document knowledge base can be obtained through the following construction steps. This construction step can be performed by a processing terminal. The processing terminal can be an internally deployed server, an engineering document processing platform, a cloud server, a local server, an edge computing device, or a processing system formed by the collaboration of multiple computing nodes. The specific deployment form of the processing terminal does not affect the execution of the method in this embodiment, as long as it can complete the acquisition of engineering documents, document structuring processing, data association, and knowledge base construction.

[0027] The construction process may include the following steps.

[0028] Step S101: Obtain the project document to be processed.

[0029] The engineering documents to be processed are engineering materials that need to be incorporated into the engineering document knowledge base. These engineering materials can be project contracts, engineering specifications, design instructions, calculation sheets, processing technology documents, construction plans, review opinions, visa documents, drawings, or project management documents in curtain wall engineering. They can also be technical materials from other engineering fields that require knowledge accumulation and retrieval reuse. The file formats of the engineering documents to be processed can be text-based PDFs, scanned PDFs, Word documents, image files, spreadsheets, exported CAD files, screenshots of drawings, or a combination of multiple formats.

[0030] In practice, the processing end can obtain project documents to be processed through user uploads, business system synchronization, object storage retrieval, project management platform pushes, or batch imports. For a project, a project document to be processed can be a single file or a collection of files belonging to the same project, the same specification system, or the same business theme. After obtaining the project document, the processing end can assign a document identifier to it. The document identifier is used to distinguish different project documents in subsequent processing and participates in subsequent association as part of the source document location information.

[0031] Step S102 involves performing layout recognition, character-level spatial correction, content block segmentation, and multimodal content recognition on the project document to be processed to obtain multiple structured document units.

[0032] Engineering documents typically differ from ordinary text documents. They often contain not only paragraphs but also multi-level headings, clause numbers, tables, formulas, drawing annotations, title blocks, drawing frames, detailed node drawings, scanning noise, handwritten comments, or image-based content. Directly converting the entire engineering document into continuous text could disrupt the correspondence between tables and formulas, the spatial relationships between drawing areas and text descriptions, and the hierarchical structure and referencing relationships of clauses. Therefore, this step does not treat the entire document as the smallest unit of processing; instead, it breaks down the engineering document into multiple structured document units.

[0033] In one processing method, the processing end can first perform layout recognition on the pages of the engineering document to be processed, identifying different candidate document regions on the page. These candidate document regions can correspond to text paragraphs, titles, tables, formulas, images, labels, title frames, drawing annotations, or other page regions with relatively independent semantics. After completing the initial layout recognition, the processing end further combines the character-level spatial correction results to correct the position of the document regions, ensuring that the subsequently segmented content blocks cover the actual content areas as much as possible, without incorrectly merging adjacent areas or omitting edge text. The specific judgment method for character-level spatial correction will be further described in subsequent embodiments regarding layout recognition and character-level spatial correction; this step only illustrates its role as a preprocessing step in generating structured document units.

[0034] Subsequently, the processing unit can segment content blocks based on the identified and corrected region locations. For text-based content blocks, the processing unit can obtain the corresponding content data through character recognition or text parsing; for content blocks containing tables, formulas, images, or drawing annotations, the processing unit can call multimodal recognition models, table parsing models, formula recognition models, or image understanding models to generate corresponding structured text content. Through the above processing, the engineering document to be processed is converted into multiple structured document units. A structured document unit can be understood as a content unit in the engineering document that can be independently indexed, independently associated, and independently traced back. It retains both the semantics of the text, tables, formulas, or images of the content unit itself, and the source position of the content unit in the original engineering document.

[0035] Each structured document unit includes content data, block type, and source document location information. Content data can be plain text, tabular structured data, formula structured data, image recognition results, drawing annotation recognition results, or descriptive text output by a multimodal recognition model. The block type indicates the content category corresponding to the structured document unit, such as text, title, table, formula, image, title block, drawing annotation, etc. Source document location information records which engineering document the structured document unit originates from and where it is located within the original engineering document.

[0036] In this embodiment, the source document location information includes document identifiers and unit location information. Unit location information includes at least a block identifier and may include at least one of page number, spatial location information, and original object address. The block identifier is used to distinguish different structured document units within the same project document. The page number indicates the page where the structured document unit is located. The spatial location information describes the position range of the structured document unit on a page or image. This spatial location information can be represented using page coordinates, normalized bounding box coordinates, or image pixel coordinates. Page coordinates are suitable for directly describing the absolute position on the document page; normalized bounding box coordinates are suitable for maintaining consistency in position expression under different resolutions or scaling ratios; and image pixel coordinates are suitable for locating specific areas in scanned documents, page screenshots, or cropped images. The original object address may be the original file address, object storage address, page image address, content block image address, or other address information capable of locating the original project document object.

[0037] Using the source document location information mentioned above, the structured document unit is not an abstract text fragment detached from the original document, but rather maintains a positional and object-level association with the original project document. Subsequent actions, whether generating vector representations, constructing graph entity relationships, or outputting project response results, can all be reviewed by returning to the original project document using the source document location information.

[0038] Step S103: Based on multiple structured document units, generate metadata records, content vector representations, and graph entity relationships corresponding to each structured document unit.

[0039] Once structured document units are obtained, the processing end can generate various data representations for different purposes around these units. Metadata records primarily describe the basic management information of the structured document units, such as document identifier, block identifier, block type, page number, chapter level, clause number, document source, project name, document version, effective date, or update time. Metadata records enable the system to manage engineering document content in a structured field format, facilitating subsequent filtering by project, specification, chapter, clause, document type, or version.

[0040] Content vector representations are used to express the features of structured document units in semantic space. The processing unit can embed the content data of structured document units to obtain vectors that can be used for similarity retrieval. For text-based content, vectors can be generated directly from the text; for tables, formulas, or images, a semantically representable text description can be obtained first through structured parsing or multimodal recognition, and then the corresponding content vector representation can be generated. In this way, even if the user's question is not entirely consistent with the wording in the original text, the system can still find relevant engineering document content through semantic similarity.

[0041] Graph entity relationships are used to express entities and relationships between entities in engineering documents. The processing end can extract engineering terms, clause numbers, chapter levels, specification names, material names, indicator names, referenced objects, applicable objects, or requirement objects from structured document units, and form entities and relationships in the graph accordingly. Graph entity relationships enable the system not only to find potentially related content based on semantic similarity, but also to perform structured reasoning based on reference relationships between clauses, correspondences between terms and definitions, citation relationships between specifications, or relationships between requirements and applicable objects. Specific node types, relationship types, and the granularity of correspondence between structured document units and graph nodes in graph entity relationships will be further elaborated in subsequent embodiments regarding the construction of graph entity relationships.

[0042] It should be noted that while metadata records, content vector representations, and graph entity relationships serve management, retrieval, and reasoning respectively, all three are generated based on structured document units. In other words, a single structured document unit can have metadata records for easy filtering and management, content vector representations for easy semantic recall, and can also participate in forming graph entity relationships for easy relational reasoning. It is this data organization method, with structured document units as the common anchor, that enables the engineering document knowledge base to be reused across various intelligent processing tasks.

[0043] Step S104: Based on the source document location information of each structured document unit, establish the association relationship between the metadata record, content vector representation, graph entity relationship and original document object corresponding to the same structured document unit, and form the engineering document knowledge base.

[0044] In this step, the processing end does not simply store metadata records, content vector representations, graph entity relationships, and original document objects separately. Instead, it associates these data representations based on the source document's location information. For the same structured document unit, the processing end can use one or more fields from document identifier, block identifier, page number, spatial location information, or original document object address as the association basis to bind the metadata record, content vector representation, graph entity relationship, and original document object corresponding to that structured document unit.

[0045] For example, a structured document unit might originate from page 35 of a curtain wall engineering specification, with its block identifier B035-07. Its spatial location indicates that this unit is situated within a clause area in the middle of the page. The processing end can record the metadata of this structured document unit as the corresponding specification document, page 35, clause area, and block identifier B035-07. Simultaneously, it converts the text content of this unit into a content vector representation. Furthermore, it can construct graph entity relationships based on the clause number, terminology, referenced specifications, or requirement objects within the unit. The processing end further associates the aforementioned metadata records, content vector representations, graph entity relationships, and object addresses of the original specification document or page image. Thus, when the system subsequently finds this content vector representation through vector retrieval, it can leverage the association relationships to locate the corresponding clause node and the original page location; conversely, when the system finds a clause node through graph relationship queries, it can also reversely locate the corresponding structured document unit and its original text object address.

[0046] The knowledge base of engineering documents can be hosted by one or more storage systems. For example, metadata records can be stored in a relational database or document database, content vector representations can be stored in a vector database or vector indexing service, graph entity relationships can be stored in a graph database or graph indexing service, and original document objects can be stored in an object storage system, a local file system, or an enterprise document management system. Whether the above storage systems are physically separated does not affect the implementation of this embodiment, as long as the processing end can locate and trace back between different data representations through association relationships.

[0047] In this embodiment, after the association is established, the engineering document knowledge base has bidirectional backtracking capability. This bidirectional backtracking is not limited to lookups between two fixed databases, but rather refers to the ability to perform forward and reverse positioning based on associations between structured document units, content vector representations, graph entity relationships, and original document objects.

[0048] For example, in the subsequent response to engineering issues, the system might first use vector retrieval to find a content vector representation, then associate the content vector representation with the corresponding structured document unit, and finally locate the page number and page area of ​​the original engineering document. Alternatively, the system might first use graph relationship queries to find a clause node, then associate that clause node with one or more structured document units, and further locate the clause position within the original engineering document. Furthermore, when a user selects a content block on the original document page, the system can also use the source document location information of that content block to reverse-search the corresponding metadata record, content vector representation, and graph entity relationships to display relevant clauses, associated specifications, or similar content.

[0049] Because the engineering document knowledge base preserves the complete link from the original engineering document object to structured document units, from structured document units to various indexed expressions, and then back to the original object from the indexed expressions, subsequent search results, response results, verification results, or translation results do not need to remain at the level of "textual similarity," but can further point to specific locations within the original engineering data. This is particularly important in the engineering field, because engineering conclusions often need to be verified by referring back to specification clauses, original contract texts, drawing areas, or calculation basis.

[0050] Through the above construction steps, the engineering document to be processed is decomposed into structured document units with source document location information. Metadata records, content vector representations, graph entity relationships, and original document objects are then associated around the same structured document unit. Since different data representations are no longer isolated storage results but instead point to the locationable engineering document content, the system can form a closed loop between semantic retrieval, graph reasoning, and original text verification when performing subsequent engineering problem responses, document location, clause verification, or other intelligent processing. Thus, the engineering document is no longer simply converted into untraceable plain text, but organized into a searchable, verifiable, locationable, and continuously updated engineering knowledge resource.

[0051] In the aforementioned steps of constructing the knowledge base of engineering documents, the quality of structured document units directly affects the reliability of subsequent metadata records, content vector representations, and graph entity relationships. For curtain wall engineering documents, pages often simultaneously contain areas such as main text clauses, tables, formulas, drawing annotations, title blocks, and drawing frames. If only the area boundary boxes output by the layout recognition model are relied upon, problems such as boundary box offsets, overlapping of adjacent areas, truncation of title block areas, or loss of table edge content may occur. Therefore, in some embodiments of this application, the spatial location information of structured document units can be further determined by combining layout recognition with character-level spatial correction.

[0052] In this embodiment, the layout recognition and character-level space correction process may include the following steps.

[0053] Step S201: Perform layout detection on the pages of the project document to be processed to obtain at least one candidate document region and the region category and initial region bounding box corresponding to each candidate document region.

[0054] The processing unit can convert the project document to be processed into a page image, or directly read the existing page rendering result in the project document, and then perform layout detection on the page. The goal of layout detection is not to directly generate the final content to be stored in the database, but to first identify several candidate document areas on the page that may have independent semantics. Candidate document areas can be a paragraph, title, table, formula, image, title block, drawing frame, or drawing annotation area on the page.

[0055] Region categories are used to indicate the content type of candidate document regions. For example, a region category can indicate that the corresponding candidate document region is at least one of the following: text region, title region, table region, formula region, image region, title block region, title frame region, and drawing annotation region. For complex regions on the same page, region categories can also have composite attributes; for example, a region may belong to both an image region and contain drawing annotations; or a region may be entirely a table region but contain formula content. The initial region bounding box is the initial position range of the candidate document region on the page given during the layout detection phase, which can be represented by page coordinates, normalized bounding box coordinates, or image pixel coordinates.

[0056] In practical implementation, layout detection can be performed using object detection models, layout analysis models, rule parsers, or a combination of models and rules. For example, the processing end can use a layout detection model trained on engineering document samples to identify title blocks, title frames, table boundaries, and text areas; it can also combine page text flow, line detection results, and image connectivity analysis results to assist in determining candidate document regions. None of the above specific detection methods limit the scope of protection of this embodiment; the key is to first obtain the candidate document regions, region categories, and initial region bounding boxes.

[0057] Step S202: Obtain the character coordinates within the candidate document area.

[0058] After obtaining the initial region bounding box, the processing unit further acquires the character coordinates within the candidate document region. These character coordinates can come from PDF character parsing results, OCR recognition results, page text layer extraction results, or character positions output by an image text recognition model. For text-based PDFs, the processing unit can directly read the coordinates of each character or string fragment in the document; for scanned documents or image-based engineering documents, the processing unit can first perform text recognition, and then obtain the coordinates of the recognized character boxes, text line boxes, or character center points.

[0059] Character coordinates reflect the actual distribution of text content on the page. Compared to the initial region bounding box, character coordinates are closer to the actual text content itself. Especially in engineering drawings, title blocks, table edges, and multi-column layout areas, layout detection models may provide candidate boxes that are too large or off-center, while character coordinates can help the processing end determine whether the candidate boxes truly cover the valid content.

[0060] Step S203: Perform a second fitting on the initial region bounding box based on the character coordinates to obtain the corrected region bounding box.

[0061] In this step, the processing unit can use the character coordinates within the candidate document region as the basis for fitting, and perform a secondary fitting on the initial region bounding box. The secondary fitting is not simply enlarging or shrinking the initial region bounding box, but rather redefining the actual content range of the candidate document region based on the distribution of the character coordinates. For example, the processing unit can calculate the minimum bounding rectangle of all character coordinates within the candidate document region, and add a preset margin to this minimum bounding rectangle to obtain the corrected region bounding box; alternatively, it can cluster the character coordinates according to the text line direction, column direction, or drawing annotation direction, and then fit the bounding box based on the clustering results.

[0062] For tables, formulas, or image regions, if the candidate document region contains recognizable character coordinates, the processing unit can use these coordinates to correct the boundaries of titles, comments, table headers, or formula symbols. If some image regions do not contain character coordinates, the processing unit can maintain the initial region bounding box or perform corrections based on region category, image edge, and line detection results. In other words, character-level spatial correction is primarily used to improve the fit between region boundaries and actual content, rather than requiring every candidate document region to contain characters.

[0063] Step S204: Determine the overlap ratio of the bounding boxes based on the initial region bounding box and the corrected region bounding box, and determine the content retention ratio.

[0064] The bounding box overlap ratio can be used to measure the degree of positional consistency between the initial region bounding box and the corrected region bounding box. In one implementation, the bounding box overlap ratio can be determined based on the overlap area and the union area of ​​the initial and corrected region bounding boxes; in another implementation, it can be determined based on the ratio between the overlap area and the area of ​​either the initial or corrected region bounding box. A low bounding box overlap ratio indicates that the corrected region bounding box is significantly offset relative to the initial region bounding box, potentially leading to misidentification or miscorrection. A bounding box overlap ratio within a reasonable range indicates that the correction is a spatial adjustment based on the initial layout detection results, rather than a complete deviation from the original region.

[0065] The content retention ratio measures whether there is significant loss of content after layout recognition compared to the initial parsing result. It is the ratio between the number of valid content blocks corresponding to content items in the original content list obtained from the initial parsing and retained after layout recognition and correction, and the number of items in the original content list. For example, if the initial parsing yields 100 text lines, table blocks, or image blocks, and layout recognition and correction retains 92 valid content blocks corresponding to content items in the original content list, then the content retention ratio can be 92%. The content retention ratio can reflect whether layout recognition has missed a large amount of content at the level of the entire page or the entire document.

[0066] Step S205: Determine whether the layout recognition result meets the correction adoption conditions based on the bounding box overlap ratio and content retention ratio.

[0067] In this embodiment, the correction conditions can be determined using a dual-index gating rule. The dual-index gating rule considers at least the bounding box overlap ratio and the content retention ratio simultaneously, ensuring that the correction result neither deviates excessively from the initial layout detection result nor causes significant content loss.

[0068] In one implementation, the processing end can preset a first overlap ratio threshold and a first content retention ratio threshold. When the bounding box overlap ratio is greater than or equal to the first overlap ratio threshold, and the content retention ratio is greater than or equal to the first content retention ratio threshold, the layout recognition result is determined to meet the correction adoption conditions. The first overlap ratio threshold is used to prevent the corrected region bounding box from deviating too far from the candidate document region, and the first content retention ratio threshold is used to prevent the correction process from discarding too much original content. In this way, the correction result adopted by the processing end needs to pass both positional consistency and content integrity verification.

[0069] In another implementation, the processing end can set different thresholds based on the region category. For example, for title block areas, drawing frame areas, and drawing annotation areas, where text is dense and spatial boundaries are crucial for subsequent positioning, a higher content retention threshold can be set. For pure image areas, the reliance on the retention ratio of character-related content can be appropriately reduced, while more attention can be paid to the overlap ratio of bounding boxes and the integrity of the image area. For table areas, the usability of the correction result can be further determined by combining table row and column lines, character coordinates within the table, and cell boundaries.

[0070] In another implementation, the processing end can employ a weighted scoring rule. For example, the bounding box overlap ratio and content retention ratio can be converted into positional confidence and content completeness, respectively, and then the overall correction confidence is determined based on the weighted result of the two. When the overall correction confidence reaches a preset correction confidence threshold, the layout recognition result is determined to meet the correction adoption conditions. This weighted scoring rule can be applied to scenarios where there are significant layout differences between different types of engineering documents, facilitating dynamic adjustment of the correction strategy based on document type, region category, or historical processing results.

[0071] Furthermore, when the content retention rate is significantly lower than the threshold, even if the bounding boxes of some candidate document regions have a high overlap rate, the processing unit can determine that the current layout recognition result does not meet the correction criteria and trigger rollback processing. Rollback processing can involve using the initial parsing result, re-executing layout recognition, reducing the segmentation granularity, calling the multimodal model for whole-page recognition, or marking the page as awaiting manual review. In this way, when the layout recognition model performs unstably on certain scanned documents, low-resolution drawings, or complex mixed-page drawings, the system will not directly adopt the structured result that may cause content loss.

[0072] The aforementioned correction employs conditional settings, making the character-level spatial correction in this embodiment not merely a simple positional adjustment, but a quality control process that combines regional positional consistency and content integrity. This process provides support for subsequent responses to creative examination comments: compared to conventional document parsing methods that only output layout detection boxes, this embodiment determines whether to adopt the correction result by jointly considering the bounding box overlap ratio and the content retention ratio, thereby improving spatial positioning accuracy while suppressing content loss caused by erroneous corrections.

[0073] Step S206: In response to the layout recognition result meeting the correction adoption conditions, the corrected region bounding box is determined as the spatial location information of the structured document unit corresponding to the candidate document region.

[0074] Once the processing unit determines that the layout recognition result meets the correction criteria, the corrected region bounding box can be used as the spatial location information of the corresponding structured document unit. This spatial location information can then be written into the source document location information and used together with document identifiers, block identifiers, page numbers, and original text object addresses for backtracking.

[0075] Therefore, this implementation method identifies candidate document regions through layout recognition, performs secondary fitting of region boundaries using character coordinates, and controls the adoption of correction results by controlling the overlap ratio of bounding boxes and the content retention ratio. Since figure labels, frames, tables, formulas, and drawing annotations in engineering documents are often sensitive to spatial location, the above processing can reduce bounding box drift, region overlap, and content loss, thereby improving the positioning reliability of structured document units. With improved positioning reliability, the subsequently established vector representations, graph relationships, and associations between original text objects are also more stable, making it less prone to positioning errors when tracing back to the original engineering document from the engineering response results.

[0076] After obtaining the engineering document knowledge base through the aforementioned construction steps, the content of the engineering document is no longer simply full-text, but organized into an engineering document knowledge base with metadata records, content vector representations, graph entity relationships, and source document location information. For engineers, the value of the knowledge base lies not only in completing document storage, but also in the system's ability to provide verifiable and traceable engineering responses based on the knowledge base when designers, managers, or construction personnel raise engineering questions. Based on this, the engineering question response method provided in this application embodiment may include the following processing steps.

[0077] This engineering problem response method can be executed by a processing end. The processing end can be a server with access capabilities to an engineering document knowledge base, an engineering Q&A platform, an enterprise knowledge management platform, an intelligent Q&A module within a project management system, or a processing system formed by the collaboration of multiple computing nodes. The focus of this embodiment is not on re-parsed and stored engineering documents, but rather on calling upon the already constructed engineering document knowledge base to retrieve, verify, generate responses to, and output the original text of the engineering problem.

[0078] The problem response method for this project may include the following steps.

[0079] Step S501: Obtain an engineering issue response request, which includes engineering issues related to engineering documents.

[0080] Engineering issue response requests can be submitted by users via web, mobile, project management system interface, or internal enterprise applications. Engineering issues can be natural language questions posed to engineering documents, or query requests that have been structured by the front-end system. For example, designers can enter questions such as "How to determine the thickness of a point-supported glass curtain wall panel?", "What are the fire performance requirements in a project contract?", "Does this version of the standard replace the old version?", and "What are the key design considerations for seismic resistance, fire resistance, and energy conservation of external curtain walls?"

[0081] Upon receiving an engineering issue response request, the processing end can parse the engineering issue text, user identity, project identifier, document scope, query language, return format, or other contextual information. While project identifier and document scope are not essential limitations in this embodiment, they can help the processing end limit the search scope and avoid retrieving results from irrelevant projects or specifications. For example, for a specific overseas curtain wall project, the processing end can search only for contracts, technical specifications, drawings, and project management regulations already included in the project's database.

[0082] The engineering questions in the response request are not limited to single-sentence questions; they can also be complex questions containing multiple requirements. For example, "Please summarize the key design points for the seismic resistance, fire protection, and energy conservation of the exterior curtain wall of a complex project, and list the corresponding code references" involves multiple professional directions, multiple code documents, and multiple output targets. For such complex questions, subsequent steps will further determine the query intent and break down the search topics.

[0083] Step S502: Determine the query intent based on the engineering problem, and if the query intent indicates that the engineering problem requires multi-target retrieval, decompose the engineering problem into multiple retrieval topics; otherwise, determine the engineering problem as a single retrieval topic.

[0084] After receiving an engineering problem, the processing end can first perform semantic understanding to determine the query intent. The query intent characterizes the engineering information processing task the user wants the system to complete. For example, the query intent might indicate that the user wants to query specification clauses, compare different versions of specifications, obtain design suggestions, locate the content of a specific document, explain engineering terminology, find formula parameters, or synthesize multiple engineering documents into a report. The query intent can be determined through keyword rules, classification models, language models, existing entity matching results in knowledge graphs, or a combination of these methods.

[0085] When an engineering problem is relatively simple and involves only one search target, the processing end can identify the engineering problem as a search topic. For example, "how to determine the thickness of a point-supported glass curtain wall panel" can usually be used as a search topic, with searches conducted around "point-supported glass curtain wall," "panel thickness," and "calculation basis."

[0086] When the query intent indicates that the engineering problem involves multiple professional directions, multiple engineering documents, multiple standard clauses, multiple search targets, or multiple verification targets, the processing end can break down the engineering problem into multiple search topics. For example, "Key points of seismic, fireproof, and energy-saving design for the exterior curtain wall of a complex project" can be broken down into multiple search topics such as "seismic design requirements for exterior curtain walls," "fireproof design requirements for exterior curtain walls," and "energy-saving design requirements for exterior curtain walls." Similarly, "Please compare the differences in glass panel thickness calculation between the new and old versions of the standard" can be broken down into search topics such as "relevant clauses in the new standard," "relevant clauses in the old standard," "differences in thickness calculation," and "verification of version substitution relationships."

[0087] By first determining the query intent and then the search topic, the processing end can avoid simply treating complex engineering problems as ordinary text for vector recall. In the engineering field, complex problems often cannot be fully answered by a single text fragment, but require retrieval and integration from multiple specifications, clauses, and professional directions. Decomposing the search topic allows subsequent searches to more closely approximate the true structure of the engineering problem.

[0088] Step S503: Based on the query intent and retrieval topic, perform vector retrieval and graph relationship query on the knowledge base of the engineering document to obtain candidate retrieval results.

[0089] The engineering document knowledge base can be constructed through the aforementioned steps. In other words, the knowledge base already stores metadata records, content vector representations, graph entity relationships, and source document location information corresponding to the structured document units. When the processing end executes an engineering problem response, it can simultaneously utilize the content vector representations for semantic retrieval and the graph entity relationships for structured queries.

[0090] For each search topic, the processing unit can first generate a query vector based on the search topic, and then perform similarity matching with the content vector representation in the engineering document knowledge base to recall structured document units semantically related to the search topic. Vector retrieval is suitable for handling differences in natural language expressions. For example, if a user asks "How is the panel thickness determined?", the original text might be expressed as "The thickness of the glass panel should be determined by calculation." The wording is not exactly the same, but relevant clauses can still be recalled through vector retrieval.

[0091] Simultaneously, the processing end can perform a graph relationship query on the knowledge base of engineering documents based on engineering terms, specification names, clause numbers, material names, design objects, or parameter names within the search topic. The graph relationship query can retrieve clause nodes, terminology nodes, external specification nodes, and their relationships related to the search topic. For example, when the search topic involves "point-supported glass curtain wall," the processing end can search the graph for definitions, applicable clauses, calculation requirements, referenced specifications, or relevant material nodes related to that term. The graph relationship query can compensate for the insufficient understanding of hierarchical, referential, and applicable relationships in simple semantic recall.

[0092] Candidate search results can be generated jointly from vector search results and graph relation query results. For the same search topic, if a structured document unit is recalled by both vector search and is associated with a clause node or term node in the graph subgraph, that structured document unit can be assigned a higher candidate priority. If a result is only similar at the vector level, but the graph relation cannot support its engineering association with the search topic, then that result can be considered a candidate but needs further evaluation in subsequent verification processes.

[0093] In this embodiment, candidate search results may include the content data of structured document units, corresponding metadata records, associated graph nodes or graph relationships, similarity information, source document information, and source document location information. Thus, candidate search results not only contain "potentially relevant text," but also basic information such as "why it's relevant" and "where it comes from."

[0094] Step S504: Perform at least one of the following verification processes on the candidate search results: graph relationship verification and cross-document verification, to obtain verified search results.

[0095] Since engineering problem responses are typically used for design review, specification lookup, contract interpretation, construction management, or technical decision-making, relying solely on language models to generate answers can easily lead to problems such as inaccurate citations, mismatched clauses, version confusion, or duplicate conclusions. Therefore, the processing end can validate candidate search results before generating the final engineering response.

[0096] Graph relationship verification can be used to determine whether the clauses, terms, references, or requirements in candidate search results are consistent with the graph entity relationships in the engineering document knowledge base. For example, if a candidate search result claims that a certain clause applies to point-supported glass curtain walls, the processing end can query the graph entity relationships to see if there is an applicable relationship, requirement relationship, or related reference relationship between the clause node and the "point-supported glass curtain wall" term node. If the terms, clauses, or references in the candidate search result cannot be found to support a corresponding relationship in the graph, the processing end can reduce the credibility of the candidate result or mark it as a result to be reviewed.

[0097] Cross-document validation can be used to handle situations where multiple engineering documents contribute to the answer. For example, the same question may involve national regulations, industry standards, enterprise standards, and project contracts. The processing end can perform consistency checks on candidate results from different source documents based on document citation relationships, clause citation relationships, version substitution relationships, or project scope of application within the engineering document knowledge base. If there are version inconsistencies, clause conflicts, different scopes of application, or duplicate conclusions among the candidate results, the processing end can generate corresponding prompts in the subsequent engineering response results, rather than simply concatenating multiple results into a generic answer.

[0098] Verified search results can retain both verified candidate results and those that have been downgraded or flagged, along with their verification status. In engineering scenarios, some low-confidence or conflicting results still offer valuable insights. For example, when differences exist between different specification versions, the system should not directly delete one, but rather prompt the user to pay attention to the version relationships and scope of application. Therefore, verified search results can include the basis for verification, the basis for conflict, the basis for further review, and corresponding verification explanations.

[0099] Step S505: Generate engineering response results based on the verified search results.

[0100] The processing unit can use the verified search results as a basis to generate user-friendly engineering response results. These results can be natural language answers, point-by-point explanations, tabular comparisons, lists of specifications, design recommendation reports, conflict warning reports, or other output formats suitable for engineers.

[0101] When generating engineering response results, the processing end can prioritize retrieval results verified through graph relationships and cross-document verification as the primary basis. For content with conflicts, version inconsistencies, or duplicate references, the processing end can explicitly indicate this in the response results. For example, when candidate results come from different versions of specifications and the version replacement relationship indicates that the old specification has been superseded by the new one, the engineering response results can prompt users to prioritize the new specification, while simultaneously explaining that the clauses of the old specification are for comparison only. Similarly, when multiple documents provide different requirements for the same engineering problem, the engineering response results can list the differences and remind users to further confirm in conjunction with the project contract, applicable region, or design phase.

[0102] The engineering response results are not limited to simply providing conclusions. For questions involving reference to standard provisions, the engineering response results may include summaries of relevant provisions, provision numbers, and applicable explanations; for questions involving design recommendations, the engineering response results may include design considerations, cited references, and precautions; for questions involving version comparisons, the engineering response results may include differences between old and new versions, substitution relationships, and explanations of their impact; for questions involving document location, the engineering response results may highlight the original text location and provide relevant links. This method of organizing results enables engineers not only to know the answer but also which engineering documents the answer comes from and how to verify it.

[0103] Step S506: Based on the association relationship in the engineering document knowledge base, the engineering response result is associated with the corresponding source document location information and output, so that the engineering response result can be traced back to the corresponding original engineering document location.

[0104] In this step, the processing end can locate the corresponding structured document unit based on the empirical retrieval results cited in the engineering response results, and then determine the source document location information through the association relationships in the engineering document knowledge base. The source document location information may include document identifiers and at least one of the following: chapter identifiers, clause identifiers, page numbers, spatial location information, and original text object addresses. The processing end can output this source document location information along with the engineering response results, or it can generate reference links, location markers, original text screenshot entry points, or page jump addresses based on this information.

[0105] For example, when an engineering response mentions a specification clause, the system can display the specification name, clause number, page number, and a location link after the conclusion. Clicking the location link allows the user to open the corresponding page area or content block image in the original specification document. As another example, if the engineering response references a table or formula, the system can output the page containing the table or formula and its spatial location, allowing the user to directly view the complete context in the original text.

[0106] By linking the engineering response results with the source document location information, the processing end can transform the answer from "model-generated text" into "a response result with engineering document support." This is of great significance for review, verification, and accountability in the engineering field. Engineers can verify the original clauses based on the location information, project managers can check whether the response conclusions come from the applicable documents, and the original basis can be quickly traced during subsequent reviews or dispute resolution.

[0107] As can be seen from the above process, this embodiment does not simply input the engineering problem into a large language model and directly generate an answer. Instead, it utilizes the vector representation in the engineering document knowledge base for semantic recall, employs graph entity relationships for structured querying and verification, and leverages source document location information to achieve original text backtracking. Because candidate search results undergo graph relationship verification and / or cross-document verification before generating a response, the system can reduce the risks of misquoting clauses, version confusion, and unfounded inferences. Furthermore, since the engineering response results are output in association with the source document location information, users can directly return to the original engineering document location from the answer for review. In this way, the engineering problem response process retains the flexibility of intelligent retrieval while possessing the verifiable evidence and traceable results required for engineering knowledge application.

[0108] In the aforementioned engineering problem response methods, the expression of the engineering problem may be relatively simple, or it may involve multiple professional directions, multiple engineering documents, or multiple verification targets. If the processing end does not distinguish the complexity of the problem and directly retrieves the entire engineering problem as a single query, it is easy to lead to an overly broad search scope, mixed recall results, or omission of some sub-targets in the engineering problem. Therefore, in some embodiments of this application, the query intent of the engineering problem can be identified first, and then it can be determined whether the search topic needs to be broken down based on the identification results.

[0109] The process of query intent identification and retrieval topic decomposition may include the following steps.

[0110] Step S601: Perform intent recognition on the engineering problem to determine the query type corresponding to the engineering problem.

[0111] After acquiring the engineering problem, the processing end can first perform semantic analysis on the problem to identify the engineering object, professional direction, document type, clause clues, version clues, formula parameter clues, and the user's expected output format. This intent recognition process can be completed through keyword rules, classification models, language models, graph entity matching, or a combination of these methods.

[0112] Query types can include at least one of the following: code clause query, version comparison query, design suggestion query, formula parameter query, and document location query. For example, when the engineering question is "How to determine the thickness of a point-supported glass curtain wall panel?", the processing terminal can identify that the question involves at least code clause queries and formula parameter queries; when the engineering question is "What are the changes in panel thickness calculation between the new and old versions of the glass curtain wall code?", the processing terminal can identify version comparison queries; when the engineering question is "What are the key design points for seismic resistance, fire protection, and energy conservation of the exterior curtain wall of a complex project?", the processing terminal can identify design suggestion queries and further discover that the question involves multiple professional directions.

[0113] During intent recognition, the processing end can also utilize terminology nodes, clause nodes, and document nodes within the engineering document knowledge base to aid in understanding engineering problems. For example, if engineering terms such as "point-supported glass curtain wall," "panel thickness," and "fire compartment" appear in the engineering problem, the processing end can search for corresponding terminology nodes or clause nodes in the engineering document knowledge base to determine which type of engineering object these terms belong to, which corresponding regulatory clauses, and which possible search directions they might involve. In this way, the query intent is not determined solely based on the surface words of natural language, but rather by combining the structured engineering knowledge within the engineering knowledge base.

[0114] Step S602: In response to the query intent characterizing that the engineering problem involves at least one of multiple professional directions, multiple engineering documents, multiple specification clauses, multiple search targets, or multiple verification targets, the engineering problem is decomposed into multiple search topics.

[0115] When the processing unit determines that an engineering problem requires multi-target retrieval, it can break down the original engineering problem into multiple retrieval topics. Retrieval topics are the basic processing units for subsequent retrieval and validation. Compared to the original engineering problem, each retrieval topic typically has a more specific retrieval objective and a narrower retrieval scope.

[0116] For example, for the engineering question "What are the key design considerations for the seismic resistance, fire protection, and energy efficiency of the exterior curtain wall of a complex project?", the processing end can break it down into three search topics: "Seismic design requirements for exterior curtain walls," "Fire protection design requirements for exterior curtain walls," and "Energy efficiency design requirements for exterior curtain walls." Each search topic corresponds to a specific professional area, and relevant standard clauses, design requirements, and applicable scopes can be searched separately, and then summarized when generating the engineering response results.

[0117] For example, for the engineering question "Please compare the differences in glass panel thickness calculation between the new and old versions of the specification," the processing end can break it down into multiple search topics such as "glass panel thickness calculation clauses in the new specification," "glass panel thickness calculation clauses in the old specification," "relationship between new and old versions," and "changes in thickness calculation parameters." In this way, the system will not only search for the clause content itself but also for version substitution relationships and parameter changes, providing a basis for subsequent cross-document verification and version notifications.

[0118] For example, regarding the engineering question, "What are the requirements for the fire resistance performance of the curtain wall in the project contract and technical specifications, and are there any conflicts?", the processing end can break it down into multiple search topics: "Fire resistance performance requirements in the project contract," "Fire resistance performance requirements in the technical specifications," and "Consistency verification between contract and specification requirements." Through this breakdown, the processing end can selectively retrieve contractual and specification bases, and retain clear verification targets for conflict detection.

[0119] Search topics can be represented as natural language phrases, structured query objects, or a combination of both. A search topic may include topic text, query type, target project object, target document scope, related terms, expected output fields, and validation requirements. This information helps subsequent vector retrieval and graph relationship queries to more accurately determine the search scope.

[0120] Step S603: In response to the query intent not indicating that the engineering problem involves multiple professional directions, multiple engineering documents, multiple specification clauses, multiple search targets, or multiple verification targets, the engineering problem is identified as a search topic.

[0121] When an engineering problem has a focused semantic scope and a singular retrieval objective, the processing end can directly identify the engineering problem as a single retrieval topic. For example, "Where is the specification regarding the area of ​​operable windows in a glass curtain wall in a certain standard?" can typically be treated as a single retrieval topic. For such questions, excessive decomposition may actually lengthen the retrieval process and introduce irrelevant results; therefore, the processing end can retain the overall expression of the original question.

[0122] It's important to note that identifying an engineering problem as a retrieval topic does not mean that only a single document fragment can be retrieved. The processing end can still perform vector retrieval and graph relationship queries based on this retrieval topic, and obtain candidate retrieval results from multiple structured document units. The difference is that the system no longer breaks down the original problem into multiple parallel sub-problems, but instead performs a centralized retrieval around the same retrieval target.

[0123] Through the aforementioned query intent identification and retrieval topic decomposition process, the processing end can dynamically determine the retrieval organization method based on the complexity of the engineering problem. For simple problems, the system quickly retrieves results using a single retrieval topic; for complex problems, the system first breaks down the problem into professional directions, document scope, or verification objectives, and then retrieves and verifies them separately. This avoids oversimplifying complex problems and over-decomposing simple problems, thereby improving the accuracy and interpretability of the response to engineering problems.

[0124] After determining the search topic, the processing end needs to retrieve engineering content related to the search topic from the engineering document knowledge base. Since engineering problems may be expressed in natural language or involve specification clauses, terminology definitions, citation relationships, and version relationships, relying solely on vector retrieval may not fully reflect the structural relationships between engineering documents; relying solely on graph queries may fail to cover situations where the user's question differs from the original text. Therefore, in some embodiments of this application, the processing end can combine vector retrieval and graph relationship queries to obtain candidate search results, and trigger secondary retrieval when the confidence of the candidate results is insufficient.

[0125] The process may include the following steps.

[0126] Step S701: Perform vector retrieval on the knowledge base of the engineering document based on the retrieval topic to obtain vector recall results.

[0127] The processing unit can convert search topics into query vectors and perform similarity searches within the content vector representation of the engineering document knowledge base. Query vectors can be generated from the search topic text, query type, engineering terminology, target engineering object, or contextual information. For engineering problems involving multiple search topics, query vectors can be generated for each search topic separately and the search can be performed independently.

[0128] Vector retrieval results can include structured document units semantically similar to the search topic, corresponding similarity scores, document identifiers, block identifiers, block types, and source document location information. For example, if a user asks "How is the thickness of a glass panel determined?", while the original text states "The thickness of a glass panel should be determined based on load-bearing capacity and deflection," vector retrieval can recall this clause based on semantic similarity. Vector retrieval can overcome the sensitivity of keyword retrieval to wording differences, allowing users to obtain relevant content without strictly inputting keywords from the original text.

[0129] Step S702: Perform a graph relationship query on the knowledge base of the engineering document based on the search topic to obtain the graph subgraph corresponding to the search topic.

[0130] The processing unit can also identify engineering terms, specification names, clause numbers, material names, parameter names, or design objects from the search topic, and perform graph relationship queries based on these entities within the engineering document knowledge base. The results of the graph relationship query can be graph subgraphs related to the search topic. Graph subgraphs can include relevant document nodes, chapter nodes, clause nodes, terminology nodes, external specification nodes, and the hierarchical relationships, referencing relationships, definition relationships, requirement relationships, and applicability relationships between these nodes.

[0131] For example, when the search topic involves "thickness of point-supported glass curtain wall panels," the processing terminal can find the terminology node for "point-supported glass curtain wall," the parameter node for "panel thickness," the relevant clause node, and the external standard node referenced by that clause in the graph. If the search topic involves "version comparison," the processing terminal can query the version substitution relationship between document nodes. If the search topic involves "whether the contract and the standard conflict," the processing terminal can query the requirement relationship between the contract clause nodes and the standard clause nodes related to the same project object.

[0132] Graph relationship queries can help the system understand the engineering relationships between candidate content. For example, if two texts both semantically mention "thickness," but only one of them is applicable to "point-supported glass curtain wall," the graph query results can help the processing end prioritize the truly relevant clauses.

[0133] Step S703: Based on the vector recall results and the graph subgraph, generate candidate retrieval results.

[0134] The processing unit can fuse vector recall results and attribution subgraphs to generate candidate search results. During fusion, structured document units in the vector recall results can be matched with clause nodes, term nodes, or specification nodes in the attribution subgraph. If a structured document unit has both high vector similarity and is associated with a key node in the attribution subgraph, then that structured document unit can be identified as a priority candidate result.

[0135] Candidate search results can include candidate content, the structured document units corresponding to the candidate content, vector similarity, matched graph nodes, matched graph relationships, source documents, chapter or clause information, and source document location information. For a search topic, candidate search results can be a set of results sorted by relevance, or a collection of results organized according to document source, professional direction, or clause hierarchy.

[0136] In some implementations, the processing end can also deduplicate vector retrieval results and graph subgraphs. For example, vector retrieval may recall multiple adjacent structured document units of the same clause, while graph queries may hit multiple fragments under the same clause node. The processing end can deduplicate or merge based on document identifiers, clause identifiers, and block identifiers to make the candidate retrieval results more compact.

[0137] Step S704: Determine the overall confidence level of the candidate search results.

[0138] The processing end can determine the overall confidence level for candidate search results. The overall confidence level measures the credibility of the candidate search results for the current search topic. The overall confidence level can be determined by at least one of the following factors: vector similarity, graph matching degree, source document weight, and version consistency. It can also be further determined by combining factors such as the old and new version status of the candidate results, the scope of document application, the clause level, the number of hits, and the scope of documents specified by the user.

[0139] Vector similarity reflects the semantic closeness between the search topic and candidate content. Graph matching reflects the structured matching degree between candidate content and engineering terms, clause nodes, or relationship paths in the search topic. Source document weight reflects the credibility level of different source documents in the current project or problem; for example, project contracts, applicable specifications, enterprise standards, or general reference materials may have different weights. Version consistency is used to determine whether the document version corresponding to the candidate result matches the current project or query scenario; for example, a superseded older version of the specification may be assigned a lower weight, while the currently applicable version may be assigned a higher weight.

[0140] In one implementation, the processing unit can calculate the vector similarity score, graph matching score, source document weight score, and version consistency score of the candidate retrieval results separately, and then perform a weighted sum of these scores to obtain the overall confidence score. In another implementation, the processing unit can employ rule-based gating, for example, only identifying high vector similarity results as high-confidence results when the graph matching degree reaches a certain condition. This avoids situations where candidate content is textually similar but the engineering object or applicable scope is inconsistent.

[0141] The calculation rules for the overall confidence score can be adjusted according to the engineering scenario. For example, querying specification clauses can improve the weight of graph matching and version consistency; querying design suggestions can improve the weight of vector similarity and source document; and querying document location can improve the weight of document range matching and the completeness of source document location information. In this way, the overall confidence score not only reflects text similarity but also the standardization, applicability, and traceability of engineering documents.

[0142] Step S705: In response to the overall confidence level being lower than the preset confidence threshold, a secondary search topic is generated based on the candidate search results.

[0143] When the overall confidence level of the candidate search results is lower than a preset confidence threshold, the processing unit can consider the primary search results insufficient to directly support the engineering response. In this case, the processing unit can generate secondary search topics based on the candidate search results. Secondary search topics are used to further narrow down, expand, or correct the search direction.

[0144] For example, if a primary search result matches clauses related to "glass panel thickness," but the overall confidence level is low, it may be because the curtain wall type is not clearly defined. The processing end can extract keywords such as "point-supported," "frame-supported," "load-bearing capacity," and "deflection" from the candidate results to generate "calculation basis for glass panel thickness of point-supported glass curtain walls" as a secondary search topic. Similarly, if a primary search result matches clauses from an older version of the standard, indicating low version consistency, the processing end can generate "corresponding alternative clauses in the new standard" as a secondary search topic.

[0145] Secondary search topics can be generated using language models, rule templates, or graph expansion methods. The processing end can generate new search directions using related terms, superior nodes, subordinate nodes, reference nodes, or adjacent clauses in the graph subgraph, or it can generate supplementary search directions based on missing information in the primary candidate results.

[0146] Step S706: Expand the search scope based on the secondary search topic and perform re-sorting to obtain updated candidate search results.

[0147] The processing end can perform vector retrieval and graph relationship query again based on the secondary search topic. Compared with the primary search, the secondary search can expand the search scope and change the search strategy. For example, the secondary search can increase the number of recalls, expand to adjacent chapters, include citation specifications, query external specification nodes, expand term synonyms, or retrieve other clauses that have citation relationships with the candidate clauses.

[0148] After obtaining the secondary search results, the processing unit can merge the primary candidate results and the secondary search results and perform a re-ranking process. The re-ranking can comprehensively consider vector similarity, graph matching degree, source document weight, version consistency, and the mutual support relationships between candidate results. If the secondary search finds terms that have a citation relationship or version substitution relationship with the primary candidate results, the processing unit can improve the ranking of the relevant results; if some results are inconsistent with the graph relationship or the version is not applicable, their ranking can be reduced.

[0149] Through the aforementioned primary retrieval, confidence assessment, secondary retrieval, and re-ranking processes, the engineering problem response method can automatically perform supplementary retrieval when the initial retrieval results are insufficient. Compared to one-time vector recall, this approach is better suited to common engineering problems such as clause citations, version substitutions, ambiguous terminology, and cross-document associations, thus providing more reliable candidate data for subsequent verification and response generation.

[0150] After obtaining candidate search results, if the processing end directly generates engineering response results based on the candidate results, inconsistencies may still occur between the candidate results and the engineering atlas, incorrect cited clauses, version conflicts between multiple documents, or overlapping of duplicate conclusions. To improve the credibility of the engineering response results, in some embodiments of this application, atlas relationship verification and cross-document verification can be performed on the candidate search results, and the source document location information can be associated when outputting the response results.

[0151] In this embodiment, the verification process and the traceable output process may include the following steps.

[0152] Step S801: Match at least one of the clause identifiers, term entities, reference relationships, and requirement relationships in the candidate search results with the graph entity relationships in the engineering document knowledge base.

[0153] The processing end can extract the object to be verified from the candidate search results. The object to be verified can include at least one of the following: clause identifier, term entity, reference relationship, and requirement relationship. For example, the candidate search results may contain a standard clause number, an engineering term, an external standard reference, or a requirement relationship regarding material, thickness, fire resistance, or deformation limit.

[0154] The processing end matches these objects to be verified with the entity relationships in the knowledge base of the engineering document. If a candidate search result claims that a clause applies to point-supported glass curtain walls, the processing end can check whether there is an applicable or requirement relationship between the clause node in the knowledge base and the "point-supported glass curtain wall" term node. If a candidate search result references an external standard, the processing end can check whether there is a reference or citation relationship between the clause node in the knowledge base and the external standard node. If a candidate search result contains a term definition, the processing end can check whether the term node is associated with the definition content or the definition clause.

[0155] This matching process can be achieved through methods such as exact matching, standardized name matching, synonym matching, clause number matching, or graph path matching. For engineering documents, the same term may have abbreviations, English names, or different expressions in different documents. The processing end can first perform terminology normalization before performing graph matching.

[0156] In step S802, in response to the inconsistency between the matching result and the relationship between the candidate search result and the entity in the graph, the confidence of the candidate search result is reduced or the candidate search result is marked as a result to be reviewed.

[0157] When the matching results indicate that a candidate search result is inconsistent with the entity relationships in the graph, the processing end can lower the confidence level of the candidate search result or mark it as a result requiring review. For example, if a candidate search result mentions that a clause references external standard A, but the entity relationships in the graph show that the clause actually references external standard B, the processing end can lower the confidence level of the candidate result. Similarly, if a candidate search result applies a requirement to all curtain wall types, but the entity relationships in the graph show that the requirement only applies to a specific curtain wall structure, the processing end can mark it as a result requiring review.

[0158] Lowering the confidence level does not necessarily mean deleting candidate search results. In the engineering field, some inconsistencies may stem from differences in document versions, clause wording, or incomplete map construction. To avoid missing potentially useful information, the processing end can retain the candidate result and prompt the user in subsequent engineering responses with messages such as "requires verification," "insufficient evidence," or "scope of application to be confirmed." In this way, the system avoids directly outputting unverified conclusions without completely discarding potentially valuable engineering data.

[0159] Step S803: Based on at least one of the document reference relationships, clause reference relationships, and version substitution relationships in the engineering document knowledge base, perform consistency verification on the multiple engineering documents involved in the candidate search results.

[0160] When candidate search results involve multiple engineering documents, the processing end can further perform cross-document validation. Cross-document validation is mainly used to determine whether the citation relationships, applicability relationships, version relationships, and conclusion relationships between different engineering documents are consistent.

[0161] Document references indicate that a specification, contract, or technical document references another document. Clause references indicate that a clause references another clause. Version substitutions indicate that a version of a document substitutes for or supersedes a version of another document. The processing end can use these relationships to determine whether there are applicable priorities, version conflicts, or reference chains among candidate results.

[0162] For example, when candidate search results contain both old and new version standard clauses, the processing end can determine whether the old clauses are still applicable based on the version substitution relationship. If the project contract explicitly stipulates the application of the old standard, the processing end can retain the old clauses and indicate the contract's applicable stipulations; if the knowledge base shows that the new standard has replaced the old standard and the project has no special stipulations, the processing end can prioritize the new standard clauses and indicate that the old clauses are for comparison only. As another example, when multiple clauses in the candidate results make different requirements for the same project object, the processing end can determine whether these requirements are complementary, have different scopes of application, or have potential conflicts based on the clause reference relationships and document hierarchy.

[0163] Step S804: In response to the consistency verification results indicating that there are clause conflicts, version inconsistencies, duplicate references, or duplicate conclusions among multiple engineering documents, generate conflict prompts, version prompts, or duplicate prompts for incorporating the engineering response results.

[0164] When cross-document validation detects anomalies, the processing end can generate corresponding prompts and incorporate them into the project response results. Conflict prompts alert users to differences in requirements between different documents or clauses; version prompts alert users to candidate results involving different versions of documents or substitution relationships; and duplication prompts alert users to multiple candidate results that essentially point to the same basis or the same conclusion.

[0165] For example, when a contract requires a performance indicator to meet a higher standard, while the technical specification provides a lower minimum requirement, the processing end can generate a conflict or difference alert, indicating that the contract requirements differ from the specification minimum requirements. Users should make a judgment based on the project contract priority. As another example, when multiple search results come from adjacent content blocks of the same clause, the processing end can generate a duplicate alert and merge these contents in the engineering response results to avoid repetitive listing.

[0166] These hints are not simply additional explanations, but rather the results of the verification process. By explicitly outputting conflicts, versions, and duplicates, the system avoids mechanically piecing together candidate results from multiple sources into a seemingly complete but actually contradictory answer.

[0167] Step S805: Based on the relationships in the engineering document knowledge base, determine the source document location information corresponding to the engineering response result.

[0168] When generating or organizing engineering response results, the processing end can track the empirical retrieval results on which each response content is based, and further determine the corresponding source document location information through the association relationships in the engineering document knowledge base. The source document location information may include at least one of the following: document identifier, chapter identifier, clause identifier, page number, spatial location information, and original object address.

[0169] For example, if a conclusion in the engineering response comes from Clause 5.1.4 of a specification, the processing end can determine the document identifier, chapter identifier, clause identifier, and page number corresponding to that conclusion. If the specific area of ​​that clause in the original page has been recorded by a structured document unit, the processing end can also determine the spatial location information. If the system has saved the content block image or page image of that area, the processing end can further determine the address of the original document object.

[0170] Source document location information enables traceability of every key conclusion in the engineering response. For engineering design, construction management, or contract review, this source location is more valuable than simply providing an answer, because users typically need to verify the original context, scope of application, and complete clause content.

[0171] Step S806: Generate a reference link or location marker based on the source document location information to trace back to the original project document location.

[0172] The processing end can generate reference links or location markers based on the source document's location information. Reference links can be links to the original document file, page images, content block images, or enterprise document management system pages. Location markers can be page number markers, clause markers, area highlight markers, coordinate markers, or page screenshot markers.

[0173] For example, when the source document location information includes document identifier, page number, and spatial location information, the processing end can generate a location link that opens the original document, jumps to the corresponding page number, and highlights the corresponding area. When the source document location information includes the address of the original text object, the processing end can directly generate a reference link pointing to the content block image. When the project response result references multiple clauses, the processing end can generate independent location markers for each clause, allowing users to review each clause individually.

[0174] In some implementations, reference links or locators can also carry version information, document source information, or permission information. For example, if the original engineering document is stored in an internal enterprise document system, the reference link can open the original document when the user has the appropriate permissions; if the user does not have permissions, the system can display document identifiers and clause identifiers for them to request to view.

[0175] Step S807: Output the project response results, source document location information, and reference links or location markers together.

[0176] The processing unit can output the project response results along with the corresponding source document location information, reference links, or location markers. The output format can be natural language answers, reports, tables, card-style results, Markdown documents, Word reports, or structured records from a project management system.

[0177] In one output method, each conclusion in the engineering response results is followed by corresponding source information and a location entry. For example, the system can display "Basis: Clause 5.1.4 of a certain standard, page 32, click to view the original text" after the conclusion. In another output method, the system can generate a list of cited sources at the end of the response results, listing all cited documents, chapters, clauses, page numbers, and location links. For response results with conflict warnings, version warnings, or duplicate warnings, the system can output the warning content along with the corresponding source document, enabling users to understand the source of the conflict or version difference.

[0178] Through the aforementioned verification process and traceable output, the engineering problem response method can perform structured verification of candidate results before generating the answer and retain the original text location basis when outputting the answer. Since the clauses, terms, citation relationships, and requirement relationships in the candidate retrieval results need to match the graph entity relationships in the engineering document's knowledge base, the system can reduce the risk of unfounded citations and terminological mismatches. Because consistency verification can also be performed between multiple engineering documents, the system can detect common problems in engineering scenarios such as version inconsistencies, clause conflicts, and duplicate conclusions. Furthermore, after the engineering response result is output in association with the source document location information, users can directly return to the original engineering document location from the answer for review, thereby making the engineering problem response result more credible, interpretable, and traceable.

[0179] The foregoing embodiments have described the construction method of the engineering document knowledge base and the engineering problem response process based on this knowledge base. In actual engineering business, users often do not first complete the entry of all documents into the database and then ask questions separately at a later time. Instead, they immediately raise engineering questions based on a new engineering document or in conjunction with existing materials when uploading a new engineering document. For example, after uploading a newly received English specification for a project, a designer immediately inquires about the special requirements for the fire resistance performance of curtain walls in that specification; or, after uploading a supplementary contract, a project manager immediately inquires whether the supplementary contract has changed the material testing requirements in the original contract. For this use case, in some implementations, the engineering problem response request can be a composite processing request, which also includes the engineering document to be processed.

[0180] In this embodiment, the composite processing request scenario can be understood as a combination of the document entry route and the issue response route. This scenario does not simply execute the "upload document" and "answer question" actions in parallel. Instead, it first processes the newly uploaded project document into data that can be added to the project document knowledge base, and then performs retrieval, verification, and response generation based on the updated project document knowledge base. In this way, the project document recently uploaded by the user can participate in the current project issue response, avoiding the system from missing new document content by answering only based on old data.

[0181] In scenarios involving complex processing requests, this engineering problem response method may also include the following steps.

[0182] Step S901: Obtain a composite processing request, which includes the project document to be processed and the project issues related to the project document.

[0183] The processing end can receive composite processing requests through web pages, mobile devices, project management system interfaces, or internal enterprise document platforms. A composite processing request includes both the engineering document to be processed and engineering issues. The engineering document to be processed can be a newly uploaded engineering specification, contract, drawings, calculation sheets, review comments, approval documents, or project technical data; the engineering issue can be a question raised by the user regarding the newly uploaded document, or a question that requires a combination of the newly uploaded document and existing engineering documents to answer.

[0184] For example, a user can upload a scanned copy of a project contract and ask, "What are the fire resistance requirements for curtain wall materials in this contract?" Alternatively, they can upload a new version of an engineering specification and ask, "Are there any differences between the new specification and the requirements in the existing project documentation?" In these scenarios, the engineering documents to be processed are not merely for future database entry, but need to be immediately used for the retrieval and verification of the current issue.

[0185] After receiving a composite processing request, the processing end can first assign a document identifier to the project document to be processed and record the association between the document and the current composite processing request. If the composite processing request also contains project identifier, user identity, specified document scope, return format, or business scenario information, the processing end can also use this information as contextual conditions for subsequent document processing and problem response.

[0186] Step S902 involves performing layout recognition, character-level spatial correction, content block segmentation, and multimodal content recognition on the project document to be processed to obtain multiple structured document units.

[0187] The processing end can employ the document structuring methods described in the aforementioned engineering document knowledge foundation construction process to process the engineering document to be processed. Specifically, the processing end can first perform layout recognition on the pages of the engineering document to be processed, identifying candidate document areas such as text, titles, tables, formulas, images, title blocks, drawing frames, and drawing annotations; then, it can combine character-level spatial correction to correct the boundaries of the areas, making the candidate document areas more closely match the actual content; subsequently, it can perform content block segmentation based on the corrected areas, and obtain content data using methods such as text recognition, multimodal recognition, table parsing, formula recognition, or image understanding according to the block type.

[0188] After the above processing, the project document to be processed is converted into multiple structured document units. Each structured document unit includes content data, block type, and source document location information. The source document location information may include at least one of the following: document identifier, block identifier, page number, spatial location information, and original object address. Since these structured document units are generated in real time within the current composite processing request, they can serve as a data source for subsequent knowledge base updates and can also directly participate in the retrieval and answering of the current project question.

[0189] Step S903: Based on the source document location information of multiple structured document units, update the metadata records, content vector representations, graph entity relationships, and associations with the original document objects in the engineering document knowledge base.

[0190] The processing unit can update the engineering document knowledge base based on the newly acquired structured document units. This update is not simply appending the full text of the new document to the existing database, but rather updating the metadata records, content vector representations, graph entity relationships, and associations between the original document objects around the structured document units.

[0191] For example, the processing end can generate new metadata records for newly generated structured document units to record information such as document source, page number, block type, clause number, chapter level, and project affiliation; it can also convert the content data of structured document units into new content vector representations for subsequent semantic retrieval; for clauses, terms, normative references, material names, or requirement relationships identified therein, the processing end can generate new graph entity relationships; at the same time, the processing end will also establish associations between the new structured document units and the original document objects or content block images, so that the new document content also has the ability to trace back to the original text.

[0192] Because the engineering document knowledge base is updated in the composite processing request, subsequent searches for engineering issues can include both newly uploaded engineering documents and existing engineering documents. This allows the system to utilize the relevant content from newly uploaded documents in the current response without waiting for the offline data import task to complete.

[0193] Step S904: Determine the query intent and retrieval topic based on the engineering problem, and perform vector retrieval and graph relationship query based on the updated engineering document knowledge base to obtain candidate retrieval results.

[0194] After updating the engineering document knowledge base, the processing end can identify the query intent and determine the search topic for engineering issues in composite processing requests. If the engineering issue involves only a single objective, the processing end can determine it as a search topic; if the engineering issue involves multiple professional directions, multiple documents, multiple clauses, or multiple verification objectives, the processing end can break it down into multiple search topics.

[0195] Compared to a simple problem-response approach, the retrieval target in this step is the updated engineering document knowledge base. In other words, when the processing end performs vector retrieval and graph relationship queries, it can access not only the content vector representations and graph entity relationships corresponding to existing engineering documents, but also the newly added content vector representations and newly added graph entity relationships generated based on the engineering document to be processed.

[0196] For example, when a user uploads a new specification and asks, "What are the requirements for fire protection design of curtain walls in this specification?", the processing terminal can retrieve the fire protection clauses in the new specification based on the updated knowledge base. It can also perform a relational lookup by combining the fire protection requirements from existing project contracts or enterprise standards. The resulting candidate search results reflect both the content of the newly uploaded project document and the connections between the new document and existing materials.

[0197] Step S905: Perform at least one of the following verification processes on the candidate search results: graph relationship verification and cross-document verification, to obtain verified search results.

[0198] Since composite processing requests typically involve combining newly uploaded documents with existing documents, candidate search results are more prone to issues such as version differences, clause conflicts, duplicate bases, or inconsistent scope of application. Therefore, the processing end can perform graph relationship verification and / or cross-document verification on candidate search results.

[0199] Graph relationship verification can be used to determine whether the terms, clauses, citation relationships, or requirement relationships in candidate search results are consistent with the graph entity relationships in the updated engineering document knowledge base. Cross-document verification can be used to compare document citation relationships, clause citation relationships, version substitution relationships, or requirement relationships between newly uploaded engineering documents and existing engineering documents.

[0200] For example, if a user uploads a new version of a specification and then inquires about its differences from the old version, the processing system can verify the candidate results based on version substitution relationships and corresponding clause relationships. If a requirement in the newly uploaded contract exceeds the minimum requirement in an existing specification, the processing system can identify this as a difference and remind the user of the relationship between the contract stipulations and specification requirements in the subsequent project response results.

[0201] Step S906: Generate engineering response results based on the verified search results.

[0202] The processing unit can generate engineering response results based on validated search results. Engineering response results can be answers to engineering questions, clause summaries, discrepancies explanations, conflict alerts, version information, design suggestions, or comprehensive reports. Because validated search results incorporate newly uploaded documents and existing knowledge bases, engineering response results reflect the latest information status.

[0203] For example, when uploading a new contract and asking "Are the material testing requirements in the contract consistent with the original specifications?", the engineering response results can list the testing requirements in the new contract and the testing requirements in the existing specifications, indicating the parts that are consistent, conflicting, or have different scopes of application. For content in the newly uploaded document that has not been fully parsed or whose verification confidence is insufficient, the processing end can also generate a "to be reviewed" prompt in the engineering response results.

[0204] Step S907: Based on the association relationships in the updated engineering document knowledge base, the engineering response result is associated with the corresponding source document location information and output, so that the engineering response result can be traced back to the corresponding original engineering document location.

[0205] The processing end can determine the source document location information upon which the engineering response result is based based on the relationships in the updated engineering document knowledge base. For references from newly uploaded engineering documents, the source document location information can point to page numbers, clauses, spatial areas, or content block images in the newly uploaded document; for references from existing engineering documents, the source document location information can point to the original document object in the existing knowledge base.

[0206] In the final output, the processing end can associate the project response with the source document location information, reference links, or location markers. This allows users to not only see the system's response to complex processing requests, but also distinguish which data comes from newly uploaded project documents and which comes from existing project documents, and to trace back to the corresponding original text location.

[0207] Through the aforementioned processing steps in the composite processing request scenario, after a user uploads a new document and asks a question, the system can first convert the new document into structured document units and update the engineering document knowledge base. Then, based on the updated knowledge base, it performs retrieval, verification, and response output. Because newly uploaded documents can instantly participate in vector retrieval, graph query, and cross-document verification, the system is no longer limited to answering questions based on historical data. Furthermore, since the engineering response results are still linked to the source document's location information, users can directly return to the original location in the newly uploaded document or existing documents for review. In this way, the composite processing route can cover the high-frequency scenario of "instant analysis of newly added data" in engineering practice and form a complete closed loop with the document entry route and the question response route.

[0208] In the aforementioned complex processing request scenario, knowledge base updates are a crucial link connecting "new document processing" and "responding to questions based on new documents." Reconstructing the entire engineering document knowledge base every time a new document is received is not only costly but also risks affecting the indexing stability of existing documents. Therefore, in some embodiments of this application, an incremental update method can be used to incorporate the data corresponding to newly uploaded engineering documents into the existing engineering document knowledge base.

[0209] In this embodiment, the incremental update process of the engineering document knowledge base may include the following steps.

[0210] Step S1001: Generate new metadata records, new content vector representations, and new graph entity relationships based on structured document units.

[0211] The processing end can perform data representation transformation on newly generated structured document units in composite processing requests. For each structured document unit, the processing end can generate a new metadata record based on its content data, block type, and source document location information. The new metadata record may include fields such as document identifier, block identifier, page number, block type, chapter information, clause information, document source, project identifier, version information, and update time.

[0212] The processing unit can also convert the content data of structured document units into vector representations of newly added content. If the structured document unit is text, clause, or title, the processing unit can directly generate vectors based on the text content; if the structured document unit is a table, formula, image, or drawing annotation, the processing unit can first convert its recognition results into structured text content, and then generate the corresponding vector. This vector representation of newly added content enables newly uploaded engineering documents to participate in subsequent semantic retrieval.

[0213] Simultaneously, the processing end can extract new graph entity relationships from structured document units. For example, it can extract new document nodes, chapter nodes, clause nodes, terminology nodes, and external specification nodes from newly uploaded specifications, and generate corresponding graph entity relationships based on hierarchical relationships, referencing relationships, definition relationships, requirement relationships, and applicability relationships. If there are referencing, substitution, or supplementary relationships between the newly uploaded document and existing engineering documents, the processing end can also generate cross-document graph relationships.

[0214] Step S1002: The newly added metadata records, newly added content vector representations, and newly added graph entity relationships are merged with the existing metadata records, content vector representations, and graph entity relationships in the engineering document knowledge base, respectively.

[0215] After generating new data, the processing end can merge the new metadata records, new content vector representations, and new graph entity relationships into the existing engineering document knowledge base. During the merging process, the processing end can determine the relationship between the new data and the existing data based on document identifiers, version information, clause numbers, block identifiers, term names, or standardized entity identifiers.

[0216] For newly added metadata records, the processing end can insert them into an existing metadata set, or perform updates or overwrites when the same document identifier and version are detected to already exist. For newly added content vector representations, the processing end can add them to the vector index and create index records corresponding to the structured document units. For newly added graph entity relationships, the processing end can merge the new nodes and relationships into the existing graph, and perform entity alignment and deduplication for terms with the same name, clauses, external specifications, or entity relationships.

[0217] For example, the term "structural adhesive" appearing in a newly uploaded document may already have a corresponding term node in the existing knowledge base. The processing end can perform name normalization matching between the new term and the existing term node. If it is determined to be the same entity, the definition, reference, or requirement relationship in the new document is attached to the existing term node, instead of repeatedly creating multiple term nodes with the same meaning. Similarly, if a newly uploaded specification may replace an existing specification, the processing end can retain the old document node and establish a version replacement relationship between the old and new document nodes, instead of simply deleting the old specification.

[0218] Through the above merging method, the engineering document knowledge base can maintain data consistency while continuously receiving new documents. New data is incorporated into the existing metadata, vector, and graph system, and the historical relationships of existing data are also preserved, thereby supporting subsequent version comparisons, cross-document verification, and historical basis tracing.

[0219] Step S1003: Based on the source document location information, establish the association between the newly added metadata record, the newly added content vector representation, the newly added graph entity relationship, and the original document object.

[0220] After merging the new data, the processing end also needs to establish the relationships between the new data based on the source document location information. For each newly generated structured document unit, the processing end can use its document identifier, block identifier, page number, spatial location information, and original object address to associate the new metadata record, the new content vector representation, the new graph entity relationship, and the original document object.

[0221] For example, for a clause content block in a newly uploaded contract, the processing end can associate the newly added metadata record of the clause with the newly added content vector representation, so that it can be recalled by semantic retrieval; it can also associate the contract clause node, requirement relationship or responsible party node generated by the clause with the structured document unit, so that it can be hit by graph query; at the same time, it can associate the structured document unit with the page number, spatial location and content block image address in the original contract scan, so that the subsequent response results can be traced back to the original text position.

[0222] In some implementations, if multiple structured document units correspond to the same clause node, the processing end can establish associations between each structured document unit and that clause node. If a structured document unit generates multiple graph nodes or multiple graph relationships simultaneously, the processing end can also establish multiple association records. By allowing one-to-many, many-to-one, and many-to-many association forms, the incremental update process can adapt to the characteristics of engineering documents such as cross-page clauses, mixed text and graphics, table-attached clauses, and distributed storage of formula descriptions.

[0223] In this implementation, the engineering document knowledge base does not need to be completely rebuilt when receiving new engineering documents. Instead, it incrementally updates structured document units, generating new metadata, vector representations, and graph relationships, which are then merged with the existing knowledge base and a retrospective association is established. Because the new data retains the source document's location information during the merging process, subsequent engineering response results generated based on the new document can still return to the original engineering document's location. Furthermore, because the new graph entity relationships are aligned and merged with existing graph entity relationships, the system can also identify terminology reuse, clause supplementation, version replacement, and requirement differences between the old and new documents. Therefore, the engineering document knowledge base can be dynamically updated as project data continues to increase, and can promptly support engineering problem responses in complex processing requests.

[0224] In the aforementioned engineering problem response methods, the engineering response results can include translated and displayed content of foreign language engineering documents, depending on the actual scenario. For business scenarios such as overseas curtain wall projects, overseas engineering contract review, and international standard comparison, users not only need to query the clauses and technical requirements in engineering documents, but also frequently need to view the corresponding Chinese explanations of foreign language engineering documents. Ordinary translation systems typically translate entire paragraphs directly, which can easily lead to problems such as inconsistent engineering terminology, mistranslation of formulas and units, disruption of table structures, and the inability of the translated text to correspond to the original text. Therefore, in some implementations, the processing end can generate translated and displayed content associated with the engineering response results based on structured document units.

[0225] In this embodiment, the processing end can call the aforementioned engineering document knowledge base, or it can generate translation display content based on the structured document units after the engineering document to be translated has completed the structured processing.

[0226] The process of generating the translated content may include the following steps.

[0227] Step S1101: Obtain translation processing requests or translation display requirements related to the engineering response results.

[0228] Engineering translation requests may include at least one of the following: the engineering document to be translated, the target language, the output translation format, and the scope of the translation. The engineering document to be translated may be an overseas project contract, engineering specification, technical manual, drawing instructions, calculation sheets, visa documents, or project correspondence. The target language may be Chinese, English, or other languages ​​required for the engineering project. The output translation format may include a bilingual document, a bilingual PDF, a sentence-to-sentence translation document, a structured translation report, or translation data that can be imported into an engineering document system.

[0229] In some implementations, the translation processing request can directly carry the project document to be translated; in other implementations, the translation processing request can also point to a project document that has already been stored in the database. If the project document to be translated has not yet been stored in the database, the processing end can first perform structured processing on it according to the aforementioned construction steps to obtain multiple structured document units. If the project document to be translated has already been stored in the database, the processing end can directly read the corresponding structured document units, source document location information, terminology nodes, graph entity relationships, and original document objects from the project document knowledge base.

[0230] Step S1102: Determine the content blocks to be translated based on structured document units.

[0231] The processing end can determine the content blocks to be translated from structured document units based on the translation scope specified in the engineering translation request. These content blocks can correspond to main text paragraphs, clauses, tables, formula descriptions, drawing annotations, figure captions, image descriptions, or comments. For translating the entire document, the processing end can use all valid structured document units in the engineering document as content blocks to be translated; for partial translation, the processing end can select only structured document units from user-specified page numbers, chapters, clauses, or areas.

[0232] When determining the content blocks to be translated, the processing end can retain the block type and source document location information for each block. The block type indicates whether the content block is plain text, a table, formula, image description, or drawing annotation; the source document location information is used to map the translated content back to its specific location in the original engineering document after the translation is generated. In this way, the translation process is not a pure text translation detached from the original format, but rather processes structured document units as translation objects.

[0233] Step S1103: Identify engineering terms in the content block to be translated and mark the engineering terms as placeholders.

[0234] The processing terminal can identify engineering terms in the content block to be translated based on the engineering glossary, term nodes in the engineering document knowledge base, project lexicon, historical translation memory or industry standard term bank. Engineering terms may include curtain wall structure names, material names, engineering component names, standard terms, performance indicators, unit symbols, formula parameters and project-specific expressions.

[0235] In one implementation, the processing terminal can adopt a multi-level term matching strategy to identify engineering terms. For example, the processing terminal may first perform exact matching to identify existing standard terms in the term bank; for compound expressions with specifications, grades or units, regular matching or rule-based matching can be further adopted; for the case that the same word has different meanings in different engineering contexts, the processing terminal can perform disambiguation in combination with context, graph entity relationships or the type of the clause where the word is located. For example, "sealant" can be understood as 密封胶 in general context, but may correspond to "结构密封胶" or "耐候密封胶" in the context of curtain wall engineering, and the processing terminal can determine its standard translation according to adjacent words, material nodes and clause topics.

[0236] After identifying the engineering terms, the processing terminal can perform placeholder marking on the engineering terms. For example, "structural sealant" can be replaced with the placeholder "TERM_001", and the standard translation "结构密封胶" corresponding to the placeholder is recorded. The translation model keeps the placeholder unmodified when processing the text to be translated, and after the translation is completed, the processing terminal replaces the placeholder with the standard translation. Through placeholder marking, the risk of the translation model making unconstrained translations of engineering terms can be reduced, and the translation of the same engineering term can be kept consistent throughout the entire document.

[0237] Step S1104, performing differentiated translation processing based on the block type of the content block to be translated.

[0238] For the content block to be translated of ordinary text type, after term placeholder marking, the processing terminal can input the text content into a translation model to generate a corresponding translation. For long clauses, the processing terminal can split them according to sentence boundaries, clause numbers, punctuation marks or semantic paragraphs, so that the translation can be easily corresponding to the original text while maintaining semantic integrity.

[0239] For tables, the processing unit can first preserve the table's row and column structure, header hierarchy, merged cell relationships, and cell order before translating the text content within each cell. For tables containing units, values, and symbols, the processing unit can identify and protect these elements, preventing changes to their representation during translation. After the table translation is complete, the processing unit can generate a translated table based on the original table structure, thus avoiding the translation of table content into unordered paragraphs.

[0240] For formula-type content blocks to be translated, the processing end can retain the formula body, variable symbols, unit symbols, and formula number, translating only the formula description, parameter explanation, or surrounding text. For engineering formulas that require standardization, the processing end can convert the formula into a LaTeX expression or other structured formula representation and establish a correspondence between the formula and its description text. In this way, the translation can both prevent the mistranslation of formula symbols and allow users to understand the meaning of each parameter in the formula.

[0241] For image-type or drawing annotation-type content blocks to be translated, the processing end can first obtain identifiable text, annotation objects, and explanatory content in the image through multimodal recognition, and then translate the identified text content. If the image contains multiple annotations, the processing end can preserve the positional relationship between the annotations and the image area, so that the translation can correspond to the annotation positions in the original image. For image content that cannot be reliably identified, the processing end can retain the original image and mark the corresponding area as awaiting manual review.

[0242] Step S1105: Generate a translation result corresponding to the original text layout based on the source document location information.

[0243] After obtaining the translation content corresponding to each block to be translated, the processing unit can generate a translation result corresponding to the original document layout based on the source document location information. The page number, spatial location information, block identifier, and original object address in the source document location information can indicate the location of each translated content in the original project document. The processing unit can then generate bilingual PDFs, two-column documents, sentence-by-sentence translation documents, or structured translation data.

[0244] When generating bilingual PDFs, the processing unit can use the original page image as a base map and overlay the translated text near the corresponding positions of the original content blocks, or generate a translated area on the side of the page. For table and drawing annotations, the translation can be kept in the area corresponding to the original text based on the spatial location information of the content blocks, allowing users to intuitively find the corresponding original text when viewing the translation.

[0245] When generating a sentence-by-sentence translated document, the processing end may organize the original text and the translation according to sentences, clauses or structured document units. For example, original sentences or original clauses are displayed on the left, with corresponding translations displayed on the right, and the page number, clause number, block identifier and original object address to which the original text belongs are retained. In this way, users can quickly check the correspondence between the translation and the original text when reviewing the translation.

[0246] When generating structured translation data, the processing end may store each translated content in association with the corresponding structured document unit, engineering term placeholder records, source document positioning information and translation status. The translation status may include states such as translated, pending review, term conflict, and uncertain image recognition. The structured translation data can be further written into the engineering document knowledge base for subsequent retrieval, question answering, review or secondary translation.

[0247] Step S1106: output the translation result in association with source document positioning information and term marking records.

[0248] The processing end may output the translation result, source document positioning information and term marking records in association. Term marking records may include original term text, placeholders, standard translations, term sources, affiliated structured document units and occurrence positions. Source document positioning information may include document identifiers, page numbers, block identifiers, spatial position information and original object addresses. By outputting these associated pieces of information, users can not only view the translation, but also know which position of the original text the translation comes from, which engineering terms have been standardized, and which contents need further review.

[0249] For example, in the contract translation scenario of an overseas curtain wall project, the system may uniformly translate terms such as "curtain wall", "structural sealant" and "firestop material" into "幕墙", "结构密封胶" and "防火封堵材料", and indicate in the term records that these translations come from the engineering term base or the enterprise term list. For the fire protection clause on a certain page of the contract, the system can output the translation, original page number, clause position and content block image link, enabling technical personnel to quickly check the original text. For material performance indicators in a table, the system may retain the numerical values and units, and maintain the original table structure in the translated table.

[0250] Through the above-described translation demonstration content generation process, the translation workflow is no longer ordinary text translation detached from the engineering document structure. Instead, it is based on structured document units, combining engineering terminology recognition, placeholder protection, block type differentiation processing, and source document location information to generate the translation. Because engineering terms are identified and protected before translation, the translation of the same engineering term remains stable, reducing the likelihood of general translation models rewriting technical terms based on context. Since tables, formulas, images, and drawing annotations are processed according to their respective block types, the translation better preserves the structural and technical meaning of the engineering document. Furthermore, because the translation result is output in association with the source document location information, users can quickly return to the original engineering document location from the translation for review, thereby improving the efficiency and reliability of overseas engineering document translation, review, and knowledge accumulation.

[0251] The following example, using the real-time analysis of new specifications in overseas curtain wall projects, further illustrates the implementation process of the aforementioned engineering problem response method in a scenario involving complex processing requests.

[0252] In this application scenario, a curtain wall company is handling a curtain wall project for an overseas mixed-use complex. The project team received a new English technical specification document, a scanned PDF of 80 pages, containing clauses, tables, formulas, drawing screenshots, and several project-specific requirements. The designers want to immediately understand the specific requirements related to fire protection design of the curtain wall after uploading the specification document and request the system to provide the location of the original text for review.

[0253] The designers uploaded the English technical specification document through the company's internal intelligent engineering document processing platform and entered the engineering question: "Please extract the requirements related to the fire protection design of the curtain wall from the technical specifications of this project, and explain whether there are any differences from the existing fire protection specifications in the knowledge base."

[0254] Upon receiving the aforementioned composite processing request, the processing unit first identifies the uploaded English technical specification document as the project document to be processed and assigns a document identifier to it. Subsequently, the processing unit performs layout recognition on the English technical specification document, identifying candidate document areas such as text areas, title areas, table areas, formula areas, image areas, and drawing annotation areas. For the text clauses in the scanned pages, the processing unit corrects the region boundary boxes obtained from layout recognition through character-level spatial correction, ensuring that clause text, clause numbers, and table titles are located within the same structured document unit as much as possible. For table areas, the processing unit performs block-level cropping according to the corrected spatial positions to obtain table content block images. For drawing screenshots and drawing annotation areas, the processing unit crops the corresponding content block images for subsequent multimodal recognition.

[0255] After completing the above processing, the processing end obtains multiple structured document units. For example, one structured document unit corresponds to the clause area on "fire resistance of curtain wall perimeter joint" on page 32 of the English technical specification. This structured document unit includes the clause text, block type, document identifier, page number, block identifier, spatial location information, and the image address of the content block corresponding to this clause area. Another structured document unit may correspond to the fire-resistant material performance table on the same page. The content data of this unit includes fields such as the table row and column structure, material name, fire resistance time, and applicable locations.

[0256] The processing unit further generates new metadata records, new content vector representations, and new graph entity relationships based on the aforementioned structured document units. For the aforementioned fire protection clause area, the processing unit can generate corresponding clause nodes and extract term nodes such as "curtain wall," "fire resistance," "perimeter joint," and "firestop material" from the clause text; for the fire protection material performance table, the processing unit can extract material nodes, performance index nodes, and requirement relationships. If the English technical specification references local building fire protection codes, the processing unit can also generate external code nodes and establish reference relationships between the clause node and external code nodes. The processing unit incorporates these new metadata records, new content vector representations, and new graph entity relationships into the engineering document knowledge base and establishes associations with the original PDF file and content block images based on document identifiers, block identifiers, and original object addresses.

[0257] After the engineering document knowledge base is updated, the processing end performs intent recognition on the engineering questions entered by the designers. This engineering question involves two objectives: "curtain wall fire protection design requirements" and "whether there are differences with existing fire protection codes." Therefore, the processing end can break it down into at least two search topics: one search topic is used to retrieve clauses related to curtain wall fire protection design in the newly uploaded English technical specifications, and the other search topic is used to retrieve existing code clauses related to curtain wall fire protection design in the existing engineering document knowledge base, and to verify the differences.

[0258] For the first search topic, the processing system performed vector searches and graph relationship queries based on terms such as "curtain wall fire resistance," "perimeter joint firestop," and "curtain wall fire protection," retrieving relevant clauses and tables from newly uploaded English technical specifications from the updated engineering document knowledge base. For the second search topic, the processing system searched for curtain wall fire protection-related clauses in existing fire protection codes, enterprise standards, and project history data, and determined the requirement relationships between these clauses and terms such as "curtain wall fire protection," "firestopping," and "fire resistance integrity" through graph relationship queries.

[0259] After obtaining the candidate search results, the processing end verifies the candidate clauses in the newly uploaded technical specifications and the candidate clauses in existing specifications. If the newly uploaded technical specification requires fire-resistant sealing materials for a certain part to achieve a 2-hour fire resistance performance, while the existing enterprise standard only requires a 1.5-hour fire resistance performance for the corresponding part, the processing end can identify the difference based on the relationship between the clause node, performance index node, and applicable part node, and mark it as a difference prompt. If a clause in the newly uploaded technical specification references a local building fire protection code, the processing end can verify whether the reference exists in the engineering document knowledge base through the external code node and reference relationship; if no corresponding external code is found, the processing end can mark the reference as a basis for review.

[0260] Subsequently, the processing unit generates engineering response results based on the verified search results. These results may include: summaries of clauses related to curtain wall fire protection design from newly uploaded English technical specifications, performance requirements for fire-resistant materials, applicable locations, explanations of differences from existing fire protection codes or enterprise standards, and external specification references requiring further review by designers. For English clauses, the processing unit can also generate corresponding Chinese translations by invoking the engineering translation workflow without altering the aforementioned composite processing approach, allowing designers to simultaneously view the original English text, Chinese explanations, and engineering summaries. This translation can serve as supplementary content to the engineering response results, and its basis remains the already established structured document units.

[0261] When outputting engineering response results, the processing end associates each response with the source document's location information. For example, for the response "the fire resistance of fire-stopping materials should reach 2 hours," the system can simultaneously output the document name, page number, clause number, content block image link, and page area location marker. Designers can click the location marker to directly open page 32 of the uploaded English technical specification and locate the corresponding clause area. For existing enterprise standard clauses referenced in the difference explanation, the system can also output the document identifier, clause number, page number, and location link of that enterprise standard for designers to compare and verify.

[0262] As demonstrated by the above application scenarios, the composite processing approach enables newly uploaded engineering documents to complete structured processing, knowledge base updates, retrieval verification, and response output within a single request. Since clauses, tables, and drawing annotations in the new document are converted into structured document units with source document location information, the processing end can correlate the newly uploaded document with existing specifications, contracts, and enterprise standards within the knowledge base. Furthermore, because the engineering response results carry the original document location information, designers can quickly return to the specific locations of the original technical specifications and existing standards for verification. In overseas curtain wall projects where a large amount of new data, foreign language materials, and project-specific requirements are constantly being added, this method reduces the workload of manual page-by-page review and comparison, and mitigates design risks arising from overlooked new document requirements or the use of incorrect specification clauses.

[0263] Those skilled in the art will understand that Figure 4 The structures shown are only partial structures relevant to the present application and do not constitute a limitation on the computer device described in this application. Actual computer devices may include, but are not limited to, those described in this application. Figure 4 The method may involve more or fewer components, combinations of certain components, or different component arrangements. All or part of the processes described in the foregoing method embodiments can be implemented by computer program instructions to related hardware. This computer program can be stored in a computer-readable storage medium and executed by at least one processor to implement the steps in the above method embodiments.

[0264] Please refer to Figure 4 In one embodiment, the computer device 1100 can be a terminal or a server; wherein the terminal can be an electronic device with communication function such as a smartphone, tablet computer, laptop computer, desktop computer, personal digital assistant, wearable device, etc., and the server can be an independent server or a server cluster composed of multiple servers.

[0265] like Figure 4 As shown, the computer device 1100 includes a processor 1102, a memory, and a network interface 1105 connected via a system bus 1101. The memory may include a non-volatile storage medium 1103 and internal memory 1104. The non-volatile storage medium 1103 may store an operating system 11031 and a computer program 11032. The computer program 11032 includes program instructions. When the processor 1102 executes the program instructions, it can implement the method steps of any of the foregoing embodiments.

[0266] The processor 1102 provides computing and control capabilities to support the operation of the computer device 1100. The internal memory 1104 provides an environment for the execution of the computer program 11032 in the non-volatile storage medium 1103. The network interface 1105 is used for network communication with other devices, such as receiving pending project documents, project problem response requests, or outputting project response results and corresponding source document location information.

[0267] The processor 1102 may be a central processing unit, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array, or other programmable logic devices, or other general-purpose processors. The non-volatile storage medium 1103 may be a read-only memory, flash memory, hard disk, solid-state drive, magnetic disk, optical disk, or other medium capable of storing program code.

[0268] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0269] Therefore, this application also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program, wherein the computer program includes program instructions. When executed by a processor, the program instructions cause the processor to perform the method steps of the foregoing embodiments.

[0270] The storage medium can be any computer-readable storage medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk.

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

[0272] In the several embodiments provided in this application, it should be understood that the disclosed methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

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

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

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

Claims

1. A method for responding to engineering problems based on AI and a knowledge base of traceable engineering documents, characterized in that, include: Obtain engineering issue response requests, which include engineering issues related to engineering documents; Based on the engineering problem, the query intent is determined, and if the query intent indicates that the engineering problem requires multi-target retrieval, the engineering problem is decomposed into multiple retrieval topics; otherwise, the engineering problem is determined as a single retrieval topic. Based on the query intent and the retrieval topic, vector retrieval and graph relationship query are performed on the engineering document knowledge base to obtain candidate retrieval results; wherein, the engineering document knowledge base includes metadata records, content vector representations, graph entity relationships and original document objects associated with structured document units, and the association between the structured document unit and the metadata records, the content vector representations, the graph entity relationships and the original document objects is established based on the source document location information of the structured document unit; The candidate search results are subjected to at least one of the following verification processes: graph relationship verification and cross-document verification, to obtain verified search results; Engineering response results are generated based on the verified search results; Based on the association relationships in the engineering document knowledge base, the engineering response result is associated with the corresponding source document location information and output, so that the engineering response result can be traced back to the corresponding original engineering document location.

2. The method according to claim 1, characterized in that, The engineering document knowledge base is constructed through the following steps: Obtain the project document to be processed; The project document to be processed is subjected to layout recognition, character-level spatial correction, content block segmentation, and multimodal content recognition to obtain multiple structured document units; wherein, each structured document unit includes content data, block type, and source document location information, the source document location information includes document identifier and unit location information, the unit location information includes at least a block identifier, and includes at least one of page number, spatial location information, and original object address; Based on the multiple structured document units, metadata records, content vector representations, and graph entity relationships corresponding to each structured document unit are generated; Based on the source document location information of each structured document unit, establish the association between metadata records, content vector representations, graph entity relationships and original document objects corresponding to the same structured document unit, and form the knowledge base of the engineering document; The engineering document knowledge base is configured to perform bidirectional backtracking between the structured document units, the content vector representation, the graph entity relationships, and the original document objects based on the association relationships.

3. The method according to claim 2, characterized in that, The layout recognition and the character-level spatial correction include: The layout of the pages of the project document to be processed is detected to obtain at least one candidate document region and a region category and an initial region bounding box corresponding to each candidate document region; wherein, the region category is used to indicate that the corresponding candidate document region is at least one of the following: text region, title region, table region, formula region, image region, title block region, drawing frame region, and drawing annotation region; Obtain the character coordinates within the candidate document region; Based on the character coordinates, the initial region bounding box is fitted twice to obtain the corrected region bounding box; Based on the initial region bounding box and the corrected region bounding box, the bounding box overlap ratio is determined, and the content retention ratio is determined. The content retention ratio is the ratio between the number of valid content blocks corresponding to the content items in the original content list obtained from the initial parsing and retained after layout recognition and correction, and the number of the original content list. Based on the bounding box overlap ratio and the content retention ratio, determine whether the layout recognition result meets the correction adoption conditions; In response to the layout recognition result satisfying the correction adoption condition, the corrected region bounding box is determined as the spatial location information of the structured document unit corresponding to the candidate document region.

4. The method according to claim 2, characterized in that, The content block segmentation and the multimodal content recognition include: Based on the block type and the spatial location information, the project document to be processed is cropped at the block level to obtain a content block image corresponding to the structured document unit; The storage address of the content block image is used as part of the source document location information and associated with the corresponding structured document unit for storage; In response to the fact that the block type corresponding to the structured document unit is text type, text recognition is performed on the structured document unit; In response to the structured document unit being a table, formula, or image type, a multimodal recognition model is invoked to recognize the corresponding content block image and generate structured text content.

5. The method according to claim 2, characterized in that, The generation of graph entity relationships corresponding to each of the structured document units includes: Metadata records are extracted based on the multiple structured document units, and at least one graph node is generated from the document node, chapter node, clause node, terminology node and external specification node corresponding to the metadata records; Based on at least one of the hierarchical, referential, definitional, requirement, and applicability relationships among the graph nodes, the graph entity relationships are generated. The step of establishing the association between metadata records, content vector representations, graph entity relationships, and original document objects corresponding to the same structured document unit based on the source document location information of each structured document unit includes: Using the document identifier and block identifier in the source document location information as association keys, a first association relationship is established between the structured document unit and the content vector representation; Establish a second association relationship between the structured document unit and the graph nodes corresponding to the graph entity relationship; Establish a third association between the structured document unit and the original document object address of the original document object.

6. The method according to claim 1, characterized in that, The vector retrieval and graph relationship query performed on the knowledge base of the engineering document to obtain candidate retrieval results include: Based on the search topic, a vector search is performed on the knowledge base of the engineering document to obtain vector recall results; Based on the search topic, a graph relationship query is performed on the engineering document knowledge base to obtain a graph subgraph corresponding to the search topic; Based on the vector recall results and the graph subgraph, the candidate retrieval results are generated; Determine the overall confidence level of the candidate search results; In response to the overall confidence level being lower than a preset confidence threshold, a secondary search topic is generated based on the candidate search results; The search scope is expanded based on the secondary search topics, and a re-sorting process is performed to obtain updated candidate search results.

7. The method according to claim 1, characterized in that, The step of performing at least one of the following verification processes on the candidate search results—graph relation verification and cross-document verification—to obtain verified search results includes: At least one of the clause identifiers, term entities, reference relationships, and requirement relationships in the candidate search results is matched with the graph entity relationships in the engineering document knowledge base; In response to the matching result indicating that the candidate search result is inconsistent with the relationship between the entity in the graph, the confidence of the candidate search result is reduced or the candidate search result is marked as a result to be reviewed; Based on at least one of the document citation relationship, clause citation relationship, and version substitution relationship in the engineering document knowledge base, the consistency of multiple engineering documents involved in the candidate search results is verified. In response to the consistency verification results indicating that there are clause conflicts, version inconsistencies, duplicate references, or duplicate conclusions among the multiple project documents, conflict prompts, version prompts, or duplicate prompts are generated for incorporating the project response results. The step of associating the engineering response result with the corresponding source document location information based on the association relationships in the engineering document knowledge base, so that the engineering response result can be traced back to the corresponding original engineering document location, includes: Based on the aforementioned relationship, the source document location information corresponding to the engineering response result is determined. The source document location information includes a document identifier and at least one of the following: chapter identifier, clause identifier, page number, spatial location information, and original object address. Based on the source document location information, generate reference links or location markers for tracing back to the original project document location; The project response results, the source document location information, and the reference links or location markers are associated and output.

8. The method according to claim 1, characterized in that, The engineering problem response request is a composite processing request, which also includes the engineering document to be processed. Before performing vector retrieval and graph relationship query on the engineering document knowledge base, the method further includes: The project document to be processed is subjected to layout recognition, character-level spatial correction, content block segmentation, and multimodal content recognition to obtain multiple structured document units; wherein, each structured document unit includes content data, block type, and source document location information; Based on the source document location information of the multiple structured document units, update the metadata records, content vector representations, graph entity relationships, and associations with the original document objects in the engineering document knowledge base; The step of performing vector retrieval and graph relationship query on the engineering document knowledge base based on the query intent and the retrieval topic includes: performing vector retrieval and graph relationship query on the updated engineering document knowledge base based on the query intent and the retrieval topic.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1 to 8.

Images