Method and system for RAG type data item extraction and consistency checking oriented to engineering technology document

Abstract

The invention relates to the technical field of intelligent processing of document information, discloses a method and a system for extracting RAG type data items and checking consistency for engineering technology documents, and solves the problem that an existing scheme is difficult to consider high-accuracy extraction, cross-document consistency, strong traceability and structured landing in engineering technology document data processing. The scheme comprises the following steps of: performing layout analysis and necessary OCR (Optical Character Recognition) processing on a received document, and dividing the document into multiple levels of text blocks; carrying out vectorization processing on the multi-level text blocks by adopting an embedding model subjected to two-stage fine adjustment, establishing a vector index and recalling candidate fragments to form a candidate fragment set; a cross encoder with efficient fine tuning of parameters is adopted to screen out high-correlation fragments; performing standardization processing by extracting a target variable to form a structured record; consistency checking is conducted on the target variables, and finally structured records and checking results are bound with minimum evidence fragments and corresponding position information to be exported through a format list.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of intelligent processing of document information, and in particular to a method and system for RAG type data item extraction and consistency checking for engineering technical documents. BACKGROUND

[0002] In the whole life cycle management of engineering projects, engineering technical documents such as specification files, technical reports, equipment parameter data, and test detection records are core data carriers. Such documents generally have the characteristics of large volume and various types: they contain both structured table data and unstructured text descriptions, and the same technical parameters (such as equipment model, material strength, design size, etc.) often appear repeatedly in different documents (such as design specifications and construction plans) or different versions of the same document, and even have problems such as numerical deviation, unit inconsistency, and heterogeneous expression.

[0003] Traditional engineering data processing relies on manual extraction and proofreading. Workers need to check documents one by one, manually extract key parameters, and compare consistency. This not only consumes time and effort, but also is prone to omissions and errors due to human negligence, making it difficult to meet the actual needs of engineering projects for high-frequency data updates, rapid verification, and traceable audit.

[0004] With the development of technology, some automatic processing schemes have appeared in the prior art, mainly divided into two categories: (1) Rule / template driven: relying on regular expressions, handwritten business rules, or fixed format templates to implement field extraction. This scheme has strong interpretability, but has poor adaptability to cross-document heterogeneous expression, synonym variants, unit conversion differences, and format drift of engineering documents, and has high maintenance cost.

[0005] (2) General large language model direct question answering / extraction: using the context understanding ability of general large language models to directly complete question answering extraction. This scheme can handle complex document structures, but still has some problems: first, it is prone to hallucinations and generates false parameters that do not exist in the document; second, it has weak traceability and cannot locate the original text fragment corresponding to the result, making it difficult to verify manually; third, it has poor cross-document consistency and cannot systematically compare differences in the same parameter in multiple documents.

[0006] To alleviate the above problems, the industry introduces the Retrieval-Augmented Generation (RAG) technology, which improves the reliability of the results by first retrieving relevant fragments and then generating answers. However, in the context of engineering long documents, the general RAG scheme still faces the following common technical difficulties: (1) Insufficient recall: general embedding models are not sensitive to engineering domain-specific terminology, variable aliases, and cross-version expressions, resulting in low recall rate of relevant fragments; at the same time, improper setting of block granularity and overlap degree can damage the completeness of the parameter context.

[0007] (2) Ranking bias: re-ranking models without domain fine-tuning have difficulty distinguishing between "semantically similar but irrelevant" interference segments, resulting in high-score misranking, directly affecting downstream extraction accuracy.

[0008] (3) Difficulty in variable-level standardization: engineering parameters cover numerical types (including units, precision requirements) and non-numerical types (such as material types, grade standards), and general RAG lacks unified unit conversion rules, precision control strategies, and alias normalization mechanisms, making it difficult to meet the standardization requirements of engineering data.

[0009] (4) Lack of cross-document consistency: there is no systematic comparison and source priority strategy for the same variable between different documents / versions, and it is difficult to determine whether it is consistent and to provide a difference explanation.

[0010] (5) Lack of traceability: the extraction results are not bound to the minimum evidence segment and the original text location, making it impossible to achieve one-key backtracking verification.

[0011] (6) Lack of structured landing: the output format has no unified specification, and the subsequent archiving and auditing cost is high.

[0012] (7) Deployment and compliance restrictions: engineering documents often contain sensitive information, and general RAG solutions do not implement local reasoning priority and cloud-based high-precision model fallback flexible deployment strategies, making it difficult to balance data security and processing accuracy.

[0013] In summary, the existing technology cannot simultaneously meet the comprehensive needs of high accuracy, strong traceability, cross-document consistency, and easy structured landing for engineering technical documents, and there is an urgent need for a RAG-type data extraction and consistency verification method and system for engineering documents that can introduce domain-oriented model fine-tuning in recall and ranking stages, and combine variable-level standardization, cross-document consistency verification, evidence traceability backtracking, and structured export to achieve comprehensive improvement in accuracy, traceability, and engineering usability. SUMMARY

[0014] The technical problem to be solved by the present application is to provide a RAG-type data item extraction and consistency verification method and system for engineering technical documents, which solves the problem that existing solutions cannot simultaneously consider high-accuracy extraction, cross-document consistency, strong traceability, and structured landing in engineering technical document data processing.

[0015] The technical solution adopted by the present application to solve the above technical problems is: On the one hand, the present application provides a RAG-type data item extraction and consistency verification method for engineering technical documents, comprising the following steps: S1. receiving an engineering field document, performing layout analysis and necessary optical character recognition on the document, extracting positioning metadata, and simultaneously performing encoding unification, noise cleaning, and format normalization on the document; S2. dividing the document into multiple levels of text blocks according to the title hierarchy and semantics of the document; S3. using an embedded model with two-stage fine-tuning to vectorize the multiple levels of text blocks and establish a vector index; the two-stage fine-tuning includes: first-stage model training based on a ranking loss function and second-stage difficult negative sample mining based on the model weights after the first-stage training and continuing training; recalling candidate segments from the vector index based on preset recall conditions to form a candidate segment set; S4. using a cross-encoder with parameter-efficient fine-tuning to calculate the relevance of the candidate segment set to the target query and score, and selecting a preset number of high-relevance segments based on the scoring results; S5. extracting target variables from the high-relevance segments, normalizing the target variables, and forming structured records including field names, values, units / precisions, and source segments; S6. obtaining values of the same target variable in different documents, different versions, or different sources and comparing, outputting consistency determination results according to preset checking rules, the consistency determination results including consistent or inconsistent conclusions and difference explanations, and determining the final value and the list of alternative values to be accepted; S7. binding the structured records and the consistency determination results to the corresponding minimum evidence segments, respectively, and the original text location information corresponding to the minimum evidence segments, to support one-key jumping to the corresponding location in the original text based on the original text location information; S8. exporting the consistency determination results as a list in a preset format, performing preset hierarchical constraint rules during the exporting process, and recording the audit log of the exporting process.

