A method and system for automated construction of hydropower knowledge graph based on a large model

Abstract

This invention discloses an automated method and system for constructing a hydropower knowledge graph based on a large model. The method includes: constructing a hydropower semantic planning and ontology logic schema; constructing a large model knowledge graph agent, unifying multi-source heterogeneous data into a natural language sequence through context fusion, constructing a constraint-injected prompt containing logical constraints, calling the large model to extract candidate triples and performing multiple validations; constructing an automated knowledge extraction workflow to achieve end-to-end processing of multi-source documents; and writing triples into a graph database through knowledge fusion and dynamic graph integration. This invention solidifies hydropower business rules into computable constraints, driving the large model to accurately extract knowledge within a semantic framework. It effectively solves the problems of traditional methods such as reliance on manual labor, weak generalization ability, and extraction results easily violating hydropower logic. This significantly improves the automation, accuracy, and logical consistency of knowledge graph construction while reducing manual maintenance costs.

Description

Technical Field

[0001] This invention belongs to the field of artificial intelligence and knowledge graph technology, specifically relating to an automated construction method and system for hydropower knowledge graph based on a large model. Background Technology

[0002] Current applications of knowledge graph construction technology in the hydropower field mainly fall into three categories. Traditional rule-based methods match entities and relationships from text using predefined domain dictionaries or annotation templates and regular expressions. For example, rule engines are used to parse technical documents and extract "equipment-function" relationships, such as "hydro turbine → power generation." Traditional machine learning methods employ Conditional Random Field (CRF) or Named Entity Recognition (NER) models, combined with manually labeled data, for entity extraction. Common examples include BiLSTM-CRF models, which, after being trained with annotations, can identify faulty equipment and their causes from defect reports. In the past two years, some research has attempted to utilize general-purpose large models, such as GPT, LLaMA, and Qwen, for open-domain knowledge graph construction. The typical process involves inputting raw text, designing a prompt, and the model outputting triples. However, the extraction results are often directly related to individual technical experience.

[0003] Rule-based and traditional machine learning methods rely on manually defined dictionaries, templates, or labeled data, resulting in weak generalization capabilities, high maintenance costs, and difficulty in handling the complexity and dynamism of hydropower texts. While generalized large language models (LLMs) offer high extraction efficiency, in highly specialized fields like hydropower, agents cannot determine the reasonableness of extraction results if they are unaware of business rules such as the governor belonging to a specific hydropower generator unit or the shutdown protection being triggered by exceeding certain setpoint limits. The main reason is the lack of embedded hydropower business logic, which easily generates semantic errors or invalid triples. The generated results often violate the logical relationships of hydropower equipment, and the frequent occurrence of fragmented contextual information leads to extraction results that cannot be aligned with a unified knowledge model, making integration difficult. Furthermore, the lack of modular design prevents the implementation of differentiated processing strategies for different needs such as full-text, tables, and metadata.

[0004] Therefore, it is necessary to design an automated construction method and system for hydropower knowledge graphs based on large models to solve the above problems. Summary of the Invention

[0005] The purpose of this invention is to provide an automated method and system for constructing a hydropower knowledge graph based on a large model. This aims to address several issues in existing technologies, including: the failure of semantic constraints in the hydropower domain (i.e., how to transform hydropower business rules into executable semantic specifications to constrain the extraction behavior of large models); the disconnect between the knowledge graph schema and workflow (i.e., how to design a structured workflow to achieve differentiated processing and seamless integration of full text, tables, metadata, and triples); insufficient accuracy in large model extraction (i.e., how to construct domain-constrained agent operators to enable accurate knowledge extraction within the hydropower semantic framework); and low automation in the knowledge graph construction process (i.e., how to achieve end-to-end automated construction from raw multimodal data to the knowledge graph, eliminating the problems of manual rule formulation, annotation, and verification). By deeply integrating hydropower domain expertise with large model technology, an end-to-end automated knowledge graph construction pipeline is constructed, achieving efficient and accurate conversion from unstructured text to structured knowledge graphs. The core innovation lies in solidifying hydropower industry standards, business logic, empirical rules, and equipment object relationships into semantic constraints. It further transforms hydropower industry knowledge into computable ontology constraints and drives the large model agent to adaptively extract hydropower domain knowledge through a "constraint injection-type Prompt + two-stage rule verification" mechanism, achieving end-to-end controllable extraction. At the same time, it decouples the design data processing and knowledge graph injection core nodes, constructs an event-driven automated workflow for graph construction, and avoids the high cost and high error problems of traditional manual annotation.

