Operation and maintenance case matching method and device based on hierarchical knowledge base

Abstract

This invention discloses a method and apparatus for matching operation and maintenance (O&M) cases based on a hierarchical knowledge base, comprising: receiving an O&M case matching request sent by a large-scale operational model during the O&M of a flexible DC converter station; parsing the O&M case matching request to obtain a first-level identifier, a case type identifier, and an O&M intent query statement; determining an initial hierarchical case range corresponding to the first-level identifier in a preset hierarchical knowledge base; performing parallel retrieval within the initial hierarchical case range using the case type identifier and the O&M intent query statement to obtain O&M action triples and O&M semantic vectors; the preset hierarchical knowledge base is constructed and combined using the component categories in the physical topology of the modular multilevel converter in the flexible DC converter station; and aggregating the O&M action triples and the O&M semantic vectors to obtain the target O&M case. This invention can improve the accuracy of case matching when the large-scale operational model performs O&M on flexible DC converter stations.

Description

Technical Field

[0001] This invention relates to the field of power systems, and more particularly to a method and apparatus for matching operation and maintenance cases based on a hierarchical knowledge base. Background Technology

[0002] Flexible DC converter stations (FCS stations) serve as crucial hubs for new energy grid connection and inter-regional power transmission, exhibiting complex operational states and wide-ranging impacts from faults. With the deepening application of artificial intelligence technology in power systems, large-scale operational models have become a key tool supporting intelligent operation and maintenance decisions for FCS stations. In actual operation and maintenance, these models need to provide accurate case matching and decision-making suggestions for current operation and maintenance tasks (such as fault diagnosis, equipment maintenance, or control strategy adjustments) based on multi-source information including historical operation and maintenance cases, real-time monitoring data, and equipment ledgers.

[0003] Currently, the case matching system relied upon by the large-scale operation model of flexible power substations is mainly based on traditional knowledge management systems, but it has significant drawbacks: On the one hand, existing systems generally adopt a flat storage architecture, which mixes operation and maintenance cases from different MMC (Modular Multilevel Converter) levels of flexible power substations. This makes it difficult for the system to accurately distinguish the physical level to which a case belongs when the large-scale operation model initiates an operation and maintenance case matching request, and it cannot achieve accurate matching based on the physical level, resulting in insufficient accuracy of the matched cases. On the other hand, existing methods lack a hierarchical fusion retrieval mechanism for multi-source cases. They cannot accurately locate standardized operation and maintenance actions at a specific level through structured queries, nor can they effectively cover experiential cases and related contexts at the same level through semantic retrieval. As a result, the large-scale operation model has difficulty obtaining complete and related case contexts when matching operation and maintenance cases, which directly affects the accuracy of case matching. Summary of the Invention

[0004] This invention provides a method and apparatus for matching operation and maintenance cases based on a hierarchical knowledge base. This invention can improve the accuracy of case matching when operating a large model to perform operation and maintenance on flexible DC converter stations.

[0005] In a first aspect, an embodiment of the present invention provides a method for matching operation and maintenance cases based on a hierarchical knowledge base, including: Receive operation and maintenance case matching requests sent by the large-scale operational model during the operation and maintenance of the flexible DC converter station; The operation and maintenance case matching request is parsed to obtain the first-level identifier, the case type identifier, and the operation and maintenance intent query statement; Based on the first-level identifier, an initial-level case range corresponding to the first-level identifier is determined in a preset hierarchical knowledge base. Parallel retrieval is performed in the initial-level case range using the case type identifier and the operation and maintenance intent query statement to obtain operation and maintenance action triples and operation and maintenance semantic vectors. The preset hierarchical knowledge base is constructed and combined using the component categories in the physical topology of the modular multilevel converter in the flexible DC converter station. The initial-level case range includes graph database case range and vector database case range. The operation and maintenance action triples and the operation and maintenance semantic vectors are aggregated to obtain the target operation and maintenance case.

[0006] By receiving maintenance case matching requests sent by the large-scale model during the operation and maintenance of the flexible DC converter station, clear case matching requirements for the flexible DC converter station's operation and maintenance can be captured from the source of operation and maintenance decisions, ensuring the accuracy of case matching from the source. Parsing the maintenance case matching requests yields a first-level identifier, a case type identifier, and an operation and maintenance intent query statement. This deconstructs complex natural language requests into precise retrieval dimensions. The first-level identifier directly corresponds to the physical topology level of the flexible DC converter station's MMC, providing precise input for subsequent hierarchical retrieval and laying the foundation for accurate case matching. Based on the first-level identifier, an initial hierarchical case range is determined in a preset hierarchical knowledge base. This hierarchical knowledge base is defined as being constructed and combined using the component categories in the physical topology of the modular multilevel converter in the flexible DC converter station. The initial hierarchical case range includes graph database case ranges and vector database case ranges. Utilizing a knowledge organization method strictly aligned with the equipment's physical structure, the retrieval scope can be converged from the global to the level relevant to the fault. This approach, by identifying specific hierarchical subsets corresponding to faulty equipment or maintenance objects, completely resolves the hierarchical confusion caused by flat storage in existing technologies at the data source level. It also provides a well-organized search space that separates structured and semantic knowledge for subsequent parallel retrieval, improving the accuracy of case matching. Parallel retrieval of maintenance action triples and semantic vectors within the initial hierarchical case range using case type identifiers and maintenance intent query statements allows for simultaneous execution of precise retrieval based on structured queries and associative retrieval based on semantic similarity within a defined hierarchy. This ensures the accuracy and standardization of matching cases in terms of operational steps while expanding the coverage of unstructured knowledge such as relevant experience and contextual background, overcoming the shortcomings of existing single retrieval mechanisms that cannot simultaneously address accuracy and relevance, thus improving the accuracy of case matching. Aggregating the maintenance action triples and semantic vectors yields target maintenance cases, integrating precise structured operational steps with rich semantic association information into a unified, complete, and context-enhanced target maintenance case, further improving the accuracy of case matching. This application can improve the case matching accuracy of large-scale operational models when performing maintenance on flexible DC converter stations.

[0007] Furthermore, the preset hierarchical knowledge base is obtained by constructing corresponding levels and combining them according to the component categories in the physical topology of the modular multilevel converter in the flexible DC converter station, specifically including: A case architecture is constructed based on the component categories, wherein the component categories include sub-modules, valve groups, converters, and systems. The case architecture includes a sub-module layer corresponding to the sub-modules, a valve group layer corresponding to the valve groups, a converter layer corresponding to the converters, and a system layer corresponding to the systems. Based on the aforementioned case architecture, a hierarchical graph database and a hierarchical vector database are constructed. Each layer of the hierarchical graph database and the hierarchical vector database contains a second-level identifier that identifies the level. The second-level identifier includes a submodule identifier, a valve group identifier, a converter identifier, and a system identifier. An initial knowledge base is constructed based on the hierarchical graph database and the hierarchical vector database. Obtain several historical cases, and parse each historical case to obtain the component identifiers corresponding to each historical case; Using the component identifiers involved, each historical case is assigned to the corresponding level of the hierarchical graph database and the hierarchical vector database in the initial knowledge base, thus obtaining the hierarchical knowledge base.

[0008] This case architecture, built based on component categories and including submodule, valve group, converter, and system layers, ensures that the knowledge base's organizational structure is strictly aligned with the actual physical topology of the flexible DC station. This provides an accurate logical framework for hierarchical knowledge storage and retrieval, guaranteeing the hierarchical accuracy of subsequent case matching from an architectural design perspective. By constructing a hierarchical graph database and hierarchical vector database with second-level identifiers based on this case architecture, independent storage partitions with clear hierarchical identifiers, corresponding one-to-one with the physical levels, can be established, providing a clear and isolated data foundation for accurate case matching. Furthermore, building an initial knowledge base containing the hierarchical graph database and hierarchical vector database provides a hierarchical and structured data container for the inclusion of historical cases, ensuring the knowledge base is ready for use from the outset. The ability to organize hierarchically improves the accuracy of subsequent case matching. By acquiring historical cases and parsing the identifiers of the components involved, the system can automatically identify the specific physical components associated with each case, providing a key basis for accurately classifying them into the corresponding level. This avoids the subjectivity and errors of manual classification and improves the accuracy of subsequent case matching. By using the identifiers of the components involved to classify each historical case into the corresponding level, the system can achieve automated and precise organization of knowledge based on physical topology. This allows the knowledge base to ultimately form a hierarchical system that is completely consistent with the equipment structure. This completely solves the problem of knowledge mixing at the data source level, ensuring that when the large model is running case matching, each case retrieved is strictly limited to the correct physical level, thereby directly and significantly improving the accuracy of case matching.