[0016] Further, in step S2, the document is divided into multiple levels of text blocks using three-level recursive blocking: the first-level blocks are in chapters / sections, the second-level blocks are in paragraphs, and the third-level blocks are in sentences / table cells, while controlling the block length to be 512-1024 characters and the overlap ratio to be 10%-20%, and binding original text location metadata to each third-level block, including the page number, paragraph number, and table cell coordinates of the document.

[0017] Furthermore, in step S3, the ranking loss function adopts MNR loss or InfoNCE loss, and the first stage training adopts a non-repeating sampling method; the difficult negative sample mining is to select from the candidate segments generated by the model after the first stage training that have a similarity to the target query higher than a preset threshold but have negative labels as difficult negative samples.

[0018] Furthermore, in step S4, the cross-encoder with efficient parameter fine-tuning inserts a low-rank adapter into the attention layer of the cross-encoder. During training, only the parameters of the low-rank adapter are optimized, while the pre-trained weights of the cross-encoder are preserved.

[0019] Furthermore, in step S5, the normalization process includes: performing unit conversion, precision adaptation, and value range verification on numerical target variables, wherein the precision adaptation includes setting the number of decimal places to retain and determining the numerical rounding method; and performing aliasing normalization and parsing based on regular expressions or prompt word templates on non-numerical target variables.

[0020] Furthermore, in step S6, the preset verification rules include: source priority rules, tolerance rules, and conflict determination rules; the source priority rules include: standard documents have higher priority than third-party testing reports, and third-party testing reports have higher priority than internal records; the tolerance rules include: using absolute tolerance or relative tolerance to determine consistency for numerical target variables, and calculating string similarity using edit distance algorithm or Jaccard similarity algorithm to determine consistency for non-numerical target variables; the conflict determination rules include: when the values ​​of the same field in multiple documents exceed the tolerance range, the system will mark them as "conflicting" and output a difference description.

[0021] Furthermore, in step S8, the list in the preset format includes index, keyword, unit, and quantity fields. The unit and quantity fields are merged in the list corresponding to the non-numerical target variable, and normalization information is retained in the remarks column. The hierarchical constraint rule is to fill in only the lowest-level variables in the target variables; The preset formats include Excel, CSV, or JSON formats.

[0022] On the other hand, the present invention also provides a system for extracting and verifying RAG-type data items for engineering technical documents, the system comprising: The document preprocessing module is used to receive engineering documents, perform layout parsing and necessary optical character recognition processing on the documents, extract the location metadata of the documents, and perform encoding unification, noise removal and format regularization on the documents. The recursive block division module is used to divide the document processed by the document preprocessing module into multi-level text blocks according to the title level and semantics of the document. The vectorization and indexing module is used to vectorize the multi-level text blocks and establish vector indexes using a two-stage fine-tuned embedding model. The retrieval module is used to retrieve candidate segments from the vector index based on preset recall conditions to form a candidate segment set; The reordering module is used to employ a cross encoder with efficient parameter fine-tuning to calculate and score the relevance between the candidate fragment set and the target query, and to filter out a preset number of highly relevant fragments based on the scoring results. The extraction and standardization module is used to extract target variables from the highly correlated segments, and to standardize the target variables to form a structured record including field name, value, unit / precision, and source segment. The consistency verification module is used to obtain and compare the values ​​of the same target variable in different documents, versions or sources, output the consistency judgment result according to the preset verification rules, and determine the final value to be accepted and the list of alternative values. The tracing and export module is used to bind the corresponding minimum evidence fragment and the original text location information of the minimum evidence fragment to the structured record and the consistency judgment result respectively, so as to support one-click jump back to the corresponding location in the original text based on the original text location information; export the consistency judgment result as a list in a preset format and execute hierarchical constraint rules, while recording audit logs.

[0023] Furthermore, the system also includes infrastructure components, which include: a vector database, a model inference service, an OCR / layout parsing service, and an audit log service; The vector database is used to store vector data generated by the vectorization module; the model inference service is used to provide local inference and cloud-based model inference support; the OCR / layout parsing service is used to perform optical character recognition processing and layout parsing on scanned documents; and the audit log service is used to store audit logs generated by the data export module.

[0024] Furthermore, the source tracing and export module provides the original text location information of the smallest evidence fragment bound to the structured record and consistency judgment result, including: document identifier, page number, paragraph number, table cell coordinates, text start offset, and text end offset.

[0025] The beneficial effects of this invention are: (1) Improve the quality of retrieval and extraction: The embedding model used for vectorization is fine-tuned in two stages (ranking loss pre-training and hard negative sample incremental training), which can accurately identify engineering domain professional terms, parameter aliases and cross-version expression differences. Combined with recursive semantic block segmentation to ensure the integrity of the context, it effectively reduces the omission of relevant segments due to insensitive terms or improper block segmentation. The cross-encoder with parameterized efficient fine-tuning used in the re-ranking process can distinguish semantically similar but irrelevant interference segments, improve the relevance of candidate segment ranking, and reduce the error risk of downstream data extraction from the source.

[0026] (2) Implement variable-level standardization: For numerical parameters, unified unit conversion, customized precision rules, and value range verification are used to avoid data ambiguity caused by inconsistent units and non-standard precision. For non-numerical parameters, alias normalization and template parsing are used to unify heterogeneous representations and ensure that the value format of the same parameter is consistent in different documents.

[0027] (3) Ensure consistency across documents: By setting source priority rules and combining tolerance judgment for numerical parameters and string similarity judgment for non-numerical parameters, the system can automatically compare the values ​​of the same parameter in multiple documents / versions, output "consistent / inconsistent" conclusions and explanations of differences, and determine the final accepted value and alternative values ​​based on the rules, thus avoiding the subjectivity and omissions of manual comparison.

[0028] (4) Full-chain traceability: Each extraction result is bound to the smallest piece of evidence and the corresponding original text location information, supporting one-click jump back to the original text location for verification; the structured export synchronously records the audit log, meeting the audit requirements of engineering projects for traceable data sources and processes, and reducing the complexity of manual verification. Attached Figure Description

[0029] Figure 1 This is a system architecture diagram for RAG-type data item extraction and consistency verification of engineering technical documents in an embodiment of the present invention.

[0030] Figure 2 This is a flowchart of a method for extracting and verifying RAG-type data items for engineering technical documents in an embodiment of the present invention.

[0031] Figure 3 This is a flowchart of the recursive block processing in an embodiment of the present invention.

[0032] Figure 4 This is a flowchart of the two-stage fine-tuning process of the embedded model in an embodiment of the present invention.

