Cloud intelligent analysis method and corresponding product for power generation enterprise maintenance documents

Abstract

The application relates to the field of industrial Internet of Things, and provides a cloud intelligent analysis method for maintenance documents of a power generation enterprise and a corresponding product. The method comprises the following steps: a cloud analysis service divides document content into a plurality of logically independent content areas by analyzing the underlying file structure of the maintenance documents of the power generation enterprise; fine-grained business semantic classification is performed on each content area; structured JSON data with semantic labels and retaining the original document topology is generated for the classified content; the structured JSON data is rendered into an interactive visual document editor through a front-end Web application; the underlying JSON data is synchronously updated in response to the verification and correction completed by a user on the visual document editor, and the final standard JSON data and the associated semantic labels are published to a data storage service after being confirmed by the user, so that downstream business systems or search engines can be integrated and searched.

Description

Technical Field

[0001] This application relates to the field of industrial Internet of Things, and in particular to a cloud-based intelligent parsing method and corresponding products for maintenance documents of power generation enterprises. Background Technology

[0002] With the deepening of Industry 4.0 and the construction of smart power plants, power generation companies are accelerating their transformation towards digitalization and intelligence in their production and operation. Equipment maintenance, as a core link in ensuring the safe and stable operation of power plants, generates maintenance document packages (including work instructions, process cards, test reports, etc.) that contain crucial process knowledge, quality inspection standards, and historical data. These documents typically exist in unstructured electronic document form. How to efficiently and accurately convert them into machine-readable and understandable structured data is a crucial data foundation for realizing the digital inheritance of maintenance experience, intelligent process optimization, and predictive maintenance of equipment condition.

[0003] Currently, there are two main technical approaches for the structured processing of documents similar to those used in power plant maintenance. One approach is based on fixed rule matching, such as extracting key fields like titles and numbers from documents using predefined regular expressions. While simple to implement, this method is poorly suited for complex industrial documents with nested tables and numerous merged cells. It cannot accurately reconstruct the document's physical topology and struggles to understand specific business semantics such as "quality inspection points (W / H points)" and "tools." The other approach directly uses general document parsing libraries to read the document's text and table content. While this method can obtain the original text information, it loses crucial layout information such as rich styles and merged cell attributes found in Word documents. This results in flattened output data that fails to retain the original document's hierarchical structure and relationships, making it difficult to directly import into subsequent maintenance management systems or knowledge bases.

[0004] Therefore, existing technologies generally suffer from the following shortcomings: 1) Low parsing fidelity, especially insufficient ability to restore the topological structure of complex tables, leading to data structure distortion; 2) Lack of semantic understanding capability, failing to identify the deep business meaning contained in the document content, making the output structured data meaningful but lacking "soul"; 3) Process breakpoints, the parsed data often requires a lot of manual secondary processing before it can be used by downstream business systems or data analysis platforms, failing to form an automated closed loop from unstructured documents to data assets that can drive business. This has become a key technical bottleneck restricting the data value mining and intelligent application in the power industry. Summary of the Invention

[0005] This application provides a cloud-based intelligent parsing method and corresponding product for power generation enterprise maintenance documents. Through an automated intelligent parsing and visual verification closed loop, it achieves highly reliable conversion of power generation enterprise maintenance documents into high-fidelity, semantic business data.

[0006] On the one hand, this application provides a cloud-based intelligent parsing method for maintenance documents of power generation enterprises, the method comprising: Step S1: The cloud-based parsing service parses the underlying file structure of the power generation company's maintenance document, extracts the document metadata, and identifies the chapter structure based on style and numbering features, dividing the document content into multiple logically independent content areas; Step S2: For each content area, traverse the paragraph text and table cell text within it, apply a set of composite regular rules and context features for joint judgment, and perform fine-grained business semantic classification on the traversed text. The business semantic classification includes quality inspection points, multiple options, equipment codes, and tools. Step S3: For the categorized content, perform data structuring assembly based on a predefined JSON Schema template corresponding to the document type. Specifically, for the tables in the power generation enterprise maintenance documents, execute a table topology reconstruction algorithm based on grid coordinates and recursive merging detection to restore the original topology of irregularly merged cells and generate structured JSON data with semantic tags that retain the original document topology. The semantic tags are associated with the business semantic classification. Step S4: Render the structured JSON data into an interactive visual document editor through a front-end web application. The visual document editor allows users to verify and correct the table topology. Step S5: In response to the user's verification and correction completed on the visual document editor, the underlying JSON data is updated synchronously, and after the user confirms, the final standard JSON data and its associated semantic tags are published to the data storage service for integration and retrieval by downstream business systems or search engines.

[0007] On the other hand, this application provides a cloud-based intelligent parsing device for power generation enterprise maintenance documents, the device comprising: The parsing module is used to parse the underlying file structure of the power generation company's maintenance documents input by the cloud parsing service, extract the document metadata, and identify the chapter structure based on style and numbering features, dividing the document content into multiple logically independent content areas; The semantic recognition module is used to traverse the paragraph text and table cell text in each content area, apply a set of composite regular rules and context features to make joint judgments, and perform fine-grained business semantic classification on the traversed text. The business semantic classification includes quality inspection points, multiple options, equipment codes, and tools. The reorganization module is used to perform data structure assembly on the classified content according to the predefined JSON Schema template corresponding to the document type. Specifically, for the tables in the power generation enterprise maintenance documents, a table topology reconstruction algorithm based on grid coordinates and recursive merging detection is executed to restore the original topology of irregular merged cells and generate structured JSON data with semantic tags that retain the original document topology. The semantic tags are associated with the business semantic classification. The rendering module is used to render the structured JSON data into an interactive visual document editor through a front-end web application. The visual document editor allows users to verify and correct the table topology. The update module is used to respond to the verification and correction completed by the user on the visual document editor, synchronously update the underlying JSON data, and publish the final standard JSON data and its associated semantic tags to the data storage service after user confirmation, so that downstream business systems or search engines can integrate and retrieve it.

[0008] Thirdly, this application provides an apparatus comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the cloud-based intelligent parsing method for power generation enterprise maintenance documents described above.

[0009] Fourthly, this application provides a storage medium storing a computer program, which, when executed by a processor, implements the steps of the cloud-based intelligent parsing method for power generation enterprise maintenance documents described above.

[0010] As can be seen from the technical solution provided in this application, on the one hand, by deeply analyzing the underlying file structure of the document and dividing the content area, it ensures that no physical information such as the style and chapters of the original document is omitted. In particular, by using a table topology reconstruction algorithm based on grid coordinates and recursive merging detection, the original layout of irregularly merged cells can be accurately restored, solving the core problem of structural distortion when processing complex industrial tables in existing technologies, and providing a high-fidelity data foundation for subsequent processing. On the other hand, by using semantic layer recognition, that is, using a composite regular rule set and contextual features to jointly judge the text, fine-grained classification of business concepts such as quality inspection points and equipment codes is achieved. This makes the final generated JSON data not only contain text content, but also carry semantic tags associated with business semantic classification. When this structured data with rich semantic tags is published to the data storage service, downstream search engines or business systems can directly perform efficient and accurate retrieval and integration based on the semantic dimension, improving the efficiency of data processing. The application demonstrates several key aspects: First, the cloud-based parsing service completes the arduous initial screening and structuring work, while users can perform final verification and fine-tuning of the results through an intuitive front-end web application. This closed-loop process, primarily machine-based with human-machine collaboration, ensures processing efficiency while guaranteeing the semantic consistency between the output data and the source documents through manual verification, meeting the reliability standards required by business needs. This truly achieves automated output from unstructured documents to high-quality, trustworthy data assets. Second, because the technical solution of this application is based on an architecture design that combines cloud-based parsing services with front-end web applications, the core parsing capabilities can be provided as a service. This not only facilitates the elastic expansion of computing resources to meet the demands of massive document processing but also, through API interface separation from the front-end, allows the intelligent parsing capability to be flexibly integrated into different smart power plant platforms or data middleware, demonstrating good scalability and the service-oriented characteristics of cloud computing software, laying the foundation for building larger-scale industrial data service platforms. In summary, the technical solution of this application, through automated intelligent parsing and visual verification closed-loop, achieves highly reliable conversion of power generation enterprise maintenance documents into high-fidelity, semantic business data. Attached Figure Description

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

[0012] Figure 1 This is a flowchart of the cloud-based intelligent parsing method for power generation enterprise maintenance documents provided in the embodiments of this application; Figure 2This is a schematic diagram of the table merging unit detection algorithm provided in the embodiments of this application; Figure 3 A schematic diagram of the topology operation interface of the visual table editor provided in the embodiments of this application; Figure 4 This is a schematic diagram of the content operation interface of the visual table editor provided in the embodiments of this application; Figure 5 This is a schematic diagram of the cloud-based intelligent parsing device for power generation enterprise maintenance documents provided in this application embodiment; Figure 6 This is a schematic diagram of the device provided in the embodiments of this application. Detailed Implementation