[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: An automated method for constructing a hydropower knowledge graph based on a large model includes the following steps: S1. Construct a hydropower semantic planning and hydropower ontology logical schema; the schema should include at least a set of hydropower knowledge graph entity types E, a set of relation types R, and a set of logical constraints C. S2, constructs a large model knowledge graph Agent, which serves as the core operator module for each node in the knowledge extraction workflow, including full-text extraction, meta-information extraction, table extraction, and triple extraction. S3 constructs an automated knowledge extraction workflow, which includes a series of full-text extraction nodes, metadata extraction nodes, table extraction nodes, and triplet extraction nodes. S4 uses the triples output from the automated knowledge extraction workflow to perform knowledge fusion and dynamic graph input operations, writing the triples into the graph database to complete the automated construction of the knowledge graph.

[0007] Preferably, step S1 includes the following steps: S101, Define the entity type E of the hydropower knowledge graph as {hydropower station, system, equipment, component, technical parameter, event, document, relationship, logical constraint}; S102, define the system subclass set E1={hydro turbine generator set, power grid distribution system, power output and plant power system, technical water supply system...}; S103, define the equipment subclass set E2 = {water turbine, governor, generator, excitation system...}; S104, define the component subclass set E3 = {turbine main shaft, runner, upper crown, lower ring, blades, spillway cone...}; S105, define the parameter subclass set E4 = {rated power, head, voltage, temperature, ...}; S106, Define the event subclass set E5 = {Normal, Alarm, Warning, Defect, Fault, Maintenance...}; S107, Define the document subclass collection E6 = {National Standards, Industry Standards, Company Procedures, Case Documents, Defect Reports, Maintenance Reports, Equipment History, etc.}; S108, define the set of relation types R = {Composition, Driver, Protection, Monitoring, Association, Technical Parameter, Source, Applicable...}; S109 defines a set of logical constraints C, which includes a multi-level, computable, and self-verifiable rule system that transforms the professional knowledge, business logic, and operating procedures in the hydropower field into automated verification rules that can be executed by machines. S110, Design the calculation rule system for entity set E; S111 defines the extraction rules, encodes the sets E, R, and C into JSON format files, and generates a structured file conforming to the OWL2 standard, which includes entity / relationship definitions, attribute constraints, and rule engine configurations, serving as the semantic benchmark for subsequent extraction.

[0008] Preferably, in step S109, the logical constraint set C includes: C1 Subordination Constraint: E2 must belong to a certain system E1, and E3 must belong to E2 (e.g., "governor" must be associated with "hydro turbine"). C2 Factual Relationship Constraint: Events must be associated with parameters (e.g., "temperature exceeds limit" is associated with "temperature threshold"); C3 Business Logic Constraints: Rule relationships must satisfy the "condition → action" logic (e.g., "tailrace gate slides down 2m → trigger alarm"). C4 Device Logical Object Instantiation Constraints: Any device entity must have a non-null attribute, such as "belonging to a unit or system"; C5 event class constraint: Any event entity must be associated with at least one parameter instance; C6 Computable Logical Constraints: For each relation r in the relation type set R, define its allowed head entity type set HeadType(r) and tail entity type set TailType(r) such that for any candidate triple (h, r, t), h∈HeadType(r) and t∈TailType(r) must be satisfied. Preferably, in the C6 computable logical constraint, if r = "technical parameter" in the triple (h, r, t), then h ∈ E3 and t ∈ E4.

[0009] Preferably, in step S110, the design of the calculation rule system for entity set E includes entity hierarchical classification and attribution rules, specifically including: Rule E-R1, hierarchical progressive rule: Entity classification follows the physical composition hierarchy of "hydropower station → system → equipment → component". Any lower-level entity must be linked to its direct superior entity through a membership or composition relationship. Rule E-R2, multi-dimensional labeling rule: Each entity must be labeled with at least two dimensions: physical dimension labels: {hydropower station, system, equipment, component, parameter} and business dimension labels: {operation entity, monitoring entity, control entity, document entity, event entity}.

[0010] Preferably, in step S110, the design of the calculation rule system for entity set E includes entity recognition and disambiguation rules, specifically including: Rule E-R3, Standard Terminology Precedence Rule: The input text terms are matched against the hydropower standard terminology database. If there is a complete match, they are directly mapped to standard entity names. If there is no complete match, the word vector similarity is calculated. If the similarity is greater than 0.85, it is mapped to the most similar standard entity. If the similarity is less than or equal to 0.85, it is marked as a new entity pending review. Rule E-R4, Context Disambiguation Rule: Disambiguation of ambiguous entities is performed based on the context: For example, when "rotor" appears, it is judged according to the context: if the context contains "generator" → it is marked as "generator rotor", if the context contains "hydro turbine" → it is marked as "hydro turbine runner", if there is no clear context → it is marked as "rotor (to be determined)".

[0011] Preferably, in step S110, the calculation rule system design for entity set E includes relation type determination rules, specifically including: Physical topology determination: If entity A and entity B appear simultaneously in the text, and there are expressions such as "device A is B", "device A is composed of B", or "device A contains B", then relation R = "composes"; if there are expressions such as "device A drives B" or "device A drives B", then relation R = "drives"; if there are expressions such as "device A monitors B" or "device A detects B", then relation R = "monitors". Determining business logic relationships: If entity A is an event and entity B is a device or parameter, and A describes a change in the state of B, then relation R = "affects"; if A is caused by B, then relation R = "causes"; if A requires inspection or repair of B, then relation R = "related to maintenance". Relationship direction calculation: The direction of compositional relationships is from the whole to the parts; the direction of technical parameter relationships is from the components to the parameters; and the direction of monitoring relationships is from the monitoring equipment to the monitored equipment.

[0012] Furthermore, in step S109, the calculation rules for the logical constraint set C include: Mandatory dependency checks ensure that the physical composition relationships between entities conform to the standard hierarchical structure of hydropower equipment. For example, for any equipment entity ∈ E2, there must be at least one triple (equipment, 'belongs to', system), where system ∈ E1 (system class entity); for any component entity component ∈ E3, there must be at least one triple (component, 'belongs to', equipment), where equipment ∈ E2 (equipment class entity); if the (A, 'composes of', B) relationship exists, then the (B, 'belongs to', A) relationship must also exist; all dependencies of equipment under a system in the knowledge graph must be closed. Factual relationship constraints ensure that the association between events and parameters, and states and measurements, conforms to physical facts. Event-parameter-device associations are mandatory; for example, for any event entity ∈ E5, one of the following conditions must be met: a. There exists a triple (event, 'associated parameter', parameter), where parameter ∈ E4; b. There exists a triple (event, 'acts on', device), where device ∈ E2. Business logic constraints are a computable rule system designed specifically for coding the operating procedures, workflows, and protection mechanisms of the hydropower industry in this invention. Unlike syntactic and semantic constraints, they focus on verifying the rationality of business processes, temporal logic, and operational compliance.

[0013] Preferably, in step S2, the large model knowledge graph Agent, as a core operator module, is configured to perform the following operations: S201, deploying large language models as the technical foundation for extracting key elements of knowledge graphs; S202, Standardized Input Interface Operation: The Agent pre-designs an interface to connect to the input data and designs a standardized data object, which contains the following three elements: text_blocks: A list of sentences extracted from the full-text nodes; metadata: A dictionary derived from the metadata extraction nodes; table_rows: A list of dictionaries from which nodes are extracted from the table; S203, preprocess the input from step S202 through context fusion, converting the information in the metadata into natural language descriptions and inserting them into the header of text_blocks; converting each row of data in table_rows into a structured description sentence; concatenating all the processed text into a single string fused_text; specifically as follows: If table_rows is not empty, then iterate through each dictionary row and generate a structured description sentence; If metadata is not empty and contains an applicable_unit field, then insert a sentence at the beginning of text_blocks; The merged text_blocks are concatenated into a single string fused_text; S204, classify according to the extraction task type, the extraction task type includes full text extraction, metadata extraction, table extraction and triplet extraction, and corresponds to the automated workflow in step S3; S205, construct a customized Prompt according to the task type, obtain the entity set E, relation set R, and constraint set C from step S1, and construct a Prompt template based on the JSON file encoded in step S111. S206, Invoke the large language model, pass in the Prompt, and obtain the response text; S207, Multiple Constraint Verification: After passing in the file to be extracted and completing the context fusion through standardization, the input module is called and the deployed large language model is started. The above Prompt is passed in to obtain the response text. Parse the response text and extract all candidate triples of the form [(A, B, C)]. Perform multiple checks on each candidate triple (h, r, t), including hydropower logic checks and hydropower semantic checks: Hydropower logic verification: Verify h∈(E∪E1∪E2∪E3∪E4), t∈(E∪E1∪E2∪E3∪E4), r∈R; Hydropower semantic verification: If r = "technical parameters", then force verification of h∈E3 and t∈E4; The triples that pass all validations are retained as the final output of the Agent; S208, through the output and integration module, generates a knowledge graph from the final output triples and calls the graph database interface to achieve automated database entry.

[0014] Preferably, step S3 specifically includes: designing a modular workflow, predefining four nodes: full-text extraction, metadata extraction, table extraction, and triplet extraction, and matching them with step S2 to achieve end-to-end processing of multi-source heterogeneous data such as technical manuals (PDF / Word), accident reports (plain text), equipment parameter tables (Excel), and maintenance records (structured tables). S301, Configure the full-text extraction node: Configure the Agent preset in step S2 to extract general text, parse unstructured text, and output text blocks with semantic tags (e.g., "The turbine rotor experienced abnormal vibration during operation" is output as "The turbine rotor experienced abnormal vibration during operation"). S302, Configure the metadata extraction node: Link with step S1, embed business logic rules and hydropower-specific ontology logic, configure the Agent preset in step S2 to extract metadata, extract document metadata (author, version number, applicable unit number), and generate a metadata table (such as {"applicable unit": "#3 unit", "version": "V2.1"}). S303, Configure table extraction node: Configure the large model Agent operator identification device parameter table preset in step S2, convert it into a structured table, convert the table into a dictionary list by row, and assign the technical parameters to specific systems, devices or components according to the constraints of step S1. S304, Configure the triple extraction node: Link with step S1, embed business logic rules and water and electricity-specific ontology logic, configure the Agent preset in step S2 to extract triples, receive text blocks / tables / meta information, call the large model Agent to execute the extraction task, and realize the automation of "input → structured output". The above four nodes constitute an end-to-end knowledge graph construction pipeline. Among them, the triple extraction node is the core intelligent node that performs semantic understanding and knowledge generation, while the other three nodes are data preprocessing nodes.

[0015] Preferably, step S4 specifically includes: Perform Jaccard similarity conflict resolution on the triples output by the Agent; The triplet after elimination is subjected to multiple checks in step S3 again to prevent logical errors from being introduced by fusion; Batch writes are performed using the graph database's API, and incremental triggers are configured so that only the corresponding workflow node is triggered when a new file is written.

[0016] Preferably, an automated construction system for a hydropower knowledge graph based on a large model is provided for executing the automated construction method for a hydropower knowledge graph based on a large model. The system includes: The hydropower semantic planning module is configured to construct a hydropower semantic planning and hydropower ontology logic schema. The schema includes at least a set of entity types E of the hydropower knowledge graph, a set of relation types R, and a set of logical constraints C used to transform hydropower domain expertise, business logic, and operating procedures into machine-executable automated verification rules. The large-scale knowledge graph Agent module is configured as the core operator for each node in the knowledge extraction workflow. The Agent module includes: The input interface unit is used to receive standardized input data, which includes at least one of a list of text blocks, a metadata dictionary, and table row data. The context fusion unit is used to convert the metadata dictionary and table row data into natural language descriptions and then fuse them with the list of text blocks to generate a fused text sequence. The Prompt construction unit is used to obtain the entity type set E, relation type set R, and logical constraint set C from the hydropower semantic planning module according to the extracted task type, and construct a constraint injection Prompt containing the logical constraint set C. The large model calling unit is used to call the large language model. It inputs the fused text sequence and the constraint-injected Prompt together to obtain the candidate triples output by the large language model. The multi-validation unit is used to perform multi-validation on candidate triples. The multi-validation includes schema-level validation based on entity type set E and relation type set R, and business logic-level validation based on logical constraint set C. The output unit is used to output the triplet that passes all verifications as the Agent. The automated workflow module is configured to build and execute an automated knowledge extraction workflow. The workflow includes a series of full-text extraction nodes, metadata extraction nodes, table extraction nodes, and triplet extraction nodes. The full-text extraction nodes, metadata extraction nodes, and table extraction nodes are configured with the large model knowledge graph agent module for data preprocessing, while the triplet extraction node is configured with the large model knowledge graph agent module for core knowledge extraction. The knowledge fusion and graph entry module is configured to perform knowledge fusion and dynamic graph entry operations on the triples output by the automated workflow module, write the triples into the graph database, and complete the automated construction of the knowledge graph.

[0017] Furthermore, the multi-verification unit of the large model knowledge graph Agent module further includes: The hydropower logic verification subunit is used to verify that the head entity and tail entity of the candidate triplet belong to the entity type set E, and the relation belongs to the relation type set R. The hydropower semantic verification subunit is used to verify whether candidate triples conform to hydropower business logic based on the logical constraint set C. The logical constraint set C includes at least: subordinate relationship constraints, factual relationship constraints, business logic constraints, equipment logical object instantiation constraints, event class constraints, and computable logical constraints.

[0018] Furthermore, in the automated workflow module: The full-text extraction node is configured to parse unstructured text and output a list of text blocks with semantic tags; The metadata extraction node is configured to extract document metadata and generate a metadata dictionary. The table extraction node is configured to recognize tables in a document and convert them into a dictionary list by row. The triplet extraction node is configured to receive the text block list, the metadata dictionary, and the dictionary list, and then call... The large-scale model knowledge graph Agent module performs execution context fusion, constraint injection-based prompt construction, large-scale model invocation, and multiple verifications, outputting triples that conform to the logic of the hydropower domain.

[0019] Furthermore, the knowledge fusion and graph integration module includes: The conflict resolution unit is configured to perform Jaccard similarity conflict resolution on the triples output by the automated workflow module; The secondary verification unit is configured to perform the multiple verification again on the resolved triplet to prevent logical errors introduced by fusion. The batch write unit is configured to call the graph database interface to write triples in batches. The incremental trigger unit is configured to monitor the file directory. When a new file is written, it triggers the corresponding workflow node to achieve incremental updates of the knowledge graph.

[0020] Furthermore, the hydropower semantic planning module is configured to encode the entity type set E, relation type set R, and logical constraint set C into a JSON format file, generating a structured file conforming to the OWL2 standard, which serves as the semantic benchmark for the large model knowledge graph Agent module.

[0021] Furthermore, it also includes a computer device comprising a memory and a processor, which are interconnected and communicate with each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the aforementioned automated construction method for hydropower knowledge graph based on a large model.

[0022] Furthermore, it also includes a computer-readable storage medium storing computer instructions for causing a computer to execute the described automated construction method for a large-model-based hydropower knowledge graph.

[0023] The beneficial effects of the automated construction method and system for hydropower knowledge graph based on a large model provided by this invention are as follows: This invention innovatively proposes an automated knowledge graph construction architecture for hydropower, consisting of "hydropower semantic specification constraints + domain standard driving + large-scale model precise extraction + dynamic fusion into the graph." It constructs a knowledge extraction agent with a large model as the core, using pre-constraints such as hydropower logical rules and semantic specifications to prevent illegal triples like "tailrace level → located → power plant." Post-processing multiple checks improve the accuracy of knowledge extraction. Task nodes for text recognition, metadata recognition, table recognition, and triple recognition are designed to drive the large-scale model agent to perform domain-adaptive knowledge extraction. This constructs an end-to-end automated workflow from multi-source heterogeneous documents to a high-quality knowledge graph. This method effectively solves the problems of traditional construction methods being highly dependent on manual labor, costly, and inconsistent. It achieves precise hydropower knowledge extraction, automated process operation, and computable domain knowledge, providing a general solution for the intelligent construction of knowledge graphs in the hydropower industry and even the energy industry. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the method flow of the present invention; Figure 2 This is a schematic diagram of the process of constructing a large model knowledge graph agent in an embodiment of the present invention; Figure 3 This is a schematic diagram of the system structure in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of the multiple verification unit in an embodiment of the present invention; Figure 5 This is a schematic diagram of the knowledge fusion and image input module in an embodiment of the present invention. Figure 6 This is a comparison chart of the extraction effects of different methods in the embodiments of the present invention; Figure 7 This is a comparison chart of the logic error rates of different methods in the embodiments of the present invention; Figure 8 This is a comparison chart of labor costs for different methods in the embodiments of the present invention; Figure 9 This is a comprehensive comparison diagram between the method described in this embodiment and the general large model. Figure 10 This is a schematic diagram of the structure of a computer device in an embodiment of the present invention. Detailed Implementation

[0025] Example 1: like Figure 1 As shown, an automated method for constructing a hydropower knowledge graph based on a large model includes the following steps: S1. Construct a hydropower semantic planning and hydropower ontology logical schema; the schema should include at least a set of hydropower knowledge graph entity types E, a set of relation types R, and a set of logical constraints C. S2, constructs a large model knowledge graph Agent, which serves as the core operator module for each node in the knowledge extraction workflow, including full-text extraction, meta-information extraction, table extraction, and triple extraction. S3 constructs an automated knowledge extraction workflow, which includes a series of full-text extraction nodes, metadata extraction nodes, table extraction nodes, and triplet extraction nodes. S4 uses the triples output from the automated knowledge extraction workflow to perform knowledge fusion and dynamic graph input operations, writing the triples into the graph database to complete the automated construction of the knowledge graph.

[0026] Preferably, step S1 has the following features: Based on authoritative standards such as "Terminology for Hydropower Station Equipment" (GB / T 15601-2018) and "Electric Power Safety Regulations" (DL / T 1056-2021), a hydropower-specific ontology logic (Schema) is designed to achieve standardized and structured expression of domain knowledge. Entity types are fully covered from the equipment dimension and business dimension, and are constrained by rules.

[0027] Step S1 includes the following steps: S101, Define the entity type E of the hydropower knowledge graph as {hydropower station, system, equipment, component, technical parameter, event, document, relationship, logical constraint}; S102, define the system subclass set E1={hydro turbine generator set, power grid distribution system, power output and plant power system, technical water supply system...}; S103, define the equipment subclass set E2 = {water turbine, governor, generator, excitation system...}; S104, define the component subclass set E3 = {turbine main shaft, runner, upper crown, lower ring, blades, spillway cone...}; S105, define the parameter subclass set E4 = {rated power, head, voltage, temperature, ...}; S106, Define the event subclass set E5 = {Normal, Alarm, Warning, Defect, Fault, Maintenance...}; S107, Define the document subclass collection E6 = {National Standards, Industry Standards, Company Procedures, Case Documents, Defect Reports, Maintenance Reports, Equipment History, etc.}; S108, define the set of relation types R = {Composition, Driver, Protection, Monitoring, Association, Technical Parameter, Source, Applicable...}; S109 defines a set of logical constraints C, which includes a multi-level, computable, and self-verifiable rule system that transforms the professional knowledge, business logic, and operating procedures in the hydropower field into automated verification rules that can be executed by machines. S110, Design the calculation rule system for entity set E; S111 defines the extraction rules, encodes the sets E, R, and C into JSON format files, and generates a structured file conforming to the OWL2 standard, which includes entity / relationship definitions, attribute constraints, and rule engine configurations, serving as the semantic benchmark for subsequent extraction.

[0028] Preferably, in step S109, the logical constraint set C includes: C1 Subordination Constraint: E2 must belong to a certain system E1, and E3 must belong to E2 (e.g., "governor" must be associated with "hydro turbine"). C2 Factual Relationship Constraint: Events must be associated with parameters (e.g., "temperature exceeds limit" is associated with "temperature threshold"); C3 Business Logic Constraints: Rule relationships must satisfy the "condition → action" logic (e.g., "tailrace gate slides down 2m → trigger alarm"). C4 Device Logical Object Instantiation Constraints: Any device entity must have a non-null attribute, such as "belonging to a unit or system"; C5 event class constraint: Any event entity must be associated with at least one parameter instance; C6 Computable Logical Constraints: For each relation r in the relation type set R, define its allowed head entity type set HeadType(r) and tail entity type set TailType(r) such that for any candidate triple (h, r, t), h∈HeadType(r) and t∈TailType(r) must be satisfied. Preferably, in the C6 computable logical constraint, if r = "technical parameter" in the triple (h, r, t), then h ∈ E3 and t ∈ E4.

[0029] Preferably, in step S110, the design of the calculation rule system for entity set E includes entity hierarchical classification and attribution rules, specifically including: Rule E-R1, hierarchical progressive rule: Entity classification follows the physical composition hierarchy of "hydropower station → system → equipment → component". Any lower-level entity must be linked to its direct superior entity through a membership or composition relationship. Rule E-R2, multi-dimensional labeling rule: Each entity must be labeled with at least two dimensions: physical dimension labels: {hydropower station, system, equipment, component, parameter} and business dimension labels: {operation entity, monitoring entity, control entity, document entity, event entity}.

[0030] Preferably, in step S110, the design of the calculation rule system for entity set E includes entity recognition and disambiguation rules, specifically including: Rule E-R3, Standard Terminology Precedence Rule: The input text terms are matched against the hydropower standard terminology database. If there is a complete match, they are directly mapped to standard entity names. If there is no complete match, the word vector similarity is calculated. If the similarity is greater than 0.85, it is mapped to the most similar standard entity. If the similarity is less than or equal to 0.85, it is marked as a new entity pending review. Rule E-R4, Context Disambiguation Rule: Disambiguation of ambiguous entities is performed based on the context: For example, when "rotor" appears, it is judged according to the context: if the context contains "generator" → it is marked as "generator rotor", if the context contains "hydro turbine" → it is marked as "hydro turbine runner", if there is no clear context → it is marked as "rotor (to be determined)".

[0031] Preferably, in step S110, the calculation rule system design for entity set E includes relation type determination rules, specifically including: Physical topology determination: If entity A and entity B appear simultaneously in the text, and there are expressions such as "device A is B", "device A is composed of B", or "device A contains B", then relation R = "composes"; if there are expressions such as "device A drives B" or "device A drives B", then relation R = "drives"; if there are expressions such as "device A monitors B" or "device A detects B", then relation R = "monitors". Determining business logic relationships: If entity A is an event and entity B is a device or parameter, and A describes a change in the state of B, then relation R = "affects"; if A is caused by B, then relation R = "causes"; if A requires inspection or repair of B, then relation R = "related to maintenance". Relationship direction calculation: The direction of compositional relationships is from the whole to the parts; the direction of technical parameter relationships is from the components to the parameters; and the direction of monitoring relationships is from the monitoring equipment to the monitored equipment.

[0032] Furthermore, in step S109, the calculation rules for the logical constraint set C include: Mandatory dependency checks ensure that the physical composition relationships between entities conform to the standard hierarchical structure of hydropower equipment. For example, for any equipment entity ∈ E2, there must be at least one triple (equipment, 'belongs to', system), where system ∈ E1 (system class entity); for any component entity component ∈ E3, there must be at least one triple (component, 'belongs to', equipment), where equipment ∈ E2 (equipment class entity); if the (A, 'composes of', B) relationship exists, then the (B, 'belongs to', A) relationship must also exist; all dependencies of equipment under a system in the knowledge graph must be closed. Factual relationship constraints ensure that the association between events and parameters, and states and measurements, conforms to physical facts. Event-parameter-device associations are mandatory; for example, for any event entity ∈ E5, one of the following conditions must be met: a. There exists a triple (event, 'associated parameter', parameter), where parameter ∈ E4; b. There exists a triple (event, 'acts on', device), where device ∈ E2. Business logic constraints are a computable rule system designed specifically for coding the operating procedures, workflows, and protection mechanisms of the hydropower industry in this invention. Unlike syntactic and semantic constraints, they focus on verifying the rationality of business processes, temporal logic, and operational compliance.

[0033] like Figure 2 As shown, in step S2, the large model knowledge graph Agent, as a core operator module, is configured to perform the following operations: S201, deploying large language models as the technical foundation for extracting key elements of knowledge graphs; S202, Standardized Input Interface Operation: The Agent pre-designs an interface to connect to the input data and designs a standardized data object, which contains the following three elements: text_blocks: A list of sentences extracted from the full-text nodes; metadata: A dictionary derived from the metadata extraction nodes; table_rows: A list of dictionaries from which nodes are extracted from the table; S203, preprocess the input from step S202 through context fusion, converting the information in the metadata into natural language descriptions and inserting them into the header of text_blocks; converting each row of data in table_rows into a structured description sentence; concatenating all the processed text into a single string fused_text; specifically as follows: If table_rows is not empty, then iterate through each dictionary row and generate a structured description sentence; If metadata is not empty and contains an applicable_unit field, then insert a sentence at the beginning of text_blocks; The merged text_blocks are concatenated into a single string fused_text; S204, classify according to the extraction task type, the extraction task type includes full text extraction, metadata extraction, table extraction and triplet extraction, and corresponds to the automated workflow in step S3; S205, Construct a customized Prompt based on the task type. Obtain the entity set E, relation set R, and constraint set C from step S1, and construct a Prompt template based on the JSON file encoded in step S111; a specific example is as follows: The following is a sample of the knowledge extraction agent prompt: As a knowledge extraction expert in the hydropower field, please strictly follow the following schema when performing tasks. Entity type: {E}; Relation type: {R}; Logical constraint: {C}; Input content: {fused_text} Output requirements: Return a list of triples that conform to the schema, in the format: [('header entity', 'relation', 'tail entity')], and reject any invalid triples.

[0034] Role setting: You are a knowledge extraction expert in the hydropower industry. Your task is to extract accurate and structured triples based on the original text provided by the user, strictly following the given schema.

[0035] Triplet extraction rules: 1. Fully understand the semantic and structural information of the original text, and accurately determine entities and attributes based on the contextual semantics.

[0036] 2. Extraction should be based on the original text itself. Note: Citations, references, and other similar content should not be used as the basis for attributes such as author, date, or source.

[0037] 3. Time-related attributes should be extracted from the main text first.

[0038] For example, if the original text contains the phrase "October 2, 2012 to October 7, 2012", then the publication time should be 2012-10-07 00:00:00; if the original text does not provide a corresponding time, then an empty string should be returned; all times should be in the format: `YYYY-MM-DD 00:00:00`.

[0039] 4. Applicable logic devices: Extract directly from the title or text, for example: "This standard applies to governors, water turbines, ultrasonic flow measurement devices, and disc valves."

[0040] Output format example: {"Applicable": {"Logical Device": ["Governor","Water Turbine","Ultrasonic Flow Measurement Device","Disc Valve"]}}; If the original text does not contain the corresponding content, it will be empty.

[0041] 5. Applicable Systems (Medium Systems): Refer to the main text or the first paragraph, for example: "This standard applies to the thrust bearing system of xx unit, the upper guide bearing system of xx unit, and the Gezhouba 4F oil system."

[0042] Output format: {"Applicable": {"System": ["11F Thrust Bearing System","xx Upper Guide Bearing System","xx Oil System"]}}; if not present, leave empty.

[0043] 6. Applicable Equipment (Medium-sized Equipment): For example: "This equipment is suitable for the 5LH current transformer at the generator end of the xx unit, the 541# lower layer rod of the generator stator, and the 8# exhaust valve upstream."

[0044] Output format: {"Applicable": {"Equipment": ["5LH current transformer at generator terminal of xx unit","541# lower layer conductor of generator stator of xx unit","8# exhaust valve upstream of xx unit"]}}; if not present, leave blank.

[0045] 7. Related departments: For example: "This standard is associated with the power generation division, electrical division, electrical maintenance department, etc."

[0046] Output format: {"Related": {"Department": ["Power Generation Division","Electrical Division","Electrical Maintenance Department"]}}, if not present, it will be empty.

[0047] 8. Related Majors: For example: "This standard involves related professional electrical primary, electrical secondary, lifting metal structures, hydraulic engineering, machinery, and gantry cranes."

[0048] Output format: {"Related": {"Specialty": ["Electrical Primary","Electrical Secondary","Lifting Metal Structure","Hydraulic Engineering","Mechanical","Gantry"]}}, if not present, it will be empty.

[0049] 9. National Standard Entity Construction Rules: The standard number and the Chinese standard name are combined into a single entity name.

[0050] Example: Number: DL / T722-2014; Name: Guidelines for Analysis and Judgment of Dissolved Gases in Transformer Oil → Entity name: DL / T722-2014 Guidelines for Analysis and Judgment of Dissolved Gases in Transformer Oil.

[0051] 10. Standard type fixed return: Industry test standard.

[0052] 11. The logical device in the applicable relationship is fixedly supplemented with: ["main transformer system", "main transformer"]. If the original text does not have explicit data, these two values ​​should also be returned.

[0053] S206, Invoke the large language model, pass in the Prompt, and obtain the response text; S207, Multiple Constraint Verification: After passing in the file to be extracted and completing the context fusion through standardization, the input module is called and the deployed large language model is started. The above Prompt is passed in to obtain the response text. Parse the response text and extract all candidate triples of the form [(A, B, C)]. Perform multiple checks on each candidate triple (h, r, t), including hydropower logic checks and hydropower semantic checks: Hydropower logic verification: Verify h∈(E∪E1∪E2∪E3∪E4), t∈(E∪E1∪E2∪E3∪E4), r∈R; Hydropower semantic verification: If r = "technical parameters", then force verification of h∈E3 and t∈E4; The triples that pass all validations are retained as the final output of the Agent; S208, through the output and integration module, generates a knowledge graph from the final output triples and calls the graph database interface to achieve automated database entry.

[0054] Preferably, step S3 specifically includes: designing a modular workflow, predefining four nodes: full-text extraction, metadata extraction, table extraction, and triplet extraction, and matching them with step S2 to achieve end-to-end processing of multi-source heterogeneous data such as technical manuals (PDF / Word), accident reports (plain text), equipment parameter tables (Excel), and maintenance records (structured tables). S301, Configure the full-text extraction node: Configure the Agent preset in step S2 to extract general text, parse unstructured text, and output text blocks with semantic tags (e.g., "The turbine rotor experienced abnormal vibration during operation" is output as "The turbine rotor experienced abnormal vibration during operation"). S302, Configure the metadata extraction node: Link with step S1, embed business logic rules and hydropower-specific ontology logic, configure the Agent preset in step S2 to extract metadata, extract document metadata (author, version number, applicable unit number), and generate a metadata table (such as {"applicable unit": "#3 unit", "version": "V2.1"}). S303, Configure table extraction node: Configure the large model Agent operator identification device parameter table preset in step S2, convert it into a structured table, convert the table into a dictionary list by row, and assign the technical parameters to specific systems, devices or components according to the constraints of step S1. S304, Configure the triple extraction node: Link with step S1, embed business logic rules and water and electricity-specific ontology logic, configure the Agent preset in step S2 to extract triples, receive text blocks / tables / meta information, call the large model Agent to execute the extraction task, and realize the automation of "input → structured output". The above four nodes constitute an end-to-end knowledge graph construction pipeline. Among them, the triple extraction node is the core intelligent node that performs semantic understanding and knowledge generation, while the other three nodes are data preprocessing nodes.

[0055] Preferably, step S4 specifically includes: Perform Jaccard similarity conflict resolution on the triples output by the Agent; The triplet after elimination is subjected to multiple checks in step S3 again to prevent logical errors from being introduced by fusion; Batch writes are performed using the graph database's API, and incremental triggers are configured so that only the corresponding workflow node is triggered when a new file is written.

[0056] like Figure 3 As shown, preferably, an automated construction system for hydropower knowledge graphs based on large models is provided for executing the automated construction method for hydropower knowledge graphs based on large models. The system includes: The hydropower semantic planning module is configured to construct a hydropower semantic planning and hydropower ontology logic schema. The schema includes at least a set of entity types E of the hydropower knowledge graph, a set of relation types R, and a set of logical constraints C used to transform hydropower domain expertise, business logic, and operating procedures into machine-executable automated verification rules. The large-scale knowledge graph Agent module is configured as the core operator for each node in the knowledge extraction workflow. The Agent module includes: The input interface unit is used to receive standardized input data, which includes at least one of a list of text blocks, a metadata dictionary, and table row data. The context fusion unit is used to convert the metadata dictionary and table row data into natural language descriptions and then fuse them with the list of text blocks to generate a fused text sequence. The Prompt construction unit is used to obtain the entity type set E, relation type set R, and logical constraint set C from the hydropower semantic planning module according to the extracted task type, and construct a constraint injection Prompt containing the logical constraint set C. The large model calling unit is used to call the large language model. It inputs the fused text sequence and the constraint-injected Prompt together to obtain the candidate triples output by the large language model. The multi-validation unit is used to perform multi-validation on candidate triples. The multi-validation includes schema-level validation based on entity type set E and relation type set R, and business logic-level validation based on logical constraint set C. The output unit is used to output the triplet that passes all verifications as the Agent. The automated workflow module is configured to build and execute an automated knowledge extraction workflow. The workflow includes a series of full-text extraction nodes, metadata extraction nodes, table extraction nodes, and triplet extraction nodes. The full-text extraction nodes, metadata extraction nodes, and table extraction nodes are configured with the large model knowledge graph agent module for data preprocessing, while the triplet extraction node is configured with the large model knowledge graph agent module for core knowledge extraction. The knowledge fusion and graph entry module is configured to perform knowledge fusion and dynamic graph entry operations on the triples output by the automated workflow module, write the triples into the graph database, and complete the automated construction of the knowledge graph.

[0057] like Figure 4 As shown, the multi-verification unit of the large model knowledge graph Agent module further includes: The hydropower logic verification subunit is used to verify that the head entity and tail entity of the candidate triplet belong to the entity type set E, and the relation belongs to the relation type set R. The hydropower semantic verification subunit is used to verify whether candidate triples conform to hydropower business logic based on the logical constraint set C. The logical constraint set C includes at least: subordinate relationship constraints, factual relationship constraints, business logic constraints, equipment logical object instantiation constraints, event class constraints, and computable logical constraints.

[0058] Furthermore, in the automated workflow module: The full-text extraction node is configured to parse unstructured text and output a list of text blocks with semantic tags; The metadata extraction node is configured to extract document metadata and generate a metadata dictionary. The table extraction node is configured to recognize tables in a document and convert them into a dictionary list by row. The triplet extraction node is configured to receive the text block list, the metadata dictionary, and the dictionary list, and then call... The large-scale model knowledge graph Agent module performs execution context fusion, constraint injection-based prompt construction, large-scale model invocation, and multiple verifications, outputting triples that conform to the logic of the hydropower domain.

[0059] like Figure 5 As shown, the knowledge fusion and graph integration module includes: The conflict resolution unit is configured to perform Jaccard similarity conflict resolution on the triples output by the automated workflow module; The secondary verification unit is configured to perform the multiple verification again on the resolved triplet to prevent logical errors introduced by fusion. The batch write unit is configured to call the graph database interface to write triples in batches. The incremental trigger unit is configured to monitor the file directory. When a new file is written, it triggers the corresponding workflow node to achieve incremental updates of the knowledge graph.

[0060] Furthermore, the hydropower semantic planning module is configured to encode the entity type set E, relation type set R, and logical constraint set C into a JSON format file, generating a structured file conforming to the OWL2 standard, which serves as the semantic benchmark for the large model knowledge graph Agent module.

[0061] Example 2: This embodiment provides an end-to-end automated knowledge graph construction method and system for the hydropower field. Its core lies in transforming domain knowledge into computable constraints and designing an intelligent workflow to drive a large model for accurate extraction of hydropower domain knowledge.

[0062] The system's implementation follows a technical roadmap of "knowledge solidification in the hydropower field → constraint-driven extraction → workflow automation → closed-loop quality control." First, the professional standards and business logic of the hydropower industry are formalized into a set of machine-understandable ontologies and rules. Then, this schema serves as guidance and constraints, directing the large-scale model agent to extract knowledge. Finally, a modular, event-driven pipeline automatically completes the entire process from multi-source heterogeneous documents to graph database records, with built-in multi-verification and fusion mechanisms to ensure knowledge quality.

[0063] The implementation details of the core module are as follows: 1. Step S1, Hydropower Semantic Planning and Computable Ontology Construction: The goal of this step is to create a "domain knowledge model" on which the entire system operates.

[0064] Systematic Definition of Entities and Relationships: Based on national standards and industry regulations, the system defines an entity type system covering six dimensions: equipment, systems, components, parameters, events, and documents, as well as clearly defined relationship sets such as "composition," "technical parameters," and "occurrence location." All types are stored in structured list format.

[0065] Key Innovation: Encoding of Logical Constraints: Moving beyond the traditional approach of merely defining categories in ontology, this invention transforms the core logic of hydropower operations into a series of automatically executable logical constraint rules. For example: Subordination constraint: It is mandatory that "governor" must be associated with "hydro turbine", and "hydro turbine" must belong to a certain "hydro turbine generator set" system. This is reflected at the data level as a validation rule: "If the entity type is 'equipment', then there must exist a 'belongs to' relationship pointing to the 'system' type entity."

[0066] Parameter association constraint: This stipulates that any "alarm" or "fault" event must be associated with a specific "technical parameter" (e.g., a "temperature over-limit" event must be associated with the "temperature" parameter and its threshold). This prevents isolated events from occurring.

[0067] Computability constraint: It is clear that the "technical parameter" relationship can only exist between the two types of entities, "component" and "parameter", which ensures the mathematical and physical rationality of the triple.

[0068] Deliverables: All the above definitions (entities, relationships, constraints) are encoded into a structured configuration file (such as JSON-LD or an OWL2-compliant format). This file serves as the rule base for all subsequent automated processing modules to load and execute directly.

[0069] 2. Step S2, Implementation of the Large Model Knowledge Extraction Agent: Agent is not a single model, but an intelligent operator with embedded domain knowledge and standardized processing procedures.

[0070] Standardized input and context fusion: The Agent receives three types of standardized data from upstream: a list of text blocks, a metadata dictionary, and table row data.

[0071] Core preprocessing operation—context fusion: To address the information silo problem, the system semantically renders non-textual information and injects it into the text context. Specifically, meta-information (such as "This document applies to Unit #3") is added as a prefix; each row of a table is transformed into a natural language sentence stating "Parameter B of device A is value C". Ultimately, all inputs are fused into a coherent, structured natural language description, providing an unambiguous and complete business context for the large model.

[0072] Constraint-injected Prompt project: Prompt is not a simple command, but rather a dynamic population of the template with the complete schema (entity list, relationship definition, and especially hard logical constraints) built in S1 as a prerequisite.

[0073] The generated prompt will explicitly instruct the large model to act as a hydropower expert and strictly follow the given domain rules for extraction. For example, it will emphasize that "'technical parameter' relationships can only be used to connect 'component' and 'parameter' entities, and those that violate this rule will be filtered out."

[0074] Multi-rule validation mechanism: Phase 1: Schema-level validation. Parse the candidate triples returned by the large model and quickly check whether the types of its head entity, tail entity, and relationship are within the allowed range predefined by the schema.

[0075] Phase Two: Logical Level Verification. This phase applies deep filtering based on the complex business constraints encoded in S1. For example, it verifies whether the head entity of the "technical parameter" relationship is indeed a "component" and the tail entity is a "parameter"; it also verifies whether the extracted "fault" event is associated with at least one parameter or device entity.

[0076] Only triples that pass all validations will be output, thus ensuring that the extraction results conform to the domain logic.

[0077] 3. Step S3, Automated knowledge extraction workflow orchestration: The system uses a workflow engine (such as Airflow) to orchestrate the processing into a high-efficiency pipeline containing four decoupled nodes: Full-text extraction nodes: Use a customized agent to parse unstructured documents such as PDF / Word documents and cut them into plain text blocks with semantic tags.

[0078] Metadata extraction node: Using another customized Agent, key metadata such as "applicable unit", "document version", and "report date" are extracted from document titles, headers and footers.

[0079] Table extraction nodes: For tables in the document, the Agent is used to identify their structure and convert each row into a key-value pair dictionary, explicitly identifying fields such as device name, parameter name, value, and unit.

[0080] Triple Extraction Node (Core): Receives the output of the first three nodes, executes the complete process described in S2 above (context fusion → Prompt construction → large model call → multiple verifications), and generates the final knowledge triple.

[0081] These four nodes are connected in an event-driven manner, with the output of the upstream node automatically triggering the execution of the downstream node, thus achieving full automation of "document input and knowledge output".

[0082] 4. Step S4, Knowledge Integration and Dynamic Image Integration Closed Loop: This step is responsible for integrating the discretely extracted knowledge into a unified, high-quality knowledge graph.

[0083] Conflict resolution and secondary verification: For triples from different documents or different parts of the same document, duplicate or slightly conflicting entities are identified and merged based on algorithms such as Jaccard similarity. After merging, logical constraint verification is initiated again to prevent the merging process from introducing new logical errors.

[0084] Batch writing and incremental updates: The cleaned and merged set of triples is efficiently written into the knowledge graph through the batch import interface of the graph database. The system is designed with an incremental triggering mechanism that monitors a specified directory. When a new document is added, the corresponding workflow instance is automatically triggered, enabling the continuous and dynamic growth of the knowledge graph without manual intervention to restart the process.

[0085] Example 3: This embodiment uses the intelligent operation and maintenance knowledge base construction project of a large hydropower station with an installed capacity of 6×700MW as the application scenario. This hydropower station has accumulated nearly 15 years of operation and maintenance documents, including 358 equipment technical manuals, 2,147 defect reports, 1,236 maintenance records, 89 accident analysis reports, and 523 equipment parameter tables, totaling approximately 4,353 multi-source heterogeneous documents, covering core equipment such as turbines, generators, governors, excitation systems, and technical water supply systems. The method described in this invention is used to construct a knowledge graph in the hydropower field, aiming to achieve end-to-end automated construction from raw documents to structured knowledge.

[0086] The method of this invention was used to process the aforementioned 4,353 documents. The operating environment was: 4 NVIDIA A100 GPU servers, deploying the Qwen-72B large language model, and using Apache Airflow as the workflow engine. The results are shown in Table 1 below. Table 1: Operational data of the method of the present invention;

[0087] To verify the technical effect of the present invention, the following three existing technical methods are set up for comparison: Method A, traditional rule-based method: a rule matching method based on regular expressions and predefined dictionaries; Method B, traditional machine learning method: using BiLSTM-CRF named entity recognition model, trained with 5,000 manually labeled data; Method C, General Large Model Method: Using the Qwen-72B large model, triples are directly extracted using the general Prompt.

[0088] The above three comparison methods were run on the same dataset of 4,353 documents. The experimental results are shown in Table 2 below: Table 2: Comparative experimental data of different methods;

[0089] As can be seen from Tables 1 and 2 above, the present invention exhibits significant advantages in the following five dimensions: 1. Significantly Improved Extraction Accuracy. The method of this invention achieves a precision of 93.8%, a recall of 91.5%, and an F1 score of 92.6%, which is 25.7 percentage points higher than traditional rule-based methods (F1=66.9%), 16.6 percentage points higher than traditional machine learning methods (F1=76.0%), and 15.4 percentage points higher than general large model methods (F1=77.2%). The core reason lies in: solidifying hydropower-related professional knowledge (such as "the governor must belong to the turbine system") into computable constraints through a set of logical constraints C; driving the large model to extract within the semantic framework through constraint injection Prompt; and filtering illegal triples through a multi-verification mechanism, fundamentally solving the problem of "semantic drift" in the hydropower professional field of general large models.

[0090] 2. Significantly reduced logical error rate. The method of this invention controls the error rate of equipment dependency relationship (2.1%), parameter association (1.8%), and event logic (2.4%) to within 3%, while the comparative methods are generally between 20% and 35%. The detection rate of illegal triples reaches 96.5%, indicating that the multi-verification mechanism of this invention can effectively identify and filter invalid triples that violate the logic of hydropower business, ensuring the logical consistency of the knowledge graph.

[0091] 3. Outstanding multi-source data processing capabilities. The method of this invention achieves a table data recognition accuracy of 96.8% and a metadata extraction accuracy of 97.2%, significantly outperforming the comparison methods. The core lies in the context fusion preprocessing mechanism: transforming table rows into natural language descriptions such as "Parameter B of device A is value C", and injecting metadata (such as "This document applies to Unit #3") into the text context, enabling the large model to extract data within a complete semantic background, avoiding the entity attribution ambiguity caused by fragmented multi-source data.

[0092] 4. Significantly reduced manual intervention costs. The manual annotation workload of the method in this invention is only 12 person-days, approximately 27% of that of general large-scale model methods and 2.5% of that of traditional machine learning methods; the rule / model maintenance cost is only 2 person-days / month, approximately 40% of that of general large-scale model methods and 7% of that of traditional machine learning methods. This is thanks to the end-to-end automated workflow design, which decouples and connects the four nodes of full-text extraction, metadata extraction, table extraction, and triple extraction, realizing full-process automation from raw documents to knowledge graphs and eliminating traditional steps such as manual rule formulation, data annotation, and result verification.

[0093] 5. Significant advantages in construction efficiency and scalability. The method of this invention processed 4,353 documents in a total time of 47.2 hours, which is 10% faster than the general large model method (52.6 hours), 72% faster than the traditional machine learning method (168.3 hours), and 85% faster than the traditional rule method (312.5 hours). The incremental update response time is only 8.3 seconds per document, demonstrating good scalability and adapting to the real-world needs of continuously growing hydropower station operation and maintenance documents.

[0094] In summary, this invention, through its technical architecture of "hydropower semantic specification constraints + domain standard driving + large model precise extraction + dynamic fusion into the graph," achieves automation, precision, and computability in the construction of hydropower knowledge graphs, providing a general solution for the intelligent construction of knowledge graphs in the hydropower industry and even the energy industry.

[0095] Figure 6 For comparison of extraction performance of different methods, this invention significantly outperforms traditional rule-based methods, machine learning methods and general large model methods in terms of precision (93.8%), recall (91.5%) and F1 score (92.6%), indicating that the extraction accuracy and completeness are fundamentally improved after integrating hydropower semantic constraints and multiple verification mechanisms. Figure 7 The comparison of logical error rates shows that the present invention controls the error rates of equipment subordination (2.1%), parameter association (1.8%), and event logic (2.4%) to within 3%, which is far lower than the comparison method (20%~35%). This proves that the "constraint injection Prompt + double verification" effectively eliminates invalid triples that violate the rules of hydropower business. Figure 8 Compared to manual labor costs, the initial annotation workload of this invention is only 12 person-days, and the monthly maintenance cost is 2 person-days, which is more than 90% lower than traditional methods, fully demonstrating the efficiency advantages brought by end-to-end automated workflow. Further comparison of this invention with general large models in dimensions such as automation level, multi-source fusion capability, logical consistency, and illegal triplet detection rate shows that this invention leads by an overwhelming margin. Four figures systematically verify the breakthrough progress of this invention in terms of accuracy, logical consistency, automation level, and maintainability.

[0096] Example 4: like Figure 10 As shown, embodiments of the present invention also provide a computer device. Figure 10 Taking a single processor 10 as an example, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other using different buses and can be mounted on a common motherboard or otherwise installed as needed. The processor can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices, such as display devices coupled to the interface. In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations, for example, as a server array, a group of blade servers, or a multiprocessor system.

[0097] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0098] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0099] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0100] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0101] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0102] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