[0033] Figure 5 This is a flowchart of the candidate reordering process in an embodiment of the present invention. Detailed Implementation

[0034] This invention aims to provide a method and system for extracting and verifying the consistency of RAG-type data items in engineering and technical documents. It addresses the challenges of existing solutions in engineering and technical document data processing, which struggle to simultaneously achieve high-accuracy extraction, cross-document consistency, strong traceability, and structured implementation. The core idea is to customize and optimize Retrieval Enhanced Generation (RAG) technology for the engineering domain, combining variable-level standardization, cross-document consistency verification, end-to-end evidence tracing, and structured export design. This forms a complete technical closed loop from document input to structured usability. It overcomes the shortcomings of general RAG in terms of sensitivity to engineering terminology, cross-document consistency judgment, and traceability, while avoiding the adaptability limitations of traditional rule / template solutions and the illusionary risks of general large-scale models. Ultimately, it achieves efficient, accurate, and auditable extraction and application of engineering and technical document data.

[0035] More specifically, the present invention achieves the above-mentioned core idea through the following means: (1) In view of the characteristics of engineering documents, such as many professional terms, heterogeneous parameter descriptions, and complex context of long documents, the sensitivity of domain terms and parameter aliases is improved by two-stage fine-tuning of the embedding model. The integrity of parameter context is ensured by recursive semantic segmentation. Then, the candidate segment sorting accuracy is optimized by cross-encoder with efficient parameter fine-tuning. The accuracy of data extraction is improved from the source of recall and sorting, thus solving the problem of insufficient adaptability of general RAG to engineering scenarios.

[0036] (2) In response to the strict requirements of uniform units, standardized precision, and cross-document consistency for engineering data, a variable-level standardization mechanism is designed to perform unit conversion, precision rule adaptation, and range verification for numerical parameters, and alias normalization and template parsing for non-numerical parameters. At the same time, a cross-document consistency verification logic is established. By pre-setting source priority, numerical tolerance, and string similarity judgment rules, the value of the same parameter in multiple documents or multiple versions of the same document is automatically compared, and the consistency conclusion and acceptance value are output to solve the inconsistency problem caused by heterogeneous expression and version differences in engineering data.

[0037] (3) To meet the needs of auditable data and reusable results in engineering scenarios, each extracted result is bound to the smallest evidence fragment and the corresponding original text location information, and one-click back verification is supported; at the same time, a standardized four-list export format is designed, and the rule of only filling in the last-level variable is implemented to ensure that the results can be directly connected to the engineering management system.

[0038] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0039] This embodiment first provides a system for extracting and verifying the consistency of RAG-type data items in engineering technical documents. In specific implementation, the system architecture is described below.Figure 1 The system adopts a B / S architecture, consisting of a front-end interactive interface and back-end application services. The back-end includes modules for document preprocessing, recursive chunking, vectorization and indexing, retrieval, reordering, extraction and standardization, consistency verification, tracing, and export. Supporting components include vector databases (such as ChromaDB), model inference services (local priority, cloud backup), OCR / layout parsing services, engine, and audit log services. The system supports multiple document inputs and outputs to adapt to batch processing scenarios for engineering reports.

[0040] The functions of each module in the above system are described below: The document preprocessing module is used to receive engineering documents, perform layout parsing and necessary optical character recognition processing on the documents, extract the location metadata of the documents, and perform encoding unification, noise removal and format regularization on the documents.

[0041] The recursive block division module is used to divide the document processed by the document preprocessing module into multi-level text blocks based on the document's title level and semantics.

[0042] The vectorization and indexing module is used to vectorize the multi-level text blocks and establish vector indexes using a two-stage fine-tuned embedding model.

[0043] The retrieval module is used to retrieve candidate segments from the vector index based on preset recall conditions, forming a candidate segment set.

[0044] The reordering module is used to employ a cross-encoder with efficient parameter fine-tuning to calculate and score the relevance between the candidate fragment set and the target query, and to filter out a preset number of highly relevant fragments based on the scoring results.

[0045] The extraction and standardization module is used to extract target variables from the highly correlated segments, and to standardize the target variables to form structured records including field names, values, units / precision, and source segments.

[0046] The consistency verification module is used to obtain and compare the values ​​of the same target variable in different documents, versions or sources, output consistency judgment results according to preset verification rules, and determine the final value to be accepted and the list of alternative values.

[0047] The tracing and export module is used to bind the corresponding minimum evidence fragment and the original text location information of the minimum evidence fragment to the structured record and the consistency judgment result respectively, so as to support one-click jump back to the corresponding location in the original text based on the original text location information; export the consistency judgment result as a list in a preset format and execute hierarchical constraint rules, while recording audit logs.

[0048] The document preprocessing module and recursive chunking module primarily provide a high-quality data foundation for subsequent retrieval, ensuring the integrity of metadata and the continuity of context. The vectorization and indexing module, retrieval module, and reordering module constitute the core retrieval chain of RAG, aiming to accurately select highly relevant segments from massive documents. The extraction and standardization module and consistency verification module are the core of engineering data quality control, solving the problems of heterogeneous parameter representations and cross-document differences. The tracing and exporting module plays a role in ensuring auditability.

[0049] The model scheduling and resource management module is the core control and adaptation hub of the system. Through intelligent scheduling and management of models, computing resources and processing flow, it ensures that the entire system achieves the best balance between performance, cost, security and scalability. Its main functions are: (1) Intelligent scheduling: As the brain of the system, it automatically selects and switches the most suitable model (local lightweight model or cloud high-precision model) and computing resources according to the task type, data sensitivity (such as confidential documents), processing accuracy requirements and current system load. (2) Resource optimization: It is responsible for managing and allocating local and cloud computing resources to ensure that resources are used efficiently during peak processing periods and released in time during off-peak periods, thereby achieving the optimization of operating costs while ensuring processing speed. (3) System decoupling and expansion: It decouples each functional module from the underlying components such as specific models, databases, and engines. This allows these components to be flexibly replaced, upgraded or expanded, greatly improving the maintainability of the entire system and its ability to adapt to different engineering scenarios. (4) Stability and security assurance: It monitors the health status of the system and resource usage in real time to ensure the stable operation of the system. Meanwhile, by prioritizing the use of local resources to process classified data and strictly recording all scheduling decisions and resource usage, a complete audit chain is provided to ensure the security and compliance of data processing.

[0050] Based on the above system, this embodiment also provides a method for extracting and verifying the consistency of RAG-type data items in engineering technical documents, the process of which is described in [link to flowchart]. Figure 2 This includes the following steps: S1. Document Preprocessing: In this embodiment, after receiving engineering documents (such as PDF, Excel, Word, and scanned documents) from external sources, the document preprocessing module needs to perform differentiated processing according to document type: For scanned documents, the image content is first converted into machine-processable text data using Optical Character Recognition (OCR) technology, and layout parsing is performed to recover the document's structural information (such as headings, paragraphs, tables, lists, etc.). The OCR engine uses preferred open-source or commercial OCR tools (such as Tesseract and ABBYY OCR) for text extraction, and automatically corrects and completes misidentified or blurred text during this process to maximize the accuracy of the text content.