[0013] 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 embodiments of this application, and not all embodiments. 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.

[0014] In this specification, adjectives such as "first" and "second" are used only to distinguish one element or action from another, without necessarily requiring or implying any actual such relationship or order. Where circumstances permit, reference to an element or component or step (etc.) should not be construed as being limited to only one of the elements, components, or steps, but may be one or more of the elements, components, or steps, etc.

[0015] For ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn to actual scale.

[0016] Currently, there are two main technical approaches for the structured processing of documents similar to those used in power plant maintenance. One approach is based on fixed rule matching, such as extracting key fields like titles and numbers from documents using predefined regular expressions. While simple to implement, this method is poorly suited for complex industrial documents with nested tables and numerous merged cells. It cannot accurately reconstruct the document's physical topology and struggles to understand specific business semantics such as "quality inspection points (W / H points)" and "tools." The other approach directly uses general document parsing libraries to read the document's text and table content. While this method can obtain the original text information, it loses crucial layout information such as rich styles and merged cell attributes found in Word documents. This results in flattened output data that fails to retain the original document's hierarchical structure and relationships, making it difficult to directly import into subsequent maintenance management systems or knowledge bases. Therefore, existing technologies generally suffer from the following shortcomings: 1) Low parsing fidelity, especially insufficient ability to restore the topological structure of complex tables, leading to data structure distortion; 2) Lack of semantic understanding capability, failing to identify the deep business meaning contained in the document content, making the output structured data meaningful but lacking "soul"; 3) Process breakpoints, the parsed data often requires a lot of manual secondary processing before it can be used by downstream business systems or data analysis platforms, failing to form an automated closed loop from unstructured documents to data assets that can drive business. This has become a key technical bottleneck restricting the data value mining and intelligent application in the power industry.

[0017] To address the aforementioned problems in existing technologies, this application proposes a cloud-based intelligent parsing method for maintenance documents of power generation enterprises, the flowchart of which is attached. Figure 1 As shown, it mainly includes steps S1 to S5, which are detailed below: Step S1: The cloud-based parsing service parses the underlying file structure of the power generation company's maintenance documents, extracts the document metadata, and identifies the chapter structure based on style and numbering features, dividing the document content into multiple logically independent content areas.

[0018] The purpose of step S1 above is to perform a preliminary deconstruction of the original unstructured document, namely the power generation company's maintenance document, to understand its macro-level layout and define the boundaries for subsequent fine-grained analysis. It should be noted that the cloud-based parsing service is a backend processing module deployed on a cloud server, responsible for receiving user-uploaded documents and executing the core parsing logic. Before step S1, an initialization step can also be included: receiving the .docx format power generation company maintenance document uploaded via the API interface, decompressing it as a ZIP archive, and locating and reading the word / document.xml file containing the document's main content. The .docx format is essentially a ZIP archive, where the word / document.xml file defines all the document's content, style, and structure in XML format, forming the basis for deep parsing.

[0019] Step S1 is mainly achieved by extracting document metadata, identifying chapter structure based on style and numbering features, and dividing content areas, as detailed below: S101: Extract document metadata.

[0020] In this embodiment, document metadata includes, but is not limited to, document title, document number, project name, equipment code, compiler / reviewer, date, etc., which are typically located at the beginning of the document, such as the cover page. The cloud-based parsing service captures metadata by reading specific paragraphs at the beginning of the power generation company's maintenance document and matching them with predefined metadata extraction rules (e.g., identifying the text after "Document Number:").

[0021] S102: Identify chapter structure based on style and numbering characteristics.

