A knowledge graph-based document format knowledge representation method and device

Abstract

The application discloses a kind of based on knowledge graph's document format knowledge representation method and device, to solve the problem that format rule is difficult to be utilized by machine in existing intelligent document generation system, semantic generation and format control are separated, based on knowledge graph's document format knowledge representation method includes: constructing multi-source format corpus and carrying out structured preprocessing;Format entity and its relationship are extracted using deep learning model;Based on the extraction result, a format knowledge graph containing a structure layer, a semantic layer and a functional layer is constructed;And introduce adaptive adjustment mechanism based on downstream task feedback, dynamically optimize the graph.The present application converts unstructured format specifications into structured graph representations, enabling agents to accurately invoke format rules and possess self-learning evolution capabilities, significantly improving the format compliance and adaptability of official document generation.

Description

Technical Field

[0001] This invention relates to the field of natural language processing technology, and more specifically, to a document format knowledge representation method and apparatus based on knowledge graphs, used to transform unstructured document format specifications into machine-readable and reasonable structured knowledge, so as to assist intelligent document generation systems in achieving precise format control and compliant output. Background Technology

[0002] With the deepening of digital transformation in e-government, intelligent document generation has become a key tool for improving administrative efficiency. Official documents (such as notices, reports, and letters) not only require semantic accuracy but also must strictly adhere to mandatory standards, involving complex formatting specifications such as document numbering, title hierarchy, security classification, and attachment arrangement. However, current mainstream technical solutions have the following shortcomings in handling document formats: Large-scale models lack awareness of formatting: General-purpose large language models output in free text form and cannot perceive or control the underlying structural style of Word documents. This results in generated content that, while semantically reasonable, suffers from chaotic formatting, such as misaligned headings and incorrect attachment placement. Existing research largely focuses on content generation, neglecting format compliance, leaving generated documents requiring significant manual post-formatting.

[0003] Limitations of static templates: Existing intelligent writing tools mostly use preset templates for filling, which can ensure consistent formatting, but lacks flexibility and cannot adapt to multiple legal layout variations arising from changes in content logic within the same document type (for example, "attachments" can be placed after the main text or before the imprint). Templates cannot exhaustively list all variations, and maintenance costs are high.

[0004] The fragmentation of knowledge representation: Traditional knowledge bases primarily store textual semantics (such as policy clauses), while formatting rules are usually scattered in standard documents in natural language form and are not modeled as structured knowledge. Even with RAG (Retrieval Enhanced Generation) technology, the retrieved formatting rules are often fragmented due to unreasonable segmentation strategies, such as mixing "header rules" and "page description rules" together, or losing logical dependencies between clauses, resulting in inaccurate application during generation.

[0005] Lack of adaptive evolutionary capability: The existing system's reliance on format rules is one-off, and it cannot optimize knowledge representation based on feedback from the quality of downstream generated results. When policies are updated or new formatting variations emerge, manual reconfiguration is required, making it difficult to meet the frequently changing needs of government affairs. Summary of the Invention

[0006] To address the technical problems in existing technologies where document format rules are difficult to directly utilize by AI systems and where semantic generation and format control are separated, this invention proposes a document format knowledge representation method based on knowledge graphs. This method transforms format specifications into structured graph representations and introduces an adaptive feedback adjustment mechanism to achieve dynamic optimization and precise invocation of format knowledge, filling the gap in the current intelligent document generation's "semantic-format" collaborative control.

[0007] To achieve the above objectives, the first aspect of the present invention provides a document format knowledge representation method based on knowledge graphs, comprising: Collect multi-source format standard data, preprocess the multi-source format standard data, and extract structural features and semantic features; Based on the extracted structural and semantic features, a deep learning model is used to identify format entities and the relationships between format entities from preprocessed multi-source format specification data. Based on the identified format entities and the relationships between them, a graph database for storing format knowledge is constructed, forming a format knowledge graph. This includes: mapping the identified format entities to node types in the graph database, storing the entity name, attribute information, and location coordinates for each node; mapping the relationships between the identified format entities to edge types in the graph database, storing the relationship type and attribute information for each edge; and organizing the nodes and edges according to a three-layer architecture of structural layer, semantic layer, and functional layer to form a format knowledge graph. An adaptive feedback mechanism is introduced to optimize and update the formatted knowledge graph.

[0008] In one implementation, the structural features include heading levels, paragraph numbers, font sizes, indentation alignment, and page layout information; the semantic features include text semantic vector representation, terminology definitions, functional descriptions, and applicable scenario information.

[0009] In one implementation, based on extracted structural and semantic features, a deep learning model is used to identify format entities and relationships between format entities from preprocessed multi-source format specification data, including: Obtain a joint extraction model based on a pre-trained language model, which includes a shared encoding layer, a conditional random field layer for entity recognition, and a dual affine attention layer for relation classification. Format entities are identified from preprocessed multi-source format specification data using conditional random field layers; A dual affine attention layer is used to identify relationships between format entities in preprocessed multi-source format specification data.

[0010] In one implementation, the structure layer uses layout entities as nodes and structural relationships as edges to describe the physical organization of the document; the semantic layer stores the definitions, synonyms, and applicable scenarios of official document terms; and the functional layer associates the functional units of the official document with the corresponding format templates.

[0011] In one embodiment, the method further includes: connecting the layers of the format knowledge graph through cross-layer relationships to support joint queries, wherein the cross-layer relationships include: a correspondence relationship between the structural layer and the semantic layer, used to connect the title nodes in the structural layer with the concept nodes in the semantic layer; a use relationship between the structural layer and the functional layer, used to connect the attachment nodes in the structural layer with the attachment description function nodes in the functional layer, clarifying the functional positioning of structural elements; and a containment function relationship between the semantic layer and the functional layer, used to connect the document type nodes in the semantic layer with the function nodes in the functional layer, establishing a mapping between document types and functional units.

[0012] In one implementation, the method further includes using the format knowledge graph to assist in the generation of downstream documents, specifically: obtaining format templates and constraints by querying the format knowledge graph, and generating Word documents that conform to the format specifications by combining Text2API technology.

[0013] In one implementation, an adaptive feedback mechanism is introduced to optimize and update the formatted knowledge graph, including: Statistical analysis of the error rate of specific format elements in downstream generated documents; Determine whether the error rate exceeds a preset threshold. If it does, backtrack and retrieve the relationship path corresponding to the format element in the format knowledge graph. If ambiguity or missing information is detected in the knowledge representation, new triples are extracted from the newly added correct samples, and the formatted knowledge graph is pruned, expanded, or its attributes are updated.

[0014] Based on the same inventive concept, a second aspect of the present invention provides a document format knowledge representation device based on a knowledge graph, comprising: The multi-source format standard data acquisition and preprocessing module is used to acquire multi-source format standard data, preprocess the multi-source format standard data, and extract structural features and semantic features. The format entity and relation recognition module is used to identify format entities and the relationships between format entities from preprocessed multi-source format specification data based on extracted structural and semantic features and using a deep learning model. The format knowledge graph construction module is used to build a graph database for storing format knowledge based on the identified format entities and the relationships between them, forming a format knowledge graph. This includes: mapping the identified format entities to node types in the graph database, storing the entity name, attribute information, and location coordinates for each node; mapping the relationships between the identified format entities to edge types in the graph database, storing the relationship type and attribute information for each edge; and organizing the nodes and edges according to a three-layer architecture of structural layer, semantic layer, and functional layer to form the format knowledge graph. The adaptive update module is used to introduce an adaptive feedback mechanism to optimize and update the formatted knowledge graph.