Claims

1. A method for automatically constructing a hydropower knowledge graph based on a large model, characterized in that, Includes the following steps: S1. Construct a hydropower semantic planning and hydropower ontology logical schema; the schema should include at least a set of hydropower knowledge graph entity types E, a set of relation types R, and a set of logical constraints C. S2, constructs a large model knowledge graph Agent, which serves as the core operator module for each node in the knowledge extraction workflow, including full-text extraction, meta-information extraction, table extraction, and triple extraction. S3 constructs an automated knowledge extraction workflow, which includes a series of full-text extraction nodes, metadata extraction nodes, table extraction nodes, and triplet extraction nodes. S4 uses the triples output from the automated knowledge extraction workflow to perform knowledge fusion and dynamic graph input operations, writing the triples into the graph database to complete the automated construction of the knowledge graph.

2. The method for automatically constructing a hydropower knowledge graph based on a large model according to claim 1, characterized in that, Step S1 includes the following steps: S101, Define the entity type E of the hydropower knowledge graph as {hydropower station, system, equipment, component, technical parameter, event, document, relationship, logical constraint}; S102, define the system subclass set E1={hydro turbine generator set, power grid distribution system, power output and plant power system, technical water supply system}; S103, define the equipment subclass set E2 = {water turbine, governor, generator, excitation system}; S104, Define the component subclass set E3 = {turbine main shaft, runner, upper crown, lower ring, blades, and spillway cone}; S105, define the parameter subclass set E4 = {rated power, head, voltage, temperature}; S106, Define the event subclass set E5 = {Normal, Alarm, Warning, Defect, Fault, Maintenance}; S107, Define the document subclass collection E6 = {National Standards, Industry Standards, Company Procedures, Case Documents, Defect Reports, Maintenance Reports, Equipment History}; S108, define the set of relation types R = {Composition, Driver, Protection, Monitoring, Association, Technical Parameter, Source, Applicable}; S109 defines a set of logical constraints C, which includes a multi-level, computable, and self-verifiable rule system that transforms the professional knowledge, business logic, and operating procedures in the hydropower field into automated verification rules that can be executed by machines. S110, Design the calculation rule system for entity set E; S111 defines the extraction rules, encodes the sets E, R, and C into JSON format files, and generates a structured file conforming to the OWL2 standard, which includes entity / relationship definitions, attribute constraints, and rule engine configurations, serving as the semantic benchmark for subsequent extraction.