[0022] Identifying chapter structure based on style and numbering characteristics is key to understanding the logical organization of a document. Power plant maintenance documents typically have a clear hierarchical structure, such as "1. Work Preparation," "1.1 Tools and Equipment," "2. Work Procedures," etc. This application achieves automated identification of the chapter structure of power plant maintenance documents by comprehensively analyzing multiple features, including paragraph style and numbering characteristics. This includes extracting the outline-level attribute of all paragraphs in the power plant maintenance document. <w:outlinelvl>) and font bold attribute ( <w:b>); identifying the numbering模式 of paragraph texts, for example, "1.", "1.1", "(1)"; combining these outline level attributes, font bold attributes and numbering modes, the chapter level of paragraphs is determined by heuristic rules, and the tree directory structure of the document is constructed. Specifically, the paragraph XML element of a Word document (i.e <w:p>The headings may contain outline-level attributes, directly indicating their hierarchy within the document outline. Additionally, chapter headings are typically bolded. Furthermore, text paragraphs conforming to Chinese or Arabic numeral numbering patterns are highly likely to be headings. The parsing service calculates a "heading confidence" score for each paragraph, a weighted combination of the aforementioned features. For example, a paragraph that simultaneously satisfies the features of "outline level 1," "bold font," and "text beginning with '1.'" has extremely high confidence and can be identified as a level 1 heading. By traversing all paragraphs and applying this rule, a directory tree reflecting the nested relationships of document chapters can be constructed.

[0023] S103: Divide the content area.

[0024] After identifying chapter titles, and combining these outline-level attributes, font bolding attributes, and numbering patterns, the chapter level of paragraphs is determined through heuristic rules, and a tree-like directory structure of the document is constructed. Figure 1 The example method could also include dividing the identified chapter headings and their subsequent content, up to the next same-level or higher heading, into a separate content region, and assigning a unique region identifier to each content region. For example, after identifying the heading "2.1 Disassembling the Bearing," all subsequent paragraphs, tables, and images, until encountering the heading "2.2 Cleaning and Inspection" or a higher-level heading "3. Reassembly," are classified as a separate content region belonging to the "Disassembling the Bearing" chapter. This region identifier (e.g., section_2_1) is used in subsequent processing to associate all parsing results within that region. This division allows subsequent semantic recognition and structural reorganization to be performed in parallel or independently on a region-by-region basis, improving processing efficiency.

[0025] Step S2: For each content area, traverse the paragraph text and table cell text within it, apply a set of composite regular rules and contextual features to make joint judgments, and perform fine-grained business semantic classification on the traversed text.

[0026] Existing document parsing technologies can only extract "what the text is," but fail to understand "what the text represents in the business context," which is the fundamental flaw of converting undifferentiated strings into machine-understandable semantic units with specific business meanings. For example, existing simple keyword-based matching schemes often perform string matching in text by predefining a list of keywords such as "inspection" and "acceptance." The shortcomings of this scheme include extremely low accuracy, inability to distinguish between "inspection tools" (non-quality control points) and "inspection of sealing" (quality control points), heavy reliance on fixed expressions, poor generalization ability to variations of business terms (e.g., "W point," "H point," "witness point"), and complete neglect of context. Another existing technical solution, namely the use of a general NLP entity recognition model, can employ a natural language processing model pre-trained on general corpora (e.g., news, encyclopedias) for entity recognition. However, general models lack expertise in the power maintenance field and cannot accurately identify that "KYN28A-12" is an equipment code rather than a regular string, nor can they understand that "□" represents "multiple options" in a process card. This necessitates retraining with a large amount of domain-labeled data, resulting in high costs, uncontrollable model decisions, and difficulty in integrating clear business rules. Therefore, the solution proposed in this application is as follows: For each content area, the paragraph text and table cell text are traversed, and a set of composite regular rules and contextual features are applied for joint judgment to perform fine-grained business semantic classification on the traversed text. This business semantic classification includes quality inspection points, multiple options, equipment codes, and tools, etc. By combining a set of compound regular rules with contextual features, the technical solution of this application creates an interpretable and configurable domain semantic understanding mechanism. It can not only identify patterns on the surface of text (through regular rules), but also combine its position in the document (e.g., chapter, table column header) and surrounding environment (e.g., semantics of adjacent cells) for comprehensive reasoning. This makes the data output by the system upgrade from a "set of characters" to a "set of business entities", giving the data a true business soul and providing a reliable data foundation for subsequent semantic-based retrieval, process triggering and knowledge graph construction.

[0027] For classification problems in specific business areas such as power maintenance, semantic recognition methods based solely on keywords or regular expressions have low accuracy and poor generalization ability, while general natural language processing models lack domain knowledge and their decision-making is uncontrollable. Therefore, as an embodiment of this application, the above-mentioned application of a set of composite regular rules and contextual features for joint judgment, and the fine-grained business semantic classification of the traversed text can be achieved through the following steps S201 to S203: Step S201: Configure the regular expression rule set R.

[0028] In this embodiment, the regular expression rule set R contains multiple regular expression patterns for identifying quality checkpoint markers, checkboxes, and specific encoding formats. This is a "pattern library" for semantic recognition. For example, the rule for identifying quality checkpoints (W points / H points) might be: r_W point = r'(W|H)[0-9]{1,3}' (matching text such as W1, H25); the rule for identifying multiple options (checkboxes) might be: r_option = r'□\s*[yes]' (matching patterns like "□ yes"); the rule for identifying device encoding might be: r_device encoding = r'[AZ]{2,4}-[0-9]{3}-[A-Z0-9]{2}' (matching encoding of a specific format), and so on.

[0029] Step S202: Capture the contextual features C of the current text.

[0030] Capturing the contextual features C of the current text is crucial for achieving joint judgment. Here, the text includes paragraph text and table cell text within the content area defined in step S1. Its contextual features C include at least the current chapter title determined in step S1, and the column header and semantic type of adjacent cells when the text is located within a table. Context provides essential scene information for rule matching. For example, in a table, a cell located under the "Tools" column, even if its content does not match any specific tool rule, can have its semantic type inferred as "Tools" based on the column header. Step S22, when capturing contextual features within the table, also includes the step of: determining the business attributes of the column by analyzing the text content of the header row cell of the column containing the current table cell, as a column-level contextual feature, thereby achieving "column-level understanding" of the table content.

[0031] Step S203: Apply compound regular rule set R to the text for rule matching, and perform context analysis based on the captured context features C. When the text matches a specific rule r_i in the regular rule set R, and its context features C meet the preset business scenario conditions, then classify it into the business semantic type corresponding to r_i and C.

[0032] In this embodiment, the system maintains a classification decision matrix, and step S203 is a comprehensive decision-making process. For example, for the text "□ Completed", if it matches the r_ option through rule matching, and then, through context analysis, it is located in a table in the "Pre-work Preparation" section, with the column title being "Check Items", then the joint judgment result is: because the option rule is matched, and the context (column title "Check Items") indicates that this is an item that needs to be confirmed, it can be classified as a "Multi-option" subclass under "Quality Inspection Points", rather than a regular tool option; conversely, if the same text "□ Completed" appears in the "Status" column of the "Safety Tools and Equipment List" table, it may be classified as "Tool Status". Through this composite mechanism, the system can accurately identify various business entities contained in the document, laying the foundation for the subsequent generation of structured data rich in semantic information.

[0033] The above embodiments create an interpretable and configurable domain-adaptive semantic recognition mechanism through the collaborative judgment logic of rule matching and context analysis. This enables the system to not only rely on text patterns, but also to combine its structural position in the document (e.g., the chapter it belongs to, the column it is in) for comprehensive reasoning, thereby greatly improving the accuracy and robustness of semantic classification. Furthermore, the recognition logic is transparent and adjustable to domain experts, ultimately producing data rich in accurate business semantic tags.

[0034] As another embodiment of this application, the above-mentioned application of a set of composite regular rules and context features for joint judgment, and the fine-grained business semantic classification of the traversed text can also be achieved through the following steps S'201 to S'204: Step S'201: Build and maintain an evolutionary dynamic rule knowledge base. The dynamic rule knowledge base initially contains multiple basic regular expression patterns for recognizing quality checkpoint markers, option boxes, and specific encoding formats, and associates a dynamic weight coefficient W_r and an effective context scenario description set Ctx_r with each rule. Step S'202: Extract a multi-dimensional contextual feature vector: For the current text to be classified, extract a multi-dimensional feature vector F, which includes at least: the semantic encoding of the chapter title determined by step S1, the embedded representation of the column title text in the table, the predicted semantic type distribution of adjacent cells (top, bottom, left, right), and the text style features of the current cell (e.g., font, bold, color). Step S'203: Perform attention-weighted rule matching and context compliance calculation, specifically including: matching the current text using all basic regular expression patterns in the dynamic rule knowledge base to obtain an initial matching result set M={m_1,m_2,...,m_k}, where each matching result m_i contains the matched rule r_i and the matched text fragment; for each matching result m_i, calculate its context compliance score Score_ctx_i: compare the similarity between the multidimensional feature vector F extracted in step S'202 and the effective context scene description set Ctx_r associated with rule r_i, and refer to the frequency of similar context features in historical successful matching cases to calculate a score between 0 and 1; Step S'204: Perform confidence-weighted fusion decision and rule base evolution, specifically including: for each matching result m_i, calculate its comprehensive confidence Conf_i=W_{r_i}*Score_ctx_i, where W_{r_i} is the current dynamic weight coefficient of rule r_i; select the matching result m_max with the highest comprehensive confidence as the primary candidate classification; if the highest confidence exceeds the preset threshold Th_high, then directly adopt this classification result; if the confidence of the primary candidate classification is between the preset thresholds Th_low and Th_high, then initiate a weighted fusion decision based on the rule base. The arbitration model of the large-scale neural network takes the multidimensional feature vector F and all matching results M as inputs and outputs the final semantic classification and confidence level. Regardless of the decision path adopted, the system feeds back the final classification result, the rule used, the multidimensional feature vector F, and the decision confidence level as a training sample to the dynamic rule knowledge base. If the classification is correct (which can be verified by subsequent manual verification or self-consistent judgment with high confidence), the weight W_r of the rule that was successfully applied is appropriately increased, and its Ctx_r may be expanded. If the classification is incorrect or the confidence level is low, a new rule mining process is triggered or the parameters of the existing rule are adjusted.

[0035] On the one hand, the above scheme upgrades the fixed set of regular rules into a knowledge base with learning capabilities and the ability to dynamically adjust weights and applicable scenarios. This means that the effectiveness of the rules is no longer preset, but is continuously strengthened or weakened through practical feedback, enabling the system to adapt to the subtle differences between different power plants and different document templates, thus solving the fundamental problem of insufficient generalization ability of static rules. On the other hand, due to the closed-loop learning feedback mechanism formed in step S'204, correct decisions will strengthen the relevant rules and expand their scope of application, while incorrect or uncertain decisions will trigger adjustments to the rule base or the mining of new rules. This transforms the entire semantic classification system from a pre-configured tool into an intelligent agent that can continuously self-optimize during use, with its classification accuracy and adaptability continuously increasing over time.

[0036] Furthermore, step S2 of the above embodiment may also include the following confidence assessment and conflict resolution mechanism for semantic classification results: assigning an initial confidence score to each semantic classification result, which is calculated based on the number, accuracy and context fit of the matching rules; when the same text unit is matched to different semantic types by different rules or context features, comparing the confidence scores of each matching result, and introducing a preset domain knowledge priority rule for adjudication to select the final semantic type.

[0037] Step S3: For the categorized content, perform data structuring assembly based on the predefined JSON Schema template corresponding to the document type. For the tables in the power generation company's maintenance documents, execute a table topology reconstruction algorithm based on grid coordinates and recursive merging detection to restore the original topology of irregularly merged cells and generate structured JSON data with semantic tags that retain the original document topology. The semantic tags are associated with business semantic classification.

[0038] Existing technologies often suffer from data structure collapse and logical relationship disorder due to the loss of merged cell information when processing complex tables commonly found in industrial documents. This is one of the biggest technical obstacles preventing the transformation of unstructured documents into usable structured data. For example, if a general document parsing library (e.g., the default table reader in python-docx) is used to directly obtain a two-dimensional array representation of the table, the w:gridSpan (spanning columns) and w:vMerge (spanning rows) attributes will be completely ignored or misinterpreted. This results in a "work content" cell spanning multiple rows being split and repeatedly distributed across multiple rows, leading to data redundancy and semantic fragmentation. The complex multi-layered merging relationships in the table header become flattened, completely destroying the inherent logical hierarchy and grouping relationships of the table, rendering the generated data completely unusable. Although computer vision / OCR-based table recognition solutions can convert document pages into images and use visual cues to identify table lines and cells, this approach is greatly affected by document format and print quality, and the processing is cumbersome (requiring rendering, image processing, and OCR), resulting in high computational costs. Most importantly, it cannot distinguish whether visually merged cells are "true merges" or "independent borderless cells," making it difficult to 100% reproduce the precise topological logic defined at the document's underlying level. Accuracy cannot be guaranteed, and it is disconnected from the document's original digital information processing flow.

[0039] To address the aforementioned problems of the prior art, the technical solution adopted in this application includes: assembling the categorized content into structured data based on a predefined JSON Schema template corresponding to the document type; wherein, for tables in the maintenance documents of power generation enterprises, a table topology reconstruction algorithm based on grid coordinates and recursive merging detection is executed to restore the original topology of irregularly merged cells, generating structured JSON data with semantic tags that retain the original document topology, wherein the semantic tags are associated with business semantic classification.

[0040] The implementation of step S3 mainly includes two core sub-processes: table topology reconstruction based on grid coordinates and recursive merging detection, and structured assembly based on JSON Schema templates. These are detailed below: S301: Table topology reconstruction based on grid coordinates and recursive merging detection.

[0041] One of the core processes, S301, involves performing a table topology reconstruction algorithm based on grid coordinates and recursive merging detection on tables in power generation company maintenance documents. This is a key technology for solving the table fidelity problem, aiming to accurately reconstruct the original layout of arbitrarily complex tables in Word documents. For example... Figure 2 As shown, it is a schematic diagram of the table merging cell detection algorithm of this application, which intuitively shows how the algorithm marks the range of horizontal and vertical merged cells in the logical grid.

[0042] As mentioned earlier, existing general document parsing technologies, when processing Word documents, neglect or fail to correctly parse the w:gridSpan (spanning columns) and w:vMerge (spanning rows) attributes, resulting in the loss of merged cell information in complex tables. This leads to fundamental defects such as collapsed output data structure, disordered logical hierarchy, and inability to reflect the original table layout. To address this long-standing technical bottleneck in industrial document digitization, the table topology reconstruction algorithm based on grid coordinates and recursive merge detection for tables in power generation enterprise maintenance documents, as described in the above embodiment, can be implemented through steps S3011 to S3014, as detailed below: Step S3011: Traverse the table rows in the XML structure of the power generation company's maintenance documents (Word document). <w:tr>) and column ( <w:tc>Construct a two-dimensional logical grid, with each grid point associated with a document object model pointer of the corresponding cell.

[0043] Specifically, the parsing service reads word / document.xml and locates the table element ( <w:tbl>The table consists of rows ( <w:tr>Composed of ) rows, containing cells ( <w:tc>The algorithm first ignores all merge attributes and then proceeds according to each... <w:tc>Assuming each grid cell occupies a position, an initial two-dimensional logical grid of M rows × N columns is constructed. Each grid point stores a pointer to its corresponding... <w:tc>A pointer to the Document Object Model (DOM) of an XML element, used for subsequent access and manipulation.

[0044] Step S3012: Parse the w:gridSpan and w:vMerge attributes of each cell and mark the horizontal and vertical range of merged cells in the two-dimensional logical grid.

[0045] Typically, Word documents define cell merging using the `w:gridSpan` attribute (whose value indicates the number of columns spanned horizontally) and the `w:vMerge` attribute (whose value is `restart` to indicate the start of the merge and `continue` to indicate the continuation of the merge). The table topology reconstruction algorithm based on grid coordinates and recursive merge detection traverses the two-dimensional logical grid as follows: if a cell's `w:gridSpan` value is n (n>1), then that cell is marked as a "horizontal merge source," and the n-1 consecutive grid points to its right are marked as "merged horizontally by this cell"; if a cell's `w:vMerge` value is `restart`, then it is marked as a "vertical merge source," and the search continues downwards until a cell with a `w:vMerge` value other than `continue` is encountered, marking all cells encountered along the way as "merged vertically by this cell." In this way, the algorithm accurately marks the "sphere of influence" of all merged cells in the logical grid.

[0046] Step S3013: Traverse all cells in the two-dimensional logical grid that are not marked as merge sources, call the semantic recognition method in step S2 on the text content of each valid cell, parse its content type, and generate a lightweight JSON object containing content, semantic type, and cell position information.

[0047] In this embodiment, a valid cell refers to a grid point that represents an independent content entity (i.e., a merged source cell or an unmerged independent cell) within the grid. The table topology reconstruction algorithm based on grid coordinates and recursive merge detection generates a structured data object for each valid cell, for example: { "content": "Torque wrench 100N.m" "semantic_type":"tools" "position":{"row":5,"col":2}, "rowspan": 1, "colspan":1 } The initial values ​​of rowspan and colspan are calculated based on the marking results in step S3012. When generating the cell JSON object in step S3013, the following steps are also performed: detecting whether there are multiple parallel entries connected by specific delimiters (e.g., " / ", ", etc.); when multiple parallel entries are detected, automatically splitting the string into an array structure based on the semantic type of the cell identified in step S2, while maintaining the original text order of each array element. For example, "torque wrench / hydraulic wrench" will be automatically converted to ["torque wrench", "hydraulic wrench"], further refining the data structure.

[0048] Step S3014: Based on the merging range marked in step S3012, reconstruct the merging relationship of cells in the output table data structure, filter out redundant marked cells used only for layout, and output lightweight table data that fully retains the original table topology.

[0049] Specifically, the table topology reconstruction algorithm based on grid coordinates and recursive merge detection updates the rowspan and colspan properties in the valid cell JSON object according to the marked merge range. For example, a cell that has merged 3 columns horizontally has its colspan value set to 3. At the same time, the corresponding XML pointers of those grid points marked as "merged" in step S3012 are redundant and do not generate independent JSON objects, thus being "filtered out" in the output, ultimately forming a lightweight data structure that accurately reflects the row and column merging relationship of the original table.

[0050] As can be seen from steps S3011 to S3014 of the above embodiment, by constructing a two-dimensional logical grid, parsing merged attributes, recursively detecting, and reconstructing merged relationships, any irregular merged cells (e.g., headers, descriptions, etc. spanning multiple rows and columns) are accurately mapped into structured data objects with parent-child or related relationships. This ensures 100% topological fidelity in the conversion from unstructured tables to structured data such as JSON, providing a geometrically correct input for subsequent data processing.

[0051] As another embodiment of this application, the table topology reconstruction algorithm based on grid coordinates and recursive merging detection can also be implemented for tables in the maintenance documents of power generation enterprises through the following steps S'3011 to S3'014: Step S'3011: Traverse the table rows in the XML structure of the power plant's maintenance documents (Word document). <w:tr>) and table column definition ( <w:gridcol>Construct an initial M-row × N-column base grid and assign an initial cell node to each base grid cell.

[0052] Step S'3012: Parse each physical cell ( <w:tc>The `w:gridSpan` and `w:vMerge` attributes of the grid and their actual extent in the base grid are defined, and cell nodes are created or updated accordingly. Specifically, a merge source node is created for each physical cell that spans multiple rows or columns, and a virtual subordinate node pointing to the merge source node is created for each base grid cell covered by the physical cell. This constructs a directed graph of cell merging relationships with the merge source node as the root and the virtual subordinate nodes as the leaves.

[0053] Step S'3013: Dynamic tagging and pruning: Traverse the directed graph of cell merging relationships, identify all pure virtual subordinate nodes that do not directly contain the original text content and are only part of the merged structure, remove these pure virtual subordinate nodes from the queue to be processed, but retain their connection relationship in the directed graph to record the topology history. Step S'3014: Topology Stitching and Lightweight Data Structure Generation: Based on the merging relation directed graph constructed in step S'3012 and the pruning results in step S'3013, perform the following steps S'3014a to S'3014c: Step S'3014a: Using each merged source node and its directly associated valid text content as the core, generate a logical cell object. This "logical cell" object records its original content, semantic type (obtained from step S2), and the corresponding row / column span range in the directed graph. Step S'3014b: Analyze the relationship between the merged source nodes. If the coverage areas of two merged source nodes are adjacent in the base grid and are separated only by the removed pure virtual subordinate nodes, then it is determined that the two belong to the same continuous area logically and they are associated with the same higher-level table area identifier. Step S'3014c: Output a lightweight, topologically traceable table data structure consisting of a list of logical cell objects and table range relationships.

[0054] Compared to steps S3011 to S3014 in the aforementioned embodiments, the scheme in steps S'3011 to S3'014 explicitly and structurally models the implicit parent-child or master-slave relationships by constructing a directed graph of cell merging relationships. This is not only a change in data storage format but also a deepening of the understanding of table topology, providing a theoretical basis for handling more complex and irregular nested merging. On the other hand, by creating virtual subordinate nodes and subsequently pruning them, this scheme can clearly distinguish between the physical layout and logical content entities of the table. This separation allows the algorithm to filter out redundant blank cells used only for layout alignment, thereby outputting a purer logical structure that is closer to the essence of business data. Thirdly, by analyzing the spatial relationships between merging source nodes, it can automatically infer and reconstruct continuous logical regions that are broken due to complex merging. For example, a title merged across the same column in multiple rows, even if separated by other rows, may be identified by this algorithm as a continuation of the same logical title, thereby outputting a more semantically coherent data structure.

[0055] S302: Structure assembly based on JSON Schema template.

[0056] To ensure that the output data has a unified format that can be understood by business systems, this application adopts a template-driven architecture. When faced with maintenance documents from different power plants, different equipment types, or updated versions, traditional methods require modification of the parsing code, making rapid adaptation difficult. Therefore, to solve the problem of hard-coded binding between the parsing system and specific document templates, resulting in poor scalability, the predefined JSON Schema templates corresponding to document types in this embodiment can be created and managed through the methods described in steps S3021 to S3023 as follows: Step S3021: Define the JSON Schema for different types of power generation maintenance documents. The JSON Schema specifies the root structure of the output JSON, required fields, data types of the fields, and the mapping relationship between the fields and business semantics.

[0057] For example, "Steam Turbine Body Overhaul Procedure Card" and "Transformer High Voltage Test Report" correspond to different JSON Schemas; JSON Schema is a blueprint for a data structure.

[0058] Step S3022: Store the JSON Schema in the form of a configuration file. At the start of the parsing process, dynamically load the matching JSON Schema template based on the metadata or filename characteristics of the input document.

[0059] Step S3023: In step S3, the semantic layer recognition results are assembled into a JSON instance that conforms to the loaded JSON Schema according to the specification of the JSON Schema.

[0060] In this embodiment, the parsing service is analogous to an assembly worker. It reads the JSON Schema template and, according to its specifications, fills the semantic classification results generated in step S2 and the table topology data generated in core process S301 into the positions specified in the template. The final generated structured JSON data has field names and nested structures defined by the Schema, while the field values ​​are filled with specific business content, and it includes semantic tags and retains the original document topology. For example, a list of "quality checkpoints" will appear under an array field named quality_check_points in the JSON. Each object in the array contains a step description extracted from the original document, W / H point numbers, and associated option states.

[0061] The above-described method of creating and managing JSON Schema templates decouples the core of the parsing system from the data definition, enabling the system to upgrade from processing a single fixed format to a configurable parsing framework. This means that when new document types need to be adapted, only the external JSON Schema configuration file needs to be added or modified, without changing the core parsing algorithm, thereby greatly improving the system's scalability, maintainability, and agile response to business changes.

[0062] As can be seen from step S3 and its specific implementation, the algorithm based on grid coordinates and recursive merging detection achieves lossless reverse engineering of the document's underlying logical structure. It operates directly at the XML source code level of the Word file, by tracing... <w:tbl> 、 <w:tr> 、 <w:tc>The original tags and attributes are precisely reconstructed to accurately determine the physical location and span of each cell. This allows the final generated structured data (JSON) to perfectly mirror the visual and logical structure of the original document's tables. As a result, complex process cards, bills of materials, and other data can be accurately converted into nested structures that can be directly received and understood by relational or NoSQL databases, ensuring that the integrity of the information is not compromised during the conversion process.

[0063] Step S4: Render the structured JSON data into an interactive visual document editor through the front-end web application. The visual document editor allows users to verify and correct the table topology.

[0064] Step S4 is a crucial link in the human-machine collaborative closed loop, aiming to provide an intuitive and reliable final verification and correction interface for the parsing results of the table topology reconstruction algorithm. In traditional methods, correcting the parsing results usually requires technical personnel to directly edit complex JSON or code, which is difficult and error-prone. This application uses a WYSIWYG web editor to restore the data structure to a visual form close to the original document, allowing users to make corrections in a natural way, similar to manipulating an original Word document, greatly reducing the barrier to entry and ensuring the accuracy of the corrections.

[0065] Specifically, rendering structured JSON data into an interactive visual document editor through a front-end web application can be achieved through the following steps S401 to S403: Step S401: Data binding and initial rendering.

[0066] The front-end web application (developed using frameworks such as Vue.js and React) retrieves the structured JSON data generated in step S3 from the back-end. The front-end framework dynamically generates the corresponding HTML based on the number of rows and columns in the table within the JSON data, as well as the rowspan and colspan attributes of each cell. Structure. Each When an element is created, it is bound to a unique identifier (e.g., an ID based on row and column coordinates) of the corresponding cell in the JSON data. Simultaneously, the cell's content and semantic type are populated. In Chinese, CSS styles can be used to visually distinguish content of different semantic types, such as using different colored backgrounds to mark "quality inspection points" and "equipment codes".

[0067] Step S402: Listen for and respond to user interaction events.

[0068] The visual document editor needs to capture user operations on table topology and content. Specifically, step S4 supports user verification and correction of table topology through the following methods: In the visual document editor, the table topology in the JSON data is rendered into an HTML table, and each cell is bound to its underlying JSON data node; listen for user interface operation events triggered on the HTML table, such as merging, splitting, adding, or deleting rows and columns; based on the interface operation events, calculate the changes in the coordinates of the affected cells in real time, and update the row and column span attributes and content reference relationships in the bound underlying JSON data nodes.

[0069] like Figure 3 As shown, this is a schematic diagram of the topology operation interface of the visual table editor of this application, demonstrating how users can perform topology operations such as merging and splitting tables through the toolbar. Taking "merging cells" as an example, it mainly includes the following operation steps 3.1) to 3.4): 3.1) Users can select multiple consecutive cells by dragging the mouse; 3.2) The front end calculates the starting row / column and ending row / column of the selected area; 3.3) Real-time calculation of changes in the coordinates of affected cells: The system simulates a merge operation, determines whether the merge is legal (e.g., whether it is a cross-structure merge), and calculates the new merge range; 3.4) Update the underlying JSON data: Locate the data node corresponding to the top-left cell of the selected area, update its rowspan and colspan attributes to the new range values, and mark the data nodes corresponding to the other cells to be merged as "redundant". In the subsequent data structure, clear their content or mark them as referenced. The front-end interface then re-renders the table area according to the updated JSON data, and the user immediately sees the merged effect. This two-way binding ensures that every operation of the user on the interface can be mapped to the changes in the underlying data structure in real time and accurately.