[0051] For structured documents (such as Excel spreadsheets), cell data is read directly and linked to the table header to avoid data being separated from field names; for unstructured documents (PDF, Word), paragraph levels are parsed to preserve the relationship between headings and content.

[0052] In addition, metadata such as page numbers, paragraph numbers, and table cell coordinates are extracted and stored during preprocessing. This information will be used for subsequent original text location and tracing, ensuring that each data item can be associated with a specific location in the original text. The document's encoding format will be uniformly converted to the standard UTF-8 encoding format, and noise in the content will be cleaned up (such as removing redundant spaces and special characters) to ensure consistency and accuracy in subsequent processing. The preprocessed document results will be passed to the downstream recursive chunking module.

[0053] S2. Recursive block division: After document preprocessing, the recursive chunking module divides the text into multiple levels of semantic blocks based on the document's structure, facilitating subsequent embedding, vectorization, and retrieval. The granularity of chunking is typically paragraph → sentence → table cell, and each block retains the original text's coordinate information (such as document ID, page number, paragraph number, table cell coordinates, start offset, and end offset). This approach provides precise location support for each field during subsequent data extraction and consistency checks, ensuring that the generated structured data can be traced back to its specific location within the original document.

[0054] The block length and overlap ratio are controlled within specific ranges: block length is typically 512–1024 characters, and overlap ratio is 10%–20%, to balance computational efficiency and contextual integrity. Appropriate overlap is maintained between blocks to ensure that relevant contextual information is not lost during recursive block division. This parameter range has been experimentally verified and can reduce computational and storage resource consumption while ensuring the integrity of textual information.

[0055] Furthermore, the recursive chunking module dynamically adjusts the chunking strategy based on the document's content and structure. For example, in technical documents, heading levels and sections may contain multiple related paragraphs, so the module will prioritize grouping headings and related paragraphs into a single chunk to better capture the semantic information of that section. All chunks are saved as independent text units and bound to location information in the original text (such as paragraph numbers and page numbers).

[0056] Each chunk (whether a paragraph, sentence, or table cell) is assigned a unique ID and stored as a structured data unit. This data unit will include the following: Document ID: A unique identifier that identifies a document; Page number: The page number where the section is located; Paragraph number (if applicable): The paragraph number in which the block is located; Table cell coordinates (if applicable): If the block comes from a cell in a table, record the table position and cell number; Start and end offsets: Used to mark the specific location of the block in the document, ensuring that it can be accurately located in the original text.

[0057] This information will be stored in the vectorization and indexing module for subsequent vectorization and retrieval processes. The text content of each chunk and its associated location metadata are stored together, and an index is generated for each document to ensure fast response times for subsequent queries and retrievals.

[0058] In one example implementation, the recursive block processing flow is as follows: Figure 3 As shown, the details are as follows: Input objects: Covers common document types in the engineering field such as PDF, Word, and scanned documents, adapting to the multi-format characteristics of engineering documents. Chunking configuration parameters: Chunk length is set to 512-1024 characters, and the overlap ratio between chunks is 10%–20%; the chunking process must retain complete positioning metadata, including document page numbers, paragraph numbers, table cell coordinates, and text offsets.

[0059] The segmentation process employs a three-level recursive hierarchical structure: Level 1 segmentation: Divided by document "chapter / section", corresponding to the highest level of semantics in the document, ensuring the integrity of the main theme; Level 2 segmentation: Further subdivided into "paragraph" level segments based on Level 1 segments, focusing on medium-granularity semantic units; Level 3 segmentation: Finally refined to the "sentence / table unit" level, accurately capturing parameter-level core information and avoiding contextual fragmentation.

[0060] After the text is divided into blocks, location metadata is bound to each block, such as: {id:1024-17}, {page:12, para:3}, {cell:R4C2}, {offset:128-256}, to achieve precise binding between each text block and the original text position.

[0061] S3. Vectorization and Recall: In this embodiment, the vectorization and recall module is responsible for converting the text blocks generated by the recursive chunking module into vector representations and establishing vector indexes. This module uses pre-trained embedding models (such as the BGE series, Sentence-BERT, and FAISS) for vectorization, converting text blocks into dense vectors of fixed dimensions. These vectors can capture the semantic information of the document.

[0062] To improve the sensitivity and recall accuracy of engineering domain terminology, this embodiment introduces a two-stage fine-tuning strategy for the embedding model. First, a pre-trained embedding model is used for initial vectorization. Then, two-stage fine-tuning is performed on a specific engineering domain corpus to further improve the model's understanding of domain-specific terms, variants, and aliases, thereby enhancing retrieval accuracy and recall.

[0063] In one exemplary implementation, the two-stage fine-tuning process is described below. Figure 4 The specific explanation is as follows: 1. First stage of fine-tuning: The first stage of fine-tuning is primarily performed using ranking loss functions, such as MNR (Multiple Negatives Ranking) or InfoNCE. In this stage, the model aims to maximize the similarity between positive sample pairs and minimize the similarity between negative sample pairs through negative sample mining.

[0064] To ensure the effectiveness of fine-tuning, a non-repeating sampling strategy was adopted, selecting different text pairs from the project documents for training. The optimal range of hyperparameters during training was: Learning Rate: 1e -5 ~5e -4 Batch Size: 16–128; Epochs: 1–5.

[0065] The result of this fine-tuning phase is a preliminary embedding model that can vectorize standard terms and expressions in engineering documents, but its recall effect on low-frequency terms and aliases in specific domains is still weak.

[0066] 2. Second stage fine-tuning: After the first stage of fine-tuning, the second stage focuses on identifying difficult negative samples. High-scoring mismatches are selected from the candidate set generated in the first stage and used as new negative samples for incremental training. The inclusion of difficult negative samples significantly improves the model's generalization ability, enabling it to better identify synonyms and aliases. The key points of the second stage of fine-tuning are as follows: Selection of difficult negative samples: From the large-scale candidate set (Top-k recall results), select those texts that have a high similarity to the query text but have negative labels as negative samples.

[0067] Training method: Based on stage one, use a lower learning rate (e.g., 1e). -6 ~1e -5 Incremental training is performed.

[0068] The preferred hyperparameter setting is: Learning Rate: 1e -6 ~1e -5 Batch Size: 16–64; Epochs: 1–5.

[0069] Through the second stage of training, the model is better able to capture high-frequency synonyms, aliases, and near-synonyms in engineering documents, greatly improving the accuracy and recall of retrieval candidates.