[0015] Based on the same inventive concept, a third aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein when the program is executed by a processor, it is used to implement the above-described document format knowledge representation method based on knowledge graphs.

[0016] Based on the same inventive concept, a fourth aspect of the present invention provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it is used to implement the above-described document format knowledge representation method based on knowledge graph.

[0017] Compared with the prior art, the advantages and beneficial technical effects of the present invention are as follows: This invention discloses a document format knowledge representation method based on a knowledge graph. It constructs a multi-source format corpus and performs structured preprocessing; extracts format entities and their relationships using a deep learning model; constructs a format knowledge graph containing structural, semantic, and functional layers based on the extraction results; and introduces an adaptive adjustment mechanism based on downstream task feedback to dynamically optimize the graph. This invention transforms unstructured format specifications into structured graph representations, enabling intelligent agents to accurately invoke format rules and possess self-learning and evolutionary capabilities, significantly improving the format compliance and adaptability of generated official documents. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A schematic diagram illustrating a document format knowledge representation method based on a knowledge graph, provided in an embodiment of the present invention; Figure 2This is a schematic diagram of the neural network model structure for formatted entity and relation extraction in an embodiment of the present invention; Figure 3 This is a schematic diagram of the format knowledge graph constructed in an embodiment of the present invention; Figure 4 This is a schematic diagram of the three-layer architecture (structural layer, semantic layer, and functional layer) of the format knowledge graph in an embodiment of the present invention; Figure 5 This is a flowchart illustrating the adaptive feedback adjustment mechanism in an embodiment of the present invention. Detailed Implementation

[0020] To overcome the technical problems of existing technologies, such as the difficulty for AI systems to directly utilize document format rules and the separation of semantic generation and format control, this invention adopts the following technical solution: By constructing a multi-source format corpus, a deep learning model is used to extract format entities and their relationships from the corpus. Based on the extraction results, a format knowledge graph containing structural, semantic, and functional layers is constructed. An adaptive feedback adjustment mechanism is introduced, enabling the graph to dynamically optimize based on the quality feedback from downstream document generation tasks, achieving self-evolution of format knowledge. The intelligent document generator obtains format constraints by querying this graph, integrates semantic content with format instructions, and outputs compliant documents that conform to national standards.

[0021] Compared with existing methods, the uniqueness of this invention is reflected in the following three aspects: First, a paradigm shift from text-based rules to graph structures. In existing technologies, formatting specifications are mostly in the form of natural language text. Traditional rule engines require manual coding to implement rule judgments, resulting in rigidity and high maintenance costs. While RAG technology can retrieve relevant text, its unreasonable segmentation strategy often leads to fragmented formatting rules, such as mixing "header rules" and "page description rules," or losing logical dependencies between clauses. This invention, for the first time, transforms natural language-described formatting specifications into a fine-grained, computable knowledge graph. Each formatting element and its relationships are defined as nodes and edges in the graph, achieving precise representation and flexible invocation of formatting rules, fundamentally solving the problems of rigid rule engines and fragmented RAG retrieval.

[0022] Second, the invention achieves three-layer knowledge decoupling and integration. Existing knowledge bases typically store only textual semantic information, while formatting rules involve multiple dimensions such as physical layout, terminology definitions, and functional logic, which are difficult to cover with a single representation method. This invention achieves multi-dimensional organization of formatting knowledge through the separation and association of structural, semantic, and functional layers: the structural layer describes the physical organization of the document (such as the positional relationship of the header and footer); the semantic layer stores the definitions and applicable scenarios of official document terms (such as the conceptual explanation of "announcement"); and the functional layer associates functional units with corresponding format templates (such as "policy objectives" typically using a first-level heading format). These three layers can be stored and queried independently, and can also be collaboratively invoked through cross-layer relationships, adapting to the flexible needs of different document types and scenarios.

[0023] Third, adaptive evolution based on feedback. Existing knowledge bases are mostly statically constructed, making them difficult to update once built. When policies are revised or new formatting variations emerge, manual intervention and reconfiguration are required. This invention introduces a feedback adjustment mechanism driven by the quality of generated results. By continuously monitoring the format compliance of downstream document generation tasks, it automatically identifies ambiguities or omissions in the knowledge representation and extracts new knowledge from newly added correct samples to prune, expand, or update the graph's attributes. This mechanism enables the format knowledge graph to continuously learn and evolve like an intelligent agent, keeping pace with policy updates and scenario changes, achieving a leap from a static knowledge base to a dynamic intelligent agent—a capability not possessed by existing technologies.

[0024] This invention solves the core problem of separating semantic generation from format control by transforming document format specifications into structured graph representations and introducing an adaptive feedback mechanism, providing computable, inferable, and evolvable format knowledge support for intelligent document generation systems.

[0025] Example 1 This embodiment provides a document format knowledge representation method based on knowledge graphs. Please refer to [link to relevant documentation]. Figure 1 ,include: S1: Collect multi-source format standard data, preprocess the multi-source format standard data, and extract structural features and semantic features.

[0026] Specifically, S1 is the construction and preprocessing of multi-source format corpora.

[0027] The extracted structural features include heading level, paragraph number, font size, indentation alignment, and page layout information. These features provide boundary determination criteria for subsequent entity recognition, type judgment clues for relation extraction, and serve as core elements for constructing the knowledge graph structure layer. The extracted semantic features include text semantic vector representation, terminology definition, functional description, and applicable scenario information. These features assist in fine-grained entity type recognition, support the extraction of logical relationships, and serve as the content source for constructing the knowledge graph semantic layer.

[0028] In the specific implementation process, the multi-source format specification data includes national mandatory standards, local implementation rules and historical document samples; the preprocessing includes OCR recognition and layout analysis of PDF documents, parsing XML and extracting style information from docx documents, and calling a large language model to identify implicit titles and add virtual structure tags to txt documents.

[0029] In its implementation, this invention first collects three core data sources: national mandatory standards, such as GB / T9704-2012 and its subsequent revisions, obtained in PDF or docx format; local implementation rules, namely the document formatting specifications and operation guidelines issued by provincial and municipal government agencies; and historical document samples, collecting over 1500 anonymized official documents from government information disclosure platforms, covering 15 document types including notices, reports, and requests, and including 300 complex documents with attachments. For standard PDF files, open-source tools such as pdfplumber are used to extract text content and font information. By analyzing font height and layout coordinates, chapter titles (such as "7.2 Header Layout Rules") are automatically identified and hierarchical tags H1, H2, and H3 are added. For scanned documents, OCR recognition is performed first, and then XML structure repair technology is used to complete the title hierarchy. For docx files, the python-docx library is used to parse the underlying XML, extracting formatting information such as paragraph styles, heading styles, table structures, headers, and footers, and mapping them to standard structured markup. For text files without explicit structure, such as txt, a large language model is used to identify implicit headings and insert virtual structure tags. Finally, each document is converted into a uniform intermediate representation, including text block sequences, hierarchical tags, and style attributes such as font, font size, and indentation.

[0030] S2: Based on the extracted structural and semantic features, a deep learning model is used to identify format entities and the relationships between them from the preprocessed multi-source format specification data.

[0031] Specifically, S2 is entity and relation extraction. Format entities include at least layout entities, style entities, metadata entities, and functional entities. The relationships between format entities include structural relationships, attribute relationships, and logical relationships.

[0032] Specifically, S2 can be achieved through the following steps: S2.1: Obtain a joint extraction model based on a pre-trained language model, which includes a shared encoding layer, a conditional random field layer for entity recognition, and a dual affine attention layer for relation classification. S2.2: Identify format entities from preprocessed multi-source format specification data using a conditional random field layer; S2.3: Use a dual affine attention layer to identify relationships between format entities from preprocessed multi-source format specification data.

