Knowledge graph construction method and device, and electronic device

Abstract

This application provides a method, apparatus, and electronic device for constructing a knowledge graph. It includes: integrating multimodal elements of standard regulatory documents to obtain a document object model data file; splitting the document object model data file to obtain a list of clause unit objects; extracting information from the list of clause unit objects based on a target graph pattern to obtain structured triple data; and constructing a two-level knowledge graph based on the document object model data file, the list of clause unit objects, and the structured triple data. The first level of the knowledge graph consists of metadata and a document relationship graph, used for macro-level positioning, version management, and impact scope analysis of standard regulatory documents. The second level of the knowledge graph is a fine-grained technical knowledge graph, including: topic communities, fragment layers, and triple instance data. This application can accurately express the relationships between regulatory, standard, and technical elements, providing convenient semantic queries, impact transmission, and intelligent decision-making.

Description

Technical Field

[0001] This application relates to the field of knowledge graph construction technology, and in particular to a knowledge graph construction method, apparatus and electronic device. Background Technology

[0002] Building an accurate and dynamically evolving regulatory / standards knowledge system is crucial for automotive product compliance and overseas expansion. Currently, the construction of such a system still relies on manual interpretation, information extraction, and correlation analysis of numerous multi-source regulatory / standard documents. This traditional workflow is severely mismatched with the pace of automotive product iteration and the frequency of regulatory / standard changes. Furthermore, it heavily depends on the personal experience of experts, making it prone to errors and omissions, and failing to achieve deep connections and understanding between regulations and standards. Summary of the Invention

[0003] This application provides a knowledge graph construction method, apparatus, and electronic device, which aim to construct a fine-grained knowledge graph to accurately express the relationship between regulations, standards, and technical elements, and provide convenient semantic query, influence transmission, and intelligent decision-making.

[0004] In a first aspect, embodiments of this application provide a knowledge graph construction method, including: The multimodal elements of the identified standard regulatory documents in the target domain are integrated to obtain a document object model data file; The document object model data file is split into clause-level semantic units to obtain a list of clause unit objects; Information is extracted from the list of clause unit objects based on a predefined target graph pattern to obtain structured triplet data. Based on the document object model data file, the list of clause unit objects, and the structured triplet data, a two-level knowledge graph is constructed. The first level of the knowledge graph is a metadata and document relationship graph, used for macro-level positioning, version management, and impact scope analysis of standard and regulatory documents. The second level of the knowledge graph is a fine-grained technical knowledge graph, including: topic communities, fragment layers, and triplet instance data. The triplet instance data includes: entity nodes and the relationships between them. The fragment layer includes: nodes corresponding to all clause unit objects. The topic community includes: virtual grouping nodes generated by clustering entity nodes and their relationships in the second level.

[0005] This application embodiment obtains a document object model data file by integrating multimodal elements of standard regulatory documents, obtains a list of clause unit objects by splitting clause-level semantic units, and then extracts structured triple data based on a predefined target graph pattern. Finally, it constructs a two-layer knowledge graph containing macro-level document relationships and fine-grained technical elements. The fine-grained technical knowledge graph accurately associates regulations, standards and technical elements through a hierarchical design of topic communities, fragment layers and triple instance data. Relying on this graph, convenient semantic queries, influence transmission and intelligent decision-making are realized, thereby providing a solid knowledge foundation for the compliance and standard construction of car companies.

[0006] Secondly, embodiments of this application provide a knowledge graph construction apparatus, including: The document acquisition module is used to integrate the multimodal elements of the identified standard regulatory documents in the target domain to obtain a document object model data file. The list acquisition module is used to perform clause-level semantic unit splitting on the document object model data file to obtain a list of clause unit objects. The data acquisition module is used to extract information from the list of clause unit objects based on a predefined target graph pattern to obtain structured triplet data. The knowledge graph construction module is used to construct a two-level knowledge graph based on the document object model data file, the list of clause unit objects, and the structured triplet data. The first level of the knowledge graph is a metadata and document relationship graph, used for macro-level positioning, version management, and impact scope analysis of standard and regulatory documents. The second level of the knowledge graph is a fine-grained technical knowledge graph, including: topic communities, fragment layers, and triplet instance data. The triplet instance data includes: entity nodes and the relationships between them. The fragment layer includes: nodes corresponding to all clause unit objects. The topic community includes: virtual grouping nodes generated by clustering entity nodes and their relationships in the second level.

[0007] This application embodiment obtains a document object model data file by integrating multimodal elements of standard regulatory documents, obtains a list of clause unit objects by splitting clause-level semantic units, and then extracts structured triple data based on a predefined target graph pattern. Finally, it constructs a two-layer knowledge graph containing macro-level document relationships and fine-grained technical elements. The fine-grained technical knowledge graph accurately associates regulations, standards and technical elements through the hierarchical design of topic communities, fragment layers and triple instance data. Based on this graph, convenient semantic query, influence transmission and intelligent decision-making can be achieved.

[0008] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory, wherein, Memory, used to store computer programs; A processor is used to execute programs stored in memory to implement the knowledge graph construction method described in the first aspect above.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the knowledge graph construction method described in the first aspect. Attached Figure Description

[0010] Figure 1 A flowchart illustrating the steps of a knowledge graph construction method provided in this application embodiment; Figure 2 A schematic diagram illustrating the overall system architecture and data processing flow provided in an embodiment of this application; Figure 3 A schematic diagram of a two-layer coupled knowledge graph provided in an embodiment of this application; Figure 4 A flowchart illustrating dynamic schema evolution and human-machine collaboration is provided as an embodiment of this application. Figure 5 A schematic diagram of the structure of a knowledge graph construction device provided in an embodiment of this application; Figure 6 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0011] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0012] Reference Figure 1 The diagram illustrates a flowchart of the steps involved in constructing a knowledge graph according to an embodiment of this application. Figure 1 As shown, the knowledge graph construction method may include steps 110 to 140.

[0013] Step 110: Integrate the multimodal elements of the identified standard regulatory documents in the target domain to obtain a document object model data file.

[0014] In this embodiment, the target domain can be, but is not limited to, the vehicle domain.

[0015] Taking the vehicle sector as an example, standard regulatory documents refer to the regulations, national standards, industry standards, and enterprise standards related to car manufacturers. These documents can be in various formats, including PDF (editable / scanned), DOCX, and images. The content covers technical requirements and management regulations related to power battery safety, vehicle emissions, and crash testing.

[0016] Multimodal elements refer to the various types of information elements contained in standard regulatory documents. They are mainly divided into text elements (the main text of regulatory clauses, titles, notes, etc.) and non-text elements (tables, formulas, diagrams, etc.), which together constitute the complete information of the document.

[0017] Document Object Model (DOM) data files refer to data files in a unified format (such as JSON format) formed by structuring and integrating the multimodal elements of standard regulatory documents. They contain text elements, non-text elements, their reference relationships, and document metadata, which facilitates subsequent splitting and extraction processing.

[0018] When constructing a knowledge graph for a target domain (taking the vehicle domain as an example), one can... The system retrieves standard regulatory documents from the target field (automotive companies) through automatic retrieval (connecting to automotive KMS systems and national standard databases) or manual upload. It identifies document formats (PDF, DOCX, images, etc.) and performs preliminary verification (format compliance, deduplication). Multimodal element extraction: It extracts text elements (body text, titles, annotations, etc.) from the documents; performs layout analysis, cropping to obtain image slices; and identifies non-text elements (tables, formulas, diagrams) using a large visual language model, recording the position and type information of each element. Element association establishment: Through spatial location comparison (adjacent / contained text and non-text elements) and explicit text references (such as "see Table 1 for details"), it establishes reference associations between text and non-text elements and records these associations. Data integration and storage: It integrates text elements, non-text elements, reference association information, and document metadata (document number, issuing agency, implementation date, etc.) and stores them in a unified format (such as JSON) to form a document object model data file. This implementation process will be described in detail in the following embodiments, and will not be repeated here.

[0019] Step 120: Perform clause-level semantic unit splitting on the document object model data file to obtain a list of clause unit objects.

[0020] Clause-level semantic decomposition refers to breaking down the legal content in a document object model data file into independent, individually processable smallest semantic units (clause units) according to the semantic integrity of the clauses, ensuring that each unit corresponds to a complete legal meaning.

[0021] The list of clause unit objects is a collection obtained after breaking down clause-level semantic units. Each list item is a clause unit object, which contains at least the legal text element, reference association information, original hierarchical path information, location reference information, document type, and metadata.

[0022] After obtaining the document object model data file, file structure information (hierarchy, headings, paragraph divisions) can be extracted to clarify the clause hierarchy of the standard regulatory document (such as chapters, clauses, sub-clauses). Using a large language model combined with set prompt words, and based on the document structure information, preliminary segmentation of the regulatory text elements and citation associations in the document is performed to obtain a candidate segment list. Multi-round iterative segmentation: A label-based multi-round iterative segmentation algorithm is used to mark candidate segments as pending processing. The semantic completeness of each segment is judged by the large language model, and segments are merged or split according to adjustment suggestions, updating the label status. Finally, after determining that the iteration has reached the convergence condition, the iteration is terminated, and each final complete semantic unit (clause) is encapsulated as a clause unit object (i.e., a ClauseUnit object), and a list of clause unit objects is formed. This implementation process will be described in detail in the following embodiments, and will not be repeated here.

[0023] Step 130: Extract information from the list of clause unit objects based on a predefined target graph pattern to obtain structured triplet data.

[0024] The target graph schema is a pre-defined knowledge graph structure specification that clarifies the entity types, relation types, and attribute types that the graph must contain. It is used to constrain the information extraction process and ensure that the extracted triple data meets the graph construction requirements.

[0025] Structured triple data is structured data presented in the form of (head entity, relation, tail entity) or (entity, attribute, value). It is the core data of knowledge graphs and accurately reflects the relationships between entities and the attributes of the entities themselves.

[0026] After obtaining the list of clause unit objects, the currently used graph schema can be determined. If a latest version exists, it is designated as the target graph schema (i.e., Schema). Otherwise, a predefined minimum core graph schema (with clearly defined entity, relation, and attribute types) is adopted. Using a large language model combined with set prompt words, triples conforming to the graph schema are extracted from the list of clause unit objects. Simultaneously, undefined candidate elements (candidate entities, candidate relations, and candidate attributes) in the graph schema are recorded. Then, candidate entities are matched and linked to achieve entity disambiguation, resulting in disambiguated candidate entities. Candidate relations and attributes are then subjected to type adaptation and constraint validation to achieve relation and attribute disambiguation, resulting in disambiguated candidate relations and candidate attributes. Triple integration: The initially extracted triples are integrated with the triples corresponding to the disambiguated candidate elements, and invalid data is removed to obtain structured triple data. This implementation process will be described in detail in the following embodiments, and will not be repeated here.

[0027] Step 140: Based on the document object model data file, the list of clause unit objects, and the structured triple data, a two-level knowledge graph is constructed. The first level of the knowledge graph is a metadata and document relationship graph, used for macro-level positioning, version management, and impact scope analysis of standard regulatory documents. The second level of the knowledge graph is a fine-grained technical knowledge graph, including: topic communities, fragment layers, and triple instance data. The triple instance data includes: entity nodes and the relationships between them. The fragment layer includes: nodes corresponding to all clause unit objects. The topic community includes: virtual grouping nodes generated by clustering entity nodes and their relationships in the second level.

[0028] Metadata and document relationship graph (first level) is the macro level of the knowledge graph. The nodes are mainly legal / standard documents, the attributes are the basic information of the documents, and the relationships are the hierarchical and time-related associations between documents. It is used to realize the macro management and positioning of standard and legal documents.

[0029] The fine-grained technical knowledge graph (second level) is a micro-level of the knowledge graph, which includes three layers: topic communities, fragment layers, and triple instance data. It focuses on the relationship between legal provisions and technical elements, and accurately reflects technical details.

[0030] Thematic communities are virtual grouping nodes generated by clustering entity nodes and their relationships in the second level. Each node corresponds to a technical topic (such as "battery safety"), which is used to achieve the classification and management of technical elements.