[0070] Step S403: Support direct content editing.

[0071] like Figure 4 As shown, this is a schematic diagram of the content operation interface of the visual table editor of this application, demonstrating how users can directly click on cells to modify text content. Users can directly click on the text in any cell to make changes. After editing, the front-end framework captures the modification event and updates the new text content to the content field of the JSON data node bound to that cell. At the same time, the system can re-perform a lightweight step S2 semantic recognition (applying the same rules and context) on the new text to update its semantic_type, ensuring the accuracy of the semantic label.

[0072] Through the above mechanism, step S4 realizes the transformation from "static data" to "dynamic interactive document", providing users with a powerful tool for final verification and correction of parsing results.

[0073] Step S5: Respond to the user's verification and correction in the visual document editor, synchronously update the underlying JSON data, and after the user confirms, publish the final standard JSON data and its associated semantic tags to the data storage service for integration and retrieval by downstream business systems or search engines.

[0074] Step S5 is responsible for assetizing the high-quality data after manual verification and delivering it to downstream applications. It ensures that the parsed output is no longer an isolated file, but rather an integrable and searchable data service. Specifically, step S5 can be implemented through the following steps S501 to S503: Step S501: Record the corrections and generate version tracking information.

[0075] For auditing and data traceability, the system records the user's correction history. The verification and correction completed by the user in the visual document editor can be: recording every modification made by the user to the content in the visual editor, which can be text modification, cell merging / splitting, row and column addition / deletion; generating a correction record for each modification, which includes the modification location, original value, modified value and modification type; and storing the correction record in association with the final exported standard JSON data to form version tracking information. For example, a correction record may be: {"id":"rev001","position":"table1[2][3]","operation":"content_update","oldValue":"torque wrench","newValue":"torque wrench","timestamp":"2023-10-27T10:30:00Z"}. All correction records, together with the document's unique ID and the final JSON data, constitute a complete version.