[0009] Furthermore, the step of using the component identifiers to categorize each historical case into the corresponding level of the hierarchical graph database and the hierarchical vector database in the initial knowledge base, thereby obtaining the hierarchical knowledge base, specifically includes: For each of the aforementioned historical cases, a preset information extraction model is used to extract knowledge from the historical cases to obtain the corresponding historical action triplet for each historical case. The historical cases are semantically encoded using a preset language model to obtain the historical semantic vectors corresponding to the historical cases; The historical action triples and the historical semantic vectors are stored in the hierarchical graph database and the hierarchical vector database, respectively, at the corresponding levels where the second-level identifier and the identifier of the involved component are the same, to obtain the hierarchical knowledge base.

[0010] By using component identifiers to categorize historical cases into corresponding levels, automated and precise knowledge organization based on physical topology can be achieved. This enables the knowledge base to ultimately form a hierarchical system that is completely consistent with the equipment structure, thoroughly solving the problem of knowledge mixing at the data source level. This ensures that when the large model is running case matching, every case retrieved is strictly limited to the correct physical level, thereby directly and significantly improving the accuracy of case matching.

[0011] Furthermore, the historical cases include external cases. The step of using the involved component identifiers to categorize each historical case into the corresponding level of the hierarchical graph database and the hierarchical vector database in the initial knowledge base to obtain the hierarchical knowledge base further includes: Feature extraction is performed on the external cases to obtain the first parameter set; The second parameter set is obtained by extracting features from the component identifiers corresponding to the external cases in the preset ledger database. The preset ledger database is constructed from the static standard parameters of each component in the flexible DC converter station. The first similarity is calculated based on the first parameter set and the second parameter set; If the first similarity is greater than a preset threshold, the external case is replaced with a difference using the second parameter set to obtain a local adapted case. Using the component identifiers corresponding to the external cases, the local adaptation cases are categorized into the corresponding levels of the hierarchical graph database and the hierarchical vector database in the initial knowledge base, thus obtaining the hierarchical knowledge base.

[0012] This process involves extracting features from external cases to obtain the first parameter set, providing an objective and quantitative comparison basis for subsequent localization adaptation and ensuring the accuracy of the adaptation process. By using the identifiers of the involved components to extract the second parameter set from a pre-set database, authoritative and accurate standard parameters for the corresponding components of the local flexible vertical station can be quickly obtained, providing a true and accurate reference benchmark for comparing external cases with local components. Calculating the first similarity between the first and second parameter sets quantitatively assesses the degree of consistency between external cases and local components in key parameters, ensuring the potential matching accuracy of the knowledge entered into the database from the source. If the first similarity is greater than a preset threshold, then the second parameter set is used... The two-parameter set corrects parameters in external cases that do not match local components to local standard parameters, generating locally adapted cases that are fully adapted to the actual local components. This solves the incompatibility problem caused by directly reusing external cases, greatly improving the applicability of external knowledge in local scenarios and thus improving the accuracy of its invocation in subsequent case matching. Locally adapted cases are categorized into corresponding levels according to the component identifiers they involve, ensuring that the adapted high-quality external knowledge can be organically integrated into the corresponding positions in the hierarchical knowledge base. This allows the running large model to obtain broader and more local case support, systematically improving the accuracy of case matching.

[0013] Furthermore, the step of determining the initial hierarchical case range corresponding to the first hierarchical identifier in a preset hierarchical knowledge base based on the first hierarchical identifier specifically includes: If the first level identifier is the submodule identifier, then an interval search is performed in the hierarchical knowledge base to determine the range of graph database cases and the range of vector database cases where the second level identifier is the submodule identifier; If the first-level identifier is the valve group identifier, then an interval search is performed in the hierarchical knowledge base to determine the range of graph database cases and the range of vector database cases where the second-level identifier is the valve group identifier; If the first-level identifier is the converter identifier, then an interval search is performed in the hierarchical knowledge base to determine the graph database case range and the vector database case range where the second-level identifier is the converter identifier; If the first-level identifier is the system identifier, then an interval search is performed in the hierarchical knowledge base to determine the range of graph database cases and the range of vector database cases where the second-level identifier is the system identifier; Based on the case range of the graph database and the case range of the vector database, the initial hierarchical case range is determined.

[0014] This approach allows for precise range retrieval within the hierarchical knowledge base based on first-level identifiers (such as submodules, valve groups, converters, or system identifiers). This enables rapid location and locking of graph database and vector database case ranges that strictly correspond to that level. It ensures that the retrieval process is efficiently converged to a specific physical level directly related to the operation and maintenance object, completely avoiding interference from irrelevant cross-level knowledge at the operational level, thereby directly improving the accuracy of case matching.

[0015] Furthermore, the parallel retrieval of the case type identifier and the operation and maintenance intent query statement within the initial level case range to obtain operation and maintenance action triples and operation and maintenance semantic vectors specifically includes: The operation and maintenance action triplet is obtained by performing a structured search within the graph database case range of the initial level case range using the case type identifier; The operation and maintenance semantic vector is obtained by performing a similarity search on the vector database case range within the initial level case range using the case type identifier and the operation and maintenance intent query statement.

[0016] By utilizing case type identifiers and operation and maintenance intent query statements to perform parallel retrieval within the initial level of cases to obtain operation and maintenance action triples and operation and maintenance semantic vectors, it is possible to simultaneously perform precise retrieval based on structured queries and related retrieval based on semantic similarity within a limited level. This ensures the accuracy and standardization of the operational steps in the matched cases, while also expanding the coverage of unstructured knowledge such as relevant experience and contextual background. This overcomes the shortcomings of existing single retrieval mechanisms that cannot balance accuracy and relevance, thereby improving the accuracy of case matching.

[0017] Furthermore, the step of using the case type identifier and the operation and maintenance intent query statement to perform a similarity search within the vector database case range of the initial level case range to obtain the operation and maintenance semantic vector specifically includes: The operation and maintenance intent query statement is encoded using a preset encoding model to obtain a query vector; Based on the case type identifier, several candidate case vectors are determined within the case range of the vector database; The similarity between the query vector and each candidate case vector is calculated to obtain several second similarities. The second similarity is filtered using preset similarity conditions to obtain the operation and maintenance semantic vector.

[0018] By using a pre-defined encoding model to encode the natural language description of the operation and maintenance intent query statement into a query vector, a precise quantitative expression of complex semantics is achieved. Candidate case vectors are selected based on case type identifiers, ensuring that the retrieval process focuses on specific types of knowledge categories. By calculating the similarity between the query vector and the candidate case vector and filtering according to pre-defined similarity conditions, the cases most relevant to the current operation and maintenance intent semantics can be automatically and objectively identified from a large number of candidate knowledge sources. This effectively expands the coverage and semantic relevance of knowledge retrieval, thereby significantly enhancing the completeness and contextual relevance of case matching results, and ultimately improving the accuracy of case matching in running large models.

[0019] Furthermore, after using the component identifiers to classify each historical case into the corresponding level of the hierarchical graph database and the hierarchical vector database in the initial knowledge base to obtain the hierarchical knowledge base, the method further includes: real-time monitoring of preset trigger events; if the trigger event is triggered, obtaining the trigger case data associated with the trigger event and classifying the trigger case data into the hierarchical knowledge base.

[0020] By continuously monitoring and responding to triggered events after building the hierarchical knowledge base, the latest dynamic data directly related to the operation and maintenance site can be automatically captured and processed. This data is then promptly added to the hierarchical knowledge base as trigger case data, enabling the knowledge base to be updated and self-enhanced synchronously with the operation and maintenance process. This ensures that the timeliness of the cases in the hierarchical knowledge base is synchronized with the site status, thereby guaranteeing that the knowledge called upon by the running large model during case matching is always up-to-date and most relevant, further improving the accuracy of case matching.

[0021] Furthermore, the triggering event includes an alarm event. If the triggering event is triggered, the triggering case data associated with the triggering event is obtained, and the triggering case data is included in the hierarchical knowledge base, specifically including: Receive the alarm signal generated by the alarm event; The alarm signal is analyzed to obtain the alarm level and alarm type; Using the alarm level and alarm type, a structured query is performed in the hierarchical knowledge base to obtain a triplet of handling cases; An alarm vector is generated based on the alarm signal, and a similarity search is performed on the alarm vector in the hierarchical knowledge base to obtain a handling case vector; Based on the disposal case triplet, the disposal case vector, and the obtained actual disposal information, the trigger case data is determined, and conflict detection is performed on the trigger case data in the hierarchical knowledge base to obtain the detection result. If the detection result meets the preset conflict inclusion condition, the trigger case data is included in the hierarchical knowledge base.

[0022] This approach, by parsing received alarm signals when the triggering event is an alarm event, accurately identifies the physical level (i.e., alarm level) and anomaly category (i.e., alarm type), thus accurately associating dynamic alarm events with the hierarchical structure of the layered knowledge base. Structured queries using alarm levels and types quickly retrieve standardized and procedural handling procedures (i.e., handling case triples), ensuring accurate responses. Simultaneously, by converting alarm signals into vectors and performing similarity retrieval, historically semantically similar handling experiences (i.e., handling case vectors) can be recalled, enhancing contextual support for handling complex or novel alarms. By integrating the aforementioned precise procedures, associated experiences, and actual handling information, structured and reusable new trigger case data is formed. After conflict detection, this data is incorporated into the layered knowledge base, achieving closed-loop learning and real-time evolution of the layered knowledge base in real-world operational scenarios, systematically improving the accuracy of case matching and decision adaptability.