[0070] After two phases of fine-tuning, the embedded model will undergo offline evaluation, primarily using the following metrics: Recall@k: Used to evaluate how many of the candidate fragments recalled by the model are relevant. Typically, k is set to 10 or 30 to evaluate the completeness of the candidate set.

[0071] MRR (Mean Reciprocal Rank): Used to evaluate the ranking quality of candidate segments. The higher the MRR, the more accurate the model's ranking.

[0072] NDCG (Normalized Discounted Cumulative Gain): Used to evaluate the order of related documents in a ranking process.

[0073] When the embedding model meets the preset standards on these metrics (e.g., Recall@10 ≥ 0.85, NDCG@10 ≥ 0.8), the model will be officially launched and begin supporting subsequent candidate fragment retrieval. If the evaluation does not meet the standards, the model hyperparameters will be readjusted or new training data will be added for retraining.

[0074] After embedding and vectorizing using the deployed embedding model that has undergone the two-stage fine-tuning described above, the generated text vectors will be stored in a vector database (such as FAISS). During each retrieval, the system performs Top-k recall through the vector database and further reorders and filters the recalled candidate segments. Based on the similarity between the vector representation of each segment and the query vector, the system selects the top k candidate segments according to their similarity.

[0075] Recall process: Based on similarity calculation in vector space, the top-k most relevant segments to the query are retrieved. Typically, the value of top-k is between 30 and 100. The similarity threshold is set to 0.6–0.8 by default, meaning that segments with a similarity lower than this value will be filtered out.

[0076] Through vector indexing and retrieval, the system can quickly retrieve the most relevant segments from the document and input them as a candidate set into the subsequent re-sorting module for fine-grained sorting.

[0077] In practical applications, the effectiveness of vectorization and recall can be affected by the type of data, model quality, and training data. Therefore, in specific implementations, the following strategies need to be adjusted according to different document types (such as engineering specifications, quality reports, and technical solutions): Model fine-tuning strategy: Based on the characteristics of the data (such as the diversity of engineering terminology and the richness of synonyms), the frequency of difficult negative sample mining and the sample selection method can be flexibly adjusted.

[0078] Recall Quantity (Top-k): Adjust the recall quantity according to actual needs. It can usually be set to 30-100 and then reordered after the initial recall.

[0079] Similarity threshold adjustment: The similarity threshold for different domains or tasks can be optimized based on actual data to ensure that high-quality candidate segments are recalled.

[0080] S4. Candidate Reordering: The candidate re-ranking module is responsible for refining the ranking of the Top-k candidate fragments obtained from the vectorization and recall modules to improve the relevance and accuracy of the final retrieval results. To optimize the performance of re-ranking, the system employs a cross-encoder with LoRA (Low-Rank Adaptation) parameter-efficient fine-tuning. LoRA is a parameter-efficient fine-tuning method that significantly reduces the number of new parameters added during training by inserting an adapter into the attention layer of the deep learning model, while improving the model's performance on specific tasks.

[0081] The key points for LoRA fine-tuning are as follows: Insertion location: The LoRA adapter is inserted into the attention layer of the cross encoder to fine-tune the relationships between the input text pairs.

[0082] Low-Rank Adapters: These are used to fine-tune the cross-encoder by inserting adapters, retaining the pre-trained weights of the original model, and optimizing only the newly added low-rank adapter part.

[0083] Hyperparameter tuning: Rank: The rank (r) of the adapter ranges from 32 to 256, preferably 128; Scaling factor (α): Adjusts the influence of the adapter, ranging from 64 to 512, preferably 256; Dropout: To prevent overfitting, the dropout rate is set to 0–0.1.

[0084] During LoRA fine-tuning, the model first loads pre-trained weights from a two-stage fine-tuned embedding model, then optimizes the low-rank adapter part through incremental training. This process uses a training dataset for engineering documents, including query-snippet pairs with standardized labels. The goal of fine-tuning is to minimize the scores of irrelevant query-candidate snippet pairs by maximizing the relevance scores between relevant queries and candidate snippets.

[0085] Training hyperparameter settings: Learning rate: The optimal learning rate is 1e. -5 ~1e -4 To avoid overfitting or gradient explosion during model fine-tuning; Batch Size: 16–64, used to balance training speed and model performance; Epochs: 2–5 epochs, with termination conditions determined based on model performance on the validation set.

[0086] After the model is fine-tuned, it will undergo offline evaluation. The specific process is as follows: The model is first evaluated offline on a pre-prepared test set, using metrics such as NDCG, MRR, and Precision@k to verify its performance on the re-ranking task. Once the model reaches the set evaluation thresholds in offline evaluation (e.g., NDCG@10 ≥ 0.8, MRR ≥ 0.85), it can be deployed online for actual retrieval and ranking tasks.

[0087] After the model is deployed, the system will continuously monitor its performance. If performance degradation is detected, optimization can be achieved through incremental training or switching to a newer model version. In practical applications, the performance evaluation of the re-ranking module mainly relies on the following metrics: Recall (Recall@k): measures whether the system can include documents relevant to the query in the recalled Top-k fragments; Ranking accuracy: further verifies the model's re-ranking ability by evaluating the consistency between the relevance score of the cross-encoder and the actual ranking; Response latency: the system's response latency to queries will be monitored during the deployment phase to ensure that, while maintaining accuracy, the response time does not affect the user experience.

[0088] The LoRA-tuned cross-encoder is used to reorder the recalled candidate segments. In one implementation, the reordering process is described below. Figure 5 For each query, the cross-encoder takes the query and each candidate fragment as a pair of inputs and outputs their relevance scores. Based on the relevance scores, the candidate fragments are sorted, and the top N most relevant fragments (typically N is 5–20) are retained. These highly relevant fragments are then passed to the downstream data extraction and standardization module for further processing.

[0089] S5. Extraction and Standardization: In this embodiment, the extraction and standardization module is responsible for extracting the required technical data items from the candidate fragments and standardizing the extraction results. The main tasks of this module are: data item extraction: extracting numerical and non-numerical fields (such as engineering parameters, models, material grades, etc.) from the candidate fragments; data item standardization: performing unit conversion and precision standardization for numerical fields; performing aliasing and template parsing for non-numerical fields; and field structuring: forming structured records based on field names, values, units, precision, and other elements for subsequent storage, export, and auditing. Specific details are as follows: 1. Numerical data item extraction and standardization: Numerical data items typically involve engineering and technical parameters (such as strength, weight, temperature, and dimensions). This module extracts numbers and their units from text using a combination of regular expressions, a rule engine, and model inference. For each extracted numerical data item, the system performs the following standardization processing: Unit Conversion: If the units given in the document are inconsistent (e.g., meters and feet, kilograms and pounds), the system will automatically convert them to the target unit (e.g., uniformly convert to "meters" and "kilograms") according to preset conversion rules. The unit conversion rules will be based on commonly used standards in the engineering field (such as ISO standards) or rules defined by domain experts.