[0033] Neural network models for formatted entity and relation extraction, such as Figure 2 As shown.

[0034] In practical implementation, this invention defines four types of format entities: layout entities, such as "header," "body," "pageer's note," "attachment," and "page number"; style entities, such as "font," "font size," "line spacing," "alignment," and "color"; metadata entities, such as "document number," "security classification," "urgency level," and "copy number"; and functional entities, such as "policy objectives," "division of responsibilities," and "implementation period." These functional entities are derived from the official document functional unit tag library. Simultaneously, three types of relationships are defined: structural relationships, such as "contains," "before," "after," "in the same line," and "centered vertically"; attribute relationships, such as "font size is," "font is," and "color is"; and logical relationships, such as "based on," "corresponds to," and "example to."

[0035] A joint extraction model based on a pre-trained language model (such as RoBERTa-wwm-ext) is adopted. This model includes a shared encoding layer and two task branches: the entity recognition branch uses a conditional random field layer, and the relation classification branch uses a dual affine attention layer. The training data is generated by manually annotating the corpus, with a total of 12 entity classes and 15 relation classes annotated.

[0036] For a given text paragraph, the model outputs several triples. The training and inference process of the model can be described by the following pseudocode: start # Pseudocode for Joint Entity Recognition and Relationship Extraction def train_joint_model(train_data, valid_data): # train_data: Contains text, entity label sequences, and relation triples. model = JointModel(pretrained="roberta-wwm-ext") optimizer = AdamW(model.parameters()) for epoch in range(num_epochs): for batch in train_data: text, entity_labels, relations = batch # Forward Propagation entity_logits, relation_logits = model(text) # Calculate Entity Recognition Loss (CRF) loss_entity = crf_loss(entity_logits, entity_labels) # Calculate the relationship classification loss (binary classification cross entropy) loss_relation = bce_loss(relation_logits, relations) loss = loss_entity + loss_relation # Backpropagation loss.backward() optimizer.step() return model def extract_triples(model, text): # Input a text, output a list of triples entity_logits, relation_logits = model(text) # Decoding entity sequences (Viterbi decoding) entities = crf_decode(entity_logits) # Obtain the relation type based on entity pairs and relation logits triples = [] For head in entities: For tail in entities: rel_type = argmax(relation_logits[head, tail]) if rel_type != 'none': triples.append((head.text, rel_type, tail.text)) return triples Finish First, a joint training function, `train_joint_model`, is defined, which takes the training dataset `train_data` and the validation dataset `valid_data` as input. Each sample in the training dataset contains the original text, the corresponding entity label sequence, and a relation triplet. The main body of the model uses a joint model, `JointModel`, based on the pre-trained language model `RoBERTa-wwm-ext`. This model shares the underlying encoder and derives two task branches at the top: an entity recognition branch and a relation classification branch. The entity recognition branch uses a Conditional Random Field (CRF) layer to predict entity labels for each position in the text; the relation classification branch uses a Biaffine Attention mechanism to determine whether a predefined relation exists between any two entities.

[0037] In the training loop, for each batch of samples, forward propagation is first performed to obtain the outputs of the entity recognition branch (`entity_logits`) and the relation classification branch (`relation_logits`). The entity recognition loss (`loss_entity`) is calculated using the CRF loss function, which measures the difference between the predicted entity label sequence and the true label sequence; the relation classification loss (`loss_relation`) is calculated using the binary cross-entropy loss function, which measures the difference between the predicted relation type and the true relation. The total loss is the sum of the two losses, and the model parameters are updated using the backpropagation algorithm. The training process iterates through multiple rounds until the model converges.

[0038] During the inference phase, the `extract_triples` function is used to extract triples from the given text. The text is input into the trained model, resulting in `entity_logits` and `relation_logits`. First, Viterbi decoding is performed on `entity_logits` to obtain the optimal entity label sequence, thereby identifying all entities and their boundaries in the text. Then, all possible entity pairs (head, tail) are traversed. For each pair, the corresponding relation probability vector is extracted from `relation_logits`, and the relation type is determined by taking the maximum value (if the maximum value corresponds to "no relation", the entity pair is ignored). Finally, a list of triples for all non-empty relation types is output, with each triple consisting of the head entity text, the relation type, and the tail entity text.

[0039] The meanings of the functions, methods, and parameters involved in the model's training and inference processes are as follows: train_joint_model: The joint model training function.

[0040] train_data: The training dataset, where each sample contains the original text, entity label sequence, and relation triples.

[0041] valid_data: Validation dataset, with the same structure as train_data, used for performance monitoring during training (not used directly in this pseudocode, only for illustration).

[0042] JointModel: A custom joint model class based on the pre-trained language model robotic-wwm-ext, sharing the underlying encoder, and deriving two branches at the top: entity recognition and relationship classification.

[0043] AdamW: The optimizer used to update model parameters.

[0044] num_epochs: Number of training iterations (not explicitly defined in the pseudocode, but a preset constant).

[0045] crf_loss: The Conditional Random Field loss function takes entity_logits (of shape [batch_size, seq_len, num_entity_tags]) and the true entity label sequence entity_labels as input, and outputs a scalar loss value. This loss measures the difference between the predicted sequence and the true sequence by calculating the normalized probability of all possible label sequences.

[0046] bce_loss: Binary cross-entropy loss function, used here for relation classification. relation_logits has the shape [batch_size, num_entity_pairs, num_relation_types], where relations are the corresponding true relation labels (one-hot or index), and the loss is calculated as the relation classification error for each entity pair.

[0047] extract_triples: An inference function that extracts triples from a given text.

[0048] model: The trained joint model.

[0049] text: The text string to be processed.

[0050] crf_decode: Viterbi decoding function, takes entity_logits as input and outputs the optimal sequence of entity labels after decoding, which can then be used to extract all entities and their boundaries (each entity contains text attributes and position information).

[0051] argmax: A function that takes the index of the maximum value and is used to select the most likely relation type from the relation probability vector.

[0052] head.text and tail.text: represent the text content of the head and tail entities, respectively.

[0053] The key variables have the following meanings: `entity_logits`: The output of the entity recognition branch, in the shape [batch_size, seq_len, num_entity_tags]. Here, `seq_len` is the token length of the input text, and `num_entity_tags` is the number of entity tag categories (e.g., B-format entity, I-format entity, O, etc.). The value at each position represents the unnormalized probability (logits) of the token belonging to each entity tag.

[0054] `relation_logits`: The output of the relation classification branch, usually represented as a three-dimensional tensor with shape [batch_size, num_entity_pairs, num_relation_types]. Where num_entity_pairs is the number of all possible entity pairs in the text (usually limited to pairs between predicted entities), and num_relation_types is the number of predefined relation categories (including "no relation"). The vector corresponding to each entity pair represents the unnormalized probability that there are various relations between the pair.

[0055] The aforementioned joint extraction algorithm has the following characteristics: First, the shared encoding layer enables entity recognition and relation classification to mutually promote each other, improving extraction accuracy; second, the CRF layer can model the dependencies between labels, avoiding the occurrence of illegal label sequences; third, dual affine attention can effectively capture the interaction features between entity pairs, making it suitable for complex relation classification tasks. Through this algorithm, this invention can accurately extract formatted entities and their relations from formatted corpora, providing high-quality triple input for subsequent knowledge graph construction.

[0056] For a given text paragraph, the model outputs several triples, for example: <Document Number> <Located two lines below the issuing authority's logo> <Document Number>><Font Size>><3-point Fangsong font> <Attachment><belongs to><Main body>.