[0023] Secondly, one embodiment of this application provides an operation and maintenance case matching device based on a hierarchical knowledge base, including a first module, a second module, a third module and a fourth module; The first module is used to receive operation and maintenance case matching requests sent by the running large model during the operation and maintenance of the flexible DC converter station; The second module is used to parse the operation and maintenance case matching request to obtain the first-level identifier, the case type identifier, and the operation and maintenance intent query statement; The third module is used to determine the initial hierarchical case range corresponding to the first hierarchical identifier in a preset hierarchical knowledge base based on the first hierarchical identifier, and to perform parallel retrieval in the initial hierarchical case range using the case type identifier and the operation and maintenance intent query statement to obtain operation and maintenance action triples and operation and maintenance semantic vectors. The preset hierarchical knowledge base is constructed by constructing corresponding hierarchies and combining them using the component categories in the physical topology of the modular multilevel converter in the flexible DC converter station. The initial hierarchical case range includes graph database case range and vector database case range. The fourth module is used to aggregate the operation and maintenance action triples and the operation and maintenance semantic vectors to obtain the target operation and maintenance case.

[0024] The first module receives maintenance case matching requests sent by the large-scale model during the operation and maintenance of the flexible DC converter station. This allows for the capture of clear case matching requirements for the flexible DC converter station's operation and maintenance from the source of maintenance decisions, ensuring the accuracy of case matching from the outset. The second module parses the maintenance case matching requests to obtain a first-level identifier, a case type identifier, and a maintenance intent query statement. This deconstructs complex natural language requests into precise retrieval dimensions. The first-level identifier directly corresponds to the physical topology level of the flexible DC converter station's MMC, providing accurate input for subsequent hierarchical retrieval and laying the foundation for accurate case matching. The third module determines the initial hierarchical case range in a preset hierarchical knowledge base based on the first-level identifier. This hierarchical knowledge base is defined as being constructed and combined using the component categories in the physical topology of the modular multilevel converter in the flexible DC converter station. The initial hierarchical case range includes both graph database case ranges and vector database case ranges. By utilizing a knowledge organization method strictly aligned with the physical structure of the equipment, the retrieval scope can be expanded from a global perspective. The algorithm converges to a specific hierarchical subset corresponding to the faulty equipment or maintenance object, completely resolving the hierarchical confusion problem caused by flat storage in existing technologies at the data source level. It also provides a well-organized search space that separates structured and semantic knowledge for subsequent parallel retrieval, improving the accuracy of case matching. Parallel retrieval of maintenance action triples and maintenance semantic vectors is performed within the initial hierarchical case range using case type identifiers and maintenance intent query statements. This allows for simultaneous execution of precise retrieval based on structured queries and related retrieval based on semantic similarity within a defined hierarchy. This ensures the accuracy and standardization of the matched cases' operational steps while expanding the coverage of unstructured knowledge such as relevant experience and contextual background, overcoming the shortcomings of existing single retrieval mechanisms that cannot balance accuracy and relevance, thus improving the accuracy of case matching. The fourth module aggregates the maintenance action triples and maintenance semantic vectors to obtain target maintenance cases. This integrates precise structured operational steps with rich semantic association information into a unified, complete, and context-enhanced target maintenance case, further improving the accuracy of case matching. Attached Figure Description

[0025] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0026] Figure 1 This is a flowchart illustrating an embodiment of an operation and maintenance case matching method based on a hierarchical knowledge base provided in this application; Figure 2This is a flowchart illustrating steps S201 to S205 provided in this application; Figure 3 This is a flowchart illustrating steps S301 to S302 provided in this application; Figure 4 This is a schematic diagram of the structure of an operation and maintenance case matching device based on a hierarchical knowledge base provided in this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0029] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0030] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0031] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0032] In the description of the embodiments of this application, the term "multiple" refers to two or more (including two), similarly, "multiple sets" refers to two or more (including two sets), and "multiple pieces" refers to two or more (including two pieces).

[0033] In the description of the embodiments of this application, unless otherwise expressly specified and limited, technical terms such as "installation," "connection," "joining," and "fixing" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. For those skilled in the art, the specific meaning of the above terms in the embodiments of this application can be understood according to the specific circumstances.

[0034] In the power system field, flexible DC converter stations are key hubs for new energy grid connection and inter-regional power transmission. They rely on large-scale operational models for operation and maintenance case matching to achieve intelligent operation and maintenance decisions. Existing case matching technologies are mainly based on traditional knowledge management systems, which have two significant shortcomings: First, the use of a flat storage architecture leads to a mixture of operation and maintenance cases at different physical levels, making it difficult to achieve hierarchical accurate matching and affecting matching accuracy. Second, the lack of a hierarchical fusion retrieval mechanism means that it is unable to locate precise operation and maintenance actions through structured queries or obtain related context through semantic retrieval, resulting in incomplete and inaccurate matching results, which restricts the accuracy of case matching in large-scale operational models.

[0035] See Figure 1 To improve the accuracy of case matching when operating a large model for the operation and maintenance of flexible DC converter stations, an embodiment of the present invention provides an operation and maintenance case matching method based on a hierarchical knowledge base, including steps S101 to S104. Step S101: Receive the operation and maintenance case matching request sent by the running large model during the operation and maintenance of the flexible DC converter station; In some embodiments, receiving a maintenance case matching request sent by the large-scale operation model during the operation and maintenance of a flexible DC converter station specifically includes: receiving a maintenance case matching request from the RESTful API interface of the large-scale operation model of the new flexible DC converter station. This request is triggered by the large-scale model during the intelligent operation and maintenance of the flexible DC converter station for maintenance needs such as equipment anomalies, fault diagnosis, or routine maintenance. After receiving the request, the model first verifies the integrity of its format and parameters, and discards invalid requests with missing parameters or incorrect formats. At the same time, a unique retrieval identifier is assigned to each valid request for subsequent tracking and management of the entire case matching process. The request message carries core parameters related to the operation and maintenance intent expressed in natural language, which are pre-determined by the large-scale operation model based on the hierarchical orientation, case type requirements, and the maintenance intent expressed in natural language.

[0036] It should be noted that the operation and maintenance case matching request message is encapsulated in JSON format and includes at least the target level field layer, the case type field knowledge_type, and the natural language query field query (such as the handling solution for the sudden increase in current of valve group V2).

[0037] Step S102: Parse the operation and maintenance case matching request to obtain the first-level identifier, case type identifier, and operation and maintenance intent query statement; In some embodiments, the maintenance case matching request is parsed to obtain a first-level identifier, a case type identifier, and a maintenance intent query statement. Specifically, this includes: extracting the `layer` field value from the JSON structure of the maintenance case matching request message and mapping it to the first-level identifier. This identifier specifically includes four types: submodule identifier, valve group identifier, converter identifier, and system identifier, which correspond to the predefined submodule layer, valve group layer, converter layer, and system layer in the layered knowledge base, respectively; extracting the `knowledge_type` field value and mapping it to the case type identifier, including predefined types such as fault cases, maintenance procedures, and real-time data; and extracting the `query` field value to obtain the maintenance intent query statement. This statement is natural language text input by maintenance personnel or automatically generated by running a large model. The system also performs text cleaning on the maintenance intent query statement, including removing leading and trailing whitespace characters and unifying full-width and half-width formats.