[0090] Precision standardization: For numerical data, the system adjusts the precision according to specified precision rules (e.g., retaining two decimal places, rounding, etc.). This precision standardization is a key part of ensuring data consistency.

[0091] Range validation: For extracted numerical data, it is also necessary to check whether it is within a reasonable range. For example, intensity values ​​cannot be negative, and temperature ranges should conform to standard regulations. If the data exceeds the expected range, the system will mark it as an "outlier" for manual review.

[0092] The extracted numeric fields typically include: Field name (e.g., "compressive strength"), value (e.g., "42.5"), unit (e.g., "MPa"), precision (e.g., "two decimal places"), source fragment (indicating the original text location of the data, used for subsequent source tracing and backtracking).

[0093] 2. Extraction and standardization of non-numerical data items: Non-numerical data items typically include various material types, grades, specifications, etc. Unlike numerical data items, the standardization of non-numerical data mainly includes alias normalization and template resolution.

[0094] Alias ​​unification: Many non-numerical fields may use different naming rules or have multiple synonyms. For example, "high-strength steel" can be written as "high-strength steel material" or "super-strong steel". The system automatically unifies these aliases into standard names (e.g., "high-strength steel") by building an "alias table" or using a pre-trained named entity recognition model.

[0095] Template parsing: For some structured non-numerical fields, such as equipment model, specifications, standard number, etc., the system will use template parsing technology to extract these data from candidate fragments and convert them into standard format (e.g., "Model: XY100", normalized to "XY100").

[0096] Regular expressions combined with machine learning: In addition to template parsing, the system can also combine regular expressions with machine learning models (such as NER) to parse and recognize complex text. By training the model, the system can adapt to naming conventions and expressions in different documents, improving extraction accuracy.

[0097] The extracted non-numerical data items typically include: field name (e.g., "material type"), value (e.g., "XY100"), remarks (e.g., "steel material"), and source fragment (original text location).

[0098] 3. Field structuring and records: After data items are standardized, the system stores them as structured records according to a defined structure. Each structured record consists of the following fields: Field name: The name of the data item (such as "compressive strength" or "model").

[0099] Value: The specific value of the data item (such as "42.5" or "XY100").

[0100] Units / Precision: The units for numerical data items (e.g., "MPa"). Non-numerical data items may not have units, but may include notes.

[0101] Source fragment: The original fragment of this data item in the document, for subsequent backtracking verification.

[0102] Label status: Indicates whether the data item has been marked as an outlier, a missing value, or requires manual review.

[0103] These structured records will be exported in a standardized format, such as four lists (index, keywords, units, quantities), and can be optionally stored in CSV / Excel / JSON format for subsequent auditing and archiving.

[0104] 4. Optimization and adjustment of data item standardization: In practical applications, the structure and data items of different documents may vary. To ensure the accuracy of data item standardization, the system supports the following optimizations and adjustments: Customized standardization rules: For specific fields (such as construction engineering, chemical engineering, etc.), the system can customize specific unit conversion, precision rules and alias normalization strategies based on expert feedback.

[0105] Incremental training and optimization: When the system encounters new data items or new naming methods, the model will optimize itself through incremental learning, gradually improving its ability to identify and standardize different data items.

[0106] S6. Consistency Check: The consistency verification module is responsible for checking whether the values ​​of the same variable are consistent across different documents, versions, or sources, and for determining conflicts according to preset rules. Since engineering documents often record the same parameters or fields in multiple versions, different sources, or different documents, consistency verification is a crucial step in ensuring data accuracy, reliability, and consistency. This module can effectively solve problems such as data redundancy, version control issues, and cross-document conflicts in engineering documents.

[0107] During the consistency verification process, the system employs the following strategies: Source Priority: For the same variable across multiple documents, the system will determine the final accepted value based on the source priority. For example, "standard documents" have the highest priority, followed by "third-party testing reports," and finally "internal records."

[0108] Tolerance Setting: Differences in numerical data are judged using a tolerance range. The tolerance can be an absolute value tolerance δ or a relative value tolerance. For example, for the numerical data "compressive strength," the absolute value tolerance δ is set to ±5 MPa, meaning that two candidate values ​​are considered identical if the difference does not exceed 5 MPa. Alternatively, the relative value tolerance ε is set to ±5%, meaning that two candidate values ​​are considered identical if the difference is within 5%. For non-numerical data (such as model number, material, etc.), edit distance or Jaccard similarity is used to calculate the similarity between strings. For example, the values ​​"steel" and "steel material" are considered identical based on Jaccard similarity.

[0109] Conflict detection: When the values ​​of the same field in multiple documents exceed the tolerance range, the system will mark them as "conflict" and output a description of the difference to support manual review.

[0110] It should be noted that the tolerance value and similarity threshold are adjustable parameters, which can be adjusted according to the needs of different fields or tasks in practical applications. Users can customize these parameters to suit different engineering documents and data characteristics.

[0111] Based on the above strategy, the specific process for cross-document consistency verification is as follows: Data aggregation: Extracting all values ​​of the same variable from multiple documents. Based on information such as document ID, version number, and source of each variable, aggregate them into a set of candidate values.

[0112] Tolerance assessment: For numerical data, calculate the differences between values ​​and determine if they are within the preset tolerance range. For non-numerical data, calculate the similarity of strings and determine if there are spelling errors or different representations.

[0113] Priority sorting: Candidate values ​​are sorted according to source priority, with values ​​from higher source priorities being given priority. For example, if the "compressive strength" value recorded in the standard document differs from that in the internal document, the system will prioritize the value from the standard document.

[0114] Conflict Output: When values ​​in multiple documents exceed the set tolerance range, the system will output "consistent" or "inconsistent" results, along with a description of the differences. In the case of inconsistency, the system will list all candidate values ​​and provide the final accepted value as well as a list of possible alternative values.

[0115] In one exemplary implementation, the output consistency verification result mainly includes the following parts: Consistency status: Whether each variable is consistent across multiple documents (consistent / inconsistent).

[0116] Difference Explanation: If the values ​​in multiple documents are inconsistent, the system will output a detailed difference explanation, including a comparison of each candidate value.

[0117] Final accepted value: The final accepted value is output based on the source priority and tolerance settings.

[0118] Alternative value list: In case of inconsistency, list alternative values ​​for manual review.

[0119] In addition, the system also supports the generation of audit logs, which record the specific operations and results of each consistency check, ensuring that subsequent operations are traceable.