[0031] The fragment layer is the middle layer of the fine-grained technical knowledge graph. The nodes are the nodes corresponding to all clause unit objects. Each node is bound to a clause unit object and is used to associate triple data with the original legal clauses.

[0032] Triple instance data is the core data layer of fine-grained technical knowledge graph, containing entity nodes (such as technical terms, performance indicators, etc.) and the relationships between entity nodes, which is a direct manifestation of the relationship between technical elements.

[0033] Entity nodes are the basic nodes in the fine-grained technology knowledge graph, representing specific technical elements related to automotive regulations, such as "power battery energy density" and "side impact test".

[0034] After obtaining the Document Object Model (DOM) data file, the list of clause unit objects, and the structured triplet data through the above steps, a two-level knowledge graph can be constructed based on these data. Specifically, the first level (metadata and document relationship graph) is constructed as follows: Based on the metadata in the DOM data file, regulatory / standard document nodes are built, and node attributes (document number, issuing agency, implementation date, etc.) are set; relationships (substitution, citation, etc.) are established between document nodes, forming the metadata and document relationship graph. The second level (fine-grained technical knowledge graph) is constructed based on the list of clause unit objects and the structured triplet data, constructing three layers sequentially: ① Triplet instance data layer, where entity nodes and their relationships are entered; ② Fragment layer, where nodes corresponding one-to-one with clause unit objects are constructed, linking the triplet data with the original clauses; ③ Topic community layer, where entity nodes and their relationships are clustered using a clustering algorithm, generating virtual grouping nodes and adding topic tags. Two-layer knowledge graph association: A bidirectional association is established between first-level document nodes and second-level clause nodes to ensure the linkage between macro-level documents and micro-level technical elements, thus completing the overall construction of the two-layer knowledge graph. The knowledge graph construction process will be described in detail in the following embodiments, and will not be repeated here.

[0035] This application embodiment obtains a document object model data file by integrating multimodal elements of standard regulatory documents, obtains a list of clause unit objects by splitting clause-level semantic units, and then extracts structured triple data based on a predefined target graph pattern. Finally, it constructs a two-layer knowledge graph containing macro-level document relationships and fine-grained technical elements. The fine-grained technical knowledge graph accurately associates regulations, standards and technical elements through a hierarchical design of topic communities, fragment layers and triple instance data. Relying on this graph, convenient semantic queries, influence transmission and intelligent decision-making are realized, thereby providing a solid knowledge foundation for the compliance and standard construction of car companies.

[0036] In one implementation of this application, step 110 may include sub-steps A1 to A5.

[0037] Sub-step A1: Obtain the standard regulatory documents for the target field.

[0038] In this embodiment, when constructing a knowledge graph for a target domain, standard regulatory documents for that target domain can be obtained. Taking the vehicle domain as an example, regulatory / standard documents can be automatically obtained or manually entered by connecting to a KMS (Knowledge Management System), a standard database, or a specified URL. Supported formats include PDF, DOCX, and images (JPG, PNG).

[0039] Sub-step A2: Extract the regulatory text elements from the standard regulatory document and perform layout analysis on the standard regulatory document to obtain the layout analysis results.

[0040] Page layout analysis results refer to the results obtained after dividing the standard regulatory document into pages. They include the bounding box coordinates (i.e., block position), block size, preliminary type determination (text block / non-text block), and page number of each information block in the document, providing a positional basis for subsequent image cropping.

[0041] After obtaining the standard regulatory documents, the regulatory text elements can be extracted, and layout analysis can be performed to obtain the results. Specifically, corresponding parsing tools can be used to extract the regulatory text elements from the standard regulatory documents. For editable PDF and DOCX documents, the text content and font style information can be directly extracted. For scanned PDF and image documents, the text content and character coordinates can be recognized using an OCR (Optical Character Recognition) engine. Subsequently, the layout analysis tool is used to divide each page of the document into blocks, identify the bounding box coordinates and block size of each block, preliminarily determine whether the block type is a text block or a non-text block, and record the page number of each block. All information is then integrated to form a complete layout analysis result.

[0042] Sub-step A3: Based on the layout analysis results, crop the standard regulatory document to obtain image slices.

[0043] Image slicing refers to the precise cropping of standard regulatory document images (PDF pages converted to images, image format documents) based on layout analysis results, resulting in independent image fragments corresponding to each information block, which are used by visual language large models to recognize non-text elements.

[0044] After obtaining the layout analysis results, the standard regulatory document can be cropped to obtain image slices. Specifically, the bounding box coordinates of each information block (including text blocks and non-text blocks) can be extracted based on the layout analysis results. These coordinates are then used as the basis for precise cropping of the standard regulatory document image. Each page of the PDF document is first converted to image format, while the original image is used directly for image format documents. Based on the bounding box coordinates of each block, independent image segments corresponding to each block are cropped, which are the image slices. Each image slice is bound to the layout analysis information (block type, page number) of the corresponding block for easy subsequent identification.

[0045] Sub-step A4: Using a visual language big data model, perform element recognition on the image slices based on the set prompt words to obtain non-text elements, and establish reference association information between the regulatory text elements and the non-text elements.

[0046] Setting prompts can be standardized instructions that guide the visual language model to accurately recognize non-text elements, clarifying the recognition task, constraints and output format, and ensuring that the recognition results meet the requirements.

[0047] After obtaining the image slices, all image slices and corresponding layout analysis information can be batch-input into the visual language model, along with predefined prompts. These prompts explicitly require the model to recognize only non-text elements (tables, formulas, and diagrams) and output the element type, page number, and bounding box coordinates. After the model completes recognition, it filters out all non-text elements and records their relevant information. Subsequently, two methods are used to establish reference associations between text and non-text elements: First, based on spatial location comparison, it determines whether text blocks and non-text elements are adjacent or contain each other; if the conditions are met, an association is established. Second, based on explicit text references, it identifies expressions such as "see Table X" and "as shown in Figure X" in the text, matches them with corresponding non-text elements, establishes associations, and integrates all association information to form reference association information.

[0048] Sub-step A5: Store the regulatory text elements, the non-text elements, and the reference association information as a document object model data file in a specified format.

[0049] The specified format refers to the predefined storage format of the document object model data file (such as JSON format), which is used to uniformly integrate and store regulatory text elements, non-text elements, and reference information to ensure that the data structure is standardized and can be reused later.

[0050] After obtaining the text elements, non-text elements, and reference association information of the regulations, the extracted text elements, the identified non-text elements, and the established reference association information can be integrated. At the same time, the basic metadata of the document (such as document number, issuing agency, etc.) can be supplemented and the data can be structured according to a pre-defined specified format (such as JSON format). The storage fields and levels of each data are clearly defined to ensure that the text elements, non-text elements, and reference association information correspond one-to-one and are traceable. Finally, a document object model data file is generated for subsequent processes such as clause splitting and information extraction.

[0051] In practical applications, for the identified non-textual multimodal elements, the corresponding dedicated parsing tools are called for processing and semantic enhancement, and structured data is output.

[0052] Tables: Use table recognition components (such as Tabula-py, Camelot) to convert tables and headers into structured JSON objects, preserving headers, row and column merging information, table header hierarchy semantics, and data within each cell.

[0053] Formulas: While using tools such as LaTeX-OCR to identify the structure and symbols of formulas, VLM is used to generate relevant natural language descriptions.

[0054] Image: While using a visual feature extraction model to obtain feature vectors, VLM is used to generate relevant natural language descriptions.

[0055] Non-text multimodal elements (tables, formulas, images) will be assigned globally unique identifiers (non_text_refs), such as table ID format table_001, formula ID format formula_001, and image ID format figure_001. The page number and bounding box coordinates of the non-text multimodal element in the document will also be recorded.

[0056] Then, using the parsed results of non-text multimodal elements as input, the text is stored while simultaneously associating it with the multimodal information through a list of non-text element IDs linked by `non_text_refs`. This association is then stored as a uniformly formatted Enhanced Document Object Model (EDOM) file. The establishment of these associations is based on, but is not limited to, spatial location (using the coordinates of the text blocks extracted in S121 and the coordinates of the non-text elements recorded in S122 to determine whether they are adjacent or contained on the page) and explicit text references. The EDOM file is stored as a JSON object and contains three core modules: document metadata, structure info, and non-text elements.

[0057] Document metadata describes the macro-level attributes of a document, specifically including: doc_id: A unique identifier for a document (such as a standard number or regulatory document number), a string type, such as "GB-2023-12345".

[0058] doc_type: Document type, an enumeration value (regulations / national standards / industry standards / enterprise standards), such as "national standards".

[0059] Issuing organization: The organization that created / issued the document, a string, e.g., "Ministry of Industry and Information Technology".

[0060] Release Date: The date the document was released, in YYYY-MM-DD format, such as "2023-05-10".

[0061] Implementation Date: The effective date of the document, in the format YYYY-MM-DD, such as "2024-07-01".

[0062] Replacement standard: The identifier of the old document being replaced (leave blank if none), a string, such as "GB-2018-xxxx".

[0063] Coverage: The region, industry, and product category to which the document applies, in the form of a string such as "Nationwide / Automotive Manufacturing / Power Batteries".

[0064] Structural information is used to store coarse-grained logical blocks of a document, specifically including: block_id: A unique identifier for the block (e.g., b_3_2_1, corresponding to "Chapter 3 / 3.2 / 3.2.1"), a string.

[0065] type: Block type, enumeration values ​​(heading-level 1 / heading-level 2 / clause / section / item / table / formula / image / appendix), string.

[0066] level_path: Hierarchical path (reflecting the document directory structure), a string, such as: "Chapter 3 / 3.2 / 3.2.1".

[0067] content: The text content of the block (null for non-text blocks), a string.

[0068] coordinates: The position of the block in the original document, including: page: page number (an integer starting from 1); bbox: bounding box coordinates [x1, y1, x2, y2] (top left x1, y1, bottom right x2, y2, unit: pixels), an array.

[0069] parent_id: Parent block ID (null for the root block), string.

[0070] children_ids: An array of child block IDs (fill in the blanks if there are no child blocks).

[0071] non_text_refs: A list of associated non-text element IDs (an empty array without associated elements), including three subarrays: tables, formulas, and figures, which record the IDs of the referenced tables, formulas, and figures, respectively. If there are no associated elements, the array is filled with empty elements.

[0072] Non-text elements are used to store structured data and semantic descriptions of multimodal elements such as tables, formulas, and images, specifically including: Table (table_{id}): includes type: a fixed value "table"; page: page number (starting from 1), an integer; bbox: bounding box coordinates [x1, y1, x2, y2] (top left x1, y1, bottom right x2, y2, unit: pixels), an array; data: table structured data (row and column indices, header, cell values), a JSON object (e.g., {"rows":5,"cols":3,"header":["working conditions","weight coefficients","test duration"],"cells":[["urban area","0.4","30min"],...]}); description: a semantic description of the table generated by VLM, a string, such as: "Battery life test weight coefficient table under different cyclic working conditions".

[0073] The formula (formula_{id}) includes: type: a fixed value "formula"; page: an integer page number (starting from 1); bbox: bounding box coordinates [x1, y1, x2, y2] (top left x1, y1, bottom right x2, y2, unit: pixels), an array; latex: formula symbols recognized by LaTeX-OCR, a string, such as: "E\geq200\text{Wh / kg}"; description: a natural language description of the formula (generated by VLM), a string, such as: "The formula requires the battery energy density E to be no less than 200 Wh per kilogram".

[0074] The image (figure_{id}) includes: type: a fixed value "figure"; page: an integer page number (starting from 1); bbox: bounding box coordinates [x1, y1, x2, y2] (top left x1, y1, bottom right x2, y2, unit: pixels), an array; embedding: image feature vector extracted by CLIP (a floating-point array), such as: [0.12, -0.08, ..., 0.35]; description: a semantic description of the image generated by VLM, a string, such as: "The figure shows the dummy arrangement and measurement point positions in the side impact test of an electric vehicle".