[0038] Step S103: Based on the first level identifier, determine the initial level case range corresponding to the first level identifier in the preset hierarchical knowledge base. Perform parallel retrieval in the initial level case range using the case type identifier and the operation and maintenance intent query statement to obtain operation and maintenance action triples and operation and maintenance semantic vectors. The preset hierarchical knowledge base is constructed and combined using the component categories in the physical topology of the modular multilevel converter in the flexible DC converter station. The initial level case range includes graph database case range and vector database case range. See Figure 2 In some embodiments, the preset hierarchical knowledge base is obtained by constructing corresponding levels and combining them using the component categories in the physical topology of the modular multilevel converter in the flexible DC converter station, specifically including steps S201 to S205. Step S201: Construct a case architecture based on the component category, wherein the component category includes sub-modules, valve groups, converters and systems, and the case architecture includes a sub-module layer corresponding to the sub-module, a valve group layer corresponding to the valve group, a converter layer corresponding to the converter and a system layer corresponding to the system; In some embodiments, a case architecture is constructed based on the component categories, wherein the component categories include submodules, valve groups, converters, and systems. The case architecture includes a submodule layer corresponding to the submodules, a valve group layer corresponding to the valve groups, a converter layer corresponding to the converters, and a system layer corresponding to the systems. Specifically, based on the physical topology of the modular multilevel converters in the flexible DC converter station, the equipment level is divided into four levels: submodules, valve groups, converters, and systems. Each level serves as an independent knowledge organization unit. For the submodule layer, its knowledge scope is defined to focus on the smallest equipment unit (such as IGBTs and capacitors), covering real-time monitoring data (such as voltage and temperature), equipment ledgers (such as model and factory parameters), and single-module maintenance procedures (such as IGBT replacement steps). For the valve group layer, its knowledge scope is defined to cover valve groups composed of multiple submodules (such as 200 submodules / valve groups), covering valve group collaborative control logic. (e.g., redundancy switching strategies), valve-side electrical quantity data, and valve group-level fault cases (e.g., bridge arm short circuit handling); for converters integrating multiple valve groups, the knowledge scope of the converter layer is defined to cover converter control strategies (e.g., modulation algorithms), converter-side electrical quantity data (e.g., DC voltage), and converter-level operation and maintenance plans (e.g., annual maintenance plans); for systems facing the entire station, the knowledge scope of the system layer is defined to cover station-wide alarm linkage rules, external industry cases, and grid connection standards; the various levels are connected through three types of cross-layer relationships: parent-child association (e.g., submodule layer knowledge is associated with its respective valve group layer, e.g., submodule S15 ledger → valve group V2), causal association (e.g., lower-level fault knowledge is associated with upper-level response strategies, e.g., submodule IGBT open circuit → valve group redundancy switching logic), and data association (e.g., real-time data is associated with static knowledge at the same level, e.g., valve group V2 current surge → V2 short circuit fault procedure), forming a knowledge organization system with MMC physical topology as its backbone.

[0039] Step S202: Based on the case architecture, construct a hierarchical graph database and a hierarchical vector database. Each layer of the hierarchical graph database and the hierarchical vector database contains a second-level identifier that identifies the level. The second-level identifier includes a submodule identifier, a valve group identifier, a converter identifier, and a system identifier. In some embodiments, based on the case architecture, a hierarchical graph database and a hierarchical vector database are constructed. Each layer of the hierarchical graph database and the hierarchical vector database contains a second-level identifier that identifies the level. The second-level identifier includes a submodule identifier, a valve group identifier, a converter identifier, and a system identifier. Specifically, based on the completed four-layer case architecture, a hierarchical graph database is built using Neo4j (a graph database management system) to store structured case knowledge with {entity, relation, attribute} triples. A hierarchical vector database is built using FAISS (a similarity search vector library) to store unstructured case knowledge in the form of high-dimensional semantic vectors encoded by a domain-fine-tuned language model. Both types of databases are strictly deployed hierarchically according to the submodule layer, valve group layer, converter layer, and system layer of the case architecture. Each layer is configured with an independent storage partition and retrieval engine. At the same time, a second-level identifier is assigned to each level of the hierarchical graph database and the hierarchical vector database, specifically including a submodule identifier, a valve group identifier, a converter identifier, and a system identifier. This second-level identifier serves as the core index for database retrieval and is embedded in each case data in both types of databases.

[0040] It should be noted that the hierarchical division rules and second-level identification rules of the two types of databases are completely synchronized to ensure the hierarchical consistency of case data when searching across databases.

[0041] Step S203: Based on the hierarchical graph database and the hierarchical vector database, an initial knowledge base is constructed; In some embodiments, an initial knowledge base is constructed based on the hierarchical graph database and the hierarchical vector database. Specifically, this includes: establishing a unified access interface for the two types of databases to enable cross-database joint retrieval based on the second-level identifier; building a basic database management module that includes basic functions such as data entry, updating, deletion, and backup; and establishing a unique knowledge ID association mechanism between the two types of databases (e.g., case vector ID = V2-Case-001, with the corresponding triplet IDs being the same). This completes the integration of the hierarchical graph database and the hierarchical vector database, resulting in the initial knowledge base.

[0042] Step S204: Obtain several historical cases, and parse each historical case to obtain the component identifiers corresponding to each historical case; In some embodiments, several historical cases are obtained and each historical case is parsed to obtain the component identifiers corresponding to each historical case. Specifically, this includes obtaining several historical cases related to the operation and maintenance of flexible DC converter stations from multiple sources such as the local operation and maintenance system of the flexible DC converter station, China Southern Power Grid Smart View, and the State Grid Electric Power Research Institute knowledge base. The historical cases cover various types such as sub-modules, valve groups, fault handling, routine maintenance, and parameter debugging of the modular multilevel converter at each level of the system in the flexible DC converter station. Using named entity recognition technology in natural language processing, the core equipment entities in the case text are extracted. The extracted core equipment entities are matched with the component categories in the physical topology of the modular multilevel converter to determine the specific component involved in the historical case, and then the corresponding component identifier is generated. The component identifier is completely consistent with the second-level identifier.

[0043] Step S205: Using the component identifiers involved, each historical case is assigned to the corresponding level of the hierarchical graph database and the hierarchical vector database in the initial knowledge base, thereby obtaining the hierarchical knowledge base.

[0044] In some embodiments, the step of using the involved component identifier to classify each historical case into the corresponding level of the hierarchical graph database and the hierarchical vector database in the initial knowledge base to obtain the hierarchical knowledge base specifically includes: for each historical case, using a preset information extraction model to extract knowledge from the historical case to obtain a historical action triplet corresponding to the historical case; using a preset language model to perform semantic encoding processing on the historical case to obtain a historical semantic vector corresponding to the historical case; and storing the historical action triplet and the historical semantic vector into the corresponding level of the hierarchical graph database and the hierarchical vector database, respectively, where the second level identifier is the same as the involved component identifier, to obtain the hierarchical knowledge base. Specifically, for each historical case, an information extraction model based on spaCy is used to extract knowledge from the historical cases, identifying entities, relationships between entities, and entity attributes. The unstructured case text is converted into historical action triples with {entity, relationship, attribute} as the core structure (e.g., {submodule S15, belongs to, valve group V2}, {IGBT replacement, step, disconnect DC side circuit breaker}). These historical action triples can completely retain the structured operation and maintenance knowledge in the case, including core information such as operation and maintenance objects, operation and maintenance operations, operation steps, and parameter requirements. Then, a pre-set language model based on BERT-wwm (full-word mask bidirectional encoder representation model), fine-tuned by the flexible DC domain knowledge text, is used to process the historical... The cases undergo semantic encoding, converting natural language text into historical semantic vectors (768 dimensions) that represent the deep semantics of the cases. Based on the component identifiers corresponding to the historical cases, the second-level identifiers in the hierarchical graph database and the hierarchical vector database are matched. The extracted historical action triples are stored in the corresponding level storage partition of the hierarchical graph database, and the generated historical semantic vectors are stored in the corresponding level storage partition of the hierarchical vector database. At the same time, the historical action triples and historical semantic vectors are assigned the same knowledge ID, realizing the associated storage of structured and vectorized case knowledge. After all historical cases are included, a hierarchical knowledge base with clear hierarchy and collaborative storage of structured and unstructured knowledge is formed.

[0045] By using component identifiers to categorize historical cases into corresponding levels, automated and precise knowledge organization based on physical topology can be achieved. This enables the knowledge base to ultimately form a hierarchical system that is completely consistent with the equipment structure, thoroughly solving the problem of knowledge mixing at the data source level. This ensures that when the large model is running case matching, every case retrieved is strictly limited to the correct physical level, thereby directly and significantly improving the accuracy of case matching.

[0046] In some embodiments, the historical cases include external cases. The step of using the component identifiers involved to categorize each historical case into the corresponding level of the hierarchical graph database and the hierarchical vector database in the initial knowledge base to obtain the hierarchical knowledge base further includes: extracting features from the external cases to obtain a first parameter set; extracting features from a preset ledger database using the component identifiers corresponding to the external cases to obtain a second parameter set, wherein the preset ledger database is constructed from the static standard parameters of each component in the flexible DC converter station; calculating a first similarity based on the first parameter set and the second parameter set; if the first similarity is greater than a preset threshold, performing difference replacement on the external cases using the second parameter set to obtain local adaptation cases; and categorizing the local adaptation cases into the corresponding levels of the hierarchical graph database and the hierarchical vector database in the initial knowledge base using the component identifiers corresponding to the external cases to obtain the hierarchical knowledge base. Specifically, for external industry cases accessed via HTTP interfaces, key topology parameters are extracted from interface parameters or case structured fields to form a first parameter set, including submodule model, number of submodules, valve group connection method, current threshold, and voltage threshold. Based on the component identifiers corresponding to the external case, the static rated parameters of the corresponding equipment instance are queried in the local equipment ledger database constructed from the static standard parameters of each component in the flexible DC converter station, and topology parameters of the same type are extracted to form a second parameter set representing the local benchmark. On a per-parameter basis, each parameter in the first and second parameter sets is compared, and a first similarity representing the topological similarity between the two is calculated. This topology similarity is the ratio of the number of matching parameter items to the total number of parameter items multiplied by 100%. If the calculated first similarity is greater than or equal to a preset threshold (e.g., 85%), the result is considered valid. If the external case is found to be compatible with the local flexible vertical station (FLUS), then the local standard parameters in the second parameter set are used to automatically replace the parameters that differ from those in the first parameter set. Simultaneously, the relevant parameter descriptions in the external case text are corrected to generate a locally compatible case that perfectly matches the topology and parameter standards of the local FLUS. If the topology similarity is less than a preset threshold, the external case is deemed uncompatible with the local FLUS and is directly removed without further processing. For the generated locally compatible case, based on the corresponding component identifiers, the second-level identifiers of the hierarchical graph database and hierarchical vector database are matched. These are then converted into historical action triples and historical semantic vectors, respectively, and stored in the corresponding level's storage partition. This completes the local adaptation and inclusion of the external case, ultimately resulting in a hierarchical knowledge base that integrates local cases and compatible external cases.