[0076] Step S502: User confirmation and data release.

[0077] After the user completes all validation and corrections, they click the "Confirm Release" button. The front-end application then packages the final version's JSON data, associated semantic tags, document metadata, and correction logs into a single data package.

[0078] Step S503: Publish to the data storage service and build an index.

[0079] The system publishes the final standard JSON data and its associated semantic tags to a data storage service. This "data storage service" can be a cloud database (e.g., MongoDB), a data lake, or an engine optimized for search.

[0080] If the structured JSON data generated by parsing is simply stored, its inherent semantic value is not fully explored, making efficient and accurate multi-dimensional business retrieval downstream still difficult. Therefore, after publishing the data to the data storage service in step S5, the following semantic tag-based index optimization process is also included: extracting semantic tags and their associated text content fragments from the final published JSON data to build an inverted index; and integrating this inverted index with the document's metadata and chapter structure information to form an enhanced index structure that supports multi-dimensional, cross-document aggregate retrieval. Specifically, the system traverses the JSON data, extracting all fields with semantic_type of "quality inspection point," "device code," etc., and their corresponding content text. Then, these contents are indexed in a search engine (such as Elasticsearch). For example, a "quality inspection point" would be indexed as: { "doc_id":"doc_001", "section":"2.1 Disassembling the bearing", "semantic_tag":"quality_check_point", "content": "Measure bearing clearance, standard is 0.05-0.10mm". "w_point_code":"W3" } By actively extracting semantic tags to build an inverted index and integrating it with metadata, the output of the parsing process is directly transformed into infrastructure for enhanced retrieval capabilities. This enables downstream applications (such as search engines, analytics platforms, etc.) to support complex combined queries across documents based on business semantics in a forward-looking, low-cost, and efficient manner, greatly releasing the potential application value of structured data.