[0075] This application systematically acquires standard and regulatory documents in the target domain, accurately extracts textual and non-textual multimodal elements, and combines layout analysis and visual recognition technology to achieve accurate element identification. It establishes reference relationships between elements and integrates them into a document object model data file according to a standardized format. This effectively solves the problems of scattered and unclear relationships of multimodal information in standard and regulatory documents, and realizes the structured and standardized storage of multimodal information. It provides a standardized and high-quality data foundation for subsequent clause-level splitting, knowledge extraction, and knowledge graph construction, and improves the efficiency and accuracy of the entire knowledge graph construction process.

[0076] In one implementation of this application, step 120 may include sub-step B1 and sub-step B2.

[0077] Sub-step B1: Using the large language model, based on the set prompt words and the file structure information of the document object model data file, segment the regulatory text elements and reference association information in the document object model data file to obtain a candidate fragment list.

[0078] In this embodiment, file structure information refers to the structured information contained in the document object model data file, such as document hierarchy, heading division, paragraph distribution, and clause numbering rules. This information is used to clarify the overall organizational logic of standard and regulatory documents and to provide a basis for text segmentation.

[0079] The candidate fragment list is a collection of fragments obtained after initial segmentation by a large language model. Each fragment is a combination of legal text elements and corresponding reference information. It has not undergone semantic integrity verification and is only used as the basic material for subsequent iterative segmentation.

[0080] After obtaining the Document Object Model (DOM) data file, file structure information can be extracted from it to clarify the core logic of the document, such as hierarchical division, clause numbering rules, and paragraph distribution. Simultaneously, pre-defined prompts are retrieved (clearly defining segmentation requirements: according to the logic of legal clauses and the principle of complete related citations, the text is segmented synchronously with its corresponding citation associations to ensure that each segment contains complete citation associations). Subsequently, the legal text elements and citation association information from the DOM data file, along with the extracted file structure information and the set prompts, are input into the large language model. The model, combining the file structure logic and prompt requirements, performs preliminary segmentation of the text and citation association information—binding continuous and semantically closely related text with corresponding non-textual citation associations to divide them into independent segments. All initially segmented segments are then aggregated to form a candidate segment list, with each segment associated with corresponding citation association information and preliminary positional information. The large model is fed prompts, including EDOM files, as input. The large model, considering the EDOM file structure (such as type, e.g., "clause"), level_path, punctuation, and normative keywords, performs preliminary segmentation of the text and multimodal references within the EDOM file to obtain candidate fragments, and then compiles these into a list of candidate fragments. These candidate fragments constitute the initial form of the ClauseUnit.

[0081] Sub-step B2: The candidate fragment list is processed using a tag-based multi-round iterative partitioning algorithm to obtain the clause unit object list; wherein each clause unit object in the clause unit object list includes at least: regulatory text element, reference association information, original hierarchical path information, location reference information, document type, and metadata.

[0082] The tag-based multi-round iterative partitioning algorithm is an algorithm used to verify and optimize the semantic integrity of fragments. By tagging the fragments, judging their semantics, and adjusting and reconstructing them, it goes through multiple rounds of iteration until the convergence condition is met, and finally obtains semantically complete clause units.

[0083] The original hierarchical path information is the hierarchical position information of the regulatory text corresponding to the clause unit object in the original standard regulatory document, such as "Chapter 3 → Article 3.1 → Sub-clause 3.1.1", which is used to trace the original attribution of the clause.

[0084] Location reference information refers to the specific location information of the text and non-text elements associated with the clause unit object in the original standard and regulatory document, including page numbers, bounding box coordinates, etc., which is used to accurately locate the original information.

[0085] After obtaining the candidate fragment list, it can be initialized by marking each fragment as "pending processing," and recording the file structure, reference associations, and initial location information for each fragment. Next, a multi-round iterative process is initiated: In the first iteration, each candidate fragment in the pending processing state and its context fragments (adjacent fragments) are input into the large language model. The model determines the semantic completeness of the fragment and outputs its completeness status (complete / incomplete) and adjustment suggestions (merge / split). Based on the adjustment suggestions, the candidate fragment list is reconstructed. Fragments that need merging (semantically incomplete, requiring supplementation with adjacent fragments) are merged, and fragments that need splitting (containing multiple independent semantics) are split. Processed fragments are marked as "processed," while unprocessed fragments remain marked as "pending processing." Subsequently, the candidate fragment lists before and after reconstruction are compared to determine if the convergence condition is met (segments are semantically complete, with no fragments requiring further adjustment). If not, the above iterative steps are repeated until the preset number of iterations is reached or the convergence condition is met. Finally, the iteration is terminated, and each semantically complete fragment obtained is encapsulated as a clause unit object. Each object contains regulatory text elements, reference association information, original hierarchical path information, location reference information, document type, and metadata. All clause unit objects are summarized to form a list of clause unit objects. This implementation process will be described in detail in the following embodiments, and will not be repeated here.

[0086] This application combines document structure information and set prompt words to achieve accurate initial segmentation of legal text and citation association information using a large language model. Then, a tag-based multi-round iterative segmentation algorithm is used to verify the semantic integrity of the fragments and optimize the fragment structure, ultimately obtaining a standardized list of clause unit objects. This effectively solves the problems of inaccurate segmentation of legal text, incomplete semantics, and broken citation associations, and realizes the standardized splitting of clause-level semantic units. It provides semantically complete, structurally standardized, and traceable basic data for subsequent information extraction and knowledge graph construction, improving the efficiency and accuracy of subsequent processes.

[0087] In one implementation of this application, the above sub-step B2 may include: sub-steps C1 to C4.

[0088] Sub-step C1: Mark the status of all candidate segments in the candidate segment list as pending processing.

[0089] In this embodiment, the pending state refers to the initial labeling state of the candidate segment, which is used to indicate that the candidate segment has not yet undergone semantic integrity judgment and adjustment processing, and is the initial state of multi-round iterative partitioning.

[0090] After obtaining the candidate segment list, the initially segmented candidate segment list can be initialized by iterating through each candidate segment in the list and adding a status flag field to each segment, uniformly marking the status of all candidate segments as "pending processing". At the same time, each candidate segment in the pending processing state is bound to its corresponding basic information, including the segment's own text content, reference association information, original hierarchical path information, and position reference information, to facilitate subsequent integrity judgment and adjustment processing, and to ensure that the status of each candidate segment is traceable and updatable.

[0091] In practical applications, the generated candidate fragment list can be used as the current candidate fragment list List_curr, and the status of each fragment can be set to "pending processing".

[0092] Sub-step C2: Input each candidate segment in the pending state into the large language model, and use the large language model to perform integrity judgment on each candidate segment based on the context information of each candidate segment, and output the integrity status and adjustment suggestion information of each candidate segment.

[0093] Contextual information refers to the adjacent fragments (preceding fragments and subsequent fragments) of a single candidate fragment in the candidate fragment list, as well as the hierarchical information of the original standard and regulatory document corresponding to the fragment and the reference association information, which are used to help determine the semantic integrity of the fragment.

[0094] The completeness state refers to the result output by the large language model after performing semantic judgment on the candidate segment. It is used to identify whether the segment has a complete semantic meaning and is divided into two states: "semantic complete" and "semantic incomplete".

[0095] Adjustment suggestions are suggestions output by the large language model to optimize the semantic integrity of candidate segments by combining the integrity status and contextual information. They mainly include two types: "merging" (merging with adjacent segments to supplement semantics) and "splitting" (splitting a single segment into multiple independent semantic segments).

[0096] The candidate segment list is traversed, and all candidate segments with the status "pending processing" are selected. Each candidate segment to be processed is then input into the large language model. During input, the contextual information of the candidate segment (adjacent candidate segments, original hierarchical information, and reference association information) is simultaneously passed in, along with preset prompts. These prompts explicitly require the large language model to combine the contextual information to determine whether the candidate segment possesses complete semantic meaning, and to output two results: one is the completeness status (semantically complete / semantically incomplete), and the other is adjustment suggestions (if semantically incomplete, a suggestion to merge or split must be explicitly provided, along with the corresponding target segments for merging / splitting). After the model completes processing, the completeness status and adjustment suggestions for each candidate segment to be processed are recorded, forming a judgment result list to provide a basis for subsequent segment reconstruction.

[0097] In practical applications, for each candidate segment in List_curr with a status of "Pending Processing," the complete content of its block_id node and its preceding and following sibling nodes is used as context, combined with predefined prompt words, and input into the large language model. These prompt words are designed to guide the large language model to determine whether the current candidate segment and its context constitute a semantically complete independent clause unit. The prompt words require the model to output a structured judgment result, including completeness status, clause type label, or specific boundary adjustment and merging suggestions. If the candidate segment is determined to be an independent unit, its status is adjusted to "Confirmed," and an appropriate semantic type label is assigned. If the candidate segment is determined to be incomplete, precise boundary adjustment suggestions are output, and the candidate segment and its suggested merging sibling segments are marked "To be merged, split into a new segment X" (where X is the temporary ID of the merged new segment, such as Temp_001).

[0098] Sub-step C3: Reconstruct the candidate segment list based on the adjustment suggestion information, process the candidate segments that need to be merged or split according to the integrity status, and update the marking status of the corresponding candidate segments.

[0099] Based on the output judgment result list, the candidate fragment list reconstruction process is initiated: For candidate fragments with a completeness status of "semantic incomplete" and an adjustment suggestion of "merge", they are merged with adjacent suggested fragments to form new candidate fragments, retaining the basic information of each fragment before merging (text, reference associations, etc.); for candidate fragments with an adjustment suggestion of "split", they are split into multiple semantically independent new candidate fragments according to the splitting nodes suggested by the model, and each new fragment is assigned an independent label field. After processing, the label status of all candidate fragments is updated: fragments that have completed merging and splitting and are semantically complete are marked as "processed". If there are still semantically incomplete fragments after merging and splitting, they are retained in the "pending processing" status; pending processing fragments that did not participate in this adjustment remain in the "pending processing" status, forming the reconstructed candidate fragment list.

[0100] Specifically, the system can reconstruct the fragment list based on all the states collected in this round. Candidate fragments with a "confirmed" status undergo no further processing. All fragments marked as belonging to the same "new fragment X" will be merged to form a new ClauseUnit fragment and marked as "pending processing" (for checking its integrity in the next round). Partially merged sibling ClauseUnit fragments are marked accordingly, retaining only the unmerged text and citation information; unadjusted candidate fragments remain in the "pending processing" state. The reconstructed list is denoted as List_next.

[0101] Sub-step C4: Compare the candidate fragment lists before and after reconstruction to determine whether the convergence condition is met. If it is met, terminate the iteration and output the list of clause unit objects.

[0102] Convergence criteria refer to the preset standards used to determine whether the iteration process has terminated. Specifically, in the list of candidate fragments after reconstruction, the integrity status of all candidate fragments is "semantic complete", and there are no fragments that need to be further merged or split, that is, the iteration has reached a stable state.

[0103] The reconstructed candidate fragment list is compared comprehensively with the original list, focusing on two key points: first, whether all candidate fragments in the reconstructed list are semantically complete; and second, whether there are any fragments that still need to be merged or split. If both points are met, the convergence condition is satisfied, and the multi-round iteration process terminates. If not (incomplete or unprocessed fragments exist), the process returns to sub-step C2 and repeats subsequent iteration steps until the convergence condition is met. After the iteration terminates, all semantically complete candidate fragments marked as "processed" are encapsulated into clause unit objects (each object contains legal text elements, reference information, and other required content). All clause unit objects are then aggregated, and a final list of clause unit objects is output.

[0104] Specifically, the algorithm compares the number of IDs in List_curr and List_next, as well as the corresponding segments with the same ClauseUnit ID. If both lists have the same number of segments, and the large language model determines that the content of the segments corresponding to the respective IDs is identical, or the preset maximum number of iterations (usually ≤10, with a typical value of 5) is reached, the algorithm terminates, and List_next becomes the final segment. Otherwise, List_next is assigned to List_curr, and the algorithm returns to the "Large Language Model Analysis and Suggestion" step iteration.