3. The method for automatically constructing a hydropower knowledge graph based on a large model according to claim 2, characterized in that, In step S109, the set of logical constraints C includes: C1 Subordination Constraint: E2 must belong to a certain system E1, and E3 must belong to E2; C2 Factual Relationship Constraint: Events must be associated with parameters; C3 Business Logic Constraints: Rule relationships must satisfy the "condition → action" logic; C4 Device Logical Object Instantiation Constraints: Any device entity must have a non-null attribute; C5 event class constraint: Any event entity must be associated with at least one parameter instance; C6 Computable Logical Constraints: For each relation r in the relation type set R, define its allowed head entity type set HeadType(r) and tail entity type set TailType(r) such that for any candidate triple (h, r, t), h∈HeadType(r) and t∈TailType(r) must be satisfied.

4. The method for automatically constructing a hydropower knowledge graph based on a large model according to claim 2, characterized in that, In step S110, the design of the calculation rule system for entity set E includes entity hierarchical classification and attribution rules, specifically including: Rule E-R1, hierarchical progressive rule: Entity classification follows the physical composition hierarchy of "hydropower station → system → equipment → component". Any lower-level entity must be linked to its direct superior entity through a membership or composition relationship. Rule E-R2, multi-dimensional labeling rule: Each entity must be labeled with at least two dimensions: physical dimension labels: {hydropower station, system, equipment, component, parameter} and business dimension labels: {operation entity, monitoring entity, control entity, document entity, event entity}.