[0081] Considering that traditional full-text search or simple field search cannot meet the advanced needs of business analysis such as statistics, aggregation, and distribution insights, for example, users not only want to find documents containing "quality inspection points," but also want to understand the distribution of "quality inspection points" in different equipment types, the above embodiment integrates the inverted index with document metadata and chapter structure information to form an enhanced index structure that supports multi-dimensional, cross-document aggregated retrieval. This can be achieved by using semantic tags, equipment codes, and document types as core search dimensions; establishing hierarchical aggregateable statistical information for each dimension, where, for the "quality inspection point" tag, the frequency and distribution of its occurrence in various equipment and document types are statistically analyzed; receiving search queries that can combine multiple dimensions and keywords, and returning results and associated aggregated statistical views based on the enhanced index structure. This enables downstream intelligent search engines or business systems to execute complex semantic combination queries such as "retrieving all entries in the 'quality inspection points' involving 'steam turbine #high pressure cylinder' equipment that require a gap standard of less than 0.1mm," and directly seeing the distribution statistics of these quality inspection points in various types of documents, achieving in-depth data utilization. In other words, the above solution elevates the retrieval system from "finding documents" to "discovering knowledge." The system can directly respond to users' combined dimensional queries and return aggregated results with pre-computed statistical views (e.g., frequency distribution), thereby providing users with direct business insights and achieving a leap from information retrieval to analytical support.

[0082] Furthermore, to address the engineering challenge of incompatibility between historical data parsed from the old template and the new template after JSON Schema template upgrades due to changes in business requirements during long-term operation and maintenance, resulting in inaccessible historical data or the need for costly manual migration, this application also designs a template version management mechanism, namely, Figure 1 The example method may also include the template version management and rollback mechanism in steps S5041 to S5044: Step S5041: Maintain a version history for each JSON Schema template to store different versions of the template.

[0083] Whenever the template is updated, the system records the new version number (e.g., v1.0.0, v1.1.0) and the changes.

[0084] Step S5042: After loading and applying the JSON Schema template to assemble the data, record the template version number used in this parsing.

[0085] Step S5043: When a user modifies the final data published in step S5, the system will store the modified content in association with the template version number.

[0086] Step S5044: If the JSON Schema template changes subsequently, the system can perform content mapping and adaptive transformation on historical data generated based on the old version template according to the stored template version number and historical correction records, or provide a parsed view based on the old version template.

[0087] For example, when a template is upgraded from v1.0 to v2.0, a field is renamed from `tool_list` to `tools`. When a user or application requests access to historical document data generated based on the v1.0 template, the system can automatically map the content of the `tool_list` field to the `tools` field of the new template according to predefined conversion rules, generating data for a v2.0 compatible view. In the above embodiment, content mapping and adaptive conversion of historical data generated based on the old version template can be performed as follows: identifying differences in field definitions between the old and new JSON Schema versions, including the addition, deletion, renaming, and data type changes of fields; predefining conversion rules for field differences that may be mapped; and automatically executing field mapping and data format conversion according to the predefined conversion rules when a user requests access to data based on the old template version, generating data in a form that conforms to the new template version or a compatible view. This ensures the consistency and accessibility of data during long-term evolution.

[0088] The aforementioned template management and rollback mechanism introduces lifecycle management capabilities for data pattern evolution into the entire parsing system by maintaining template version history, associating stored data with version numbers, and providing data mapping and compatibility view capabilities. This ensures the long-term accessibility and consistency of historical data during continuous system iteration, while also supporting smooth template upgrades, thereby improving the engineering maturity, system stability, and long-term value of data assets of the entire solution.

[0089] As another embodiment of this application, the JSON Schema template version management and rollback mechanism can also be implemented through the following steps S'5041 to S'5043: Step S'5041: Change semantic awareness, specifically including: when a version update of the JSON Schema template is detected, the system automatically performs a differential comparison analysis between the old and new versions (denoted as Schema_vOld and Schema_vNew). This differential comparison analysis not only identifies the addition, deletion, renaming and data type changes of fields, but also further analyzes the changes in the constraint relationships between fields, the migration of business semantic tags and the update of the calculation logic of derived fields, and generates a structured change description list with semantic annotations; Step S'5042: Automatic generation and optimization of bidirectional conversion chain, including: based on the change description list generated in step S'5041, automatically reasoning and generating or updating the bidirectional conversion rule chain for data migration through the following steps S'5042a to S'5042c; Step S'5042a: Generate forward transformation rules, which may specifically be: defining the transformation logic from the Schema_vOld data structure instance to the Schema_vNew data structure instance, including field mapping, default value filling, data type casting, and calculating the value of the new derived field based on the old data, etc.; Step S'5042b: Generate reverse transformation rules, which can be: define the transformation logic of reverse adaptation from the Schema_vNew data structure instance to the Schema_vOld view. This process needs to handle scenarios such as missing fields and type backtracking. In particular, for fields added in Schema_vNew that do not have corresponding values ​​in the old data, the reverse rules can be configured to fill specific placeholders or trigger missing value handling procedures. Step S'5042c: Optimize the transformation chain, which may specifically be: record the actual execution performance and result fidelity of each transformation, and dynamically optimize the calculation path or parameters of the transformation rules based on historical data to improve the transformation efficiency in frequent access scenarios; Step S'5043: On-demand real-time view composition and publishing, i.e., when an access request for historical data is received, based on the target schema version specified or derived in the request (which may be vOld, vNew, or any historical version), perform the following steps S'5043a to S'5043d: Step S'5043a: Locate the original parsing template version (Schema_vOrig) on ​​which the target data is based; Step S'5043b: Dynamically assemble the transformation path, that is: find the shortest or optimal transformation path from Schema_vOrig to the target Schema version in the generated transformation rule chain; Step S'5043c: Perform real-time transformation and view composition. Specifically, this may involve: applying the corresponding transformation rules sequentially along the path to process the original data, and seamlessly integrating the correction records stored by the user for the historical version of the data during the transformation process to ensure that the user's corrections are correctly reflected in the transformed view. Step S'5043d: Publish the composite view, including: returning the real-time transformed and corrected integrated data in a structured form that conforms to the target schema version, thus completing this access; the system may selectively cache frequently requested composite views to improve the performance of subsequent accesses.

[0090] The solutions exemplified by steps S5041 to S5044 in the above embodiments mainly consider forward conversion or rollback of views, while the solutions exemplified by steps S'5041 to S'5043 innovatively pre-build and maintain a bidirectional conversion rule chain. This enables the system to not only upgrade old data to a new view, but also to "downgrade" data with a new structure to be compatible with the old interface, or to freely convert between different historical versions, providing great access flexibility and meeting the diverse integration needs of downstream systems. On the other hand, by introducing an adaptive mechanism for conversion chain optimization, the system can optimize the execution efficiency or accuracy of conversion rules based on actual operating data. For example, for a frequently accessed version migration path, intermediate results can be pre-calculated and cached. This allows the version management mechanism to evolve from a static configuration into a dynamic system with self-tunable performance. In other words, the schemes exemplified in steps S'5041 to S'5043 transform template version management from a static compatibility solution focused on data backup and view rollback into a dynamic data virtualization and evolution management framework with deep change understanding, bidirectional intelligent transformation, and on-demand real-time synthesis capabilities. Through mechanisms such as semantic analysis, bidirectional chains, real-time synthesis, and optimization, it systematically solves the consistency, flexibility, and performance issues in the long-term evolution of data structures.

[0091] From the above appendix Figure 1 The cloud-based intelligent parsing method for power generation enterprise maintenance documents demonstrates two key advantages. First, by deeply analyzing the underlying file structure and dividing content areas, it ensures that no physical information, such as the style and chapters of the original document, is missing. Specifically, through a table topology reconstruction algorithm based on grid coordinates and recursive merging detection, it accurately restores the original layout of irregularly merged cells, solving the core problem of structural distortion when processing complex industrial tables in existing technologies, and providing a high-fidelity data foundation for subsequent processing. Second, through semantic layer recognition—that is, using a composite regular rule set and contextual features to jointly judge the text—it achieves fine-grained classification of business concepts such as quality inspection points and equipment codes. This ensures that the final generated JSON data not only contains text content but also carries semantic tags associated with business semantic classification. When this structured data with rich semantic tags is published to a data storage service, downstream search engines or business systems can directly perform efficient and accurate retrieval and integration based on the semantic dimension, improving efficiency and accuracy. The application enhances the usability of data. Thirdly, the cloud-based parsing service completes the arduous initial screening and structuring work, while users can perform final verification and fine-tuning of the results through an intuitive front-end web application. This closed-loop process, primarily machine-based with human-machine collaboration, ensures processing efficiency while guaranteeing the semantic consistency between the output data and the source documents through manual verification, meeting reliable standards required by business needs. This truly achieves automated production from unstructured documents to high-quality, trustworthy data assets. Fourthly, because the technical solution of this application is based on an architecture design that combines cloud-based parsing services and front-end web applications, the core parsing capabilities can be provided as a service. This not only facilitates the elastic expansion of computing resources to meet the demands of massive document processing but also, through API separation from the front-end, allows the intelligent parsing capability to be flexibly integrated into different smart power plant platforms or data middleware, demonstrating excellent scalability and the service-oriented characteristics of cloud computing software, laying the foundation for building larger-scale industrial data service platforms. In summary, the technical solution of this application, through automated intelligent parsing and visual verification closed-loop, achieves highly reliable conversion of power generation enterprise maintenance documents into high-fidelity, semantic business data.