[0105] The final output is a list of ClauseUnit objects representing the segmented fragments. Each ClauseUnit object is a structure that, in addition to containing the text content and multimodal references, also includes the original level path (level_path), its position reference in the EDOM, its document type, and its metadata set. Specifically, ClauseUnit contains the following fields: clause_id: A unique identifier for a fragment.

[0106] content: fragment of text.

[0107] clause_type: Semantic type label assigned by the large language model, such as term definition / performance requirement / test procedure / identification requirement / compliance judgment / quotation statement / other.

[0108] source_doc_meta: File metadata, namely metadata such as doc_id and doc_type inherited from EDOM.

[0109] structural_metadata: Structure-related metadata, namely level_path, block_id, coordinates, and parent_id, which are inherited from EDOM.

[0110] context_window: The context used to determine integrity (i.e., the content of the preceding and following sibling nodes).

[0111] non_text_refs: A list of associated non-text element IDs inherited from EDOM.

[0112] This application achieves multi-round iterative optimization of candidate segments by uniformly marking the status of candidate segments, judging the semantic integrity in combination with contextual information, and performing targeted merging, splitting, reconstruction, and convergence verification. It effectively solves the problems of incomplete semantics and non-standard structure of the initial segmented segments, ensuring that the final output clause unit objects all have complete semantics. This provides high-quality and standardized basic data for subsequent information extraction and knowledge graph construction. At the same time, the iterative convergence mechanism improves the accuracy and efficiency of clause splitting and reduces the cost of manual intervention.

[0113] In one implementation of this application, step 130 may include sub-steps D1 to D5.

[0114] Sub-step D1: Determine the target map pattern.

[0115] In this embodiment, the target graph pattern is a pre-defined knowledge graph structure specification that clearly defines the entity types, relation types, attribute types, and constraint rules that the knowledge graph must include. This specification is used to constrain the extraction process of triple data and ensure that the extraction results meet the requirements of subsequent knowledge graph construction.

[0116] The system retrieves the preset target schema resources and performs a validity check on the target schema, verifying whether it contains complete entity types, relation types, attribute types, and corresponding constraint rules to ensure that the schema can be used to guide triple extraction. If a latest version of the target schema exists in the system, it is prioritized as the basis for the current extraction (i.e., the latest updated version is used as the target schema). The schema update process will be described in detail later.

[0117] If a new version does not exist or has not been updated, a pre-defined minimum knowledge graph schema will be used directly as the target schema. This predefined minimum core schema includes the minimum necessary entity types, relationship types, and attribute templates in the regulatory / standard knowledge graph. This schema will evolve dynamically through subsequent steps. Entity types include regulations / standards, issuing agencies, publication dates, implementation dates, clauses, vehicle types, and geographical regions; relationship types include include contain, publish, relate, reference, substitute, and apply; attribute types include numerical values, units, dates, and text.

[0118] Sub-step D2: Using the large language model, extract triplet data that conform to the target graph pattern from the list of clause unit objects based on predefined prompt words, and record undefined candidate elements in the target graph pattern. The candidate elements include: candidate entities, candidate relations, and candidate attributes.

[0119] Predefined prompts are standardized instructions that guide large language models to accurately extract triplet data. They clarify the extraction task, target graph pattern constraints, output format, and candidate element recording requirements, ensuring that the extraction results are standardized and complete.

[0120] Triple data is structured data that is initially extracted and conforms to the target graph pattern. It is mainly presented in two forms: (head entity, relation, tail entity) and (entity, attribute, value). It is the basic material for structured triple data.

[0121] Candidate elements are elements discovered during the extraction process that are not defined by the target graph pattern. They are divided into three categories: candidate entities, candidate relations, and candidate attributes. They need to be further processed before they can be integrated into the structured triplet data.

[0122] Candidate entities are technical elements or concepts that are not defined by the target graph pattern but have clear semantic meanings, and are the basic nodes that constitute triples.

[0123] Candidate relationships are association types that are not defined by the target graph pattern and are used to connect two entities, reflecting the relationships between entities.

[0124] Candidate attributes are attribute types that are not defined by the target graph pattern and are used to describe entity features. Together with attribute values, they constitute the attribute information of the entity.

[0125] Next, the list of ClauseUnit objects, the determined target graph schema, and predefined prompt words can be input into the large language model. The predefined prompt words explicitly require the model to strictly adhere to the constraints of the target graph schema, extracting triples that meet the schema requirements from the regulatory text elements and citation association information of each ClauseUnit object. Specifically, for each ClauseUnit, the large language model extracts entities, relations, and attributes using Few-shot prompt words. Few-shot prompt words are a type of few-shot prompt that explicitly constrains the entity and relation types and attribute value formats permitted by the current schema, and stipulates that when an element not defined in the current schema is encountered, it must be recorded as a candidate element to be evaluated.

[0126] Simultaneously, elements not defined in the target graph pattern (i.e., candidate elements, including candidate entities, candidate relations, and candidate attributes) are identified and recorded. During model processing, each clause unit object is parsed one by one, extracting content that meets the requirements of entity type, relation type, and attribute type, constructing triples in the form of (head entity, relation, tail entity) or (entity, attribute, value), and summarizing them to form triple data. At the same time, elements that cannot match any type in the target graph pattern are classified and recorded as candidate entities, candidate relations, and candidate attributes, forming a candidate element list, ensuring that triple extraction and candidate element recording are completed synchronously. That is, during the triple extraction process, the large language model may identify entities, relations, or attributes that are not defined in the current schema. The above-mentioned undefined identification results will be used as "candidate elements". The system records the clause_id of its respective ClauseUnit and calculates two indicators: 1) Frequency: the number of times it appears in this graph construction process, which is a cumulative value. 2) Confidence Score: During the prompt word extraction process, the large language model is explicitly required to use its self-explanatory capabilities to assign a confidence score between 0 and 1 to each identified triple. High-frequency, high-confidence candidate elements will serve as activation conditions, initiating the dynamic evolution of the current schema. Candidate elements, their frequencies, average confidence scores, and clause_ids will be aggregated into the global candidate element report.

[0127] Sub-step D3: Perform matching and linking processing on the candidate entities in the candidate elements to obtain the processed candidate entities.

[0128] Matching and linking processing refers to the standardized processing performed on candidate entities. By associating with existing entity resources, it performs identity matching, deduplication, and normalization on candidate entities to ensure their uniqueness and standardization.

[0129] Next, all candidate entities in the candidate element list can be extracted, and the matching and linking process can be initiated. First, the existing entity resource library in the system (including historically extracted valid entities and technical entities from publicly available standards) is retrieved. Each candidate entity is matched with existing entities in the entity resource library using methods such as feature comparison and semantic similarity matching. If a candidate entity can be matched with an existing entity, it is normalized to the standard representation of the corresponding existing entity, completing deduplication and standardization. If a candidate entity cannot be matched with an existing entity, it is recorded as a new entity, its basic information is supplemented and improved, and standardization is completed. After all candidate entities have completed the matching and linking process, standardized and unique candidate entities are obtained, laying the foundation for subsequent integration work.

[0130] During this process, the system can execute the following fusion and disambiguation strategies: Name normalization: Remove spaces and punctuation from candidate entity names, and convert uppercase letters to lowercase.

[0131] Exact match: Search for entities with the same name in the existing graph entity library.

[0132] Similarity matching: If no exact match is achieved, Sentence-BERT is used to encode the candidate entity name into a vector, and the cosine similarity with the entity vector in the entity database is calculated. If the highest similarity exceeds a threshold (e.g., 0.92), it is considered a synonym entity and a link is established.

[0133] Create a new entity: For candidate entities that have not yet been matched through exact matching and similarity matching, a decision is made based on the data in the global candidate element library to determine whether to create a new element. If the frequency of the candidate entity exceeds the global frequency threshold (e.g., 3 times) and the average confidence score exceeds the global confidence threshold (e.g., 0.8), a new candidate entity is created, and its entity type is recorded according to the type suggested by the large language model during extraction. The system maintains a global candidate element report. For newly identified candidate entities, if a record with the same name and type already exists in the database, its frequency, confidence score, and location are merged and updated; otherwise, a new record is added to the database. The average confidence score is calculated as: AvgConfidence = Sum(Confidence_i) / N, where N is the frequency of the candidate entity.

[0134] For the extracted candidate relations, perform relation disambiguation based on entity disambiguation: Relationship type alignment: Generate semantic descriptions for candidate relationship names using a large language model, and compare them with the standard semantic descriptions of each predefined relationship type in the schema. If the similarity is higher than a threshold (e.g., 0.9), the candidate relationship is assigned to the corresponding standard relationship type; otherwise, it is marked as a "relationship pending review".

[0135] Entity type validation: Check whether the "head entity" and "tail entity" of the candidate relationship belong to the disambiguated entity library and whether the type conforms to the schema constraints (e.g., the head entity of the "specify" relationship must be "clause" and the tail entity must be "performance metric"). Relationship migration: If entity disambiguation results in a change of entity name (e.g., “Driving Range” → “Driving Range”), the original relationship pointing to “Driving Range” will be automatically migrated to the “Driving Range” entity.

[0136] For the extracted candidate attributes, perform attribute disambiguation based on entity and relation disambiguation: Attribute name normalization: Generate semantic descriptions of candidate attributes using a large language model, compare them with the descriptions of existing attributes in the schema, and merge them if the similarity is higher than a threshold (e.g., 0.9).

[0137] Value type validation: Check whether the value of the candidate attribute conforms to the schema constraints (e.g., the value of the "numeric" attribute must be float, and the value of "date" must be YYYY-MM-DD). If it does not conform, mark it as "type error". Attribute migration: If entity disambiguation results in entity change, the original attributes (such as the "unit" attribute of the entity "range") will be automatically migrated to the disambiguated entity.

[0138] Sub-step D4: Perform type adaptation and constraint verification on the candidate relationships and candidate attributes in the candidate elements to obtain the processed candidate relationships and candidate attributes.

[0139] Type adaptation and constraint validation refer to the standardized processing performed on candidate relations and candidate attributes. Type adaptation is used to match candidate relations and candidate attributes to a reasonable type system, and constraint validation is used to verify whether they conform to the overall constraint rules of the knowledge graph.

[0140] Finally, type adaptation and constraint validation are performed on the candidate relations and candidate attributes in the candidate element list: For candidate relations, type adaptation is performed based on the relation type system of the target graph pattern to match them to the most suitable relation type category, while verifying whether they conform to the association constraints between entities and relations in the graph (such as the range of relation types that a certain type of entity can be associated with). For candidate attributes, type adaptation is performed based on the attribute type system of the target graph pattern to clarify their corresponding entity type, while verifying whether their attribute format and value range conform to the preset constraint rules. After type adaptation and constraint validation, candidate relations and candidate attributes that do not meet the constraint requirements are eliminated, and elements that meet the requirements are retained and standardized, resulting in the processed candidate relations and candidate attributes.

[0141] Sub-step D5: Integrate the triplet data, the processed candidate entities, the processed candidate relations, and the candidate attributes to obtain the structured triplet data.

[0142] Structured triple data: A standardized set of triples obtained after preliminary extraction, candidate element processing, and integration optimization. It includes initial triples that conform to the target graph pattern and triples corresponding to the processed candidate elements. It is the core data for constructing knowledge graphs.

[0143] First, the initially extracted triplet data undergoes validity validation, eliminating invalid triples with format errors or semantic contradictions, and retaining valid triples that conform to the target graph pattern. Then, the processed candidate entities, candidate relations, and candidate attributes are combined to construct corresponding new triples (e.g., constructing (head entity, relation, tail entity) triples based on candidate entities and candidate relations, and constructing (entity, attribute, value) triples based on candidate entities and candidate attributes). Finally, the valid initial triples are integrated with the newly constructed triples, removing duplicate data and ensuring that all triples have a consistent format, semantic integrity, and conform to the target graph pattern constraints, ultimately yielding structured triplet data for subsequent knowledge graph construction.