[0057] S3: Based on the identified format entities and the relationships between them, construct a graph database for storing format knowledge, forming a format knowledge graph. This includes: mapping the identified format entities to node types in the graph database, storing the entity name, attribute information, and location coordinates for each node; mapping the relationships between the identified format entities to edge types in the graph database, storing the relationship type and attribute information for each edge; and organizing the nodes and edges according to a three-layer architecture of structural layer, semantic layer, and functional layer to form a format knowledge graph. Specifically, S3 is the construction of format knowledge graphs, such as... Figure 3 As shown, this is a format knowledge graph constructed in a specific example.

[0058] The specific construction process is as follows: The four identified format entities are mapped to node types in the graph database, storing the entity name, attribute information, and location coordinates for each node; the three identified relationships are mapped to edge types in the graph database, storing the relationship type and attribute information for each edge; nodes and edges are organized according to a three-layer architecture: structure layer, semantic layer, and functional layer. Specifically, the structure layer uses format entities as nodes and structural relationships as edges to describe the physical organization of the document; the semantic layer uses metadata entities and functional entities to describe the core storage terminology definitions and applicable scenarios; and the functional layer uses functional entities as nodes and format relationships as edges to associate functional units with format templates. Cross-layer relationship connections are established to achieve collaborative calls between the structure layer, semantic layer, and functional layer.

[0059] Specifically, please see Figure 4 The format knowledge graph comprises a three-layer architecture: The structure layer uses layout entities as nodes and structural relationships as edges to describe the physical organization of a document. Layout entities include nodes such as header, body, footer, attachments, and page numbers. Structural relationships include edge types such as contain, before, after, in the same line, and vertically centered. Each node comes with attributes such as position coordinates and hierarchy number.

[0060] The semantic layer stores the definitions, synonyms, and applicable scenarios of official document terms. The semantic nodes include document type concepts (such as notices, reports, and requests for instructions), term definitions (such as the legal meaning of "announcement"), and descriptions of applicable scenarios. Each node also includes attributes such as definition text, keyword tags, and a list of synonyms.

[0061] The functional layer associates official document functional units with corresponding format templates. Functional nodes include policy objectives, division of responsibilities, implementation period, and document issuance identification functions, while format template nodes contain complete format constraints such as title style, font and size, paragraph format, and attachment layout. Functional nodes and format template nodes are connected through the "format as" relationship.

[0062] In one implementation, the method further includes: connecting the layers of the format knowledge graph through cross-layer relationships to support joint queries, wherein the cross-layer relationships include: a correspondence relationship between the structural layer and the semantic layer, used to connect the title nodes in the structural layer with the concept nodes in the semantic layer; a usage relationship between the structural layer and the functional layer, used to connect the attachment nodes in the structural layer with the attachment description function nodes in the functional layer, clarifying the functional positioning of structural elements; and a containment function relationship between the semantic layer and the functional layer, used to connect the document type nodes in the semantic layer with the function nodes in the functional layer, establishing a mapping between document types and functional units.

[0063] In practice, joint queries are implemented as follows: When executing a query for "Given document type and function, return format template," the system first matches document type nodes at the semantic layer, locates associated function nodes through the "contains function" relationship, and then obtains the corresponding format template node through the "format is" relationship of the function node. Simultaneously, it can reversely obtain the positional constraints of related layout entities in the structural layer through the "corresponds to" relationship, achieving cross-three-layer information retrieval. When executing a query for "Given format element, return constraint rule," the system directly matches layout entity nodes at the structural layer, obtains its associated child nodes and positional attributes through structural relationships, and simultaneously obtains terminology explanations through the semantic layer via the "corresponds to" relationship and function positioning through the function layer via the "used for" relationship, achieving multi-dimensional information aggregation of a single element. When executing a query for "Given text content, predict format type," the system performs similarity matching between the text semantic vector and the functional descriptions of the function layer nodes. After a successful match, it determines the applicable document type through the semantic layer via the "contains function" relationship, obtains the format template through the "format is" relationship, and locates the specific layout entity in the structural layer through the "corresponds to" relationship, achieving a complete mapping from semantics to format.

[0064] In the specific implementation process, the extracted triples are stored in graph databases such as Neo4j to construct a format knowledge graph with a three-layer architecture. The structure layer uses layout entities as nodes and structural relationships as edges to describe the physical organization of the document. For example, the node "Header" connects to child nodes such as "Issuing Authority Logo," "Document Number," and "Separator Line" through "Inclusion" relationships, and includes location coordinate attributes. The semantic layer stores the definitions, synonyms, and applicable scenarios of official document terms. For example, the "Announcement" node is associated with its definition "used to publish matters that all relevant parties in society should abide by or be aware of," and is also associated with commonly used template nodes. The functional layer associates functional units with corresponding format templates. For example, the "Policy Objectives" functional unit usually begins with the title "I. General Requirements" and uses bold, size 3 font; therefore, the functional node "Policy Objectives" connects to specific style entities through the "Format as" relationship.

[0065] The three layers are connected through cross-layer relationships. For example, the "Heading 1" node in the structural layer corresponds to the concept of "first-level heading" in the semantic layer, and may correspond to the starting marker of multiple functional units such as "policy objectives" or "division of responsibilities" in the functional layer.

[0066] Once the graph is constructed, it supports the following query capabilities: given a text type and function, return a recommended format template; given format elements, return their constraint rules (such as position and font); given text content, predict its appropriate format type. The pseudocode is as follows: start # Query: Given a document type and function, return a recommended format template. def query_template(doc_type, function): # doc_type: e.g., "notification", function: e.g., "policy objectives" cypher = """ MATCH (f: function layer {name: $function}) - [r: formatted as] -> (s: style entity) WHERE (f)-[:applies to]->(:semantic layer{name: $doc_type}) RETURN s """ result = neo4j.run(cypher, parameters={"function": function, "doc_type": doc_type}) return result # Query: Given format elements, return constraint rules def query_constraints(element): cypher = """ MATCH (e: layout entity {name: $element})-[r]->(attr) RETURN r, attr """ return neo4j.run(cypher, parameters={"element": element}) # Query: Given text content, predict its format type. def predict_format(text): # Combining semantic similarity matching function nodes # Vector retrieval or rule matching in the graph can be invoked here. Pass Finish First, given the document type and function, the query returns a recommended format template. This query aims to retrieve applicable format templates from the knowledge graph based on the user-specified document type (e.g., "notice," "request") and the functional unit of the document content (e.g., "policy objectives," "division of responsibilities"). The query function `query_template(doc_type, function)` takes two arguments and executes the Cypher graph query language. Its query logic is as follows: First, it matches the node `f` in the functional layer whose name equals the specified function, and finds the associated style entity `s` through the "format as" relationship; simultaneously, it requires that this functional node be associated with the node in the semantic layer whose name equals the specified document type through the "applies to" relationship. This query fully utilizes the three-layer architecture of the graph: the functional layer stores the mapping between functional units and format templates, the semantic layer stores the definition and applicable scenarios of document types, and joint retrieval is achieved through cross-layer relationships. The finally returned style entity `s` contains specific format descriptions (e.g., font, font size, paragraph style, etc.), which can be directly used to guide document generation.

[0067] Next, given a format element, the query returns its constraint rules. This query is used to obtain the specific constraint rules of a particular format element (such as "document number" or "attachment") in an official document. The query function `query_constraints(element)` takes a format element name as input, performs a Cypher query, and matches the layout entity node `e` and its attribute node `attr` connected by any relation `r`. Here, relation `r` can be "located in", "font", "alignment", etc., and the attribute node `attr` is the corresponding rule description (such as "two blank lines below the issuing authority's logo", "3-point Fangsong font"). This query operates directly on the structural layer, quickly obtaining all associated constraints of a specific format element, providing a basis for format validation during document generation.