5. The method for automatically constructing a hydropower knowledge graph based on a large model according to claim 4, characterized in that, In step S110, the design of the calculation rule system for entity set E includes entity recognition and disambiguation rules, specifically including: Rule E-R3, Standard Terminology Precedence Rule: The input text terms are matched against the hydropower standard terminology database. If there is a complete match, they are directly mapped to standard entity names. If there is no complete match, the word vector similarity is calculated. If the similarity is greater than 0.85, it is mapped to the most similar standard entity. If the similarity is less than or equal to 0.85, it is marked as a new entity pending review. Rule E-R4, Context Disambiguation Rule: Disambiguation of ambiguous entities is performed based on the context.

6. The method for automatically constructing a hydropower knowledge graph based on a large model according to claim 5, characterized in that, In step S110, the design of the calculation rule system for entity set E includes relation type determination rules, specifically including: Physical topology determination: If entity A and entity B appear simultaneously in the text, and there are expressions such as "device A is B", "device A is composed of B", or "device A contains B", then relation R="compose"; if there are expressions such as "device A drives B" or "device A drives B", then relation R="drive"; if there are expressions such as "device A monitors B" or "device A detects B", then relation R="monitor". Determining business logic relationships: If entity A is an event and entity B is a device or parameter, and A describes a change in the state of B, then the relation R = "Affects"; if A is caused by B, then the relation R = "Causes"; if A requires inspection or repair of B, then the relation R = "Associated Inspection". Relationship direction calculation: The direction of compositional relationships is from the whole to the parts; the direction of technical parameter relationships is from the components to the parameters; and the direction of monitoring relationships is from the monitoring equipment to the monitored equipment.