[0120] To improve the efficiency and accuracy of consistency verification, the system adopted the following optimization strategies: Parallel computing: During the data aggregation and tolerance judgment stages, the system adopts a parallel computing strategy to accelerate the verification process of large amounts of data through multi-threading / multi-processing.

[0121] Incremental learning: As the amount of data increases during use, the system will optimize the consistency verification model through an incremental learning mechanism, enabling it to gradually improve its adaptability to different document styles and domains.

[0122] Caching mechanism: For repetitive verification tasks, the system will use a caching mechanism to avoid repeated calculations and improve processing efficiency.

[0123] S7. Evidence Tracing and Rebound: The source tracing and backtracking module generates a minimum evidence fragment for each automatically extracted data item and binds it to the original document location (e.g., document ID, page number, paragraph number, table cell, offset, etc.). This feature ensures the traceability of the results, allowing users to directly return to the specific location in the original document for manual verification or review. Furthermore, the backtracking function enables the system to support rapid location, facilitating accurate verification of the extracted content, especially in complex engineering documents, ensuring data reliability and transparency.

[0124] The "back jump" function allows the system to provide a one-click jump to the original text containing the evidence fragment, enabling users to verify the accuracy of the extracted data. Specifically, each data item displays a "back jump" button on the front-end interface. Clicking this button automatically locates the original text containing the smallest piece of evidence for that data item. For example, if a user is viewing the field "compressive strength," clicking the "back jump" button will redirect the user interface to the document page containing that data item, highlighting relevant paragraphs, tables, or cells to ensure the user can quickly find the source.

[0125] The core of the jump-back operation is original text positioning, which is achieved by binding original text coordinate information (such as document ID, page number, paragraph number, table cell coordinates, start and end offsets, etc.) to each piece of evidence. Internally, the system associates this coordinate information with the document content and positions the data according to the bound coordinates when the user clicks the jump-back button. Specifically, the system searches for the corresponding document based on the document ID and page number; locates the specified page number, highlights the paragraph, sentence, or table cell containing the data item; and maps the original text coordinates (such as start and end offsets) to the page and displays them, ensuring the user can accurately see the location of the data item.

[0126] The evidence tracing function not only provides support for data item rollback but also ensures the traceability of the resulting data. In practical applications, evidence tracing can serve as an auditing tool, helping system administrators or users track and verify extracted fields. When the system detects inconsistencies in field values ​​(such as when the cross-document consistency check module detects variable value conflicts), the evidence tracing function automatically generates a difference description and provides a rollback function to help manual review and confirm correct data. Each rollback operation is recorded in the audit log, including the rollback request time, user ID, the field information to be rolled back, and the specific location of the original document (document ID, page number, offset, etc.).

[0127] In practical applications, the performance of the evidence tracing and backtracking module may be affected by the size and complexity of the documents. To improve the efficiency of this function, the system supports the following optimization measures: Document preloading and indexing: The system preloads document content and generates a full-text index to reduce the waiting time during jumpbacks. By preprocessing the document content and coordinates, the response speed of jumpbacks can be significantly improved.

[0128] Caching mechanism: For repeated bounce requests, the system will use a caching mechanism to avoid reloading and locating the document every time, further improving the user experience.

[0129] Incremental learning and adaptability: As more documents are added, the system will optimize the localization and rebound accuracy of evidence fragments through incremental learning and adaptive algorithms, ensuring that the system can better adapt to engineering documents of different formats.

[0130] S8. Structured Export: The structured export module is responsible for exporting the extracted and consistency-verified data in a unified format and supports data audit logging. Its purpose is to transform data into a standardized, shareable format (such as a four-list structure) to facilitate further processing, storage, or use by users. The structured export and auditing functions not only improve data usability but also enhance data auditability, providing support for subsequent quality control and legal compliance.

[0131] The common export format is a four-list structure, including the following four columns: Index: A unique index number used to identify each data item.

[0132] Keyword: The keyword or field name of the data item (e.g., "compressive strength" or "model").

[0133] Unit: If the data item is numeric, record its unit (e.g., "MPa"); if it is non-numeric, this column is empty or filled with relevant information (e.g., "None").

[0134] Value: The specific numerical value or range of the data item (e.g., "42.5" or "XY100"). For non-numerical data items, record their standardized value.

[0135] For example, the system will export the "compressive strength" extracted from engineering data in the following format: Index Key words Unit Quantity 1 Compressive strength MPa 42.5 2 Specimen age Days 28 This four-list structure makes the data more standardized and easier to process, allowing users to easily import it into databases, Excel, or CSV files for subsequent analysis or export.

[0136] During the structured export process, the system follows the rule of "only filling in the lowest-level variables." For data items with hierarchical relationships (e.g., multi-level parameters or subordinate fields in a document), the system only exports the lowest-level variables. That is, only the final specific numerical values, indicators, or descriptive information will appear in the exported file, while intermediate-level parameters (such as categories, ranges, etc.) will not be listed separately. This approach simplifies the exported data structure, avoids irrelevant intermediate-level information interfering with the final data application, and ensures that the data format is concise, clear, and easy to use.

[0137] For non-numerical data items (such as "Model", "Material Grade", "Equipment Type", etc.), the system will still export according to the four-list structure, but the unit column will merge the unit and quantity fields, and record the relevant normalization information in the remarks. For example, for the model field, the system will uniformly record "Model: XY100" as "XY100", and retain the relevant remarks (such as "steel material") in the remarks field, as shown in the following export format: Index Key words Unit Quantity 1 Model XY100 2 Material grade Steel material In addition, the system will ensure that aliases or various representations in different documents (such as the model "XY100" may appear as "XY-100", "model XY100", etc.) are standardized into a unified format to facilitate subsequent processing and analysis.

[0138] To ensure the legality and compliance of the data, the system generates a corresponding audit log for each batch of data exported. This log records detailed information for each export, including: Export operation timestamp: Indicates the time of the export operation.

[0139] User information: The user ID or username who performed the export operation.

[0140] The exported data includes keywords, units, quantities, and indexes.

[0141] Description of the data source: Indicates the source of the data (such as document ID, page number, paragraph number, etc.).

[0142] Audit logs provide a basis for subsequent audits and compliance checks, ensuring the legality and traceability of each data export.

[0143] In practical use, the structured export and audit log generation can be affected by document size, data volume, and system load. To improve export efficiency, the system adopts the following optimization strategies: Data batch processing: Processing large amounts of data in batches to avoid system performance bottlenecks caused by processing a large amount of data at once.

[0144] Caching mechanism: For repeated export operations, the system uses a caching mechanism to store intermediate results, reducing unnecessary duplicate calculations and improving response speed.

[0145] Parallel computing: Enhance the parallel processing capabilities of the export process through multi-threaded or distributed computing, accelerating the export of large-scale documents.

[0146] Although embodiments of the present invention have been described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the present invention, and all such changes and alterations shall not depart from the protection scope of the present invention.