[0068] Finally, given text content, predict its appropriate format type. The goal of this query is to automatically determine the appropriate format type for an official document based on the input text fragment (such as a natural language description). Although the query function `predict_format(text)` is only explained as a comment in the pseudocode, the implementation of this invention can combine semantic similarity matching or rule-based reasoning. Specifically, the semantic vector of the input text can be compared with the descriptions of functional layer nodes to match the most likely functional unit; or reasoning can be performed using predefined rules in the graph (such as keyword matching and sentence patterns) to ultimately return the corresponding format template or style entity. This query capability enables the intelligent document generator to dynamically parse implicit format requirements in user input, achieving more intelligent format adaptation.

[0069] The functions, methods, and parameters involved in the above process have the following meanings: query_template(doc_type, function): A query function used to retrieve a format template based on the document type and function.

[0070] doc_type: A string type indicating the document type, such as "notice", "report", "request for instructions", etc.

[0071] function: A string type representing a functional unit of the document content, such as "policy objectives", "division of responsibilities", "implementation period", etc.

[0072] cypher: A string variable that stores Cypher query statements.

[0073] neo4j.run(): The execution method of the Neo4j graph database, used to execute Cypher queries and return results.

[0074] parameters: Dictionary type parameters used to safely pass function arguments to Cypher queries, preventing injection attacks.

[0075] result: The result set returned by the query, containing the matching style entity nodes.

[0076] query_constraints(element): A query function used to obtain the constraint rules of a format element.

[0077] element: A string type representing the name of a format element, such as "document number", "attachment", "header", etc.

[0078] cypher: A string variable that stores the Cypher query statement, where MATCH (e: layout entity {name: $element})-[r]->(attr) means matching the layout entity node e with the name $element, and the attribute node attr connected by any relation r.

[0079] RETURN r, attr: Returns the relation r and the attribute node attr, used to obtain the type and details of the constraint rules.

[0080] result: The result set returned by the query, which includes the relation type and the corresponding attribute description.

[0081] predict_format(text): A query function used to predict the format type of a text based on its content.

[0082] text: A string type representing a text fragment or natural language description to be predicted.

[0083] The specific implementation of this function can combine semantic similarity calculation or rule matching to return the corresponding format template or style entity.

[0084] Cypher query syntax instructions MATCH: Used to match node and relationship patterns in a graph.

[0085] (f:function_layer{name: $function}): Matches nodes with the tag "function_layer" and the name attribute value of $function, and binds the node to the variable f.

[0086] - [r:format is]->: Matches relations of type "format is" and binds the relation to the variable r.

[0087] (s:style entity): Matches the node with the tag "style entity" and binds it to the variable s.

[0088] WHERE: Used to add filtering conditions. Here, it is required that the function node f has an "applies to" relationship pointing to the semantic layer node named $doc_type.

[0089] RETURN: Specifies the content returned by the query; here, it returns style entity nodes s.

[0090] $function, $doc_type, $element: Parameter placeholders in Cypher queries. Actual values ​​are passed through the parameters dictionary to prevent injection attacks and improve query security.

[0091] S4: Introduce an adaptive feedback mechanism to optimize and update the formatted knowledge graph.

[0092] Specifically, S4 is an adaptive feedback adjustment mechanism; please refer to [link to relevant documentation]. Figure 5 S4 includes: S4.1: Calculate the error rate of specific format elements in downstream generated documents; S4.2: Determine whether the error rate exceeds a preset threshold. If it does, backtrack and retrieve the relationship path corresponding to the format element in the format knowledge graph. S4.3: If ambiguity or missing information is detected in the knowledge representation, new triples are extracted from the newly added correct samples to perform relation pruning, expansion, or attribute updates on the formatted knowledge graph.

[0093] Specifically, S4.3 employs a relationship-based ambiguity detection method that is based on multi-path conflict analysis. If multiple contradictory relationships exist for the same entity pair, the path with higher confidence is retained. The confidence level is determined by a weighted average of historical usage frequency and the authority of the sample source.

[0094] In the specific implementation process, this embodiment designs a feedback adjustment algorithm based on the quality of the generated results, enabling the graph to automatically correct itself according to the performance of downstream tasks. During the generation of the official document intelligent body, when format constraints are required, rules are obtained by querying the graph and injected into the generation process. After generation, the output document undergoes a format compliance assessment, and the error rate of specific format elements (such as attachment location and document number format) is statistically analyzed based on the rule set. If the error rate of a certain element continuously exceeds a preset threshold (such as 10%), feedback adjustment is initiated, the pseudocode of which is as follows: start # Adaptive Feedback Adjustment Algorithm def adaptive_feedback(graph, generator, threshold=0.1, window=5): # graph: Current knowledge graph # generator: Document generation intelligent agent error_stats = {} # Record the error rate of each element while True: # Generate a batch of documents docs = generator.generate_batch(num=100) # Assessment format compliance for doc in docs: errors = evaluate_format(doc) # Returns a list of error elements For elem in errors: error_stats[elem] = error_stats.get(elem, []) + [1] # Sliding window statistics for elem in error_stats: recent_errors = error_stats[elem][-window:] if len(recent_errors) == window and sum(recent_errors) / window>threshold: # Trigger Feedback Adjustment revise_graph(graph, elem) def revise_graph(graph, element): # Backtrack all paths of this element paths = query_paths(graph, element) # Analyze error types: ambiguity or missing information ambiguity = detect_ambiguity(paths) if ambiguity: # Pruning: Preserve paths with high confidence prune_ambiguous_relations(graph, element) else: # Missing: Draw triples from new samples new_samples = collect_recent_correct_samples(element) triples = extract_triples_from_samples(new_samples) graph.add_triples(triples) graph.version += 1 Finish The algorithm first defines a function `adaptive_feedback`, which accepts four parameters: the current format knowledge graph (`graph`), the document generation agent (`generator`), the error rate threshold (`threshold`, default 0.1`), and the sliding window size (`window`, default 5`). The algorithm maintains a dictionary `error_stats` to record the error history of each format element. In the main loop, each iteration generates a batch of documents (e.g., 100 documents), then calls the `evaluate_format` function on each document to evaluate its format compliance, returning a list of error elements present in that document. For each error element, a flag (1 indicating an error) is appended to `error_stats`. After evaluating a batch of documents, the algorithm iterates through each element in `error_stats`, retrieving the most recent `window` record (i.e., the sliding window). If the window is full and the average error rate within the window exceeds the `threshold`, feedback adjustment is triggered, calling the `revise_graph` function to correct the element.

[0095] The `revise_graph` function takes the current graph and the element to be revised as input. First, it uses `query_paths` to backtrack and query all paths in the graph related to the element (i.e., all relation chains in which the element is a head or tail entity). Then, it uses `detect_ambiguity` to analyze these paths for ambiguity (e.g., multiple contradictory relations for the same entity pair) or knowledge gaps. If ambiguity exists, it calls `prune_ambiguous_relations` to prune, retaining paths with higher confidence and removing contradictory relations with lower confidence. If knowledge gaps exist, it calls `collect_recent_correct_samples` to collect new samples related to the element from recently generated correct documents, then uses `extract_triples_from_samples` to extract new triplets, and finally uses `add_triples` to augment the graph with the new knowledge. Regardless of whether pruning or augmentation is performed, the graph version number is incremented after completion for future tracking and rollback.

[0096] The functions, methods, and parameters involved in the above algorithm have the following meanings: adaptive_feedback: The main function for adaptive feedback adjustment.