7. The method for automatically constructing a hydropower knowledge graph based on a large model according to claim 1, characterized in that, In step S2, the large model knowledge graph Agent, as a core operator module, is configured to perform the following operations: S201, deploying large language models as the technical foundation for extracting key elements of knowledge graphs; S202, Standardized Input Interface Operation: The Agent pre-designs an interface to connect to the input data and designs a standardized data object, which contains the following three elements: text_blocks: A list of sentences extracted from the full-text nodes; metadata: A dictionary derived from the metadata extraction nodes; table_rows: A list of dictionaries from which nodes are extracted from the table; S203, preprocess the input from step S202 through context fusion, convert the information in metadata into natural language descriptions and insert them into the header of text_blocks; convert each row of data in table_rows into a structured description sentence; and concatenate all the processed text into a single string fused_text. S204, classify according to the extraction task type, the extraction task type includes full text extraction, metadata extraction, table extraction and triplet extraction, and corresponds to the automated workflow in step S3; S205, construct a customized Prompt according to the task type, obtain the entity set E, relation set R, and constraint set C from step S1, and construct a Prompt template based on the JSON file encoded in step S111. S206, Invoke the large language model, pass in the Prompt, and obtain the response text; S207, Multiple Constraint Verification: After passing in the file to be extracted and completing the context fusion through standardization, the input module is called and the deployed large language model is started. The above Prompt is passed in to obtain the response text. Parse the response text and extract all candidate triples of the form [(A, B, C)]. Perform multiple checks on each candidate triple (h, r, t), including hydropower logic checks and hydropower semantic checks: Hydropower logic verification: Verify h∈(E∪E1∪E2∪E3∪E4), t∈(E∪E1∪E2∪E3∪E4), r∈R; Hydropower semantic verification: If r = "technical parameters", then force verification of h ∈ E3 and t ∈ E4; The triples that pass all validations are retained as the final output of the Agent; S208, through the output and integration module, generates a knowledge graph from the final output triples and calls the graph database interface to achieve automated database entry.