Claims

1. A method for extracting and verifying the consistency of RAG-type data items in engineering technical documents, characterized in that, Includes the following steps: S1. Receive engineering documents, perform layout parsing and necessary optical character recognition processing on the documents, extract positioning metadata, and simultaneously perform encoding unification, noise removal and format regularization on the documents; S2. Based on the document's heading level and semantics, divide the document into multi-level text blocks; S3. An embedding model with two-stage fine-tuning is used to vectorize the multi-level text blocks and establish a vector index; the two-stage fine-tuning includes: the first stage of model training based on the ranking loss function and the second stage of mining difficult negative samples based on the model weights after the first stage training and continuing training. Candidate segments are recalled from the vector index based on preset recall conditions to form a candidate segment set; S4. Employ a cross encoder with efficient parameter fine-tuning to calculate and score the relevance between the candidate fragment set and the target query, and select a preset number of highly relevant fragments based on the scoring results; S5. Extract the target variable from the highly correlated segment, and perform normalization processing on the target variable to form a structured record including field name, value, unit / precision, and source segment; S6. Obtain the values ​​of the same target variable in different documents, different versions or different sources and compare them. Output the consistency judgment result according to the preset verification rules. The consistency judgment result includes the conclusion of consistency or inconsistency and the explanation of the difference, and determine the final value to be accepted and the list of alternative values. S7. Bind the structured record and the consistency determination result to the corresponding minimum evidence fragment and the original text location information corresponding to the minimum evidence fragment, so as to support one-click jump back to the corresponding location in the original text based on the original text location information; S8. Export the consistency determination results as a list in a preset format, execute preset hierarchical constraint rules during the export process, and record the audit log of the export process.

2. The method for extracting and verifying the consistency of RAG-type data items in engineering technical documents as described in claim 1, characterized in that, In step S2, the document is divided into multi-level text blocks using a three-level recursive block division: the first-level block is based on chapters / sections, the second-level block is based on paragraphs, and the third-level block is based on sentences / table units. At the same time, the block length is controlled to be 512-1024 characters and the overlap ratio is 10%-20%. Original text location metadata is bound to each third-level block, including the document's page number, paragraph number, and table cell coordinates.

3. The method for extracting and verifying RAG-type data items for engineering technical documents as described in claim 1, characterized in that, In step S3, the ranking loss function adopts MNR loss or InfoNCE loss, and the first stage training adopts a non-repeating sampling method; the difficult negative sample mining is to select from the candidate segments generated by the model after the first stage training that have a similarity to the target query higher than a preset threshold but have negative labels as difficult negative samples.

4. The method for extracting and verifying the consistency of RAG-type data items in engineering technical documents as described in claim 1, characterized in that, In step S4, the cross-encoder with efficient parameter fine-tuning inserts a low-rank adapter into the attention layer of the cross-encoder. During training, only the parameters of the low-rank adapter are optimized, while the pre-trained weights of the cross-encoder are retained.

5. The method for extracting and verifying the consistency of RAG-type data items in engineering technical documents as described in claim 1, characterized in that, In step S5, the normalization process includes: performing unit conversion, precision adaptation, and value range verification on numerical target variables, wherein the precision adaptation includes setting the number of decimal places to retain and determining the numerical rounding method; and performing aliasing normalization and parsing based on regular expressions or prompt word templates on non-numerical target variables.

6. The method for extracting and verifying the consistency of RAG-type data items in engineering technical documents as described in claim 1, characterized in that, In step S6, the preset verification rules include: source priority rules, tolerance rules, and conflict determination rules; the source priority rules include: standard documents have higher priority than third-party testing reports, and third-party testing reports have higher priority than internal records; the tolerance rules include: using absolute tolerance or relative tolerance to determine consistency for numerical target variables, and calculating string similarity using edit distance algorithm or Jaccard similarity algorithm to determine consistency for non-numerical target variables; the conflict determination rules include: when the values ​​of the same field in multiple documents exceed the tolerance range, the system will mark them as "conflicting" and output a difference description.

7. The method for extracting and verifying RAG-type data items for engineering technical documents as described in any one of claims 1-6, characterized in that, In step S8, the list in the preset format includes index, keyword, unit, and quantity fields. The unit and quantity fields are merged in the list corresponding to the non-numerical target variable, and normalization information is retained in the remarks column. The hierarchical constraint rule is to fill in only the lowest-level variables in the target variables; The preset formats include Excel, CSV, or JSON formats.

8. A system for extracting and verifying the consistency of RAG-type data items in engineering technical documents, characterized in that the system includes: The document preprocessing module is used to receive engineering documents, perform layout parsing and necessary optical character recognition processing on the documents, extract the location metadata of the documents, and perform encoding unification, noise removal and format regularization on the documents. The recursive block division module is used to divide the document processed by the document preprocessing module into multi-level text blocks according to the title level and semantics of the document. The vectorization and indexing module is used to vectorize the multi-level text blocks and establish vector indexes using a two-stage fine-tuned embedding model. The retrieval module is used to retrieve candidate segments from the vector index based on preset recall conditions to form a candidate segment set; The reordering module is used to employ a cross encoder with efficient parameter fine-tuning to calculate and score the relevance between the candidate fragment set and the target query, and to filter out a preset number of highly relevant fragments based on the scoring results. The extraction and standardization module is used to extract target variables from the highly correlated segments, and to standardize the target variables to form a structured record including field name, value, unit / precision, and source segment. The consistency verification module is used to obtain and compare the values ​​of the same target variable in different documents, versions or sources, output the consistency judgment result according to the preset verification rules, and determine the final value to be accepted and the list of alternative values. The tracing and export module is used to bind the corresponding minimum evidence fragment and the original text location information of the minimum evidence fragment to the structured record and the consistency judgment result respectively, so as to support one-click jump back to the corresponding location in the original text based on the original text location information; export the consistency judgment result as a list in a preset format and execute hierarchical constraint rules, while recording audit logs.

9. The system for RAG-type data item extraction and consistency verification for engineering technical documents as described in claim 8, characterized in that, The system also includes infrastructure components, which include: a vector database, a model inference service, an OCR / layout parsing service, and an audit log service; The vector database is used to store vector data generated by the vectorization module; the model inference service is used to provide local inference and cloud-based model inference support; the OCR / layout parsing service is used to perform optical character recognition processing and layout parsing on scanned documents; and the audit log service is used to store audit logs generated by the data export module.

10. The system for RAG-type data item extraction and consistency verification for engineering technical documents as described in claim 8 or 9, characterized in that, The source tracing and export module provides the original text location information of the smallest evidence fragment bound to the structured record and consistency judgment result, including: document identifier, page number, paragraph number, table cell coordinates, text start offset, and text end offset.

Images