[0097] graph: The current format knowledge graph object, containing all nodes, edges, and version information.

[0098] generator: A document generation intelligent agent object that provides the method generate_batch for generating documents.

[0099] threshold: A floating-point number representing the error rate threshold. When the error rate within the sliding window exceeds this value, feedback adjustment is triggered. The default value is 0.1.

[0100] window: Integer, the size of the sliding window used to count the number of errors for a specific element in the most recently generated document, default is 5.

[0101] error_stats: A dictionary where the key is the name of the format element (e.g., "document number") and the value is a list of error records for that element in each generation. Each element in the list is 1 to represent one error (for simplification, it can actually record 0 / 1 or the number of errors).

[0102] docs: A list that stores the paths or objects of a batch of documents generated by generator.generate_batch.

[0103] evaluate_format: A function that evaluates the format compliance of a single document and returns a list of erroneous elements (a list of strings) found in the document.

[0104] elem: String, the name of the error element.

[0105] recent_errors: A list that takes the last window element of error_stats[elem] and is used to calculate the error rate within the sliding window.

[0106] revise_graph: A function that performs graph revisions on specific features.

[0107] revise_graph: The revision function.

[0108] element: A string representing the name of the formatting element that needs to be corrected.

[0109] paths: A list of all relationship paths related to an element, returned by query_paths. Each path typically contains the head entity, relationship type, tail entity, and attribute information.

[0110] query_paths: A function that takes a graph and a feature name and returns all relational paths in which that feature participates as a head or tail entity.

[0111] `detect_ambiguity`: A function that analyzes a set of paths for ambiguity and returns a boolean value. Ambiguity is defined as the existence of multiple contradictory relations for the same entity pair (e.g., the same relation type pointing to different tail entities, or multiple conflicting relations between the same pair of entities).

[0112] `prune_ambiguous_relations`: This function performs pruning, preserving paths with high confidence and removing contradictory relationships with low confidence. Confidence levels can be determined by weighting factors such as historical usage frequency and the authority of the sample source.

[0113] collect_recent_correct_samples: This function collects new samples related to the element from recently generated correct documents and returns a list of samples (usually text fragments or structured data).

[0114] extract_triples_from_samples: This function extracts new triplets from the collected samples and returns a list of triplets, where each triplet is (head entity, relation, tail entity).

[0115] graph.add_triples: A method of the knowledge graph object used to add triplets in batches.

[0116] graph.version: The graph version number, which is incremented after each pruning or expansion for easy tracking and rollback.

[0117] The key variables have the following meanings: error_stats[elem]: A list that records whether the element elem has an error in each batch of document generation (1 indicates an error has occurred; in practice, more granular information can be recorded).

[0118] recent_errors: The last window of elements extracted from error_stats[elem], used to calculate the error rate of the most recent window of documents.

[0119] threshold: The error rate threshold that triggers feedback. For example, 0.1 means that correction will be made when the error rate exceeds 10%.

[0120] paths: The set of paths obtained from the query. Each path may contain a head entity, a relation, a tail entity, and additional attributes (such as confidence, source, etc.).

[0121] new_samples: A list of correct samples collected, used to extract new knowledge.

[0122] The aforementioned feedback mechanism utilizes reinforcement learning principles, using the generated results as environmental feedback to continuously optimize the accuracy and adaptability of knowledge representation. For example, if newly released local regulations stipulate that "no period should be added after the appendix description," but the graph still retains the old rule, an update is triggered through error rate monitoring. The relation "Appendix description <punctuation mark is> none" is extracted from the new samples and added to the graph.

[0123] In one implementation, the method further includes using the format knowledge graph to assist in the generation of downstream documents, specifically: obtaining format templates and constraints by querying the format knowledge graph, and generating Word documents that conform to the format specifications by combining Text2API technology.

[0124] Specifically, this implementation provides a concrete application of atlases in intelligent document generation.

[0125] In practice, the intelligent document generator (such as a workflow based on the Xingchen Agent platform) first analyzes the user's intent before generation, determines the document type and core functions, and then queries the graph to obtain the corresponding format templates and constraints. During the generation process, the semantic content and format instructions are integrated through Text2API technology to output a Word document that conforms to GB / T 9704-2012.

[0126] The following is an example of pseudocode being called during generation: start def generate_document(user_input): # Analyzing User Intent intent = parse_intent(user_input) # Returns the language, function, theme, etc. # Query the graph to obtain the format template template = query_template(intent.doc_type, intent.function) # Construct prompts and integrate format constraints prompt = build_prompt(intent, template) # Generate structured instruction sequences from a large model (Text2API) api_sequence = llm_generate(prompt) # Execute the API sequence to generate a Word document. doc = execute_api_sequence(api_sequence) return doc Finish The algorithm first defines a function `generate_document` that receives the user's natural language text input `user_input` as a parameter. This function contains five key steps, realizing a complete closed loop from parsing user intent to the final Word document output.

[0127] The first step is to parse the user's intention by calling the parse_intent function to perform semantic understanding on the user input. Based on natural language processing techniques, this function extracts the key elements required for official document generation from the input text, including document type (such as "notice", "request for instructions"), functional units (such as "policy objectives", "responsibility assignment"), core theme, and possible special requirements. The parsing result is returned in the form of a structured object intent, serving as the input basis for subsequent steps.

[0128] The second step is to query the knowledge graph to obtain the format template. Call the query_template function, taking the document type intent.doc_type and functional unit intent.function parsed in the previous step as parameters, and initiate a query to the format knowledge graph. Based on the three-layer graph architecture constructed in this invention, this query can accurately return the format template applicable to the current document type and functional unit, which includes complete format constraint rules such as title hierarchy, font size, paragraph style, attachment layout, etc.

[0129] The third step is to build the prompt, integrating format constraints. Call the build_prompt function to integrate the user's intention with the query-obtained format template. This function generates a structured prompt that contains both the semantic content required by the user (such as theme, key points) and format constraint instructions (such as "the first-level title uses bold and size three" and "the document number is located two lines below the issuing agency logo"). This integration ensures that subsequent large model generation can guarantee both semantic accuracy and compliance with format specifications.