8. The method for automatically constructing a hydropower knowledge graph based on a large model according to claim 1, characterized in that, Step S3 specifically includes: designing a modular workflow, predefining four nodes: full-text extraction, metadata extraction, table extraction, and triplet extraction, and matching them with step S2 to achieve end-to-end processing of multi-source heterogeneous data. S301, Configure the full-text extraction node: Configure the Agent preset in step S2 to extract general text, parse unstructured text, and output text blocks with semantic tags; S302, Configure the metadata extraction node: Link with step S1, embed business logic rules and water and electricity exclusive ontology logic, configure the Agent preset in step S2 to extract metadata, extract document metadata, and generate a metadata table. S303, Configure table extraction node: Configure the large model Agent operator identification device parameter table preset in step S2, convert it into a structured table, convert the table into a dictionary list by row, and assign the technical parameters to specific systems, devices or components according to the constraints of step S1. S304, Configure the triple extraction node: Link with step S1, embed business logic rules and water and electricity-specific ontology logic, configure the Agent preset in step S2 to extract triples, receive text blocks / tables / meta information, call the large model Agent to execute the extraction task, and realize the automation of "input → structured output"; The above four nodes constitute an end-to-end knowledge graph construction pipeline. Among them, the triple extraction node is the core intelligent node that performs semantic understanding and knowledge generation, while the other three nodes are data preprocessing nodes.