[0047] For example, in addition to calculating similarity by comparing each parameter in the first and second parameter sets on a per-parameter basis, the parameters can also be integrated into a vector (e.g., vector = [device model A, number of sub-modules N1, threshold X, ...]), and the first similarity can be obtained by calculating the cosine similarity of the vectors.

[0048] This process involves extracting features from external cases to obtain the first parameter set, providing an objective and quantitative comparison basis for subsequent localization adaptation and ensuring the accuracy of the adaptation process. By using the identifiers of the involved components to extract the second parameter set from a pre-set database, authoritative and accurate standard parameters for the corresponding components of the local flexible vertical station can be quickly obtained, providing a true and accurate reference benchmark for comparing external cases with local components. Calculating the first similarity between the first and second parameter sets quantitatively assesses the degree of consistency between external cases and local components in key parameters, ensuring the potential matching accuracy of the knowledge entered into the database from the source. If the first similarity is greater than a preset threshold, then the second parameter set is used... The two-parameter set corrects parameters in external cases that do not match local components to local standard parameters, generating locally adapted cases that are fully adapted to the actual local components. This solves the incompatibility problem caused by directly reusing external cases, greatly improving the applicability of external knowledge in local scenarios and thus improving the accuracy of its invocation in subsequent case matching. Locally adapted cases are categorized into corresponding levels according to the component identifiers they involve, ensuring that the adapted high-quality external knowledge can be organically integrated into the corresponding positions in the hierarchical knowledge base. This allows the running large model to obtain broader and more local case support, systematically improving the accuracy of case matching.

[0049] For example, for multi-source knowledge of different levels and types in flexible DC substations, access channels and transmission protocols for each level can be designed. Specifically, this includes: real-time monitoring data from the submodule and valve group layers are accessed through an edge computing gateway, using the MQTT protocol for low-latency, high-reliability data transmission. The edge computing gateway has a built-in data cleaning module that performs real-time preprocessing before data upload, including removing noise data with instantaneous voltage fluctuations below a threshold (e.g., 0.5%), filling in missing timestamps, and normalizing dimensions. The cleaned real-time data is directly written to the corresponding level's time-series database, InfluxDB, and associated with static knowledge such as equipment ledgers and maintenance procedures at that level through equipment IDs, for subsequent case matching and alarm triggering. For static knowledge at all levels, such as ledger information, maintenance procedures, and rated parameters, unified uploading is carried out through the web management terminal, supporting mainstream document formats such as PDF, Word, and Excel. The system automatically matches the corresponding level through a keyword matching algorithm for filenames (e.g., if it contains "submodule maintenance", it maps to the submodule level; if it contains "valve group short circuit", it maps to the valve group level). At the same time, it uses OCR optical character recognition + NLP natural language processing technology (such as Python's spaCy library) to perform structured parsing of document content, extract core knowledge information, and store it in the structured database of the corresponding level. For external industry cases such as Southern Power Grid Smart View and State Grid Electric Power Research Institute knowledge base, remote access is carried through a standardized HTTP interface, and the core topology information of the case is mandatory in the interface request parameters.

[0050] In some embodiments, after using the component identifiers to classify each historical case into the corresponding level of the hierarchical graph database and the hierarchical vector database in the initial knowledge base to obtain the hierarchical knowledge base, the method further includes: real-time monitoring of preset trigger events; if a trigger event is triggered, obtaining trigger case data associated with the trigger event and classifying the trigger case data into the hierarchical knowledge base. Specifically, after the hierarchical knowledge base is constructed, a preset trigger event monitoring module is immediately started. This module monitors various trigger events during the operation and maintenance of the flexible vertical control station in real time. Trigger events specifically include real-time alarm events (such as temperature > 80℃), new knowledge injection events, and scheduled inspection events (such as checking the standard library version every 6 hours). The monitoring module communicates with the flexible vertical control station real-time monitoring system and the operation and maintenance management system to perceive and identify various trigger events. If a trigger event is detected, the case data acquisition process is immediately started, and case data is acquired from the flexible vertical control station real-time monitoring system and the operation and maintenance management system according to the type and associated information of the trigger event. The relevant data, such as device status, fault information, operation and maintenance, and processing results, directly associated with the triggering event are integrated to generate trigger case data. This trigger case data contains both structured operation information and unstructured descriptive information. Based on the components involved in the trigger case data, corresponding component identifiers are generated. Strictly following the historical case inclusion rules, the trigger case data is converted into structured triples and vectorized semantic vectors, stored in the corresponding level of the hierarchical knowledge base, and the update is notified to the running large model hierarchical knowledge base through the message queue Kafka. This achieves dynamic updating and self-enhancement of the hierarchical knowledge base.

[0051] For example, the hierarchical knowledge base also includes a timed update mechanism, that is, static knowledge (such as operation and maintenance standards) is synchronized with external knowledge bases (such as the State Grid Electric Power Research Institute Standards Library) on an hourly basis (such as every 6 hours) to ensure the timeliness of standards.

[0052] By continuously monitoring and responding to triggered events after building the hierarchical knowledge base, the latest dynamic data directly related to the operation and maintenance site can be automatically captured and processed. This data is then promptly added to the hierarchical knowledge base as trigger case data, enabling the knowledge base to be updated and self-enhanced synchronously with the operation and maintenance process. This ensures that the timeliness of the cases in the hierarchical knowledge base is synchronized with the site status, thereby guaranteeing that the knowledge called upon by the running large model during case matching is always up-to-date and most relevant, further improving the accuracy of case matching.

[0053] In some embodiments, the triggering event includes an alarm event. If the triggering event is triggered, obtaining trigger case data associated with the triggering event and incorporating the trigger case data into the hierarchical knowledge base specifically includes: receiving an alarm signal generated by the alarm event; parsing the alarm signal to obtain an alarm level and alarm type; performing a structured query in the hierarchical knowledge base using the alarm level and alarm type to obtain a handling case triplet; generating an alarm vector based on the alarm signal and performing a similarity search on the alarm vector in the hierarchical knowledge base to obtain a handling case vector; determining the trigger case data based on the handling case triplet, the handling case vector, and the obtained actual handling information, and performing conflict detection on the trigger case data in the hierarchical knowledge base to obtain a detection result. If the detection result meets a preset conflict incorporation condition, the trigger case data is incorporated into the hierarchical knowledge base.Specifically, the system receives alarm signals generated by real-time monitoring events at the flexible DC substation. These alarm signals are triggered by real-time monitoring data from the substation equipment, such as submodule temperature exceeding thresholds or sudden increases in valve group current. The alarm signals contain information such as the device ID, alarm value, and alarm time. The received alarm signals are parsed. First, the physical topology of the modular multilevel converter in the flexible DC substation is matched based on the device ID to determine the corresponding device level, generating an alarm level that is consistent with the second-level identifier. Then, based on the alarm value and device type, the specific anomaly category of the alarm is determined, generating an alarm type. Using the parsed alarm level and alarm type as search criteria, a structured and precise query is performed in the hierarchical graph database of the hierarchical knowledge base to retrieve fault handling procedures matching the alarm level and alarm type, obtaining the corresponding handling case triplet. Simultaneously, the core information of the alarm signal is converted into standardized text, and semantically encoded using a preset BERT-wwm language model to generate an alarm vector. This alarm vector is then used to... For retrieval purposes, an approximate nearest neighbor similarity search is performed in the hierarchical vector database of the hierarchical knowledge base to find the historical alarm handling cases that are semantically most similar to the alarm vector, thus obtaining the handling case vector. After the alarm event is handled, the actual handling information of the alarm event is obtained from the flexible substation operation and maintenance management system, including handling steps, operation parameters, handling results, and experience summaries of operation and maintenance personnel. The handling case triples, handling case vectors, and actual handling information are integrated to generate trigger case data that combines structured and unstructured elements. Then, the conflict detection mechanism of the hierarchical knowledge base is used to compare the trigger case data with existing case data of the same level and type in the knowledge base to check for completely duplicated case records. If the detection result shows no duplicate cases, that is, the preset conflict inclusion condition is met, the trigger case data is converted into historical action triples and historical semantic vectors, assigned a unique knowledge ID, and stored in the corresponding level in the hierarchical knowledge base. If the detection result shows that duplicate cases exist, the trigger case data is removed and no inclusion operation is performed.