[0130] The fourth step is to call the large model to generate a structured instruction sequence, namely the Text2API process. Input the constructed prompt into the large language model, and the model outputs a structured instruction sequence api_sequence that conforms to the predefined format. This sequence consists of a series of document operation primitives, such as add_heading(text="I. Policy Objectives", level=1), add_paragraph(text="...", style="body text"), set_metadata(key="document number", value="

[2025] XX No."), etc. This design transfers format control from the model to deterministic program execution, significantly improving the stability and reliability of the output.

[0131] The fifth step is to execute the API sequence to generate a Word document. This involves calling the `execute_api_sequence` function to parse and execute the structured instruction sequence line by line. This function is based on document manipulation libraries such as python-docx, creating the document, setting styles, inserting content according to the instructions, and finally generating and returning a Word document (.doc) conforming to the GB / T 9704-2012 standard.

[0132] The functions, methods, and parameters involved in the above process have the following meanings: generate_document(user_input): The main function, which implements the complete generation process from user input to a Word document.

[0133] user_input: A string type containing natural language text input by the user, such as "Write a notice about safe production in a rigorous style".

[0134] `parse_intent(user_input)`: This is the intent parsing function, which extracts key elements for document generation based on natural language processing technology. It includes: { Input: User-input text.

[0135] Output: A structured object intent, containing at least the following properties: intent.doc_type: String, document type, such as "notice", "report", "request".

[0136] intent.function: String, functional unit, such as "policy objective", "division of responsibilities", "implementation period".

[0137] intent.topic: String, the core topic.

[0138] intent.requirements: Optional, a list or dictionary that stores specific requirements made by the user (such as "include data tables").

[0139] } query_template(doc_type, function): A graph query function that retrieves a format template based on the document type and function.

[0140] doc_type: String, document type.

[0141] Function: String, functional unit.

[0142] Output: A dictionary named `template` containing formatting constraints, for example: { "Title": {"Level": 1, "Font": "Small Song", "Font Size": 14, "Alignment": "Center"},"Body Text": {"Font": "Fangsong", "Font Size": 12, "Line Spacing": 1.5}, "Attachments": {"Position": "After Body Text", "Font": "Fangsong", "Font Size": 12}} `build_prompt(intent, template)`: This function constructs the prompt word, combining user intent with a format template. It includes: { Intent: The result object of intent resolution.

[0143] Template: A dictionary of format templates.

[0144] Output The string "prompt" is a structured prompt word that contains both semantic content and formatting constraints.

[0145] } llm_generate(prompt) The large language model generation function calls the pre-trained model to output a structured instruction sequence. This includes: { prompt: string, the constructed prompt word.

[0146] Output A list `api_sequence`, where each element is a document operation primitive, for example: [ {"op": "add_heading", "text": "I. Policy Objectives","level": 1}, {"op": "add_paragraph", "text": "To improve administrative efficiency...", "style": "Main text"}, {"op": "set_metadata", "key": "Document Number", "value": "〔2026〕XX"}] } `execute_api_sequence(api_sequence)`: An API sequence execution function that converts structured instructions into a Word document. It includes: { api_sequence: A list that stores document operation primitives.

[0147] Output: doc, the generated Word document object (in practice, it can be directly saved as a file or returned as a path).

[0148] Underlying implementation: Typically based on libraries such as python-docx, it parses each instruction and calls the corresponding methods (such as add_heading, add_paragraph, set_metadata, etc.).

[0149] } The document manipulation primitives are explained below: add_heading(text, level): Adds a heading, where text is the heading text and level is the heading level (1, 2, 3, etc.).

[0150] add_paragraph(text, style): Adds a paragraph, where text is the paragraph content and style is a predefined style (such as "body text" or "attachment description").

[0151] set_metadata(key, value): Sets the document metadata, where key is the metadata field (such as "document number" or "security level") and value is the corresponding value.

[0152] Other possible primitives include add_table(rows, cols, data), add_page_break(), set_margins(top, bottom, left, right), etc., which can be extended according to actual needs.

[0153] The following example illustrates the construction of a format knowledge graph for GB / T 9704-2012: Step 101: Corpus Preprocessing Obtain the PDF of the GB / T 9704-2012 standard and use pdfplumber to extract text lines and coordinate information. Identify heading levels by analyzing font size and bolding attributes: mark text with a font size greater than 14pt and centered as H1 (e.g., "Page 7 Header"), and mark text with a font size of 12pt and left-aligned as H2 (e.g., "7.2 Document Number"). Preserve the style attributes (e.g., SimSun, size 3) for body paragraphs.

[0154] Step 102: Entity and Relation Extraction Select the section on "header" in the standard (7.2), the content of which is: "The document number is typeset two lines below the document issuing agency logo, centered. The year and the document sequence number are marked with Arabic numerals; the year should be written in full and enclosed in hexagonal brackets '〔 〕'; the document sequence number does not add the word 'No.', does not have leading zeros, and adds the word 'No.' after the Arabic numerals." Define entities: document number, document issuing agency logo, hexagonal brackets; Define relationships: The document number is two lines below the document issuing agency logo, the document number is centered, the document number contains the year and the document sequence number, and the year is enclosed in hexagonal brackets. Input the text into the joint extraction model, and output triples: (document number, located at, two lines below the document issuing agency logo), (document number, alignment method, centered), (year, enclosing symbol, hexagonal brackets), etc.

[0155] Step 103: Map storage Store the above triples in Neo4j. Create a node "document number" and add the attribute "font = 3rd typeface of imitation Song typeface" (extracted from another article). Create a relationship "located at" pointing to the node "two lines below the document issuing agency logo" (this node is used as a position description and can be further decomposed into coordinates). At the same time, associate the "document number" with the semantic layer node "document metadata" and the functional layer node "document issuing identification function".

[0156] Step 104: Feedback adjustment example Suppose in a municipal government affairs system, the system monitors and discovers that the "document number" element in the generated official documents frequently appears with format errors. Specifically, the position where the hexagonal brackets "〔〕" should be used is misused as square brackets "[]". After statistical analysis of the error rate, the error rate of this element in 5 consecutive batches of generated documents exceeds the preset threshold of 10%, and the system automatically triggers the feedback adjustment mechanism.

[0157] First, trace back and query all paths related to the "document number" in the knowledge graph, and find that the "hexagonal brackets" node only stores the name attribute, lacking specific glyph descriptions and normalization rules. This lack of knowledge representation causes the large model to be unable to accurately understand the morphological characteristics and usage scenarios of the hexagonal brackets during generation, resulting in format deviations.

[0158] Subsequently, relevant information was extracted from recently generated correct document samples to expand the knowledge base. Specific operations included: adding the attribute "unicode=3014,3015" (corresponding to the Unicode encoding of the left and right hexagonal brackets respectively) to the "hexagonal bracket" node; adding the example "〔2025〕" ​​as a reference template; and adding a new rule: "If the user enters a year without brackets, hexagonal brackets will be automatically added." After these corrections, another batch of official documents was generated. Monitoring showed that the error rate of the "document number" element decreased from 15.6% to 4.2%, lower than the expected target of 5%, verifying the effectiveness of the feedback adjustment mechanism.

[0159] Step 105: Effect Verification To comprehensively evaluate the technical effectiveness of this invention, systematic verification was conducted on a test set containing 450 official documents. The test set covers 15 document types, including notices, reports, requests, letters, and announcements, and includes 100 complex documents with attachments, covering all format elements defined in the GB / T 9704-2012 standard. A fixed-length block (512 tokens) combined with general RAG retrieval was used as a baseline method for comparison.

[0160] Experimental results show that the format knowledge graph constructed using this invention, used to assist in document generation, achieves a format compliance rate of 95.2% (based on GB / T 9704-2012 standard), an improvement of 23.4 percentage points compared to the baseline method's 71.8%. The error rates of key format elements are significantly improved: the document number format error rate decreased from 12.3% to 0%, the heading level error rate decreased from 8.7% to 0%, and the attachment position error rate decreased from 15.2% to 0%. In particular, this invention can correctly handle two valid formatting variations: attachments before the imprint and attachments after the main text. In contrast, in the baseline method, 32% of the variant documents exhibited incorrect attachment placement.

[0161] This invention transforms document format specifications into a structured knowledge graph, enabling format rules to be computable, inferable, and evolvable, significantly improving the format compliance of intelligent document generation. Its unique advantages lie in fine-grained knowledge representation, breaking down format rules into entities and relationships, supporting precise retrieval and combination, and avoiding the semantic fragmentation of RAGs; a three-layer decoupled architecture allows for hierarchical storage of structure, semantics, and function, enabling both independent querying and joint reasoning, adapting to complex and ever-changing government needs; and an adaptive evolutionary mechanism, through closed-loop adjustment of generation feedback, enables continuous optimization of the knowledge graph, keeping pace with policy updates and scenario changes, achieving a leap from a static knowledge base to a dynamic intelligent agent.

[0162] Example 2 Based on the same inventive concept, this embodiment discloses a document format knowledge representation device based on a knowledge graph, comprising: The multi-source format standard data acquisition and preprocessing module is used to acquire multi-source format standard data, preprocess the multi-source format standard data, and extract structural features and semantic features. The format entity and relation recognition module is used to identify format entities and the relationships between format entities from preprocessed multi-source format specification data based on extracted structural and semantic features and using a deep learning model. The format knowledge graph construction module is used to build a graph database for storing format knowledge based on the identified format entities and the relationships between them, forming a format knowledge graph. This includes: mapping the identified format entities to node types in the graph database, storing the entity name, attribute information, and location coordinates for each node; mapping the relationships between the identified format entities to edge types in the graph database, storing the relationship type and attribute information for each edge; and organizing the nodes and edges according to a three-layer architecture of structural layer, semantic layer, and functional layer to form the format knowledge graph. The adaptive update module is used to introduce an adaptive feedback mechanism to optimize and update the formatted knowledge graph.

[0163] Since the apparatus in Embodiment 2 of the present invention is the same apparatus used in the document format knowledge representation method based on knowledge graphs in Embodiment 1, those skilled in the art can understand the specific structure and variations of this apparatus based on the method described in Embodiment 1 of the present invention, and therefore will not be repeated here. All apparatuses used in the method of Embodiment 1 of the present invention fall within the scope of protection of this invention.

[0164] Example 3 Based on the same inventive concept, the present invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a document format knowledge representation method based on a knowledge graph, as described in Embodiment 1.

[0165] Those skilled in the art should understand that all or part of the steps in the methods of the above embodiments can be implemented by a computer program instructing related hardware (such as a personal computer, server, or network device); the computer program can be stored in a computer-readable storage medium, and when the program is executed by a processor, it can perform all or part of the steps of the methods described in the various embodiments of the present invention.

[0166] Since the computer-readable storage medium described in Embodiment 3 of this invention is the same computer-readable storage medium used in implementing the document format knowledge representation method based on knowledge graphs in Embodiment 1 of this invention, those skilled in the art can understand the specific structure and variations of this computer-readable storage medium based on the method described in Embodiment 1 of this invention, and therefore will not be repeated here. All computer-readable storage media used in the method of Embodiment 1 of this invention fall within the scope of protection of this invention.

[0167] Example 4 Based on the same inventive concept, the present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in Embodiment 1.

[0168] Since the computer device described in Embodiment 4 of this invention is the same computer device used to implement the document format knowledge representation method based on knowledge graphs in Embodiment 1 of this invention, those skilled in the art can understand the specific structure and variations of this computer device based on the method described in Embodiment 1 of this invention, and therefore will not be described again here. All computer devices used in the method of Embodiment 1 of this invention fall within the scope of protection of this invention.

[0169] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0170] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0171] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention. Clearly, those skilled in the art can make various modifications and variations to the embodiments of the invention without departing from the spirit and scope of the invention. Thus, if these modifications and variations of the embodiments of the invention fall within the scope of the claims of the invention and their equivalents, the invention also intends to include these modifications and variations.