9. The method for automatically constructing a hydropower knowledge graph based on a large model according to claim 1, characterized in that, Step S4 specifically includes: Perform Jaccard similarity conflict resolution on the triples output by the Agent; The triplet after elimination is subjected to multiple checks in step S3 again to prevent logical errors from being introduced by fusion; Batch writes are performed using the graph database's API, and incremental triggers are configured so that only the corresponding workflow node is triggered when a new file is written.

10. An automated construction system for hydropower knowledge graph based on a large model, used to execute the automated construction method for hydropower knowledge graph based on a large model as described in any one of claims 1-9, characterized in that the system... include: The hydropower semantic planning module is configured to construct a hydropower semantic planning and hydropower ontology logic schema. The schema includes at least a set of entity types E of the hydropower knowledge graph, a set of relation types R, and a set of logical constraints C used to transform hydropower domain expertise, business logic, and operating procedures into machine-executable automated verification rules. The large-scale knowledge graph Agent module is configured as the core operator for each node in the knowledge extraction workflow. The Agent module includes: The input interface unit is used to receive standardized input data, which includes at least one of a list of text blocks, a metadata dictionary, and table row data. The context fusion unit is used to convert the metadata dictionary and table row data into natural language descriptions and then fuse them with the list of text blocks to generate a fused text sequence. The Prompt construction unit is used to obtain the entity type set E, relation type set R, and logical constraint set C from the hydropower semantic planning module according to the extracted task type, and construct a constraint injection Prompt containing the logical constraint set C. The large model calling unit is used to call the large language model. It inputs the fused text sequence and the constraint-injected Prompt together to obtain the candidate triples output by the large language model. The multi-validation unit is used to perform multi-validation on candidate triples. The multi-validation includes schema-level validation based on entity type set E and relation type set R, and business logic-level validation based on logical constraint set C. The output unit is used to output the triplet that passes all verifications as the Agent. The automated workflow module is configured to build and execute an automated knowledge extraction workflow. The workflow includes a series of full-text extraction nodes, metadata extraction nodes, table extraction nodes, and triplet extraction nodes. The full-text extraction nodes, metadata extraction nodes, and table extraction nodes are configured with the large model knowledge graph agent module for data preprocessing, while the triplet extraction node is configured with the large model knowledge graph agent module for core knowledge extraction. The knowledge fusion and graph entry module is configured to perform knowledge fusion and dynamic graph entry operations on the triples output by the automated workflow module, write the triples into the graph database, and complete the automated construction of the knowledge graph.

11. The automated construction system for a hydropower knowledge graph based on a large model according to claim 10, characterized in that, The multi-verification unit of the large model knowledge graph Agent module further includes: The hydropower logic verification subunit is used to verify that the head entity and tail entity of the candidate triplet belong to the entity type set E, and the relation belongs to the relation type set R. The hydropower semantic verification subunit is used to verify whether candidate triples conform to hydropower business logic based on the logical constraint set C. The logical constraint set C includes at least: subordinate relationship constraints, factual relationship constraints, business logic constraints, equipment logical object instantiation constraints, event class constraints, and computable logical constraints.

12. The automated construction system for a hydropower knowledge graph based on a large model according to claim 10, characterized in that, In the automated workflow module: The full-text extraction node is configured to parse unstructured text and output a list of text blocks with semantic tags; The metadata extraction node is configured to extract document metadata and generate a metadata dictionary. The table extraction node is configured to recognize tables in a document and convert them into a dictionary list by row. The triplet extraction node is configured to receive the text block list, the metadata dictionary, and the dictionary list, and then call... The large-scale model knowledge graph Agent module performs execution context fusion, constraint injection-based prompt construction, large-scale model invocation, and multiple verifications, outputting triples that conform to the logic of the hydropower domain.

13. The automated construction system for a hydropower knowledge graph based on a large model according to claim 10, characterized in that, The knowledge fusion and graph integration module includes: The conflict resolution unit is configured to perform Jaccard similarity conflict resolution on the triples output by the automated workflow module; The secondary verification unit is configured to perform the multiple verification again on the resolved triplet to prevent logical errors introduced by fusion. The batch write unit is configured to call the graph database interface to write triples in batches. The incremental trigger unit is configured to monitor the file directory. When a new file is written, it triggers the corresponding workflow node to achieve incremental updates of the knowledge graph.

14. The automated construction system for a hydropower knowledge graph based on a large model according to claim 10, characterized in that, The hydropower semantic planning module is configured to encode the entity type set E, relation type set R, and logical constraint set C into a JSON format file, generating a structured file conforming to the OWL2 standard, which serves as the semantic benchmark for the large model knowledge graph Agent module.

15. A computer device, characterized in that, It includes a memory and a processor, which are interconnected and communicate with each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the automated construction method of hydropower knowledge graph based on a large model as described in any one of claims 1-9.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the automated construction method for a hydropower knowledge graph based on a large model as described in any one of claims 1-9.

Images