[0092] Please see the appendix Figure 5 This application provides a cloud-based intelligent parsing device for power generation enterprise maintenance documents. The device may include a parsing module 501, a semantic recognition module 502, a reconstructing module 503, a rendering module 504, and an updating module 505, as detailed below: The parsing module 501 is used to parse the underlying file structure of the power generation enterprise maintenance documents input by the cloud parsing service, extract the document metadata, identify the chapter structure according to the style and numbering features, and divide the document content into multiple logically independent content areas. The semantic recognition module 502 is used to traverse the paragraph text and table cell text in each logically independent content area, apply a set of composite regular rules and context features to make joint judgments, and perform fine-grained business semantic classification on the traversed text. The business semantic classification includes quality inspection points, multiple options, equipment codes, and tools. The reorganization module 503 is used to perform data structure assembly on the classified content according to the predefined JSONSchema template corresponding to the document type. For the tables in the power generation enterprise maintenance documents, it executes a table topology reconstruction algorithm based on grid coordinates and recursive merging detection to restore the original topology structure of irregular merged cells and generate structured JSON data with semantic tags that retain the original document topology. The semantic tags are associated with the business semantic classification. Rendering module 504 is used to render structured JSON data into an interactive visual document editor through a front-end web application. The visual document editor allows users to verify and correct the table topology. The update module 505 is used to respond to the verification and correction completed by the user in the visual document editor, synchronously update the underlying JSON data, and publish the final standard JSON data and its associated semantic tags to the data storage service after user confirmation, so that downstream business systems or search engines can integrate and retrieve it.

[0093] From the above appendix Figure 5 As seen in the example of the cloud-based intelligent parsing device for power generation company maintenance documents, on the one hand, by deeply analyzing the underlying file structure and dividing the content areas, it ensures that no physical information such as the style and chapters of the original document is omitted. In particular, through a table topology reconstruction algorithm based on grid coordinates and recursive merging detection, it can accurately restore the original layout of irregularly merged cells, solving the core problem of structural distortion when processing complex industrial tables in existing technologies, and providing a high-fidelity data foundation for subsequent processing. On the other hand, through semantic layer recognition, that is, by using a composite regular rule set and contextual features to jointly judge the text, it achieves fine-grained classification of business concepts such as quality inspection points and equipment codes. This makes the final generated JSON data not only contain text content, but also carry semantic tags associated with business semantic classification. When this structured data with rich semantic tags is published to the data storage service, downstream search engines or business systems can directly perform efficient and accurate retrieval and integration based on the semantic dimension, improving efficiency and accuracy. The application enhances the usability of data. Thirdly, the cloud-based parsing service completes the arduous initial screening and structuring work, while users can perform final verification and fine-tuning of the results through an intuitive front-end web application. This closed-loop process, primarily machine-based with human-machine collaboration, ensures processing efficiency while guaranteeing the semantic consistency between the output data and the source documents through manual verification, meeting reliable standards required by business needs. This truly achieves automated production from unstructured documents to high-quality, trustworthy data assets. Fourthly, because the technical solution of this application is based on an architecture design that combines cloud-based parsing services and front-end web applications, the core parsing capabilities can be provided as a service. This not only facilitates the elastic expansion of computing resources to meet the demands of massive document processing but also, through API separation from the front-end, allows the intelligent parsing capability to be flexibly integrated into different smart power plant platforms or data middleware, demonstrating excellent scalability and the service-oriented characteristics of cloud computing software, laying the foundation for building larger-scale industrial data service platforms. In summary, the technical solution of this application, through automated intelligent parsing and visual verification closed-loop, achieves highly reliable conversion of power generation enterprise maintenance documents into high-fidelity, semantic business data.

[0094] Figure 6 This is a schematic diagram of the structure of a device provided in one embodiment of this application. For example... Figure 6 As shown, the device 6 in this embodiment mainly includes: a processor 60, a memory 61, and a computer program 62 stored in the memory 61 and executable on the processor 60, such as a program for a cloud-based intelligent parsing method for power generation enterprise maintenance documents. When the processor 60 executes the computer program 62, it implements the steps in the above-described embodiment of the cloud-based intelligent parsing method for power generation enterprise maintenance documents, for example... Figure 1 Steps S1 to S5 are shown. Alternatively, when processor 60 executes computer program 62, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 5 The functions of the parsing module 501, semantic recognition module 502, recombination module 503, rendering module 504, and update module 505 are shown.

[0095] For example, the computer program 62 of the cloud-based intelligent parsing method for power generation enterprise maintenance documents mainly includes: parsing the underlying file structure of the input power generation enterprise maintenance documents by a cloud-based parsing service, extracting document metadata, and identifying the chapter structure based on style and numbering features to divide the document content into multiple logically independent content areas; for each content area, traversing the paragraph text and table cell text, applying a set of composite regular rules and context features for joint judgment, and performing fine-grained business semantic classification on the traversed text; and for the classified content, according to predefined JSON corresponding to the document type... The schema template is used for data structuring and assembly. For tables in power generation company maintenance documents, a table topology reconstruction algorithm based on grid coordinates and recursive merging detection is executed to restore the original topology of irregularly merged cells, generating structured JSON data with semantic tags that retain the original document topology. These semantic tags are associated with business semantic classifications. The structured JSON data is rendered into an interactive visual document editor via a front-end web application. This visual document editor allows users to verify and correct the table topology. In response to user verification and corrections in the visual document editor, the underlying JSON data is updated synchronously. After user confirmation, the final standard JSON data and its associated semantic tags are published to a data storage service for integration and retrieval by downstream business systems or search engines. The computer program 62 can be divided into one or more modules / units, which are stored in memory 61 and executed by processor 60 to complete this application. One or more modules / units can be a series of computer program instruction segments capable of performing specific functions, describing the execution process of the computer program 62 in device 6.For example, computer program 62 can be divided into the functions of parsing module 501, semantic recognition module 502, reconstruction module 503, rendering module 504, and updating module 505 (a module in the virtual device). The specific functions of each module are as follows: Parsing module 501 is used to parse the underlying file structure of the power generation enterprise maintenance document input by the cloud parsing service, extract the document metadata, and identify the chapter structure according to style and numbering features, dividing the document content into multiple logically independent content areas; Semantic recognition module 502 is used to traverse the paragraph text and table cell text in each logically independent content area, apply a set of composite regular rules and context features for joint judgment, and perform fine-grained business semantic classification on the traversed text, where business semantic classification includes quality inspection points, multiple options, equipment codes, and tools; Reconstruction module 503 is used to reconstruct the classified content according to predefined JSON corresponding to the document type. The schema template is used for data structuring and assembly. For tables in power generation company maintenance documents, a table topology reconstruction algorithm based on grid coordinates and recursive merging detection is executed to restore the original topology of irregularly merged cells, generating structured JSON data with semantic tags that retain the original document topology. These semantic tags are associated with the business semantic classification. The rendering module 504 renders the structured JSON data into an interactive visual document editor via a front-end web application. This visual document editor allows users to verify and correct the table topology. The update module 505 responds to user verification and corrections in the visual document editor, synchronously updating the underlying JSON data. After user confirmation, the final standard JSON data and its associated semantic tags are published to the data storage service for integration and retrieval by downstream business systems or search engines.

[0096] Device 6 may include, but is not limited to, processor 60 and memory 61. Those skilled in the art will understand that... Figure 6 This is merely an example of device 6 and does not constitute a limitation on device 6. It may include more or fewer components than shown, or combine certain components, or different components. For example, the device may also include input / output devices, network access devices, buses, etc.

[0097] The processor 60 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0098] Memory 61 can be an internal storage unit of device 6, such as a hard disk or RAM of device 6. Memory 61 can also be an external storage device of device 6, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., equipped on device 6. Furthermore, memory 61 can include both internal storage units and external storage devices of device 6. Memory 61 is used to store computer programs and other programs and data required by the device. Memory 61 can also be used to temporarily store data that has been output or will be output.

[0099] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed. That is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above-described device can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0100] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0101] 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, or a combination of computer software and electronic hardware. 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 implementation should not be considered beyond the scope of this application.