[0144] The process for updating the schema can be as follows: For the output global candidate element report, its frequency and average confidence can be compared with the set global frequency threshold (5 times) and average confidence threshold (0.85). When a candidate element meets both the frequency and confidence threshold conditions, it will automatically enter the "expert review queue" and the "recommendation draft" generated by the large language model will be sent to domain experts. The recommendation draft is the large model supplementing core attributes based on the type of candidate element. The candidate element types and their core attributes include: For candidate relation types, it is necessary to define their formal relation name, semantic description, starting entity type, and target entity type.

[0145] For candidate attributes, it is necessary to define the entity type to which it belongs, the attribute name, the value type (text, numeric, date), and the constraints.

[0146] S422: Expert Review Interface: Domain experts can view the full context (ClauseUnit) and recommended drafts of their candidate elements through their personal dashboards, adopt, modify or reject the recommended drafts, and decide whether to include them in the formal schema.

[0147] S43: Schema Updates and Iterations: After expert confirmation, a new version of the schema is created and its version is managed. Graph construction (Module 5) and information extraction (Module 3) will be based on the latest schema version. For existing graph data, an asynchronous schema migration task is provided. This task can be manually triggered by the administrator or automatically triggered by the system during a preset maintenance window (e.g., 2:00 AM - 4:00 AM daily).

[0148] The closed-loop process of dynamic schema evolution and human-machine collaboration can be as follows: Figure 4 As shown, it may include: Step 410: Process Startup.

[0149] Marked as "Start", this is the starting point for triggering the schema evolution process. It can be triggered by the system on a scheduled basis, by the accumulation of candidate elements, or by manual intervention.

[0150] Step 420: Module 3 (i.e., the module for joint information extraction guided by dynamic schema) outputs a global candidate evaluation report.