[0054] This approach, by parsing received alarm signals when the triggering event is an alarm event, accurately identifies the physical level (i.e., alarm level) and anomaly category (i.e., alarm type), thus accurately associating dynamic alarm events with the hierarchical structure of the layered knowledge base. Structured queries using alarm levels and types quickly retrieve standardized and procedural handling procedures (i.e., handling case triples), ensuring accurate responses. Simultaneously, by converting alarm signals into vectors and performing similarity retrieval, historically semantically similar handling experiences (i.e., handling case vectors) can be recalled, enhancing contextual support for handling complex or novel alarms. By integrating the aforementioned precise procedures, associated experiences, and actual handling information, structured and reusable new trigger case data is formed. After conflict detection, this data is incorporated into the layered knowledge base, achieving closed-loop learning and real-time evolution of the layered knowledge base in real-world operational scenarios, systematically improving the accuracy of case matching and decision adaptability.

[0055] This case architecture, built based on component categories and including submodule, valve group, converter, and system layers, ensures that the knowledge base's organizational structure is strictly aligned with the actual physical topology of the flexible DC station. This provides an accurate logical framework for hierarchical knowledge storage and retrieval, guaranteeing the hierarchical accuracy of subsequent case matching from an architectural design perspective. By constructing a hierarchical graph database and hierarchical vector database with second-level identifiers based on this case architecture, independent storage partitions with clear hierarchical identifiers, corresponding one-to-one with the physical levels, can be established, providing a clear and isolated data foundation for accurate case matching. Furthermore, building an initial knowledge base containing the hierarchical graph database and hierarchical vector database provides a hierarchical and structured data container for the inclusion of historical cases, ensuring the knowledge base is ready for use from the outset. The ability to organize hierarchically improves the accuracy of subsequent case matching. By acquiring historical cases and parsing the identifiers of the components involved, the system can automatically identify the specific physical components associated with each case, providing a key basis for accurately classifying them into the corresponding level. This avoids the subjectivity and errors of manual classification and improves the accuracy of subsequent case matching. By using the identifiers of the components involved to classify each historical case into the corresponding level, the system can achieve automated and precise organization of knowledge based on physical topology. This allows the knowledge base to ultimately form a hierarchical system that is completely consistent with the equipment structure. This completely solves the problem of knowledge mixing at the data source level, ensuring that when the large model is running case matching, each case retrieved is strictly limited to the correct physical level, thereby directly and significantly improving the accuracy of case matching.

[0056] In some embodiments, determining the initial hierarchical case range corresponding to the first hierarchical identifier in a preset hierarchical knowledge base based on the first hierarchical identifier specifically includes: if the first hierarchical identifier is the submodule identifier, then performing an interval search in the hierarchical knowledge base to determine the graph database case range and the vector database case range where the second hierarchical identifier is the submodule identifier; if the first hierarchical identifier is the valve group identifier, then performing an interval search in the hierarchical knowledge base to determine the graph database case range and the vector database case range where the second hierarchical identifier is the valve group identifier; if the first hierarchical identifier is the converter identifier, then performing an interval search in the hierarchical knowledge base to determine the graph database case range and the vector database case range where the second hierarchical identifier is the converter identifier; if the first hierarchical identifier is the system identifier, then performing an interval search in the hierarchical knowledge base to determine the graph database case range and the vector database case range where the second hierarchical identifier is the system identifier; and determining the initial hierarchical case range based on the graph database case range and the vector database case range. Specifically, the first-level identifier obtained from parsing the operation and maintenance case matching request is used as follows: If the first-level identifier is a sub-module identifier, then this identifier is used as the core index to perform a range search in the hierarchical knowledge base. This locks all case data in the hierarchical graph database where the second-level identifier is a sub-module identifier, forming the case range for the graph database. Simultaneously, it locks all case vectors in the hierarchical vector database where the second-level identifier is a sub-module identifier, forming the case range for the vector database. If the first-level identifier is a valve group identifier, then the same search logic is used to retrieve case data and case vectors where the second-level identifier is a valve group identifier from both the hierarchical graph database and the hierarchical vector database, respectively, forming the corresponding graph database. The case scope and vector database case scope are determined as follows: If the first-level identifier is a converter identifier, the same identifier is used as an index to retrieve case data and case vectors with the second-level identifier being a converter identifier from the two types of databases in the hierarchical knowledge base, thus determining the corresponding graph database case scope and vector database case scope; if the first-level identifier is a system identifier, the case data and case vectors with the second-level identifier being a system identifier are retrieved to form the corresponding graph database case scope and vector database case scope; finally, the graph database case scope and vector database case scope that match the first-level identifier are integrated to serve as the initial hierarchical case scope for this case matching.

[0057] This approach allows for precise range retrieval within the hierarchical knowledge base based on first-level identifiers (such as submodules, valve groups, converters, or system identifiers). This enables rapid location and locking of graph database and vector database case ranges that strictly correspond to that level. It ensures that the retrieval process is efficiently converged to a specific physical level directly related to the operation and maintenance object, completely avoiding interference from irrelevant cross-level knowledge at the operational level, thereby directly improving the accuracy of case matching.

[0058] See Figure 3 In some embodiments, the parallel retrieval of the case type identifier and the operation and maintenance intent query statement in the initial level case range to obtain the operation and maintenance action triplet and the operation and maintenance semantic vector specifically includes steps S301 to S302. Step S301: Use the case type identifier to perform a structured search within the graph database case range of the initial level case range to obtain the maintenance action triplet; In some embodiments, the operation and maintenance action triples are obtained by performing a structured search within the graph database case range in the initial hierarchical case range using the case type identifier. Specifically, each case data in the hierarchical graph database is labeled with a corresponding case type tag, and the tag is consistent with the case type identifier. The structured case data in the graph database case range that completely matches the case type tag and the case type identifier are filtered out to obtain the operation and maintenance action triples stored in the form of {entity, relation, attribute}.

[0059] Step S302: Using the case type identifier and the operation and maintenance intent query statement, perform a similarity search on the vector database case range within the initial level case range to obtain the operation and maintenance semantic vector; In some embodiments, the step of performing a similarity search on the vector database case range within the initial level case range using the case type identifier and the operation and maintenance intent query statement to obtain the operation and maintenance semantic vector specifically includes: encoding the operation and maintenance intent query statement using a preset encoding model to obtain a query vector; determining several candidate case vectors in the vector database case range based on the case type identifier; calculating the similarity between the query vector and each of the candidate case vectors to obtain several second similarities; and filtering each second similarity using preset similarity conditions to obtain the operation and maintenance semantic vector. Specifically, a BERT-wwm pre-defined encoding model, fine-tuned for the flexible and directive domain, is used to semantically encode the operation and maintenance intent query statement. This transforms the natural language query statement into a high-dimensional (768-dimensional) query vector that represents its deep operation and maintenance intent. This query vector has the same dimension and semantic representation rules as the case vectors in the hierarchical vector database. Using the case type identifier as a filtering condition, all case vectors whose case types match the case type identifier are selected from the vector database case range within the determined initial hierarchical case range, forming several candidate case vectors. This ensures that the candidate case vectors match the case type of the current operation and maintenance intent. The requirements are consistent; using cosine similarity as the calculation criterion, the generated query vector is compared with each candidate case vector to obtain the similarity value between each candidate case vector and the query vector, i.e., several second similarities; preset similarity conditions are set in advance, including a minimum similarity threshold and a maximum number of returns. First, candidate case vectors with second similarity lower than the minimum similarity threshold are eliminated. Then, the remaining candidate case vectors are sorted from high to low according to the second similarity. The top N candidate case vectors are selected as the final result, where N is the preset maximum number of returns. Finally, an operation and maintenance semantic vector that highly matches the semantic meaning of this operation and maintenance intention is obtained.

[0060] By using a pre-defined encoding model to encode the natural language description of the operation and maintenance intent query statement into a query vector, a precise quantitative expression of complex semantics is achieved. Candidate case vectors are selected based on case type identifiers, ensuring that the retrieval process focuses on specific types of knowledge categories. By calculating the similarity between the query vector and the candidate case vector and filtering according to pre-defined similarity conditions, the cases most relevant to the current operation and maintenance intent semantics can be automatically and objectively identified from a large number of candidate knowledge sources. This effectively expands the coverage and semantic relevance of knowledge retrieval, thereby significantly enhancing the completeness and contextual relevance of case matching results, and ultimately improving the accuracy of case matching in running large models.