[0102] In the embodiments provided in this application, it should be understood that the disclosed apparatus / device and method can be implemented in other ways. For example, the apparatus / device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0103] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0104] 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0105] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a storage medium. Based on this understanding, all or part of the processes in the above-described embodiments of this application can also be implemented by a computer program instructing related hardware. The computer program for the cloud-based intelligent parsing method for power generation enterprise maintenance documents can be stored in a storage medium. When the computer program is executed by a processor, it can implement the steps of the above-described method embodiments, namely, the cloud parsing service parses the underlying file structure of the input power generation enterprise maintenance document, extracts document metadata, and identifies the chapter structure according to style and numbering features, dividing the document content into multiple logically independent content areas; for each content area, it traverses the paragraph text and table unit text, applies a set of composite regular rules and context features for joint judgment, and performs fine-grained business semantic classification on the traversed text; for the classified content, it uses predefined JSON corresponding to the document type. The schema template is used for structured data assembly. For tables in power generation company maintenance documents, a table topology reconstruction algorithm based on grid coordinates and recursive merging detection is executed to restore the original topology of irregularly merged cells, generating structured JSON data with semantic tags that retain the original document topology. These semantic tags are associated with business semantic categories. The structured JSON data is rendered into an interactive visual document editor via a front-end web application. This visual document editor allows users to verify and correct the table topology. In response to user verification and corrections in the visual document editor, the underlying JSON data is updated synchronously. After user confirmation, the final standard JSON data and its associated semantic tags are published to a data storage service for integration and retrieval by downstream business systems or search engines. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or some intermediate form. Storage media can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the contents of storage media can be appropriately added to or removed according to the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, storage media may not include electrical carrier signals and telecommunication signals.

[0106] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application. The specific embodiments described above further illustrate the purpose, technical solutions, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the protection scope of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application. < / w:tc> < / w:tr> < / w:tbl> < / w:tc> < / w:gridcol> < / w:tr> < / w:tc> < / w:tc> < / w:tc> < / w:tr> < / w:tbl> < / w:tc> < / w:tr> < / w:p> < / w:b> < / w:outlinelvl>

Claims

1. A cloud-based intelligent parsing method for maintenance documents of power generation enterprises, characterized in that, The method includes: Step S1: The cloud-based parsing service parses the underlying file structure of the power generation company's maintenance document, extracts the document metadata, and identifies the chapter structure based on style and numbering features, dividing the document content into multiple logically independent content areas; Step S2: For each content area, traverse the paragraph text and table cell text within it, and apply a set of composite regular expression rules and contextual features for joint judgment to perform fine-grained business semantic classification on the traversed text. The business semantic classification includes quality inspection points, multiple options, equipment codes, and tools. The application of a set of composite regular expression rules and contextual features for joint judgment to perform fine-grained business semantic classification on the traversed text includes: configuring a regular expression rule set R, which contains multiple rules for identifying quality inspection point markers, option boxes, and specific encoding formats. Regular expression pattern; capture the context features C of the current text, wherein the context features C include at least the current chapter title determined by step S1 and the column header and semantic type of adjacent cells determined when the text is in a table; apply the composite regular expression rule set R to the text for rule matching, and perform context analysis based on the captured context features C; when the text matches a specific rule r_i in the regular expression rule set R, and its context features C meet the preset business scenario conditions, then classify it into the business semantic type corresponding to r_i and C; Step S3: For the categorized content, perform data structuring assembly based on a predefined JSON Schema template corresponding to the document type. Specifically, for the tables in the power generation enterprise maintenance document, execute a table topology reconstruction algorithm based on grid coordinates and recursive merge detection to restore the original topology of irregularly merged cells, generating structured JSON data with semantic tags that retain the original document topology. These semantic tags are associated with the business semantic classification. The execution of the table topology reconstruction algorithm based on grid coordinates and recursive merge detection for the tables in the power generation enterprise maintenance document includes: Step S31: Traversing the table rows in the Word document XML structure of the power generation enterprise maintenance document (…). <w:tr>) and column ( <w:tc> Step S31: Construct a two-dimensional logical grid, with each grid point associated with a corresponding cell's document object model pointer; Step S32: Parse the w:gridSpan and w:vMerge attributes of each cell, and mark the horizontal and vertical ranges of merged cells in the two-dimensional logical grid; Step S33: Traverse all cells in the two-dimensional logical grid that are not marked as merge sources, call the semantic recognition method of step S2 on the text content of each valid cell, parse its content type, and generate a lightweight JSON object containing content, semantic type, and cell position information; Step S34: Based on the merge range marked in step S32, reconstruct the cell merge relationship in the output table data structure, filter out redundant marked units used only for layout, and output lightweight table data that completely retains the original table topology;< / w:tc> < / w:tr> Step S4: Render the structured JSON data into an interactive visual document editor through a front-end web application. The visual document editor allows users to verify and correct the table topology. Step S5: In response to the user's verification and correction completed on the visual document editor, the underlying JSON data is updated synchronously, and after the user confirms, the final standard JSON data and its associated semantic tags are published to the data storage service for integration and retrieval by downstream business systems or search engines.

2. The cloud-based intelligent parsing method for power generation enterprise maintenance documents according to claim 1, characterized in that, The predefined JSON Schema templates corresponding to document types are created and managed in the following ways: Step S301: Define a JSON Schema for different types of power generation maintenance documents. The JSON Schema specifies the root structure of the output JSON, required fields, data types of the fields, and the mapping relationship between the fields and business semantics. Step S302: Store the JSON Schema in the form of a configuration file. At the start of the parsing process, dynamically load the matching JSON Schema template based on the metadata or filename characteristics of the input document. Step S303: In step S3, the semantic layer recognition results are assembled into a JSON instance that conforms to the loaded JSON Schema according to the specification of the JSON Schema.

3. The cloud-based intelligent parsing method for power generation enterprise maintenance documents according to claim 2, characterized in that, The method also includes the following template version management and rollback mechanism: Step S304: Maintain a version history for each JSON Schema template to store different versions of the template; Step S305: After loading and applying the JSON Schema template to assemble the data, record the template version number used in this parsing; Step S306: When the user modifies the final data published in step S5, the system will store the modified content in association with the template version number; Step S307: If the JSON Schema template changes subsequently, the system can perform content mapping and adaptive transformation on historical data generated based on the old version template according to the stored template version number and historical correction records, or provide a parsed view based on the old version template.

4. The cloud-based intelligent parsing method for power generation enterprise maintenance documents according to claim 1, characterized in that, After publishing the data to the data storage service in step S5, the following index optimization based on semantic tags is also included: Step S6: Extract the semantic tags and their associated text content fragments from the final published JSON data, and construct an inverted index; Step S7: Integrate the inverted index with document metadata and chapter structure information to form an enhanced index structure that supports multi-dimensional and cross-document aggregation retrieval.

5. The cloud-based intelligent parsing method for power generation enterprise maintenance documents according to claim 4, characterized in that, The process of associating and integrating the inverted index with document metadata and chapter structure information to form an enhanced index structure that supports multi-dimensional, cross-document aggregation retrieval includes: Step S71: Use semantic tags, device codes, and document types as core search dimensions; Step S72: Establish hierarchical aggregateable statistical information for each dimension. For the "quality inspection point" tag, calculate its frequency and distribution in each device and document type. Step S73: Receive a search query, which can combine the multiple dimensions and keywords, and return results and associated aggregated statistical views based on the enhanced index structure.

6. A cloud-based intelligent parsing device for power generation enterprise maintenance documents, used to implement the cloud-based intelligent parsing method for power generation enterprise maintenance documents as described in any one of claims 1 to 5, characterized in that, The device includes: The parsing module is used to parse the underlying file structure of the power generation company's maintenance documents input by the cloud parsing service, extract the document metadata, and identify the chapter structure based on style and numbering features, dividing the document content into multiple logically independent content areas; The semantic recognition module is used to traverse the paragraph text and table cell text in each content area, apply a set of composite regular rules and context features to make joint judgments, and perform fine-grained business semantic classification on the traversed text. The business semantic classification includes quality inspection points, multiple options, equipment codes, and tools. The reorganization module is used to perform data structure assembly on the classified content according to the predefined JSON Schema template corresponding to the document type. Specifically, for the tables in the power generation enterprise maintenance documents, a table topology reconstruction algorithm based on grid coordinates and recursive merging detection is executed to restore the original topology of irregular merged cells and generate structured JSON data with semantic tags that retain the original document topology. The semantic tags are associated with the business semantic classification. The rendering module is used to render the structured JSON data into an interactive visual document editor through a front-end web application. The visual document editor allows users to verify and correct the table topology. The update module is used to respond to the verification and correction completed by the user on the visual document editor, synchronously update the underlying JSON data, and publish the final standard JSON data and its associated semantic tags to the data storage service after user confirmation, so that downstream business systems or search engines can integrate and retrieve it.

7. An apparatus 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 steps of the method as described in any one of claims 1 to 5.

8. A storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 5.

Images