[0151] Module 3 generates a global candidate evaluation report based on the results of previous knowledge extraction and entity recognition. The report contains core statistical information on candidate elements to be included in the schema (such as candidate entities, candidate relationships, and candidate attributes): Frequency of occurrence of candidate elements (number of times they are mentioned in the clause text / graph); The average confidence level of the candidate element (the degree of confidence in the model's identification / extraction of the element); Auxiliary information such as the context of candidate elements and their related context.

[0152] Step 430: Threshold condition judgment.

[0153] Perform double threshold validation on candidate elements in the global candidate evaluation report, with the following judgment conditions: The frequency of candidate elements is greater than or equal to a preset frequency threshold and the average confidence level is greater than or equal to a preset confidence threshold. If the result is "No", it means that the frequency or credibility of the candidate element is insufficient and it is not valuable to include it in the schema. The process will revert to step 410, and the global candidate evaluation report will be generated / updated by module 3 again to continue to screen for better candidate elements.

[0154] If the result is "yes", it means that the candidate element meets the requirements of high frequency and high confidence, and enters the expert review stage.

[0155] Step 440: Expert dashboard presentation.

[0156] In the expert visualization dashboard, two types of core information are displayed to domain experts: Candidate elements and context: Candidate elements (entities / relationships / attributes) to be reviewed, along with their source text and related context, to help experts understand the business meaning and usage scenarios of the elements; LLM-generated recommendation draft: The schema recommendation scheme automatically generated by the Large Language Model (LLM) includes the type definition, constraint rules, and association relationships of candidate elements, providing experts with a preliminary basis for decision-making.

[0157] Step 450: Expert decision-making.

[0158] Domain experts review the LLM recommendation draft and determine whether to adopt it or modify it to include the candidate element in the schema. If the result is "No": the experts believe that the draft is unreasonable or that the candidate element does not need to be included in the schema. The process reverts to step 410, and the global candidate evaluation report is regenerated / updated by module 3 to screen new candidate elements.

[0159] If the judgment is "yes": After the experts confirm the adoption or modification, the candidate element will be formally included in the Schema and enter the Schema definition stage.

[0160] Step 460: Output the schema definition.

[0161] The candidate elements and rules confirmed by experts will be formally output as a schema definition file, clearly defining: Add / modify entity types, relationship types, and attribute types; Various types of constraint rules (such as attribute value range, entity type restrictions for relational connections); Compatibility logic with the original schema.

[0162] Step 470: Git version control and new version generation.

[0163] Version control management of schema definition files is achieved using Git: Record the changes made during this schema evolution (new / modified / deleted elements), the submitter, and the submission time; Generate a new Schema version number to enable Schema version tracking and rollback capabilities, ensuring consistency across multiple versions.

[0164] Step 480: Pass it to module 3.

[0165] The generated new Schema is passed back to Module 3 for subsequent information extraction, knowledge graph construction and other processes, so that the new Schema can directly guide the business execution of downstream modules and realize the closed-loop iteration of Schema evolution.

[0166] Step 490: Process ends.

[0167] Marked as "End", this schema evolution process is complete. The new schema is now in effect and ready for use, awaiting the next evolution trigger.

[0168] This application addresses the issues of non-standard triple extraction, messy candidate elements, and redundant and invalid data by clearly defining the target graph pattern constraints and combining a large language model with predefined prompts to accurately extract triple data. It simultaneously records undefined candidate elements and then standardizes the candidate elements through matching links, type adaptation, and constraint verification. Finally, it integrates the data to form standardized structured triple data, effectively solving the problems of non-standard triple extraction, messy candidate elements, and redundant and invalid data. This ensures that the extraction results meet the requirements of knowledge graph construction and provides high-quality, structured core data support for the accurate construction of subsequent two-layer knowledge graphs, thereby improving the efficiency and accuracy of knowledge graph construction.

[0169] In one implementation of this application, step 140 may include sub-steps E1 to E6.

[0170] Sub-step E1: Construct the first-level node, which is a standard regulatory document node, and set the corresponding node attributes for the standard regulatory document node.

[0171] In this embodiment, the standard regulatory document node is the core node of the first-level graph, corresponding one-to-one with the regulatory / standard documents in the target field. It is used to carry the macro-level information of the standard regulatory documents and is the basis for constructing the first-level graph.

[0172] Node attributes refer to structured information used to describe the characteristics of nodes at different levels. The attributes of nodes at different levels are different. The attributes of first-level standard and regulatory document nodes are mainly document metadata, while the attributes of second-level nodes are mainly their own characteristics and related information.

[0173] In this example, the first level of standard regulatory document nodes can be constructed based on the standard regulatory document metadata in the Document Object Model (DOM) data file: All standard regulatory documents in the target domain are traversed, and an independent standard regulatory document node is created for each standard regulatory document. Each node is assigned a unique identifier to ensure its uniqueness. Subsequently, corresponding node attributes are set for each standard regulatory document node. The attribute content is derived from the DOM data file and mainly includes document metadata such as document number, document name, issuing agency, document type, effective date, repeal date, and scope of application. These attribute information is bound to the corresponding standard regulatory document node to ensure the completeness and accuracy of each node's attributes, laying the foundation for subsequently building relationships between nodes.

[0174] Sub-step E2: Construct the association relationships between the first-level nodes to obtain the first-level metadata and document relationship graph.

[0175] The association between nodes refers to the association type used to connect nodes at the same level or different levels. Associations at the same level reflect the inherent logic between nodes (such as document association at the first level and inter-level association at the second level), while associations across levels enable the linkage of two-level graphs.

[0176] Based on the attribute information (such as document number, substitution relationship, citation information, etc.) of each standard and regulatory document node, the relationships between the first-level standard and regulatory document nodes are identified and constructed: All standard and regulatory document nodes are traversed, and the document relationship information corresponding to each node is extracted (such as one document replacing another, one document citing another, etc.). The relationship type between nodes is determined based on the relationship information, and the relationship links between nodes are established. After all standard and regulatory document nodes and their relationships are constructed, they are integrated to form a first-level metadata and document relationship graph. This graph enables macro-level positioning, version management, and impact scope analysis of standard and regulatory documents.

[0177] Sub-step E3: Construct the triplet instance data layer node, fragment layer node, and topic community layer node of the second level.

[0178] The triplet instance data layer node refers to the core data layer node of the second-level fine-grained technical knowledge graph, including entity nodes and the relationship nodes between entity nodes, which is a direct manifestation of the relationship between technical elements.

[0179] Fragment layer nodes refer to the intermediate association layer nodes of the second-level fine-grained technical knowledge graph. They correspond one-to-one with clause unit objects and are used to associate triple instance data with original legal clauses, enabling the traceability of technical elements and original text.

[0180] The topic community layer node refers to the classification layer node of the second-level fine-grained technical knowledge graph. It is a virtual grouping node generated by clustering entity nodes and their relationships in the triple instance data layer through clustering algorithms, and is used to realize the classification management of technical elements.

[0181] Construct the second-level nodes in three layers based on the structured triple data and the list of clause unit objects: First, construct the nodes in the triple instance data layer. Take the entities in the structured triple data as entity nodes and the association relationships between entities as relationship nodes. Create nodes one by one and assign unique identifiers to form the triple instance data layer. Second, construct the nodes in the fragment layer. Traverse the list of clause unit objects and create a corresponding fragment layer node for each clause unit object. The node identifier corresponds one-to-one with the clause unit object identifier to achieve the binding between the fragment layer nodes and the clause unit objects. Finally, construct the nodes in the theme community layer. Use the community discovery algorithm to cluster the network composed of entity nodes and association relationships in the triple instance data layer. Divide the entity nodes and relationship nodes with close associations into a virtual group and create a theme community layer node for each virtual group to complete the construction of the three layers of the second level.

[0182] Sub-step E4: Set corresponding attributes for each layer of nodes in the second level and establish the association relationships between the layers of nodes to obtain the fine-grained technical knowledge graph of the second level.

[0183] In this step, first, corresponding attributes can be set for each layer of nodes in the second level: Set attributes such as technical features and the field of belonging for the entity nodes in the triple instance data layer, and set attributes such as relationship type and constraint conditions for the relationship nodes. Set attributes such as clause text, original hierarchical path, and position reference information for the fragment layer nodes. Set attributes such as theme labels and the scope of covered entities for the theme community layer nodes. Subsequently, establish the association relationships between each layer of nodes in the second level. Establish the association between the nodes in the triple instance data layer and the fragment layer, and anchor each triple node to the corresponding fragment layer node (i.e., the corresponding clause unit object). Establish the association between the fragment layer nodes and the theme community layer nodes, and classify each fragment layer node into the corresponding theme community group. Establish the association between the theme community layer nodes and the entity nodes in the triple instance data layer to achieve the linkage of each layer of nodes. After all node attribute settings and inter-layer association relationships are established, a fine-grained technical knowledge graph of the second level is formed.

[0184] Sub-step E5: Establish the association relationship between the graph of the first level and the graph of the second level.

[0185] Build a two-way association relationship between the first-level knowledge graph and the second-level knowledge graph to achieve the linkage of the two-level knowledge graph: On the one hand, starting from the first level, each standard regulatory document node is connected to all the fragment layer nodes corresponding to this standard regulatory document in the second level through the "contains" association relationship (that is, the nodes corresponding to all clause unit objects contained in this standard regulatory document). On the other hand, starting from the second level, each fragment layer node is connected to the corresponding standard regulatory document node in the first level through the "belongs to" reverse association relationship to clarify the standard regulatory document to which each clause unit belongs. Through the two-way association, the accurate correspondence between the macro documents in the first level and the micro technical elements in the second level is achieved, ensuring the relevance and traceability of the two-level knowledge graph data.

[0186] Sub-step E6: Set up the event trigger and status synchronization mechanism of the knowledge graph to trigger the status synchronization and impact analysis of the relevant nodes in the second-level knowledge graph when a new inter-document association relationship is added to the first-level knowledge graph, and adjust the status of the corresponding nodes in the second-level knowledge graph according to the impact analysis results.

[0187] The event trigger and status synchronization mechanism refers to the core mechanism used to achieve the linkage update of the two-level knowledge graph. When a specific event (adding an inter-document association relationship) occurs in the first-level knowledge graph, it automatically triggers the relevant processing of the second-level knowledge graph to ensure the status synchronization and data consistency of the two-level knowledge graph.

[0188] The inter-document association relationship refers to the association type between the first-level standard regulatory document nodes, mainly reflecting the logical relationships such as hierarchy and timeliness between regulatory / standard documents (such as replacement, revised from, citation, etc.).

[0189] Impact analysis refers to the process of traversing and analyzing the nodes related to the event in the second-level knowledge graph when an event trigger occurs in the first-level knowledge graph to judge the scope and degree of the impact of the event on the relevant nodes.

[0190] Simultaneously, an event triggering and state synchronization mechanism for the knowledge graph can be configured, clearly defining the triggering conditions, processing flow, and adjustment rules: the triggering condition is set as "new document-to-document relationships added to the first-level graph" (such as new replacement, revision, etc.). When the triggering condition is met, the system automatically initiates the state synchronization and impact analysis process for the second-level graph: First, it locates the standard regulatory document node corresponding to the new relationship in the first level, and then finds all fragment layer nodes and associated triplet instance data layer nodes and topic community layer nodes corresponding to that document in the second level. Second, it performs impact analysis on these related nodes to determine the impact of the new document-to-document relationships on the node status. Finally, based on the impact analysis results, it adjusts the status of the corresponding nodes in the second level (such as marking them as obsolete, revised, etc.), while recording the node status change history to ensure synchronization of the two-level graph status and data consistency, guaranteeing the timeliness and accuracy of the knowledge graph.

[0191] The L1 layer graph (i.e., the first-level graph) and the L2 layer graph (i.e., the second-level graph) achieve multiple couplings through bidirectional association and event triggering mechanisms, specifically including: Two-way association: The regulatory / standard nodes in the L1 layer graph are linked to the corresponding clause nodes in the L2 layer graph via "inclusion".

[0192] The clause nodes of the L2 layer graph are inversely linked to the regulatory / standard nodes of the L1 layer graph through the "belongs to" attribute.

[0193] Event Triggering and Status Synchronization: When a new document relationship (such as replacement, revision, or citation) is added to the L1 layer graph, the system automatically triggers status synchronization and impact analysis of the relevant nodes in the L2 layer graph. When a replacement relationship is detected, the system automatically marks the L2 clause node corresponding to the old document as "repealed" and establishes a replacement association with the new clause. Simultaneously, the system initiates impact propagation analysis: iterates through all entity nodes such as technical indicators and testing methods directly connected to the old clause node, checking whether there are other inbound relationships from valid clauses in the graph. If an entity node is only associated with a repealed clause, its status is marked as "historical / pending review"; if the entity node is still cited by other valid clauses, its "valid" status is maintained, but its association history with the old clause is recorded.

[0194] For two-layer knowledge graphs, it can be like... Figure 3 As shown, the two-layer knowledge graph architecture consists of an upper L1 layer graph (macro-level metadata and document relationship graph) and a lower L2 layer graph (fine-grained technical knowledge graph). The two layers are logically linked to achieve a hierarchical expression of "macro-level document management - micro-level technical decomposition", fully covering the entire lifecycle management of regulatory / standard documents and the traceability of technical details.

[0195] Layer L1 focuses on the macro-level management and version traceability of regulatory / standard documents, with its core being the expression of document-level nodes and metadata, as well as the relationships between documents. Core Nodes: The core entities are the "Regulations and Standards Nodes" (such as "Regulations and Standards Node 1" and "Regulations and Standards Node 2" in the figure). Each node corresponds to an independent regulation / standard document (such as national standards, industry standards, and regulatory documents).

[0196] Node attributes: Each regulatory standard node is associated with multiple attribute nodes, used to store the document's basic metadata. Example: Node 1 of the regulations and standards is associated with attributes such as "name", "ID", "issuing organization", "publication date", and "implementation date", which fully records the document's identification, publication information and timeliness information.

[0197] Relationships between nodes: There are directed associations between regulatory standard nodes (as shown in the figure, "Regulatory Standard Node" points to "Regulatory Standard Node 1", and "Regulatory Standard Node 2" points to "Regulatory Standard Node 1"), which are used to express the business logic relationships between documents, such as substitution, revision from, reference, hierarchical affiliation, etc., to support version management and impact scope analysis.

[0198] Functional positioning: Enables rapid macro-level positioning of regulatory / standard documents, version tracking, and release / effectiveness status management, serving as a management view for upper-level business operations.

[0199] The L2 layer focuses on the technical content breakdown of regulatory / standard documents, with the core being the relationship between clause-level semantic units and technical elements: Core Nodes: The core entities are the "legal clause nodes" (such as "legal clause 1", "legal clause 2", "legal clause 3", etc. in the figure). Each node corresponds to a clause-level semantic unit (ClauseUnit) split from the L1 layer standard legal document, and serves as a bridge connecting macro documents and micro technologies.

[0200] There is a hierarchical relationship between the clauses: as shown in the figure, the "Legal Clause" node points to "Legal Clause 1 / 2 / 3", which reflects the hierarchical structure of "Chapter-Clause-Sub-Clause" in the original document and supports clause traceability.

[0201] Clause Node Attributes: Each legal clause node is associated with its own metadata attributes: Example: Clause 1 of the regulations is associated with "Clause_ID" (the unique identifier of the clause) and "Level_path" (the hierarchical path of the clause in the original document, such as "Chapter 4 → Clause 4.1"), which is used to accurately trace the original location of the clause.

[0202] Technical element nodes: Regulatory clause nodes are further linked to technical nodes to achieve a structured expression of technical content. The "Technical Requirements" section represents the specific technical constraints (such as performance indicators, safety requirements, etc.) specified in the terms and conditions. The "Test Method" node is associated with the technical requirements node and represents the testing methods / processes for verifying the technical requirements, reflecting the logical link of "requirement-verification" (as shown in "Technical Requirements → Test Method" in the figure).

[0203] Functional positioning: It breaks down regulatory provisions into calculable technical elements, enabling the association and query of fine-grained knowledge such as technical requirements and testing methods, and supporting technical applications such as compliance review and impact transmission analysis.

[0204] Layer L1 and Layer L2 achieve linkage through a two-way "contains-belongs" relationship: The "regulatory standard node" in layer L1 is associated with all the "regulatory clause nodes" corresponding to the document in layer L2 through an "inclusion" relationship; The "regulatory clause nodes" in layer L2 are inversely associated with the corresponding "regulatory standard nodes" in layer L1 through a "belonging" relationship.

[0205] This connection enables end-to-end traceability from macro-level documents (L1) to micro-level clauses (L2) to technical requirements / testing methods (L2), supporting both upper-level document management and precise querying and analysis of lower-level technical details.

[0206] This application constructs a two-layer knowledge graph, clearly defining the nodes and attributes at each level, establishing intra-layer and inter-layer relationships, and combining event triggering and state synchronization mechanisms. This effectively achieves the organic integration of macro-management of standard and regulatory documents with micro-presentation of technical elements, accurately expressing the relationships between regulations, standards, and technical elements. It solves the problems of disconnect between the two-layer graph and asynchronous node states, while ensuring the standardization and timeliness of the knowledge graph. This provides structurally complete and data-accurate knowledge support for subsequent applications such as semantic querying, impact transmission, and intelligent decision-making, helping automakers to efficiently advance compliance management and standard construction.

[0207] In one implementation of this application, after step 140 above, steps F1 to F4 may also be included.

[0208] Step F1: When a new standard or regulatory document is added to the database, extract the identifier and version metadata of the new standard or regulatory document, and match the identifier and version metadata with the first-level graph to obtain the matching result.

[0209] In this embodiment, new standard and regulatory documents refer to newly uploaded, newly published, or newly acquired target domain regulations / standard documents that are intended to be entered into the system and updated to the knowledge graph, and are the triggering objects of this update process.

[0210] Identifiers are core information used to uniquely identify new standard and regulatory documents. They are usually the document's standard number, document number, etc., and are key identifiers for distinguishing different standard and regulatory documents, used for graph matching.

[0211] Version metadata is the basic information related to the version in new standard and regulatory documents. It mainly includes the implementation date, release date, and replacement standard number, and is used to determine the version relationship of the document (new, revised, or replacement).

[0212] The matching result is obtained by comparing the identifier and version metadata of the new standard and regulatory document with the existing document nodes in the first-level graph. The result is divided into three categories: "new document", "document with revision or replacement relationship" and "duplicate document".

[0213] When new standard and regulatory documents are added to the database, their identifiers and version metadata can be extracted. These identifiers and version metadata are then matched against the first-level graph to obtain the matching results. Specifically, when a regulatory / standard document D_new is added to the database, the system first extracts its core identifiers (such as the standard number) and version metadata (such as the implementation date and the replaced standard number) and matches them in the L1-level graph to determine the update strategy.

[0214] Step F2: When the matching result indicates that the new standard regulation document is a completely new document, trigger the complete document parsing, clause splitting, information extraction and graph construction process to complete the construction of the corresponding hierarchical graph nodes and relationships.

[0215] When the matching result indicates that the new standard / regulatory document is a completely new document, a complete document parsing, clause splitting, information extraction, and graph construction process is triggered to complete the construction of the corresponding hierarchical graph nodes and their relationships. Specifically, if no L1 node is matched, then D_new is determined to be a completely new regulation / standard document, triggering the complete graph construction process to build its corresponding L1 document nodes, L2 clauses, and technical entity subgraphs.

[0216] Step F3: When the matching result indicates that the new standard regulation document is a document with a revision or replacement relationship, establish the association relationship between the new and old documents in the first-level graph, compare the set of clause units of the new and old documents, detect the clause change type, update the graph nodes and status of the second level, and perform impact analysis and status adjustment on the associated nodes.

[0217] New and old documents are corresponding documents when there is a revision or replacement relationship. "New document" refers to the new standard and regulation document that is added to the database this time, and "old document" refers to the original standard and regulation document in the first level map that has a revision or replacement relationship with the new document.

[0218] A clause unit set is a collection of all clause unit objects obtained after a single standard regulatory document is split into clause-level semantic units. It is divided into a new clause unit set corresponding to a new document and an old clause unit set corresponding to an old document.

[0219] The type of clause change refers to the type of clause change identified by comparing the set of clause units in the old and new documents. It mainly includes four types: addition, revision, deletion / repeal, and no change.

[0220] Related nodes refer to nodes that are directly or indirectly related to the nodes to be updated in the second level, including clause nodes, entity nodes, relationship nodes, etc., and are the core objects of influence analysis.

[0221] When the matching result indicates that the new standard or regulatory document is a document with a revision or replacement relationship, the system establishes a relationship between the old and new documents in the first-level graph. Simultaneously, it compares the set of clause units between the old and new documents, detects the type of clause change, and updates the second-level graph nodes and their status. It also performs impact analysis and status adjustments on the associated nodes. In other words, it determines whether the current document has a revision or replacement relationship with a previous document. If an existing L1-level graph node D_old with the same core identifier and a newer version is matched, then D_new is determined to be the new version of D_old. The version update must satisfy the requirement that the implementation date is more recent. The system establishes a "replacement" relationship (or "revision from" relationship) between D_new and D_old in the L1-level graph and triggers the L2-level graph update process.

[0222] For L2-level fine-grained knowledge updates: After determining that the current document has a revision / substitution relationship with the previous document, the system performs the following steps to update the L2-level knowledge graph: Content parsing and comparison: D_new obtains its new version of the ClauseUnit collection C_new according to the steps of Module 1 and Module 2, and at the same time obtains the old version of the ClauseUnit collection C_old corresponding to D_old.

[0223] Clause Change Detection and Mapping: Based on level_Path, text similarity (calculated using embedding vectors), and intelligent matching of key entities, C_new and C_old are compared. Text similarity is calculated based on the cosine similarity of the clause content embedding vectors, identifying change types as follows: New clause: Clause for which there is no matching item in C_old.

[0224] Revised clauses must meet at least two of the following conditions: the cosine similarity of the text content embedding vectors is lower than a set value (e.g., 0.75); and the core technical requirements (e.g., key performance indicator values, test conditions, scope of effectiveness) have changed, as confirmed by a large language model-assisted judgment. The large language model-assisted judgment is achieved through a specific prompt word, which requires the large language model to compare the texts of the two clauses, focus on the technical substance, and output a Boolean value indicating whether a core change has occurred.

[0225] Deleted / Repealed Clauses: Clauses for which there are no matching entries in C_old.

[0226] Unchanged terms: Terms whose content remains essentially unchanged.

[0227] Graph nodes and status updates: For the new clause: create an L2 clause node for it and establish an inclusion relationship with the corresponding L1 node of D_new.

[0228] For revised clauses: retain the original L2 clause node, update its status to "revised," and link it to the corresponding clause ID in D_new. Alternatively, you can create a new node representing the new requirement and establish a "revised to" relationship with the old node.

[0229] For deleted / repealed clauses: update the status of the corresponding L2 clause node to "repealed".

[0230] For unchanged clauses: retain their nodes and states, but strengthen their association with the corresponding L1 node of D_new.

[0231] Impact propagation analysis: Traverse all clause nodes marked as "repealed" or "revised" and examine related nodes. If all relationships of a node originate from a repealed clause, mark its status as "historical / pending review"; if the node has any relationship with other nodes, keep its status as "valid" and record its association history with the old clause.

[0232] Step F4: When the matching result indicates that the new standard regulation document is a duplicate document, maintain the original map state.

[0233] If the matching result indicates that the new standard regulation document is a duplicate document, the original graph state is maintained. That is, it is determined that the current document has a duplicate relationship with the previous document. If a document with the same core identifier and version is matched, it is considered a duplicate document, and the graph is not updated.

[0234] This application accurately distinguishes between three document types—new, revised / replaced, and duplicate—by matching identifiers and version metadata when new standard and regulatory documents are added to the database. Different graph update strategies are then implemented accordingly. Combined with a complete construction process and node update and impact analysis mechanisms, this effectively achieves dynamic updates to the knowledge graph. This solution addresses the issues of low efficiency in adding new standard and regulatory documents and data redundancy caused by duplicate additions. It also ensures the synchronization of node states in the two-layer graph under revision / replacement scenarios, avoiding the disconnect between old and new documents and the lag in technical element states. This further guarantees the timeliness, standardization, and accuracy of the knowledge graph. Synergistically with the association and state synchronization mechanisms of the two-layer graph, it continuously improves the knowledge base, providing timely and reliable knowledge support for applications such as automotive compliance review, standard impact transmission, and intelligent decision-making, thus facilitating the efficient advancement of automotive compliance management and standard construction.

[0235] In one implementation of this application, after step 140 above, steps G1 to G3 may also be included.

[0236] Step G1: Traverse all clause nodes corresponding to the same technical entity in the knowledge graph, extract the association information of each clause node, and combine multiple dimensions of preset judgment conditions to determine whether the clause nodes constitute a conflict pair.

[0237] In this embodiment, a conflict pair refers to a combination of two or more clause nodes in the knowledge graph that have logically mutually exclusive provisions for the same technical entity and cannot be satisfied simultaneously. It is the core object of conflict detection.

[0238] The multiple dimensions of the preset judgment conditions are pre-defined and used to determine whether clause nodes constitute a conflict pair. They cover key dimensions such as the document attributes to which the clause belongs, the scope of application, and the core provision logic, ensuring the accuracy of conflict determination.

[0239] After constructing the knowledge graph, it is possible to traverse all clause nodes corresponding to the same technical entity in the knowledge graph, extract the association information of each clause node, and combine multiple dimensions of preset judgment conditions to determine whether the clause nodes constitute a conflict pair. That is, by querying different clause nodes of the same entity through the graph, for each group of the above clauses, the following conflict judgment conditions are automatically checked and applied, and if all conditions are met, it is marked as a "potential conflict pair": Same level of legal force: The standardization type or legal force level of the document to which the clause belongs is the same (for example, the document to which it belongs is a "mandatory national standard" or the document to which it belongs is an "industry standard" within the same industry).

[0240] The scope of application highly overlaps: Based on the coverage field in the document metadata, it is determined that the regions, industries, and product categories to which the clauses belong have a high degree of overlap.

[0241] The provisions stipulate logical mutual exclusion: the core requirements (numerical value, status, judgment result) of the entities covered by the clauses cannot be logically satisfied at the same time.

[0242] Step G2: Based on the preset rule base, generate conflict resolution suggestions for the clause nodes that have been identified as conflicting pairs.

[0243] The preset rule base is a pre-built set of rules used to generate conflict resolution suggestions. It contains general principles and priority logic for conflict resolution, providing a standardized basis for generating conflict resolution suggestions.

[0244] The conflict resolution suggestion information is generated based on a preset rule base and is used to resolve clause conflicts for marked conflict pairs. It clarifies the priority and specific solutions for conflict resolution and is used for human-machine collaborative review.

[0245] After obtaining conflict pairs, conflict resolution suggestions can be generated based on a pre-defined rule base for the clause nodes marked as conflict pairs. Specifically, preliminary conflict resolution suggestions can be proposed according to the pre-defined rule base for domain experts to choose from. The rule base specifies general principles including, but not limited to, the following: Timeliness: Standard clauses with more recent implementation dates take precedence.

[0246] Special considerations: Standard clauses with more specific and professional scope of application take precedence (e.g., "Safety requirements for pure electric vehicles" take precedence over "general safety requirements for automobiles").

[0247] Strictness: When the above rules are inaccurate, stricter rules (such as higher values ​​or stricter conditions) can be suggested as the compliance baseline.

[0248] Step G3: Review the judgment results of the conflict pair and the conflict resolution suggestion information through human-machine collaborative review, and perform the corresponding conflict resolution operation according to the review results.

[0249] The human-machine collaborative review method is a collaborative model that combines automatic system judgment with manual review by domain experts. The system provides the judgment results and resolution suggestions for conflict pairs, and experts review, confirm, reject, or manually adjust to ensure the rationality of conflict resolution.

[0250] The review results are conclusions reached by domain experts through a human-computer collaborative review interface after reviewing the conflict judgment results and resolution suggestions. These conclusions mainly include three categories: "confirming the conflict and adopting the suggestion", "rejecting the conflict judgment", and "manually specifying the resolution solution".

[0251] Conflict resolution is a specific operation performed based on the review results to resolve conflicts. It includes adopting system suggestions to perform resolution, removing conflict markers, and performing resolution according to manual methods, ultimately eliminating conflicts between clause nodes.

[0252] After receiving conflict resolution suggestions, the determination of conflict pairs and the conflict resolution suggestions can be reviewed through a human-machine collaborative review process. Based on the review results, corresponding conflict resolution operations will be performed. Specifically, all "potential conflict pairs" and system suggestions will be confirmed by human-machine collaborative experts in the human-machine collaborative review interface, and the experts will then complete the following operations: Identify the conflict and adopt the recommendations: Acknowledge the conflict identified by the system and the recommendations for resolution.

[0253] Conflict rejection determination: If the expert believes that the difference is a reasonable difference (such as different numerical requirements due to different testing methods), the conflict mark can be rejected. At the same time, this case is selected as a sample of the new rule and saved to the system knowledge base. Then, similar differences will be automatically identified as "reasonable differences".

[0254] Manually specify the resolution plan: Provide a plan for the final decision.

[0255] This application's embodiments effectively resolve the conflict problem of inconsistent provisions for the same technical entity in the knowledge graph by traversing and retrieving clause nodes corresponding to the same technical entity, determining conflict pairs from multiple dimensions, generating resolution suggestions based on a preset rule base, and combining human-machine collaborative review and resolution operations. This avoids the distortion of graph data caused by conflicting clauses. This solution ensures both the accuracy of conflict determination and the rationality of resolution suggestions, while balancing system automation efficiency with the professionalism of expert experience through a human-machine collaborative model. It also enables system self-learning optimization, further improving the accuracy of subsequent conflict detection, ensuring the standardization and reliability of knowledge graph data, and providing accurate and conflict-free knowledge support for graph-based compliance review, intelligent decision-making, and other applications.

[0256] Next, combined Figure 2 The overall system architecture and data flow shown below describe the technical solution of this embodiment. For example... Figure 2 As shown: I. Starting point of the process: Input the original legal / standard documents.

[0257] The process starts with "Start" as the trigger point, and inputs the regulatory / standard documents to be processed (such as national standards, industry standards, regulatory documents, etc., which can include multimodal formats such as PDF, scanned copies, and images) as the raw data source for the entire system.

[0258] 2. Module 1: Multimodal parsing and storage (OCR+VLM+EDOM storage).

[0259] Core technologies: Use OCR (Optical Character Recognition) to process scanned / image documents and extract text content; By combining VLM (Visual Language Model), non-text elements (such as tables, formulas, and diagrams) in a document are identified, and reference relationships between text and non-text elements are established. Finally, it is stored in a structured format using EDOM (Document Object Model).

[0260] Input: Original regulatory / standard multimodal documents.

[0261] Output: EDOM JSON structured document object, which uniformly encapsulates the document's text elements, non-text elements, reference association information, and document metadata (document number, issuing organization, etc.), providing a standardized data foundation for subsequent processing.

[0262] 3. Module 2: Item-level decomposition (LLM semantic determination + tag propagation iteration).

[0263] Core technologies: Semantic integrity assessment of EDOM documents based on Large Language Model (LLM); By combining the mark-propagation iterative algorithm (multi-round iterative partitioning), the document is split into the smallest semantically complete clause units, ensuring that each unit corresponds to an independent and traceable legal meaning.

[0264] Input: EDOM JSON structured document object.

[0265] Output: A list of ClauseUnit objects, each containing the clause text, reference association information, original hierarchical path, location reference information, document type, and metadata, achieving a fine-grained decomposition of the document into clause-level semantic units.

[0266] 4. Module 3: Dynamic Schema Extraction (Minimum Core Schema + Few-shot Prompt).

[0267] Core technologies: Based on the minimum core schema (a predefined basic graph structure containing core entities, relationships, and attribute types); By combining the Few-shot prompt to guide the large language model, candidate entities, relations, and attribute elements are extracted from the ClauseUnit object list, and statistical information such as the frequency and confidence of the elements are recorded simultaneously.

[0268] Input: A list of ClauseUnit objects.

[0269] Output: Global candidate element report, which summarizes all candidate schema elements (candidate entities, candidate relationships, candidate attributes) to be evaluated, providing candidate materials for subsequent schema evolution.

[0270] 5. Module 4: Schema Dynamic Evolution (Dual Threshold Evaluation + Human-Machine Collaboration).

[0271] Core technologies: Dual threshold evaluation: High-value candidate elements are screened by using a "frequency threshold + confidence threshold" to filter out invalid candidates with low frequency and low confidence. Human-machine collaborative review: LLM generates a draft schema recommendation, and domain experts review, modify, and confirm whether to include it in the schema on the Kanban board; By combining Git version control with schema version management, change tracking and rollback can be achieved.

[0272] Input: Global candidate element report Output: Evolved Schema, which is a knowledge graph structure specification that has been filtered, reviewed, and versioned, ensuring the rationality, timeliness, and scalability of the Schema, and providing dynamically updated structural constraints for graph construction.

[0273] 6. Module 5: Two-layer graph construction (community detection, conflict detection).

[0274] Core technologies: Based on the evolved schema, construct an L1 / L2 two-layer knowledge graph: L1 layer (metadata and document relationship graph): Using legal / standard documents as nodes, it stores document metadata and the relationships between documents (substitution, reference, revision, etc.) to achieve macro-version management and positioning; L2 layer (fine-grained technical knowledge graph): includes a triplet instance data layer (technical entities and relationships), a fragment layer (ClauseUnit nodes), and a topic community layer (technical topic groups are generated through clustering using community detection algorithms); Built-in conflict detection mechanism: Identifies logical conflicts between different clauses of the same technical entity, providing a basis for subsequent resolution.

[0275] Input: EDOM file object, list of ClauseUnit objects, evolved Schema, structured triplet data.

[0276] Output: A two-layer knowledge graph (L1 / L2) that organically combines macro-level management of standard and regulatory documents with micro-level decomposition of technical elements.

[0277] 7. Module 6: Compliance Service Interface (Knowledge Graph Retrieval + Reasoning).

[0278] Core technologies: The two-layer knowledge graph is encapsulated into a service-oriented interface, providing knowledge graph retrieval and reasoning capabilities: Supports cross-document knowledge retrieval and natural language question answering; It supports business scenarios such as analysis of the impact of regulations / standards, automatic compliance review, and assistance in the formulation and revision of standards.

[0279] Input: L1 / L2 two-layer knowledge graph.

[0280] Output: Compliance service interface, providing knowledge services such as compliance review, standards management, and intelligent decision-making to industry users such as automakers, realizing the business value of knowledge graphs.

[0281] In this embodiment, storage is optimized: the L1 layer graph is centrally stored in a graph database, facilitating rapid location of regulations / standards and traversal of complex relationships. The L2 layer graph is stored in shards, divided into subgraphs based on "topic communities," with each community subgraph stored in the graph database. All entity and CLAuseUNit embedding vectors are stored in vector databases such as Milvus and Chroma, and the graph database node ID associated with each vector is recorded. This hybrid storage method supports hybrid retrieval: relation queries can be performed using the graph database, and semantic similarity retrieval can be performed using the vector database. When a natural language query is received, the vector of this natural language query is embedded in the vector database for semantic similarity retrieval, obtaining a set of related entities and CLAuseUNits. Then, with the recall node as the center, a graph traversal query is performed in the graph database to obtain its associated context nodes (such as associated clauses, superior and subordinate standards, referenced test methods) and relationship paths. Semantic matching and relationship reasoning are combined to form the answer subgraph.

[0282] Intelligent query and reasoning interface: This module encapsulates the aforementioned two-layer coupled knowledge graph into a series of programmable interfaces to support the following intelligent applications: Cross-document knowledge retrieval and question answering interfaces: Provides declarative query interfaces (such as extended GraphQL / Cypher) and natural language question answering interfaces. The workflow of the natural language question answering interface is as follows: First, the user's question is parsed into a graph query intent using a large language model and converted into a specific query statement. Then, the query is executed, retrieving relevant graph substructures and text fragments. Finally, this information is submitted as factual context to the large language model to generate the final answer.

[0283] Regulatory / Standard Impact Transmission Analysis Interface: Provides a dedicated API. Input an entity (such as a performance indicator) or event (such as a standard revision). The system automatically performs impact propagation analysis based on graph networks and outputs a list of affected standards, clauses, test methods, and components, as well as an impact path report.

[0284] Automatic compliance review interface: Provides an API, input product technical parameters or design documents, and the system automatically generates a compliance inspection report by matching the performance indicators, test methods and other requirements in the graph, identifying compliant, non-compliant and missing items.

[0285] Intelligent Assistance Interface for Standard Development and Revision: Provides intelligent recommendation functionality when drafting new standards or revising existing ones. For example, by inputting a technical topic, the system recommends existing standard clauses, relevant performance indicator systems, and testing methods to be referenced, and warns of potential conflicting clauses.

[0286] Reference Figure 5 This diagram illustrates a structural schematic of a knowledge graph construction apparatus provided in an embodiment of this application. The knowledge graph construction apparatus includes functional modules that implement any of the knowledge graph construction methods of this application, such as... Figure 5 As shown, the knowledge graph construction device 500 may include the following modules: The document acquisition module 510 is used to integrate the multimodal elements of the identified standard regulatory documents in the target domain to obtain a document object model data file. The list acquisition module 520 is used to perform clause-level semantic unit splitting on the document object model data file to obtain a list of clause unit objects. Data acquisition module 530 is used to extract information from the list of clause unit objects based on a predefined target graph pattern to obtain structured triplet data. The knowledge graph construction module 540 is used to construct a two-level knowledge graph based on the document object model data file, the list of clause unit objects, and the structured triplet data. The first level of the knowledge graph is a metadata and document relationship graph, used for macro-level positioning, version management, and impact scope analysis of standard and regulatory documents. The second level of the knowledge graph is a fine-grained technical knowledge graph, including: topic communities, fragment layers, and triplet instance data. The triplet instance data includes: entity nodes and the relationships between them. The fragment layer includes: nodes corresponding to all the clause unit objects. The topic community includes: virtual grouping nodes generated by clustering the entity nodes and their relationships in the second level.

[0287] This application also provides an electronic device 600, please refer to... Figure 6It includes a processor 610 and a memory 620, wherein the memory 610 is used to store computer programs; the processor 620 is used to execute the programs stored in the memory 610 to implement the knowledge graph construction method described in any embodiment of this application.

[0288] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the knowledge graph construction method described in any embodiment of this application.

[0289] In this application, "multiple" refers to two or more.

[0290] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for constructing a knowledge graph, characterized in that, include: The multimodal elements of the identified standard regulatory documents in the target domain are integrated to obtain a document object model data file; The document object model data file is split into clause-level semantic units to obtain a list of clause unit objects; Information is extracted from the list of clause unit objects based on a predefined target graph pattern to obtain structured triplet data. Based on the document object model data file, the list of clause unit objects, and the structured triplet data, a two-level knowledge graph is constructed. The first level of the knowledge graph is a metadata and document relationship graph, used for macro-level positioning, version management, and impact scope analysis of standard and regulatory documents. The second level of the knowledge graph is a fine-grained technical knowledge graph, including: topic communities, fragment layers, and triplet instance data. The triplet instance data includes: entity nodes and the relationships between them. The fragment layer includes: nodes corresponding to all clause unit objects. The topic community includes: virtual grouping nodes generated by clustering entity nodes and their relationships in the second level.

2. The method according to claim 1, characterized in that, The process of integrating the multimodal elements of the identified standard regulatory documents in the target domain yields a document object model data file, including: Obtain the standard regulatory documents for the target field; Extract the regulatory text elements from the standard regulatory document and perform layout analysis on the standard regulatory document to obtain the layout analysis results; Based on the layout analysis results, the standard regulatory document is cropped to obtain image slices; The image slices are identified by a visual language model based on set prompts to obtain non-text elements, and reference association information between the regulatory text elements and the non-text elements is established. The regulatory text elements, the non-text elements, and the reference association information are stored as a document object model data file in a specified format.

3. The method according to claim 1, characterized in that, The document object model data file is split into clause-level semantic units to obtain a list of clause unit objects, including: Based on the set prompt words and the file structure information of the document object model data file, the large language model segments the legal text elements and reference association information in the document object model data file to obtain a candidate fragment list. A tag-based multi-round iterative partitioning algorithm is used to process the candidate fragment list to obtain the clause unit object list; wherein, each clause unit object in the clause unit object list includes at least: regulatory text element, reference association information, original hierarchical path information, location reference information, document type and metadata.

4. The method according to claim 3, characterized in that, The candidate fragment list is processed using a label-based multi-round iterative partitioning algorithm to obtain the clause unit object list, including: Mark all candidate segments in the candidate segment list as pending processing. Each candidate segment in the pending state is input into the large language model, and the large language model performs a completeness judgment on each candidate segment based on the context information of each candidate segment, and outputs the completeness status and adjustment suggestion information of each candidate segment; The candidate segment list is reconstructed based on the adjustment suggestion information, and the candidate segments that need to be merged or split according to the integrity status are processed accordingly, and the marking status of the corresponding candidate segments is updated. Compare the candidate fragment lists before and after reconstruction to determine whether the convergence condition is met. If it is met, terminate the iteration and output the list of the clause unit objects.

5. The method according to claim 1, characterized in that, The information extraction from the list of clause unit objects based on the predefined target graph pattern yields structured triplet data, including: Determine the target map pattern; Based on predefined prompt words, the large language model extracts triple data that conform to the target graph pattern from the list of clause unit objects, and records candidate elements that are not defined in the target graph pattern. The candidate elements include: candidate entities, candidate relations and candidate attributes. The candidate entities in the candidate elements are matched and linked to obtain the processed candidate entities; The candidate relationships and candidate attributes in the candidate elements are subjected to type adaptation and constraint validation to obtain the processed candidate relationships and candidate attributes. The structured triplet data is obtained by integrating the triplet data, the processed candidate entities, the processed candidate relations, and the candidate attributes.

6. The method according to claim 1, characterized in that, Based on the document object model data file, the list of clause unit objects, and the structured triplet data, a two-level knowledge graph is constructed, including: Construct the first-level node, which is a standard regulatory document node, and set corresponding node attributes for the standard regulatory document node; Construct the relationships between the nodes of the first level to obtain the metadata and document relationship graph of the first level; Construct the triplet instance data layer node, fragment layer node, and topic community layer node of the second level; Set corresponding attributes for each node in the second level and establish the association between nodes in each level to obtain a fine-grained technical knowledge graph of the second level. Establish the association between the first-level map and the second-level map; The knowledge graph is configured with an event triggering and state synchronization mechanism. When a new document relationship is added to the first-level graph, the state synchronization and impact analysis of the relevant nodes in the second-level graph are triggered. Based on the impact analysis results, the state of the corresponding nodes in the second-level graph is adjusted.

7. The method according to claim 1, characterized in that, After constructing a two-level knowledge graph based on the document object model data file, the list of clause unit objects, and the structured triplet data, the method further includes: When a new standard or regulatory document is added to the database, its identifier and version metadata are extracted, and the identifier and version metadata are matched with the first-level graph to obtain the matching result. When the matching result indicates that the new standard regulation document is a completely new document, a complete document parsing, clause splitting, information extraction, and graph construction process is triggered to complete the construction of the corresponding hierarchical graph nodes and their relationships. When the matching result indicates that the new standard regulation document is a document with a revision or replacement relationship, the association between the new and old documents is established in the first-level graph. At the same time, the set of clause units of the new and old documents is compared, the type of clause change is detected, and the graph nodes and status of the second level are updated. The influence analysis and status adjustment of the associated nodes are performed. When the matching result indicates that the new standard regulation document is a duplicate document, the original map state remains unchanged.

8. The method according to claim 1, characterized in that, After constructing a two-level knowledge graph based on the document object model data file, the list of clause unit objects, and the structured triplet data, the method further includes: Traverse all clause nodes corresponding to the same technical entity in the knowledge graph, extract the association information of each clause node, and combine multiple dimensions of preset judgment conditions to determine whether the clause nodes constitute a conflict pair. Based on a pre-defined rule base, conflict resolution suggestions are generated for clause nodes that are identified as conflict pairs. The human-machine collaborative review method is used to review the judgment results of the conflict pairs and the conflict resolution suggestions, and to perform the corresponding conflict resolution operations based on the review results.

9. A knowledge graph construction device, characterized in that, include: The document acquisition module is used to integrate the multimodal elements of the identified standard regulatory documents in the target domain to obtain a document object model data file. The list acquisition module is used to perform clause-level semantic unit splitting on the document object model data file to obtain a list of clause unit objects. The data acquisition module is used to extract information from the list of clause unit objects based on a predefined target graph pattern to obtain structured triplet data. The knowledge graph construction module is used to construct a two-level knowledge graph based on the document object model data file, the list of clause unit objects, and the structured triplet data. The first level of the knowledge graph is a metadata and document relationship graph, used for macro-level positioning, version management, and impact scope analysis of standard and regulatory documents. The second level of the knowledge graph is a fine-grained technical knowledge graph, including: topic communities, fragment layers, and triplet instance data. The triplet instance data includes: entity nodes and the relationships between them. The fragment layer includes: nodes corresponding to all clause unit objects. The topic community includes: virtual grouping nodes generated by clustering entity nodes and their relationships in the second level.

10. An electronic device, characterized in that, Including processor and memory, among which, Memory, used to store computer programs; A processor for executing a program stored in memory to implement the method described in any one of claims 1-8.

Images