[0061] By utilizing case type identifiers and operation and maintenance intent query statements to perform parallel retrieval within the initial level of cases to obtain operation and maintenance action triples and operation and maintenance semantic vectors, it is possible to simultaneously perform precise retrieval based on structured queries and related retrieval based on semantic similarity within a limited level. This ensures the accuracy and standardization of the operational steps in the matched cases, while also expanding the coverage of unstructured knowledge such as relevant experience and contextual background. This overcomes the shortcomings of existing single retrieval mechanisms that cannot balance accuracy and relevance, thereby improving the accuracy of case matching.

[0062] Step S104: Aggregate the operation and maintenance action triplet and the operation and maintenance semantic vector to obtain the target operation and maintenance case.

[0063] In some embodiments, the operation and maintenance action triples and the operation and maintenance semantic vectors are aggregated to obtain a target operation and maintenance case. Specifically, this includes: fusing the operation and maintenance action triples retrieved from the graph database with the operation and maintenance semantic vectors retrieved from the vector database; constructing a sequence of handling steps for the case using the operation and maintenance action triples as the main framework; using historical case summary texts corresponding to the operation and maintenance semantic vectors as reference experience, arranging them from high to low according to similarity scores, and appending them to the core step sequence as supplementary context; eliminating redundancy in the aggregated information; and removing completely duplicate triple instructions or case summaries with highly similar semantics to obtain the target operation and maintenance case.

[0064] For example, after aggregation is completed, the target operation and maintenance case needs to be encapsulated into a JSON format response message. The message includes fields such as target level, case type, core handling steps and similar experience references. It is then returned to the running big model through a RESTful API interface as an enhanced context input for its operation and maintenance decision-making.

[0065] For example, to further ensure service response speed, this application designs an optimization mechanism for high-frequency or repetitive query patterns. Specifically, for the final formatted knowledge package generated by a combination of specific parameters (target_layer, knowledge_type, query intent), it is automatically stored in a Redis in-memory database for caching after its initial generation and aggregation. A reasonable expiration time is dynamically set according to the knowledge type. The expiration time for high-frequency knowledge such as submodule basic ledgers and common fault handling is set to 24 hours, and the expiration time for knowledge such as system-level grid connection standards and low-frequency operation and maintenance solutions is set to 72 hours to ensure the timeliness of cached knowledge and efficient use of storage space. When the subsequent running large model sends an operation and maintenance case matching request with the same core parameter combination, the interface service will directly retrieve the corresponding standardized knowledge package from the Redis cache and return it without repeating step S103. This strictly controls the interface response time to within 100 milliseconds, fully meeting the real-time interaction requirements of second-level inference for flexible vertical station fault handling.

[0066] By receiving maintenance case matching requests sent by the large-scale model during the operation and maintenance of the flexible DC converter station, clear case matching requirements for the flexible DC converter station's operation and maintenance can be captured from the source of operation and maintenance decisions, ensuring the accuracy of case matching from the source. Parsing the maintenance case matching requests yields a first-level identifier, a case type identifier, and an operation and maintenance intent query statement. This deconstructs complex natural language requests into precise retrieval dimensions. The first-level identifier directly corresponds to the physical topology level of the flexible DC converter station's MMC, providing precise input for subsequent hierarchical retrieval and laying the foundation for accurate case matching. Based on the first-level identifier, an initial hierarchical case range is determined in a preset hierarchical knowledge base. This hierarchical knowledge base is defined as being constructed and combined using the component categories in the physical topology of the modular multilevel converter in the flexible DC converter station. The initial hierarchical case range includes graph database case ranges and vector database case ranges. Utilizing a knowledge organization method strictly aligned with the equipment's physical structure, the retrieval scope can be converged from the global to the level relevant to the fault. This approach, by identifying specific hierarchical subsets corresponding to faulty equipment or maintenance objects, completely resolves the hierarchical confusion caused by flat storage in existing technologies at the data source level. It also provides a well-organized search space that separates structured and semantic knowledge for subsequent parallel retrieval, improving the accuracy of case matching. Parallel retrieval of maintenance action triples and semantic vectors within the initial hierarchical case range using case type identifiers and maintenance intent query statements allows for simultaneous execution of precise retrieval based on structured queries and associative retrieval based on semantic similarity within a defined hierarchy. This ensures the accuracy and standardization of matching cases in terms of operational steps while expanding the coverage of unstructured knowledge such as relevant experience and contextual background, overcoming the shortcomings of existing single retrieval mechanisms that cannot simultaneously address accuracy and relevance, thus improving the accuracy of case matching. Aggregating the maintenance action triples and semantic vectors yields target maintenance cases, integrating precise structured operational steps with rich semantic association information into a unified, complete, and context-enhanced target maintenance case, further improving the accuracy of case matching. This application can improve the case matching accuracy of large-scale operational models when performing maintenance on flexible DC converter stations.

[0067] See Figure 4 Based on the above method embodiments, corresponding device embodiments are provided; An embodiment of the present invention provides an operation and maintenance case matching device based on a hierarchical knowledge base, including a first module 100, a second module 200, a third module 300 and a fourth module 400; The first module 100 is used to receive operation and maintenance case matching requests sent by the running large model during the operation and maintenance of the flexible DC converter station; The second module 200 is used to parse the operation and maintenance case matching request to obtain the first-level identifier, the case type identifier, and the operation and maintenance intent query statement; The third module 300 is used to determine the initial hierarchical case range corresponding to the first hierarchical identifier in a preset hierarchical knowledge base based on the first hierarchical identifier, and to perform parallel retrieval in the initial hierarchical case range using the case type identifier and the operation and maintenance intent query statement to obtain operation and maintenance action triples and operation and maintenance semantic vectors. The preset hierarchical knowledge base is constructed by constructing corresponding hierarchies and combining them using the component categories in the physical topology of the modular multilevel converter in the flexible DC converter station. The initial hierarchical case range includes graph database case range and vector database case range. The fourth module 400 is used to aggregate the operation and maintenance action triples and the operation and maintenance semantic vectors to obtain the target operation and maintenance case.

[0068] The first module receives maintenance case matching requests sent by the large-scale model during the operation and maintenance of the flexible DC converter station. This allows for the capture of clear case matching requirements for the flexible DC converter station's operation and maintenance from the source of maintenance decisions, ensuring the accuracy of case matching from the outset. The second module parses the maintenance case matching requests to obtain a first-level identifier, a case type identifier, and a maintenance intent query statement. This deconstructs complex natural language requests into precise retrieval dimensions. The first-level identifier directly corresponds to the physical topology level of the flexible DC converter station's MMC, providing accurate input for subsequent hierarchical retrieval and laying the foundation for accurate case matching. The third module determines the initial hierarchical case range in a preset hierarchical knowledge base based on the first-level identifier. This hierarchical knowledge base is defined as being constructed and combined using the component categories in the physical topology of the modular multilevel converter in the flexible DC converter station. The initial hierarchical case range includes both graph database case ranges and vector database case ranges. By utilizing a knowledge organization method strictly aligned with the physical structure of the equipment, the retrieval scope can be expanded from a global perspective. The algorithm converges to a specific hierarchical subset corresponding to the faulty equipment or maintenance object, completely resolving the hierarchical confusion problem caused by flat storage in existing technologies at the data source level. It also provides a well-organized search space that separates structured and semantic knowledge for subsequent parallel retrieval, improving the accuracy of case matching. Parallel retrieval of maintenance action triples and maintenance semantic vectors is performed within the initial hierarchical case range using case type identifiers and maintenance intent query statements. This allows for simultaneous execution of precise retrieval based on structured queries and related retrieval based on semantic similarity within a defined hierarchy. This ensures the accuracy and standardization of the matched cases' operational steps while expanding the coverage of unstructured knowledge such as relevant experience and contextual background, overcoming the shortcomings of existing single retrieval mechanisms that cannot balance accuracy and relevance, thus improving the accuracy of case matching. The fourth module aggregates the maintenance action triples and maintenance semantic vectors to obtain target maintenance cases. This integrates precise structured operational steps with rich semantic association information into a unified, complete, and context-enhanced target maintenance case, further improving the accuracy of case matching.

[0069] It is understood that the above-described device embodiments correspond to the method embodiments of the present invention, and can implement any of the above-described method embodiments of the present invention to provide an operation and maintenance case matching method based on a hierarchical knowledge base.

[0070] It should be noted that the device embodiments described above are merely illustrative, and some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the device embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can specifically be implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0071] Based on the above embodiment of the operation and maintenance case matching method based on a hierarchical knowledge base, another embodiment of the present invention provides a terminal device, which includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements an operation and maintenance case matching method based on a hierarchical knowledge base according to any embodiment of the present invention.

[0072] For example, in this embodiment, the computer program can be divided into one or more modules, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the terminal device.

[0073] The terminal device may be a desktop computer, laptop, handheld computer, or cloud server, etc. The terminal device may include, but is not limited to, a processor and a memory.

[0074] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the terminal device, connecting all parts of the terminal device via various interfaces and lines.