Claims

1. A document format knowledge representation method based on knowledge graphs, characterized in that, include: Collect multi-source format standard data, preprocess the multi-source format standard data, and extract structural features and semantic features; Based on the extracted structural and semantic features, a deep learning model is used to identify format entities and the relationships between format entities from preprocessed multi-source format specification data. Based on the identified format entities and the relationships between them, a graph database for storing format knowledge is constructed, forming a format knowledge graph. This includes: mapping the identified format entities to node types in the graph database, storing the entity name, attribute information, and location coordinates for each node; mapping the relationships between the identified format entities to edge types in the graph database, storing the relationship type and attribute information for each edge; and organizing the nodes and edges according to a three-layer architecture of structural layer, semantic layer, and functional layer to form a format knowledge graph. An adaptive feedback mechanism is introduced to optimize and update the formatted knowledge graph.

2. The document format knowledge representation method based on knowledge graph as described in claim 1, characterized in that, The structural features include heading levels, paragraph numbering, font size, indentation alignment, and page layout information; the semantic features include text semantic vector representation, terminology definitions, functional descriptions, and applicable scenario information.

3. The document format knowledge representation method based on knowledge graphs as described in claim 1, characterized in that, Based on the extracted structural and semantic features, a deep learning model is used to identify format entities and the relationships between them from preprocessed multi-source format specification data, including: Obtain a joint extraction model based on a pre-trained language model, which includes a shared encoding layer, a conditional random field layer for entity recognition, and a dual affine attention layer for relation classification. Format entities are identified from preprocessed multi-source format specification data using conditional random field layers; A dual affine attention layer is used to identify relationships between format entities in preprocessed multi-source format specification data.

4. The document format knowledge representation method based on knowledge graph as described in claim 1, characterized in that, The structure layer uses layout entities as nodes and structural relationships as edges to describe the physical organization of the document. The semantic layer stores the definitions, synonyms, and applicable scenarios of official document terms. The functional layer associates the functional units of the official document with the corresponding format templates.

5. The document format knowledge representation method based on knowledge graph as described in claim 1, characterized in that, The method further includes: connecting the layers of the format knowledge graph through cross-layer relationships to support joint queries, wherein the cross-layer relationships include: a correspondence relationship between the structural layer and the semantic layer, used to connect the title nodes in the structural layer with the concept nodes in the semantic layer; a usage relationship between the structural layer and the functional layer, used to connect the attachment nodes in the structural layer with the attachment description functional nodes in the functional layer, clarifying the functional positioning of structural elements; and a containment functional relationship between the semantic layer and the functional layer, used to connect the document type nodes in the semantic layer with the functional nodes in the functional layer, establishing a mapping between document types and functional units.

6. The document format knowledge representation method based on knowledge graph as described in claim 1, characterized in that, The method also includes using the format knowledge graph to assist in the generation of downstream documents, specifically: obtaining format templates and constraints by querying the format knowledge graph, and generating Word documents that conform to the format specifications by combining Text2API technology.

7. The document format knowledge representation method based on knowledge graph as described in claim 1, characterized in that, An adaptive feedback mechanism is introduced to optimize and update the formatted knowledge graph, including: Statistical analysis of the error rate of specific format elements in downstream generated documents; Determine whether the error rate exceeds a preset threshold. If it does, backtrack and retrieve the relationship path corresponding to the format element in the format knowledge graph. If ambiguity or missing information is detected in the knowledge representation, new triples are extracted from the newly added correct samples, and the formatted knowledge graph is pruned, expanded, or its attributes are updated.

8. A document format knowledge representation device based on knowledge graphs, characterized in that, include: The multi-source format standard data acquisition and preprocessing module is used to acquire multi-source format standard data, preprocess the multi-source format standard data, and extract structural features and semantic features. The format entity and relation recognition module is used to identify format entities and the relationships between format entities from preprocessed multi-source format specification data based on extracted structural and semantic features and using a deep learning model. The format knowledge graph construction module is used to build a graph database for storing format knowledge based on the identified format entities and the relationships between them, forming a format knowledge graph. This includes: mapping the identified format entities to node types in the graph database, storing the entity name, attribute information, and location coordinates for each node; mapping the relationships between the identified format entities to edge types in the graph database, storing the relationship type and attribute information for each edge; and organizing the nodes and edges according to a three-layer architecture of structural layer, semantic layer, and functional layer to form the format knowledge graph. The adaptive update module is used to introduce an adaptive feedback mechanism to optimize and update the formatted knowledge graph.

9. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the document format knowledge representation method based on a knowledge graph as described in any one of claims 1 to 7.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the document format knowledge representation method based on knowledge graph as described in any one of claims 1 to 7.

Images