[0075] Based on the above-described method embodiments, another embodiment of the present invention provides a computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to execute the operation and maintenance case matching method based on a hierarchical knowledge base as described in any of the above-described method embodiments of the present invention.

[0076] The modules / units integrated in the device / terminal equipment, if implemented as software functional units and sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0077] Based on the above-described method embodiments, another embodiment of the present invention provides a computer program product, including a computer program or instructions, which, when executed by a communication device, implements an operation and maintenance case matching method based on a hierarchical knowledge base.

[0078] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A layered knowledge base based operation and maintenance case matching method, characterized in that, include: Receive operation and maintenance case matching requests sent by the large-scale operational model during the operation and maintenance of the flexible DC converter station; The operation and maintenance case matching request is parsed to obtain the first-level identifier, the case type identifier, and the operation and maintenance intent query statement; Based on the first-level identifier, an initial-level case range corresponding to the first-level identifier is determined in a preset hierarchical knowledge base. Parallel retrieval is performed in the initial-level case range using the case type identifier and the operation and maintenance intent query statement to obtain operation and maintenance action triples and operation and maintenance semantic vectors. The preset hierarchical knowledge base is constructed and combined using the component categories in the physical topology of the modular multilevel converter in the flexible DC converter station. The initial-level case range includes graph database case range and vector database case range. The operation and maintenance action triples and the operation and maintenance semantic vectors are aggregated to obtain the target operation and maintenance case.

2. The layered knowledge base based operation and maintenance case matching method according to claim 1, characterized in that, The preset hierarchical knowledge base is obtained by constructing corresponding levels and combining them according to the component categories in the physical topology of the modular multilevel converter in the flexible DC converter station. Specifically, it includes: A case architecture is constructed based on the component categories, wherein the component categories include sub-modules, valve groups, converters, and systems. The case architecture includes a sub-module layer corresponding to the sub-modules, a valve group layer corresponding to the valve groups, a converter layer corresponding to the converters, and a system layer corresponding to the systems. Based on the aforementioned case architecture, a hierarchical graph database and a hierarchical vector database are constructed. Each layer of the hierarchical graph database and the hierarchical vector database contains a second-level identifier that identifies the level. The second-level identifier includes a submodule identifier, a valve group identifier, a converter identifier, and a system identifier. An initial knowledge base is constructed based on the hierarchical graph database and the hierarchical vector database. Obtain several historical cases, and parse each historical case to obtain the component identifiers corresponding to each historical case; Using the component identifiers involved, each historical case is assigned to the corresponding level of the hierarchical graph database and the hierarchical vector database in the initial knowledge base, thus obtaining the hierarchical knowledge base.

3. The layered knowledge base based operation and maintenance case matching method according to claim 2, characterized in that, The step of using the component identifiers involved to categorize each historical case into the corresponding level of the hierarchical graph database and the hierarchical vector database in the initial knowledge base, thereby obtaining the hierarchical knowledge base, specifically includes: For each of the aforementioned historical cases, a preset information extraction model is used to extract knowledge from the historical cases to obtain the corresponding historical action triplet for each historical case. The historical cases are semantically encoded using a preset language model to obtain the historical semantic vectors corresponding to the historical cases; The historical action triples and the historical semantic vectors are stored in the hierarchical graph database and the hierarchical vector database, respectively, at the corresponding levels where the second-level identifier and the identifier of the involved component are the same, to obtain the hierarchical knowledge base.

4. The layered knowledge base based operation and maintenance case matching method according to claim 2, characterized in that, The historical cases include external cases. The step of using the relevant component identifiers to categorize each historical case into the corresponding level of the hierarchical graph database and the hierarchical vector database in the initial knowledge base, thereby obtaining the hierarchical knowledge base, further includes: Feature extraction is performed on the external cases to obtain the first parameter set; The second parameter set is obtained by extracting features from the component identifiers corresponding to the external cases in the preset ledger database. The preset ledger database is constructed from the static standard parameters of each component in the flexible DC converter station. The first similarity is calculated based on the first parameter set and the second parameter set; If the first similarity is greater than a preset threshold, the external case is replaced with a difference using the second parameter set to obtain a local adapted case. Using the component identifiers corresponding to the external cases, the local adaptation cases are categorized into the corresponding levels of the hierarchical graph database and the hierarchical vector database in the initial knowledge base, thus obtaining the hierarchical knowledge base.

5. The layered knowledge base based operation and maintenance case matching method according to claim 2, characterized in that, The step of determining the initial hierarchical case range corresponding to the first hierarchical identifier in a preset hierarchical knowledge base based on the first hierarchical identifier specifically includes: If the first level identifier is the submodule identifier, then an interval search is performed in the hierarchical knowledge base to determine the range of graph database cases and the range of vector database cases where the second level identifier is the submodule identifier; If the first-level identifier is the valve group identifier, then an interval search is performed in the hierarchical knowledge base to determine the graph database case range and the vector database case range where the second-level identifier is the valve group identifier; If the first-level identifier is the converter identifier, then an interval search is performed in the hierarchical knowledge base to determine the graph database case range and the vector database case range where the second-level identifier is the converter identifier; If the first-level identifier is the system identifier, then an interval search is performed in the hierarchical knowledge base to determine the range of graph database cases and the range of vector database cases where the second-level identifier is the system identifier; Based on the case range of the graph database and the case range of the vector database, the initial hierarchical case range is determined.

6. The layered knowledge base based operation and maintenance case matching method according to claim 1, characterized in that, The process of using the case type identifier and the operation and maintenance intent query statement to perform parallel retrieval within the initial level case range to obtain operation and maintenance action triples and operation and maintenance semantic vectors specifically includes: The operation and maintenance action triple is obtained by performing a structured search within the graph database case range of the initial level case range using the case type identifier. The operation and maintenance semantic vector is obtained by performing a similarity search on the vector database case range within the initial level case range using the case type identifier and the operation and maintenance intent query statement.

7. The operation and maintenance case matching method based on a hierarchical knowledge base as described in claim 6, characterized in that, The step of performing a similarity search on the vector database case range within the initial level case range using the case type identifier and the operation and maintenance intent query statement to obtain the operation and maintenance semantic vector specifically includes: The operation and maintenance intent query statement is encoded using a preset encoding model to obtain a query vector; Based on the case type identifier, several candidate case vectors are determined within the case range of the vector database; The similarity between the query vector and each candidate case vector is calculated to obtain several second similarities. The second similarity is filtered using preset similarity conditions to obtain the operation and maintenance semantic vector.

8. The operation and maintenance case matching method based on a hierarchical knowledge base as described in claim 2, characterized in that, After using the component identifiers to classify each historical case into the corresponding level of the hierarchical graph database and the hierarchical vector database in the initial knowledge base to obtain the hierarchical knowledge base, the method further includes: real-time monitoring of preset trigger events; if the trigger event is triggered, obtaining the trigger case data associated with the trigger event and classifying the trigger case data into the hierarchical knowledge base.

9. The operation and maintenance case matching method based on a hierarchical knowledge base as described in claim 8, characterized in that, The triggering event includes an alarm event. If the triggering event is triggered, trigger case data associated with the triggering event is obtained, and the trigger case data is included in the hierarchical knowledge base, specifically including: Receive alarm signals generated by the alarm events; The alarm signal is analyzed to obtain the alarm level and alarm type; Using the alarm level and alarm type, a structured query is performed in the hierarchical knowledge base to obtain a triplet of handling cases; An alarm vector is generated based on the alarm signal, and a similarity search is performed on the alarm vector in the hierarchical knowledge base to obtain a handling case vector; Based on the disposal case triplet, the disposal case vector, and the obtained actual disposal information, the trigger case data is determined, and conflict detection is performed on the trigger case data in the hierarchical knowledge base to obtain the detection result. If the detection result meets the preset conflict inclusion condition, the trigger case data is included in the hierarchical knowledge base.

10. A maintenance case matching device based on a hierarchical knowledge base, characterized in that, It includes Module 1, Module 2, Module 3, and Module 4; The first module is used to receive operation and maintenance case matching requests sent by the running large model during the operation and maintenance of the flexible DC converter station; The second module is used to parse the operation and maintenance case matching request to obtain the first-level identifier, the case type identifier, and the operation and maintenance intent query statement; The third module is used to determine the initial hierarchical case range corresponding to the first hierarchical identifier in a preset hierarchical knowledge base based on the first hierarchical identifier, and to perform parallel retrieval in the initial hierarchical case range using the case type identifier and the operation and maintenance intent query statement to obtain operation and maintenance action triples and operation and maintenance semantic vectors. The preset hierarchical knowledge base is constructed by constructing corresponding hierarchies and combining them using the component categories in the physical topology of the modular multilevel converter in the flexible DC converter station. The initial hierarchical case range includes graph database case range and vector database case range. The fourth module is used to aggregate the operation and maintenance action triples and the operation and maintenance semantic vectors to obtain the target operation and maintenance case.

Images