Multi-expert hybrid paradigm power information system fault handling methods, devices, computer equipment, readable storage media, and program products

Abstract

This application relates to a multi-expert hybrid paradigm fault handling method, apparatus, computer equipment, computer-readable storage medium, and computer program product for power information systems. The method includes: acquiring fault description data from the power information system; preprocessing the fault description data to obtain fault features corresponding to the fault description data; inputting the fault features into a fault classification model to obtain the confidence level of the fault description data belonging to each candidate fault type; determining the target fault type corresponding to the fault description data from the candidate fault types based on the confidence level and a confidence threshold; sending the fault description data to a target expert model corresponding to the target fault type to obtain fault handling suggestions output by the target expert model; integrating and verifying the fault handling suggestions output by the target expert model to obtain and output the target handling suggestions corresponding to the fault description data. This method can improve the efficiency and accuracy of fault handling in power information systems.

Description

Technical Field

[0001] This application relates to the field of computer data processing technology, and in particular to a method, apparatus, computer equipment, computer-readable storage medium, and computer program product for fault handling in a multi-expert hybrid paradigm power information system. Background Technology

[0002] With the rapid development of smart grid and industrial internet technologies, the scale of power information systems is constantly expanding, and the integrated IT technology stacks are becoming increasingly complex. Modern power information systems widely adopt middleware, microservice architecture, and various network devices. Components from different technology stacks are interconnected and interwoven, jointly supporting the efficient operation of core businesses such as power dispatching, distribution automation, and power marketing. This deep integration of multiple technology stacks, while providing powerful functionality and flexibility, also brings complex challenges to fault handling in power information systems.

[0003] In the operation and maintenance of power information systems, when a system failure occurs, maintenance personnel need to quickly determine the technology stack to which the failure belongs based on the fault symptoms and formulate a handling plan based on their expertise in that technology stack. However, with the increase in the number of technology stacks and the increasing complexity of dependencies between components, traditional fault handling methods that rely on manual experience are no longer sufficient to meet the operation and maintenance needs of large-scale, highly complex power information systems. Summary of the Invention

[0004] Therefore, it is necessary to provide a multi-expert hybrid paradigm power information system fault handling method, device, computer equipment, computer-readable storage medium, and computer program product that can improve the efficiency and accuracy of fault handling and address the above-mentioned technical problems.

[0005] Firstly, this application provides a multi-expert hybrid paradigm fault handling method for power information systems, including:

[0006] Obtain fault description data from the power information system, preprocess the fault description data, and obtain the fault characteristics corresponding to the fault description data;

[0007] The fault features are input into the fault classification model to obtain the confidence level of the fault description data belonging to each candidate fault type.

[0008] The target fault type corresponding to the fault description data is determined from the candidate fault types based on the confidence level and the confidence threshold.

[0009] The fault description data is sent to the target expert model corresponding to the target fault type, so that the target expert model can analyze the fault description data and obtain the fault handling suggestions output by the target expert model; wherein, the target expert model is trained on a large language model based on the fault handling knowledge of the target fault type;

[0010] The fault handling suggestions output by the target expert model are integrated and verified to obtain and output the target handling suggestions corresponding to the fault description data.

[0011] Secondly, this application also provides a fault handling device for a multi-expert hybrid paradigm power information system, comprising:

[0012] The first acquisition module is used to acquire fault description data from the power information system, preprocess the fault description data, and obtain the fault characteristics corresponding to the fault description data.

[0013] The input module is used to input the fault features into the fault classification model to obtain the confidence level of the fault description data belonging to each candidate fault type;

[0014] The determination module is used to determine the target fault type corresponding to the fault description data from the candidate fault types based on the confidence level and the confidence threshold;

[0015] The second acquisition module is used to send the fault description data to the target expert model corresponding to the target fault type, so as to analyze the fault description data through the target expert model and obtain the fault handling suggestions output by the target expert model; wherein, the target expert model is trained on a large language model based on the fault handling knowledge of the target fault type;

[0016] The verification module is used to integrate and verify the fault handling suggestions output by the target expert model, and obtain and output the target handling suggestions corresponding to the fault description data.

[0017] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps included in any of the foregoing method embodiments.

[0018] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0019] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0020] The aforementioned power information system fault handling methods, devices, computer equipment, computer-readable storage media, and computer program products achieve accurate fault "triage" through fault classification models, solving the illusion problem of misalignment between faults and handling solutions in related technologies; they achieve professional "diagnosis" through expert models constructed according to technology stack categories, solving the problems of generalization and insufficient professionalism in single model outputs; and through the integration and verification mechanism guided by fault knowledge graphs, they achieve collaborative processing and output quality assurance for faults involving multiple technology stacks, effectively improving the accuracy and efficiency of power information system fault handling. Attached Figure Description

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

[0022] Figure 1 This is a diagram illustrating the application environment of a multi-expert hybrid paradigm power information system fault handling method in one embodiment.

[0023] Figure 2 This is a flowchart illustrating a fault handling method for a multi-expert hybrid paradigm power information system in one embodiment.

[0024] Figure 3 This is a structural block diagram of a fault handling device for a multi-expert hybrid paradigm power information system in one embodiment.

[0025] Figure 4 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0027] Before describing the embodiments of this method, the related technologies and their existing problems will be further explained:

[0028] With the rapid development of smart grids and the industrial internet, the scale of power information systems is constantly expanding, and the integrated IT technology stack is becoming increasingly complex, covering multiple technical fields such as middleware (e.g., Redis, Kafka, Nginx), databases (e.g., MySQL, Oracle, DM), microservices (e.g., Spring Cloud, Dubbo), and networking. The components of different technology stacks are interconnected and intertwined, resulting in power information system faults exhibiting characteristics of complexity, correlation, and diversity.

[0029] In related technologies, to address the issues of low efficiency and high professional threshold in manual fault handling, intelligent fault handling methods based on artificial intelligence have emerged. The most common of these is the power information system fault handling question-and-answer method based on a single model. This method collects historical fault and handling data from the power information system, extracts fault features and handling action features, and trains a unified fault handling question-and-answer model. When a new fault occurs, maintenance personnel input the fault question, and the model performs semantic parsing of the fault, outputting corresponding handling suggestions to assist maintenance personnel in completing the fault handling. This single-model architecture utilizes the semantic understanding capabilities of deep learning algorithms (such as Transformer and BERT) to perform end-to-end mapping learning between fault phenomena and handling solutions, achieving a certain degree of automation in fault handling.

[0030] However, current fault handling methods based on a single model have at least the following technical problems:

[0031] First, the model's output lacks professionalism, easily leading to illusions and generalization problems: a single model is forced to learn the mixed fault characteristics of multiple technology stacks such as middleware, databases, microservices, and networking simultaneously, making it impossible to perform in-depth, specialized learning and optimization for each technology stack. When a specific fault of a certain technology stack is input, the model's output suggestions are often too general and lack specificity. For example, for a middleware fault like "Redis connection pool exhausted," the model might output a generic response like "Please check network connectivity or restart the service." More seriously, the model may exhibit the "illusion" phenomenon of misalignment between the fault and the solution, such as incorrectly associating a database fault with a network solution. This lack of professionalism seriously affects the accuracy and reliability of fault handling.

[0032] Second, the ability to handle intertwined faults across multiple technology stacks is weak: In power information systems, there are complex dependencies between components of different technology stacks, and a single fault may be caused by anomalies in components of multiple technology stacks. For example, a "microservice call failure" may simultaneously involve multiple technology stack issues such as database connection timeouts, increased network latency, and middleware configuration errors. Relevant single models lack the ability to break down and handle intertwined faults by technology stack, failing to identify the different technology stack components involved and their relationships. This results in output handling suggestions lacking logic and specificity, making it difficult to effectively solve the problem of handling complex intertwined faults.

[0033] Third, the lack of a fault triage mechanism leads to low processing efficiency: The relevant technologies lack a dedicated fault classification module, making it impossible to accurately identify and categorize faults according to technology stack before model processing. All faults, regardless of their technology stack, must be processed entirely through a unified model. This not only increases the model's computational burden but may also lead to fault-technology stack mismatches, further reducing the response speed and accuracy of fault handling.

[0034] Therefore, it is evident that, given the characteristics of multiple technology stacks intertwined in power information systems, how to achieve professional and precise handling of faults in different technology stacks, while simultaneously improving the ability to handle faults involving multiple technology stacks, is a technical problem that urgently needs to be solved by those skilled in the art.

[0035] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0036] The multi-expert hybrid paradigm power information system fault handling method provided in this application embodiment can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or located on the cloud or other network servers. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0037] In one exemplary embodiment, such as Figure 2 As shown, a multi-expert hybrid paradigm fault handling method for power information systems is provided, which is then applied to... Figure 1 Taking terminal 102 or server 104 as an example, the following steps are included:

[0038] Step 202: Obtain fault description data from the power information system, preprocess the fault description data, and obtain the fault characteristics corresponding to the fault description data.

[0039] Fault description data can refer to natural language text information entered by maintenance personnel and other users when they discover abnormalities in the operation of the power information system, used to describe the fault phenomena. Fault description data can be entered through the human-machine interface of the maintenance personnel's terminal, such as descriptions like "database connection failed, unable to read data normally" or "microservice A frequently fails to call B, and network latency shows occasional increases" entered by maintenance personnel in the fault handling Q&A interface. Fault description data can also be automatically obtained from the power information system's alarm system, such as alarm information automatically generated by the system like "Redis connection pool exhausted" or "Nginx 502 Bad Gateway". Specifically, the sources of fault description data include text descriptions entered by maintenance personnel through terminals, alarm logs automatically generated by the power information system, fault records in the fault work order system, and abnormal event information collected from the monitoring system. In this embodiment, the fault description data exists in the form of natural language text, and its content may include the fault phenomenon, the time of fault occurrence, the name of the involved equipment or component, and related error codes or abnormal prompts.

[0040] Preprocessing refers to the cleaning, standardization, and feature extraction operations performed on the raw fault description data. The aim is to convert unstructured natural language text into structured feature vectors that can be processed by subsequent models. Specifically, preprocessing may include the following sub-steps: data cleaning (removing invalid and duplicate data), standardization (obtaining standardized descriptive data), and extracting textual features of fault phenomena and causes from the standardized descriptive data as fault features.

[0041] For example, suppose an operations and maintenance personnel inputs a fault description: "Redis connection timed out, causing microservice A to fail to query the cache." The preprocessing module first cleans the text to ensure there is no invalid or duplicate content. Then, it performs standardization: "Redis" is identified as a middleware technology stack (encoded as 1), and the fault time "2:30:25" is converted into a timestamp. Next, feature extraction is performed: the TF-IDF algorithm is used to extract the keywords "Redis," "connection," "timeout," "microservice," "cache," and "failure" as text features; simultaneously, the entity "Redis" is retrieved from the fault knowledge graph, and its type vector "middleware-key-value storage" and association vector "dependent on: microservice A" are extracted. Finally, the text features are fused with the type vector and association vector to obtain the fault feature vector F = [0.32, 0.15, 0.78, ..., 0.41].

[0042] Step 204: Input the fault features into the fault classification model to obtain the confidence level of the fault description data belonging to each candidate fault type.

[0043] A fault classification model is a pre-trained machine learning model used to identify the technology stack category to which fault description data belongs. The fault classification model can use a lightweight Transformer model as its basic architecture and introduce a technology stack feature attention mechanism on top of it. This mechanism focuses on fault features related to the technology stack category (such as technology stack keywords in the fault phenomenon and the technology stack to which associated equipment belongs), thereby improving classification accuracy.

[0044] Candidate fault types are pre-defined based on the technology stack category to which the fault belongs. The IT technology stack of a power information system can include four main categories: middleware, database, microservices, and network. Middleware faults include Redis connection pool exhaustion, Kafka message backlog, and Nginx configuration errors; database faults include MySQL connection timeouts, insufficient Oracle tablespace, and database deadlocks; microservice faults include Spring Cloud service registration failures, Dubbo call chain timeouts, and inability to connect to the configuration center; and network faults include switch port packet loss, DNS resolution failures, and firewall policy blocking. Candidate fault types can include at least two of the above four categories, specifically configured according to the actual technology stack of the power information system.

[0045] Confidence score is the probability value output by the fault classification model, used to characterize how credible it is that fault description data belongs to a certain candidate fault type. Each candidate fault type corresponds to a confidence score, and the sum of the confidence scores of all candidate fault types is 1. For example, for a fault description data, the fault classification model may output: middleware fault confidence score 0.85, database fault confidence score 0.10, microservice fault confidence score 0.03, and network fault confidence score 0.02, indicating that there is an 85% probability that the fault belongs to the middleware fault.

[0046] The input layer receives the fault feature vector. The feature attention layer calculates the correlation score between the fault features and each candidate fault type, and uses this correlation score as the attention weight to perform a weighted summation of the fault features to obtain the weighted classification features. Specifically, the feature attention layer first calculates the correlation score e_i = score(h_i, c) between each fault feature component and the candidate fault type c, where h_i is the i-th fault feature component and c is the vector representation of the candidate fault type; then, it converts the correlation score into attention weights α_i = exp(e_i) / ∑exp(e_j) using the Softmax function; finally, it calculates the weighted sum v = ∑α_i·h_i to obtain the weighted classification features. The classification output layer uses the Softmax activation function to output the probability (i.e., confidence level) of the fault belonging to each candidate fault type based on the weighted classification features.

[0047] The training process of the fault classification model may include: performing feature analysis on historical fault data of the power information system, extracting fault feature vectors and corresponding technology stack category labels from the historical fault data, and constructing training sample pairs of fault features and technology stack categories. Then, the training sample pairs are input into a preset classifier model, using the cross-entropy loss function as the optimization objective, and employing the gradient descent algorithm to jointly optimize the parameters of the feature encoding layer and the feature attention layer until the classification accuracy reaches a preset threshold (e.g., 95%) and a preset termination condition is met (e.g., the loss function value no longer decreases or the maximum number of iterations is reached), thus obtaining the trained fault classification model.

[0048] Step 206: Determine the target fault type corresponding to the fault description data from the candidate fault types based on the confidence level and the confidence level threshold.

[0049] The confidence threshold is a preset value used to determine the reliability of the classification results of the fault classification model. The confidence threshold can be set according to actual business needs, for example, to 80%. When the confidence of a candidate fault type is greater than this threshold, it indicates that the model has high confidence in its classification results, and this candidate fault type can be identified as the target fault type. When the confidence of all candidate fault types is less than this threshold, it indicates that the model cannot determine that the fault belongs to a single technology stack, meaning the fault may be an intertwined fault involving multiple technology stacks. In this case, all candidate fault types are identified as the target fault type to facilitate subsequent multi-expert collaborative processing.

[0050] The target fault type refers to the fault category that ultimately needs to be processed by the expert model, and can be one or more. Specifically, the method for determining the target fault type includes: if the maximum confidence score of the candidate fault types is greater than a preset threshold, then the candidate fault types that are sorted in descending order of confidence score and ranked in the top preset positions (such as the top 1 or top 2) are determined as the target fault types. For example, if the preset threshold is 80%, and the confidence scores of the candidate fault types are [middleware 0.92, database 0.05, microservice 0.02, network 0.01], and the maximum confidence score of 0.92 is greater than 80%, then middleware faults are determined as the target fault type.

[0051] If the maximum confidence score among the candidate fault types is less than a preset threshold, then all candidate fault types are identified as the target fault type. For example, with a preset threshold of 80%, and the confidence scores of the candidate fault types being [middleware 0.45, database 0.30, microservice 0.15, network 0.10], the maximum confidence score of 0.45 is less than 80%, indicating that the fault may involve multiple technology stacks. Therefore, middleware, database, microservice, and network are all identified as target fault types, and subsequent multi-expert collaborative processing is performed. Continuing the previous example, since the confidence score of the middleware fault (0.92) is greater than the preset threshold of 80%, the middleware fault is identified as the target fault type.

[0052] Step 208: Send the fault description data to the target expert model corresponding to the target fault type, so that the target expert model can analyze the fault description data and obtain the fault handling suggestions output by the target expert model; wherein, the target expert model is trained on a large language model based on the fault handling knowledge of the target fault type.

[0053] A target expert model refers to a pre-trained, large language model specifically designed to handle faults in a particular technology stack. This solution includes multiple expert models, each corresponding to different candidate fault types, including middleware expert models, database expert models, microservice expert models, and network expert models. For example, each expert model can use a large language model with 32 bytes or more of parameters (such as Qwen3-32B or Gemini-32B) as its foundation, and then fine-tune it by incorporating specific fault handling knowledge for the corresponding technology stack. This allows the model to accurately identify the fault modes and handling logic unique to that technology stack.

[0054] Technical stack expertise refers to the architectural principles, configuration specifications, and operational standards of the technology stack. Examples include Redis cluster configuration specifications, MySQL index optimization principles, Spring Cloud microservice registration and discovery mechanisms, and the TCP / IP protocol stack principles. Fault handling rules refer to standard handling procedures for specific fault types, such as "when the Redis connection pool is exhausted, execute the following in sequence: check maxTotal configuration, check for connection leaks, and restart the connection pool." Historical fault handling data refers to detailed records of past faults related to this technology stack, including fault symptoms, causes, handling steps, and handling effects.

[0055] Each expert model consists of a main model layer (the base layer) and an adjustment layer (the technology stack-specific fine-tuning layer) connected sequentially. The main model layer uses a pre-trained large language model with 32 bytes or more parameters to perform deep semantic encoding of fault features, uncovering the potential correlation between fault phenomena, causes, and handling actions. The adjustment layer, connected to the output of the main model layer, contains trainable fine-tuning parameters. It decodes the encoding results of the main model layer based on the technology stack knowledge corresponding to the current candidate fault type, and performs natural language processing on the decoded results to generate professional handling suggestions for the current fault. The technology stack knowledge includes the fault features of the current technology stack and the corresponding standard handling suggestions.

[0056] The training process for each expert model includes: acquiring a pre-trained large language model (such as Qwen3-32B), freezing the parameters of the large language model to maintain its general semantic understanding capability; then, using the technical stack knowledge corresponding to the current candidate fault type (i.e., specialized training data), with the cross-entropy loss function as the optimization objective, and using the gradient descent algorithm to update only the parameters of the adjustment layer, enabling the candidate expert model to learn the mapping relationship between fault features and handling suggestions of the technical stack corresponding to the current candidate fault type. During training, the specialized training data includes training sample pairs consisting of fault feature vectors of that technical stack and corresponding standard handling suggestions. When the loss function value converges to a preset range or reaches the maximum number of iterations, the preset convergence condition is met, and the trained candidate expert model is obtained. This "base freezing + adjustment layer fine-tuning" training method retains the powerful general semantic understanding capability of the large model, injects the professional knowledge of a specific technical stack, and significantly reduces the computational resources and data volume required for training.

[0057] When the target fault type is a single type, the fault description data is directly sent to the expert model (such as a middleware expert model) corresponding to that fault type. This expert model performs semantic parsing of the fault description data and outputs professional handling suggestions. These suggestions can include handling steps, execution order, and precautions, ensuring that the suggestions are specific and professional, avoiding vagueness and misalignment.

[0058] When the target fault type includes multiple types (i.e., multi-technology stack intertwined faults), the fault description data needs to be split into unprocessed fault data corresponding to each target fault type based on the fault knowledge graph. Then, each unprocessed fault data is sent to the target expert model corresponding to each target fault type for parallel processing. The fault knowledge graph includes a technology stack knowledge graph and a feature vector library. The technology stack knowledge graph includes entities representing technology stack components (such as Redis, MySQL, Nginx), faulty devices, fault phenomena, and handling actions, as well as edges representing component dependencies (such as "microservice A depends on database B"), fault propagation relationships (such as "network latency causes database connection timeout"), and fault association relationships (such as causal association, parallel association, and conflict association). The feature vector library includes technology stack type vectors, device features, handling features, and common fault features.

[0059] Following the previous example, since the target fault type is a middleware fault, the system sends the fault description data "Redis connection timeout caused microservice A to fail to query the cache" to the middleware expert model. The middleware expert model analyzes the fault and outputs the following fault handling suggestions: "1. Check the Redis service status: Execute the `redis-cli ping` command to confirm whether the service is normal; 2. Check the connection pool configuration: Check whether the `spring.redis.jedis.pool.max-active` configuration value is too small; 3. Check network connectivity: Execute `telnet Redis_IP 6379` from the server where microservice A is located; 4. If all of the above are normal, restart the Redis client connection pool."

[0060] Step 210: Integrate and verify the fault handling suggestions output by the target expert model to obtain and output the target handling suggestions corresponding to the fault description data.

[0061] Integration refers to the process of merging multiple fault handling recommendations from various expert models when there are multiple target fault types. The specific operations of integration include: determining the processing order of each fault handling recommendation based on the fault relationships extracted from the fault knowledge graph; arranging the handling steps in each recommendation in an orderly manner according to the determined processing order; eliminating duplicate handling steps; and resolving conflicts between recommendations from different expert models, such as one recommendation requiring a service restart while another requires keeping the service running, in which case priority needs to be determined based on the relationships. When the target fault type is single, the integration operation is relatively simple; the output of the expert model can be directly adopted.

[0062] Verification refers to the validation of the rationality of the integrated target handling suggestions, ensuring that the handling suggestions output to operations and maintenance personnel are feasible, safe, and effective. Verification methods may include: comparing the target handling suggestions with historical multi-technology stack fault handling data, calculating the similarity between the target handling suggestions and historical successful cases, and obtaining a feasibility assessment result; if the feasibility assessment result is lower than a preset threshold, a regeneration or manual review process is triggered. Verification content may include: whether the handling steps are complete, whether the handling sequence is reasonable, and whether there are any security risks, such as whether misoperation may lead to secondary faults.

[0063] Output refers to presenting processing suggestions to operations and maintenance personnel in natural language. Specifically, through natural language generation algorithms, processing suggestions are converted into easy-to-understand and logically clear natural language and displayed on the operations and maintenance personnel's terminals, making it easier for them to understand and execute.

[0064] Following the previous example, since the target fault type is a single middleware fault, the fault handling suggestions output by the middleware expert model are already quite complete, and the integration steps directly adopt these suggestions. The verification module compares this suggestion with successful handling cases of historical Redis connection timeout faults, confirming that the handling steps are complete, the order is reasonable, and there are no security risks; the verification passes. Finally, the system outputs the handling suggestions in a formatted manner to the operations and maintenance personnel: "Fault Cause Analysis: The Redis service may be in an abnormal state, or the Redis connection pool configuration of microservice A is too small, causing connection acquisition timeout. Handling Steps: Check the Redis service status: Execute the `redis-cli ping` command to confirm whether the service is normal; Check the connection pool configuration: Check whether the `spring.redis.jedis.pool.max-active` configuration value is too small; Check network connectivity: Execute `telnet Redis_IP 6379` from the server where microservice A is located; If all of the above are normal, restart the Redis client connection pool. Note: It is recommended to restart the Redis client connection pool during off-peak business hours, as restarting the connection pool may cause momentary request failures."

[0065] This embodiment is a power information system fault handling method based on a multi-expert hybrid paradigm. It achieves accurate fault "triage" through a fault classification model, solving the illusion problem of misalignment between faults and handling solutions in related technologies. It achieves professional "diagnosis" through expert models constructed according to technology stack categories, solving the problems of generalization and insufficient professionalism of single model outputs. Through the integration and verification mechanism guided by the fault knowledge graph, it realizes the collaborative processing and output quality assurance of faults intertwined with multiple technology stacks, effectively improving the accuracy and efficiency of power information system fault handling.

[0066] In some embodiments, the fault classification model includes an input layer, a feature attention layer, and a classification output layer connected in sequence; wherein, the feature attention layer is used to calculate the correlation score between the fault feature and the candidate fault type, and uses the correlation score as the attention weight to perform a weighted summation of the fault features to obtain a weighted classification feature; the classification output layer is used to output the confidence level of the fault feature belonging to the candidate fault type based on the weighted classification feature;

[0067] The training process of the fault classification model includes: performing feature analysis on the historical fault data of the power information system, and constructing training sample pairs based on the candidate fault type labels corresponding to the historical fault features; the training sample pairs represent the mapping relationship between fault features and candidate fault types.

[0068] The preset classifier model is trained based on the training samples, with the cross-entropy loss function as the optimization objective, and the gradient descent algorithm is used to optimize the parameters of the feature attention layer until the preset termination condition is met.

[0069] Among them, the fault classification model can adopt a lightweight Transformer architecture that introduces a technology stack feature attention mechanism. This model is specifically designed for the accurate identification of technology stack categories in fault description data.

[0070] Specifically, in the fault classification model, the input layer receives fault feature vectors. These feature vectors are multi-dimensional vector representations obtained by fusing fault description data after data cleaning, standardization, text feature extraction (such as TF-IDF or Word2Vec), and integration with entity type vectors and relationship vectors from the fault knowledge graph. For example, for the fault description data "Redis connection timed out, causing microservice A's query cache to fail," the fault feature vector F received by the input layer can be represented as F = [f , f , f , …, f ], where each f This represents a feature dimension (such as the TF-IDF value of the keyword "Redis", the encoded value of the entity type "middleware", etc.). The input layer does not perform any transformation on the features; it directly passes the feature vector to the next layer for processing.

[0071] The feature attention layer calculates the correlation score between fault features and each candidate fault type (such as middleware, database, microservice, network), and uses this correlation score as the attention weight to perform a weighted summation of the fault features, resulting in a weighted classification feature. The design philosophy of the attention mechanism is that different feature components in the fault feature vector contribute differently to determining the technology stack category to which the fault belongs. For example, the keyword "Redis" contributes more to determining middleware faults than the feature of fault occurrence time. The role of the feature attention layer is to allow the model to automatically "focus" on important features while "ignoring" unimportant ones.

[0072] Specifically, the calculation process of the feature attention layer is as follows: Let the input fault feature vector be H = [h , h ,h , …, h ], where n is the dimension of the feature vector (e.g., 128 dimensions), h Let h represent the value of the i-th feature component. For the c-th candidate fault type (c ∈ {middleware, database, microservice, network}), first calculate the value of each feature component h. The correlation score e with this fault type :e = score(h , u_c); where u_c is the learnable vector representation of the c-th candidate fault type, and score(·) is the correlation score function, usually using dot product or bilinear transformation. The formula for calculating the dot product is: The inner product of two vectors is called the inner product of two vectors. The larger the inner product value, the stronger the correlation between the feature and the fault type.

[0073] Then, the correlation scores of each feature component are converted into normalized attention weights using the Softmax function. The denominator is the sum of the exponents of the correlation scores of all feature components, ensuring that the sum of all attention weights is 1. Attention Weights The value ranges from 0 to 1. The larger the weight, the greater the contribution of the corresponding feature component to the current fault type classification.

[0074] Finally, the original feature vector is weighted and summed using the calculated attention weights to obtain the weighted classification feature vector v_c: The weighted classification feature vector v_c highlights the feature components strongly correlated with the current fault type and suppresses the interference of irrelevant features, thereby improving the accuracy of subsequent classification. It should be noted that the above calculation process generates a weighted classification feature vector v_c for each candidate fault type c. That is, for the four candidate fault types—middleware, database, microservice, and network—four different weighted classification feature vectors v_middleware, v_database, v_microservice, and v_network will be obtained respectively.

[0075] The classification output layer is connected to the output of the feature attention layer and is used to output the confidence level of the fault feature belonging to each candidate fault type based on the weighted classification features. Specifically, the classification output layer adopts a fully connected network structure, mapping each weighted classification feature vector v_c to a scalar value logit_c, and then converting each logit value into a probability distribution through the Softmax activation function, thus obtaining the confidence level of the fault belonging to each candidate fault type. Where p_c represents the confidence level that the fault belongs to the c-th candidate fault type, satisfying Σ_c p_c = 1. For example, for the aforementioned Redis fault, the classification output layer may output p_middleware = 0.92, p_database = 0.05, p_microservice = 0.02, and p_network = 0.01, indicating that the fault has a 92% probability of belonging to middleware faults.

[0076] In this embodiment, to ensure the classification accuracy and generalization ability of the fault classification model, it is necessary to train it using labeled historical fault data. The training process may include the following steps:

[0077] First, feature analysis is performed on historical fault data from the power information system to extract fault feature vectors and corresponding candidate fault type labels. Specifically, each historical fault record is preprocessed to obtain its fault feature vector F_i; simultaneously, operation and maintenance experts, or based on the technology stack field in the fault record, label the fault with its actual technology stack category y_i (such as "middleware", "database", "microservices", or "network"). For faults involving multiple technology stacks, multiple labels can be applied, or they can be treated as a separate category. Thus, a training sample set of "fault feature - technology stack category" is constructed. , where m is the total number of training samples. Each training sample pair represents the mapping relationship between fault features and candidate fault types.

[0078] Next, the parameters of each layer in the fault classification model are randomly initialized. Specifically, the learnable vector u_c in the feature attention layer is initialized with small random numbers; the parameters of the fully connected network in the classification output layer are initialized using Xavier or He methods; and the parameters of the Transformer encoder are initialized using pre-trained weights or random initialization. In this embodiment, the lightweight Transformer model has been pre-trained on a large-scale general corpus, possessing basic semantic understanding capabilities, and then targeted fine-tuning is performed in this stage.

[0079] The fault feature vector F_i from the training samples is input into the fault classification model. After successive calculations through the input layer, feature attention layer, and classification output layer, the confidence distribution of the model's predictions is obtained. , where K is the total number of candidate fault types (K=4 in this embodiment). Then, the difference between the model prediction and the true label is calculated using the cross-entropy loss function: Where y_{i,k} is the one-hot encoding of the true label of the i-th sample. If the true class of sample i is k, then y_{i,k}=1; otherwise, y_{i,k}=0. p_{i,k} is the confidence score of the model predicting that sample i belongs to class k. The smaller the value of the cross-entropy loss function, the closer the model's prediction is to the true label.

[0080] Using the cross-entropy loss function L as the optimization objective, the gradient descent algorithm is employed to calculate the gradient of the loss function with respect to the parameters of each layer, and the parameters are updated along the direction of gradient descent. Specifically, the parameters of the feature encoding layer and the feature attention layer are optimized simultaneously. The basic formula for parameter update is: Where θ represents the set of trainable parameters in the model, and η is the learning rate (which controls the step size for parameter updates). Let θ be the gradient of the loss function with respect to the parameter θ. Through multiple iterative updates, the model gradually learns the optimal mapping relationship from fault features to technology stack categories.

[0081] Repeat the forward propagation, loss calculation, backpropagation, and parameter update steps described above, using one batch of training samples per iteration. After each training epoch, evaluate the model's classification accuracy using a validation dataset. Stop training when a preset termination condition is met. The preset termination condition may include any one or more of the following: classification accuracy reaches a preset threshold (e.g., above 95%); the loss function value no longer decreases for several consecutive training epochs (i.e., the model has converged); the preset maximum number of training epochs is reached (e.g., 100 epochs). The trained fault classification model can then be used for online classification of newly input fault description data.

[0082] During training, the parameters for calculating the correlation score are automatically learned using the gradient descent algorithm, rather than being manually preset. This allows the model to automatically identify which features are most valuable for distinguishing different technology stack categories. For example, after training, the model may automatically assign higher attention weights to features such as "Redis," "connection pool," and "timeout" for middleware fault identification, and higher attention weights to features such as "MySQL," "tablespace," and "deadlock" for database fault identification. This data-driven feature learning approach enables the fault classification model to adapt to the technology stack characteristics and fault modes of different power information systems.

[0083] Following the previous example, when the fault feature vector F is input into the trained fault classification model, the model performs the following processing: At the input layer, the fault feature vector F is received as is and passed to the feature attention layer. In the feature attention layer, the model calculates the association scores between F and four candidate fault types: middleware, database, microservice, and network. Assuming F contains a "Redis" feature component (corresponding to dimension index i=5), the association score e_5_middleware between this feature and the middleware fault type is significantly higher than other features. Therefore, after Softmax normalization, the attention weight α_5_middleware corresponding to this feature is close to 1, while the weights of other features are close to 0. The weighted classification feature vector v_middleware will be mainly contributed by the "Redis" feature. At the classification output layer, the confidence scores for each type are calculated based on the weighted v_middleware, v_database, v_microservice, and v_network. Because `v_middleware` highlights middleware-related features, the value of `p_middleware` is significantly higher than other types, for example, the output is [0.92, 0.05, 0.02, 0.01]. Finally, the fault classification model outputs a middleware fault confidence score of 0.92, a database fault confidence score of 0.05, a microservice fault confidence score of 0.02, and a network fault confidence score of 0.01.

[0084] By introducing the technology stack feature attention mechanism into the fault classification model, this embodiment can accurately identify the technology stack category to which the fault belongs based on multi-dimensional features such as keywords, entity types, and relationships in the fault description data. This provides accurate triage results for subsequent expert model "diagnosis" and effectively avoids the problems of misaligned handling suggestions and "illusions" caused by classification errors in traditional single models.

[0085] In some embodiments, the candidate fault types are categorized according to the technology stack to which the fault belongs; the candidate fault types include at least two of the following: middleware fault types, database fault types, microservice fault types, and network fault types; the fault handling knowledge includes at least one of the following: technology stack expertise, fault handling rules, and historical fault handling data.

[0086] For each of the aforementioned candidate fault types, the candidate expert model corresponding to the current candidate fault type includes a large model layer and an adjustment layer connected in sequence; the large model layer is used to semantically encode the fault features to obtain an encoding result; the adjustment layer is used to decode the encoding result based on the technology stack knowledge corresponding to the current candidate fault type, and to perform natural language processing on the decoding result to obtain the fault handling suggestion; the technology stack knowledge includes the fault features of the current technology stack and the corresponding standard handling suggestions;

[0087] The training process of the candidate expert model includes: based on the technology stack knowledge corresponding to the current candidate fault type, using the cross-entropy loss function as the optimization objective, and using the gradient descent algorithm to update the parameters of the adjustment layer, so that the candidate expert model learns the mapping relationship between the fault characteristics and processing suggestions of the technology stack corresponding to the current candidate fault type, until the preset convergence condition is met, and the trained candidate expert model is obtained.

[0088] In particular, considering the diversity, complexity, and intertwined nature of the IT technology stack in power information systems, different technology stack components exhibit significant differences in fault manifestations, troubleshooting paths, and handling methods. For example, middleware faults (such as Redis connection pool exhaustion) typically require checking configuration parameters, connection limits, and slow queries; database faults (such as MySQL deadlocks) require analyzing transaction isolation levels, lock wait relationships, and index optimization; microservice faults (such as Spring Cloud registration failures) require checking the service registry, network policies, and health check configurations; and network faults (such as switch port packet loss) require checking link status, traffic policies, and device logs.

[0089] Therefore, this embodiment classifies candidate fault types into at least two categories: Middleware fault types: These refer to faults occurring in various middleware components (such as Redis caching middleware, Kafka message middleware, Nginx proxy middleware, Tomcat application server, etc.) within the power information system. Typical symptoms of this type of fault include connection timeouts, request backlogs, memory overflows, and configuration loading failures. Database fault types: These refer to faults occurring in various database systems (such as MySQL relational databases, Oracle databases, DM databases, etc.) within the power information system. Typical symptoms of this type of fault include connection failures, query timeouts, deadlocks, insufficient tablespace, and master-slave synchronization delays. Microservice fault types: These refer to faults occurring in microservice architecture-related components (such as Spring Cloud service registration and discovery, Dubbo RPC framework, configuration center, API gateway, etc.) within the power information system. Typical symptoms of this type of fault include service registration failures, call chain timeouts, circuit breaker triggering, and configuration loading failures. Network fault types: These refer to faults occurring in network infrastructure (such as switches, routers, load balancers, firewalls, etc.) within the power information system. Typical symptoms of this type of failure include increased network latency, packet loss, connection reset, and DNS resolution failure.

[0090] It should be noted that the above four fault types are only exemplary classifications and can be flexibly adjusted according to the specific technology stack configuration of the power information system in practical applications. For example, for systems that have introduced container technologies (such as Docker and Kubernetes), a "container fault type" can also be added as a candidate fault type.

[0091] For each candidate fault type, this embodiment pre-trains corresponding candidate expert models, including middleware expert models, database expert models, microservice expert models, and network expert models. The structure of each expert model can be basically the same, adopting an architecture of "large model base plus technology stack-specific fine-tuning layer". Specifically, the candidate expert model corresponding to the current candidate fault type (taking middleware fault type as an example) includes a large model layer (base layer) and an adjustment layer (technology stack-specific fine-tuning layer) connected sequentially. The large model layer (base layer) uses a pre-trained large language model with 32 bytes or more of parameters, such as Qwen3-32B or Gemini-32B. The large language model is pre-trained on a large-scale general corpus (including books, web pages, code, technical documents, etc.) and possesses powerful natural language understanding, semantic encoding, and contextual reasoning capabilities. The large model layer is used to perform deep semantic encoding on the input fault features, mining the potential correlation between fault phenomena, fault causes, and handling actions.

[0092] Specifically, after the fault description data is preprocessed to obtain a fault feature vector, this feature vector is input into the large model layer. The large model layer, through its internal Transformer network structure (including modules such as multi-head self-attention mechanism, feedforward neural network, and layer normalization), performs multi-layer nonlinear transformations on the fault features, outputting a high-dimensional semantic encoding vector. This encoding vector captures the semantic information in the fault description text. For example, for the fault "Redis connection timeout," the large model layer can understand that "Redis" is a key-value store middleware, "connection timeout" indicates an anomaly in the network or server, and there is a causal relationship between "connection" and "timeout."

[0093] Considering that the training data for fault handling in large power information systems is relatively limited, it is difficult to support the massive amount of data required to train a large model from scratch. By utilizing the existing general semantic understanding capabilities of pre-trained large models and then performing specific fine-tuning in subsequent adjustment layers, the training cost and data requirements can be significantly reduced while maintaining high performance.

[0094] The adjustment layer contains trainable fine-tuning parameters used to decode the encoded results output by the large model layer based on the technology stack knowledge corresponding to the current candidate fault type, and to perform natural language processing on the decoded results to generate specialized handling suggestions for the current fault. The adjustment layer maps the general semantic encoding output by the large model layer to a handling suggestion space specific to the technology stack. For example, for the semantic encoding of "Redis connection timeout," the adjustment layer needs to decode it into a series of specialized handling steps for the Redis middleware (such as "execute redis-cli ping," "check max-active configuration," etc.), rather than a generalized vague answer like "please check the network or service."

[0095] The adjustment layer can be implemented using any of the following techniques: Add one or more fully connected layers to the output of the large model layer, where all parameters of these fully connected layers participate in training during fine-tuning. Full fine-tuning offers high flexibility but suffers from a large number of parameters and high training costs. Alternatively, LoRA (Low-Rank Adaptation) can be used. The core idea of ​​LoRA is to inject low-rank decomposition matrices A and B into each layer of the Transformer network while keeping the original parameters of the large model layer unchanged (i.e., frozen). The newly injected parameters participate in training while the original parameters are not updated. Specifically, for the weight matrix in the large model layer... LoRA represents its update as Where B and A are low-rank matrices (rank r is much smaller than the original dimension). In this way, the number of parameters required for fine-tuning is only one ten-thousandth to one thousandth of that of the original model, significantly reducing training overhead.

[0096] The technology stack knowledge includes the fault characteristics of the current technology stack and corresponding standard handling recommendations. This knowledge comes from multiple sources: first, the operation and maintenance manuals and technical documents of the power information system, which record standard handling procedures for various faults; second, historical fault handling cases, by analyzing historical successful handling records to extract the mapping pairs of "fault phenomena - handling steps"; and third, industry technical specifications and expert experience, including fault diagnosis rules and best practices summarized by senior operation and maintenance experts in the power industry. This technology stack knowledge is organized into structured training data for fine-tuning training of the adjustment layer.

[0097] To ensure that each expert model can output professional and accurate fault handling suggestions for the technology stack it is responsible for, each expert model needs to be trained specifically. The training process may include the following steps: For the current candidate fault type (such as middleware fault type), filter fault records belonging to that technology stack from historical fault data. Each record includes fault description data (fault phenomenon, fault cause, scope of impact, etc.) and corresponding standard handling suggestions (which can be labeled by operations and maintenance experts or extracted from successful handling cases). After preprocessing, training sample pairs consisting of fault feature vectors and corresponding standard handling suggestions are obtained. The specialized training dataset only contains fault samples of that technology stack, without mixing in data from other technology stacks, to ensure the professionalism and focus of the model learning.

[0098] Obtain a pre-trained large language model, which has been pre-trained on a general corpus and possesses basic semantic understanding capabilities. In this step, the parameters of the large model layer remain in their pre-trained state (or are frozen during subsequent fine-tuning). Freezing the model parameters of the large model layer (base layer) means that the parameters of the large model layer will not be updated during subsequent fine-tuning training. This retains the rich semantic knowledge learned by the large model on the general corpus, reduces the number of parameters that need to be trained, lowers the risk of overfitting, and speeds up the training process. For an embodiment using the LoRA parameter efficient fine-tuning scheme, the original parameters of the large model layer are completely frozen, and only the injected low-rank matrix parameters are trained.

[0099] In each training iteration, a batch of specialized training samples is input into the model: the fault feature vector is encoded by the large model layer to obtain semantic encoding, and then decoded by the adjustment layer to generate a predicted sequence of treatment suggestions (using an autoregressive generation method, predicting and outputting word by word). The predicted treatment suggestions are compared with the standard treatment suggestions, and the cross-entropy loss (i.e., the sum of the negative log-likelihoods between the probability distribution of each predicted word and the true word) is calculated. Then, the gradient of the loss with respect to the adjustment layer parameters is calculated through backpropagation, and the parameters of the adjustment layer are updated using the Adam optimizer or SGD optimizer, while the parameters of the large model layer remain unchanged. The above fine-tuning training steps are repeated, and training stops when a preset convergence condition is met. The preset convergence condition may include any one or more of the following: the loss function value no longer decreases for several consecutive training epochs (i.e., the model has converged); the accuracy of the model's treatment suggestions on the validation set reaches a preset threshold (e.g., above 96%); the preset maximum number of training epochs is reached (e.g., 20 epochs). The trained candidate expert model is then deployed to the inference server to receive fault description data distributed by the fault classification model online and output professional treatment suggestions.

[0100] Following the previous example, once the target fault type is determined to be a middleware fault, the system sends the fault description data "Redis connection timeout caused microservice A to fail to query the cache" to the middleware expert model. The middleware expert model's processing flow is as follows: After the fault feature vector is input, the main model layer (Qwen3-32B) performs deep semantic encoding on it. The model understands that "Redis" is a key-value store middleware, "connection timeout" means the client cannot establish a connection with the Redis server within a specified time, "microservice A" is a caller that depends on this cache, and "query cache failure" is the business consequence caused by the connection timeout. The semantic encoding output by the main model layer is passed to the tuning layer (LoRA fine-tuning layer). Based on the middleware fault handling knowledge learned during training, the tuning layer decodes the semantics into a series of professional handling steps. The adjustment layer uses a natural language processing algorithm to output professional handling suggestions in the format of "handling steps, execution order, and precautions": "1. Check the Redis service status: Execute the `redis-cli ping` command. If it returns PONG, the service is normal; otherwise, the Redis service needs to be restarted. 2. Check the connection pool configuration: Check the `spring.redis.jedis.pool.max-active` configuration value. If it is too small (e.g., less than 10), increase it appropriately. 3. Check network connectivity: Execute `telnet Redis_IP 6379` from the server where microservice A is located to confirm that the port is reachable. 4. Check slow queries: Execute the `redis-cli --latency` command to check the latency, and execute `SLOWLOG GET 10` to check the slow query records. 5. If all of the above are normal, restart the Redis client connection pool of microservice A: via the `actuator / restart` endpoint or by restarting the microservice instance." This handling suggestion has obvious middleware professional characteristics: it uses Redis operation and maintenance terminology such as `redis-cli`, `max-active`, `telnet`, and `SLOWLOG`, and the handling steps are specific and executable.

[0101] In some embodiments, determining the target fault type corresponding to the fault description data from the candidate fault types based on the confidence level and the confidence threshold includes:

[0102] If the maximum value of the confidence score corresponding to the candidate fault type is greater than a preset threshold, the candidate fault types ranked in the preset position by descending confidence score are determined as the target fault type;

[0103] If the maximum value of the confidence level is less than the preset threshold, all candidate fault types are determined as the target fault type.

[0104] The step of sending the fault description data to the target expert model corresponding to the target fault type, so as to analyze the fault description data through the target expert model and obtain the fault handling suggestions output by the target expert model, includes:

[0105] If the target fault type includes multiple types, the fault description data is split into fault data to be processed corresponding to each target fault type according to the fault knowledge graph; wherein, the fault knowledge graph includes a technology stack knowledge graph and a feature vector library; the technology stack knowledge graph includes entities representing at least one of technology stack components, faulty equipment, fault phenomena, and processing actions, as well as edges representing at least one of component dependencies, fault propagation relationships, and fault association relationships; the feature vector library includes at least one of technology stack type vectors, equipment features, processing features, and common fault features;

[0106] The fault data to be processed is sent to the target expert model corresponding to each target fault type.

[0107] The confidence score output by the fault classification model reflects the probability that the fault description data belongs to each candidate fault type. To accurately determine the nature of the fault (single technology stack fault or multi-technology stack intertwined fault), this embodiment sets up a determination mechanism based on a confidence score threshold.

[0108] Specifically, let the confidence vector output by the fault classification model be... Where K is the total number of candidate fault types (K=4 in this embodiment, corresponding to middleware, database, microservice, and network). Let the preset threshold be λ (λ=0.8 in this embodiment, i.e., 80%), and the judgment rule can be as follows: Rule 1 (Single Technology Stack Fault): If the maximum confidence value max(P) among multiple candidate fault types is greater than the preset threshold λ, then the candidate fault type ranked first in descending order of confidence is determined as the target fault type. In this embodiment, the preset position is usually set to 1, that is, the candidate fault type with the highest confidence is determined as the unique target fault type.

[0109] When a fault may involve two technology stacks and the confidence distribution exhibits a clear "bimodal" characteristic, the preset bit can also be set to 2. For example, if the output P = [0.45, 0.42, 0.08, 0.05], and the maximum value 0.45 < 0.8 (not satisfying rule two, see below), then it will be processed according to rule two (all will be identified as the target fault type). If more granular control is needed, additional conditions such as "the difference between the second-highest confidence and the highest confidence is less than a certain threshold and the highest confidence is greater than 0.35" can be set to identify the first two bits as multiple targets.

[0110] Rule 2 (Multi-Technology Stack Intertwined Faults): If the maximum confidence value max(P) of the candidate fault types is less than the preset threshold λ, then all candidate fault types are determined as the target fault type. The specific value of the preset threshold λ can be adjusted according to actual business needs. Setting a higher threshold (e.g., 0.9) will cause more faults to be judged as multi-technology stack intertwined faults, thereby invoking the collaborative processing flow, which is suitable for scenarios with high accuracy requirements; setting a lower threshold (e.g., 0.7) will cause more faults to be judged as single-technology stack faults, resulting in higher processing efficiency. In this embodiment, 0.8 can be used as the threshold, which is a balance between accuracy and efficiency.

[0111] The technology stack knowledge graph is stored using a graph database (such as Neo4j) or a graph data structure to represent the dependencies and fault propagation relationships between various technology stack components in the power information system. The technology stack knowledge graph includes two main categories of elements: entities and edges. On the entity side, the technology stack knowledge graph includes at least the following types of entity nodes: Technology stack component entities: such as Redis, MySQL, Nginx, Spring Cloud, switches, etc., each entity records its technology stack type (middleware, database, microservice, network), version information, configuration parameters, and other attributes; Faulty device entities: such as servers, virtual machines, container instances, recording device IP, region, hardware configuration, and other attributes; Fault phenomenon entities: such as "connection timeout," "query failure," "service unavailable," "packet loss," recording phenomenon type, severity, and other attributes; Handling action entities: such as "restart service," "modify configuration," "expand node capacity," "switch route," recording action type, execution method, scope of impact, and other attributes.

[0112] In terms of edges, the technology stack knowledge graph includes at least the following types of edges: Component dependency edges: representing the call or dependency relationship between technology stack components, such as "microservice A depends on database B" and "application C uses Redis caching", the direction of the edge represents the dependency direction; Fault propagation relationship edges: representing the propagation path of faults between components, such as "network latency → database connection timeout → microservice call failure", used to trace the causal chain of faults; Fault association relationship edges: representing the association type between multiple technology stack components in the same fault event, including causal association (such as fault A causing fault B), parallel association (such as A and B being independent but occurring simultaneously), conflict association (such as the handling plan of A and the handling plan of B being contradictory), etc.

[0113] Feature vector libraries can be stored using vector databases (such as Milvus, Faiss) or relational databases to store various feature vectors to support efficient similarity retrieval and feature matching. A feature vector library should include at least the following types of feature vectors: Technology stack type vectors: Each technology stack component corresponds to a type encoding vector, for example, Redis corresponds to [1,0,0,0] (middleware), MySQL corresponds to [0,1,0,0] (database), Spring Cloud corresponds to [0,0,1,0] (microservice), and a switch corresponds to [0,0,0,1] (network); Device feature vectors: Describe the device's configuration attributes, historical fault records, performance indicators, etc., used to determine whether the device is prone to a certain type of fault; Handling feature vectors: Describe the characteristics of various handling actions, such as handling complexity, impact scope, execution time, etc., used for solution evaluation and ranking; Common fault feature vectors: Describe the common attributes of faults, such as fault level (P0, P1, P2), impact scope (single node, local, global), occurrence time (peak business period, off-peak period), etc.

[0114] The construction process of a fault knowledge graph may include the following steps: Collecting information on technology stack components, dependency descriptions, historical fault cases, and handling records from sources such as the power information system's architecture documents, operation and maintenance manuals, historical fault records, and configuration management database (CMDB). Using natural language processing (NLP) technology, entity recognition is performed on these documents to extract entities such as technology stack components, faulty equipment, fault phenomena, and handling actions. For example, from the document "Connection timeout occurred when microservice A called Redis cache," the entities "microservice A" (microservice component), "Redis" (middleware component), and "connection timeout" (fault phenomenon) are identified. A relation extraction model based on semantic dependency trees and attention mechanisms is used to identify dependencies and propagation relationships between entities. For example, the dependency edge "microservice A depends on Redis" is extracted from the above statement. The extracted entities and relationships are vectorized to generate technology stack type vectors, equipment feature vectors, handling feature vectors, and common fault feature vectors, which are stored in a feature vector library. Vectorization encoding can employ One-Hot encoding, Word2Vec, or Graph Neural Network (GNN) encoding methods. Knowledge from different data sources is integrated, deduplication is eliminated, and conflicts are resolved. Finally, power system operation and maintenance experts verify and label the knowledge graph to ensure the accuracy and completeness of the knowledge.

[0115] When it is determined that there are multiple target fault types (i.e. all candidate fault types are identified as target fault types), the system initiates a collaborative processing flow. Based on the fault knowledge graph, the fault description data is split into the fault data to be processed corresponding to each target fault type, and then distributed to the corresponding expert models.

[0116] Specifically, the splitting and distribution process may include the following sub-steps: receiving fault description data (such as "database query timed out, microservice call failure was also detected, and network latency showed occasional increases"), and performing entity matching and retrieval in the technology stack knowledge graph. First, through keyword matching and semantic similarity calculation, the technology stack component entities involved in the fault description data are identified in the technology stack knowledge graph. For example, "database" (corresponding to the database component entity), "microservice" (corresponding to the microservice component entity), and "network" (corresponding to the network device entity) are identified from the fault description.

[0117] Secondly, by leveraging the relationships between entities in the technology stack knowledge graph, fault correlations between components are extracted. Specifically, if a fault propagation edge exists in the graph indicating a "network latency to database connection timeout" relationship, the correlation between the network component and the database component is extracted as a "causal relationship" (network latency is the cause, database timeout is the result). If a fault propagation edge exists in the graph indicating a "database connection timeout to microservice call failure" relationship, the correlation between the database component and the microservice component is also extracted as a "causal relationship." If there is no direct fault propagation edge between two entities in the graph, but there is a component dependency edge (such as "microservice depends on database"), the correlation is inferred based on the dependency direction; that is, a failure in the dependent party may affect the dependent party, but the reverse is not necessarily true. Finally, the domain-specific fault behavior of each technology stack component (i.e., a specific description of each component's behavior in the current fault) and the fault correlations between components are obtained. For causal relationships, they need to be handled in the order of "handling the cause first, then the result." For parallel relationships, they can be processed in parallel, and the output is arranged in descending order of impact. For conflict associations, the content to be handled should be removed according to the preset priority rules (such as power grid security taking precedence over business continuity).

[0118] The pending fault data is a subset of the original fault description data after filtering and trimming, containing only fault information related to the components of that technology stack. For example, for the original fault description "database query timeout, microservice call failure, and occasional increase in network latency," the pending fault data generated for the database expert model is: "database query timeout" (focusing on fault manifestations at the database level); the pending fault data generated for the microservice expert model is: "microservice call failure" (focusing on fault manifestations at the microservice level); and the pending fault data generated for the network expert model is: "occasional increase in network latency" (focusing on fault manifestations at the network level).

[0119] Each expert model analyzes the fault data in parallel, outputting specialized handling suggestions for its respective domain. For example, the database expert model outputs handling suggestions for "database connection timeout" (such as checking the database process status, reviewing slow query logs, and adjusting connection pool parameters); the network expert model outputs handling suggestions for "increased network latency" (such as checking switch port traffic, troubleshooting link congestion, and adjusting QoS policies); and the microservice expert model outputs handling suggestions for "microservice call failure" (such as checking the registry status, adjusting circuit breaker timeout configuration, and reviewing call chain tracing). Each expert model can independently complete its analysis task within the same time period without sequential waiting, thus significantly reducing the overall processing time. For faults involving multiple technology stacks, parallel processing mechanisms are particularly important due to the analysis of multiple technology stacks.

[0120] In some embodiments, integrating and validating the fault handling suggestions output by the target expert model to obtain and output the target handling suggestions corresponding to the fault description data includes:

[0121] Based on the fault correlation, determine the processing order corresponding to the fault handling suggestions of the target expert model:

[0122] The fault handling suggestions are integrated according to the processing order to obtain the target handling suggestion;

[0123] And / or, compare the target processing suggestion with the processing data corresponding to historical multi-technology stack failures to obtain the feasibility assessment result of the target processing suggestion;

[0124] The target expert model is optimized based on the feasibility assessment results;

[0125] After integrating and verifying the fault handling suggestions output by the target expert model to obtain and output the target handling suggestions corresponding to the fault description data, the method further includes:

[0126] Obtain at least one of the following: feedback evaluation information on the fault handling suggestions, fault handling effect data, and newly added fault data;

[0127] For feedback evaluation information that does not conform to the expected target processing suggestion, analyze the reasons for the anomaly in the feedback evaluation information representation;

[0128] If the cause of the anomaly includes a classification defect in the classification model, supplement boundary sample data to the training set of the classification model and / or adjust the attention weight parameters of the feature attention layer in the classification model;

[0129] If the target expert model is determined to have a knowledge deficiency, the fault knowledge data corresponding to the fault type of the target expert model is added to the training dataset of the target expert model, and the parameters of the adjustment layer in the target expert model are updated based on the supplemented training data.

[0130] When the target fault type is a single technology stack fault, the fault handling suggestions output by the target expert model can be directly used as the target handling suggestions. The integration steps are relatively simple, requiring only formatting and basic verification.

[0131] When the target fault type includes multiple types (i.e., faults involving multiple technology stacks), it is necessary to collect multiple specific handling suggestions output by each expert model and integrate them into a complete and logically coherent collaborative handling suggestion based on the fault correlation.

[0132] Specifically, the integration process may include the following steps: obtaining specific handling suggestions from each expert module; each target expert model (such as database expert model, microservice expert model, and network expert model) outputting specific handling suggestions for its respective domain in parallel; each specific handling suggestion includes fault cause analysis, handling steps, execution order, and precautions for that technology stack.

[0133] Based on the pre-extracted fault relationships in the technology stack knowledge graph, the processing order of each specific handling suggestion is determined. Fault relationships include the following three types: Causal relationship: This indicates that the failure of one component leads to the failure of another component. For causal relationships, the handling steps are arranged in the order of "handling the cause first, then the result". For example, in the technology stack knowledge graph, there are fault propagation relationship edges of "network latency → database connection timeout" and "database connection timeout → microservice call failure". Therefore, the processing order is determined as follows: network failure first, database failure second, and microservice failure last. This is because only by solving the network latency problem can the database connection be restored; after the database is restored, the circuit breaker of the microservice can be released. Parallel relationship: The handling steps are arranged in the order of the largest to the smallest impact. For example, if a power outage in the data center causes all equipment to fail simultaneously, and there is no causal relationship between the failures of different technology stacks, the failure with the wider impact is handled first (e.g., restoring the network infrastructure first, then restoring the database and microservices). Conflict relationship: Conflicting handling content is eliminated according to preset priority rules. For example, a network expert might recommend disconnecting a port to isolate a fault, while a database expert might recommend maintaining the port's connectivity to ensure master-slave synchronization. In this case, based on the pre-defined rule of "power grid security taking precedence over business continuity," the network expert's isolation recommendation is prioritized, and conflicting recommendations from the database expert are discarded.

[0134] Following the established processing order, the processing steps in each special handling suggestion are arranged in an orderly manner, duplicate steps are merged (e.g., if multiple experts recommend "checking the logs", they are merged into one), logical dependencies between steps are resolved (e.g., ensuring that the microservice is retried only after the database is restored), and finally, collaborative handling suggestions are generated.

[0135] To ensure the reliability and security of the integrated target handling recommendations, this embodiment also includes a verification mechanism. Verification includes two aspects: feasibility assessment and rationality verification. The feasibility assessment compares the target handling recommendations with historical multi-technology stack fault handling data, calculates the similarity between the target handling recommendations and historical successful cases, and obtains the feasibility assessment result. Specifically, fault cases with the same or similar technology stack combinations are retrieved from the historical fault database. For example, for the current fault involving the intertwining of three technology stacks ("network + database + microservices"), historical successful handling cases involving these three technology stacks are retrieved. Cosine similarity or edit distance algorithms are used to calculate the similarity between the handling step sequence of the current target handling recommendation and the handling step sequence of historical cases. If the similarity is higher than a preset threshold (e.g., 0.85), the target handling recommendation is considered highly feasible; if the similarity is lower than the preset threshold, an alarm is triggered, prompting operations personnel to conduct manual review.

[0136] Reasonableness verification is used to check the logical consistency of target processing recommendations and to assess security risks. For example, it checks for contradictory instructions (such as one step requiring a service restart while another requires keeping the service running, and both pointing to the same service); it checks for high-risk operations (such as deleting data, disabling firewalls, etc.) without sufficient risk warnings; and it checks whether the handling steps are complete (whether key verification steps or rollback plans are missing).

[0137] If the verification process finds any unreasonable aspects in the target handling recommendations, the verification results are fed back to the corresponding expert module, triggering that expert module to adjust the specific handling recommendations until a collaborative handling recommendation that meets the verification requirements is generated. For example, if a conflict is found between the recommendations of network experts and database experts, the conflict is automatically resolved according to preset priority rules (such as "infrastructure layer takes precedence over application layer"), or the conflicting content is simultaneously displayed to the operations and maintenance personnel for their decision-making.

[0138] After the fault handling is completed (i.e., after the target handling suggestion is output and the operation and maintenance personnel have performed the corresponding handling operations), this embodiment also includes a model optimization module, which is used to collect feedback information and continuously optimize the classification model and expert model to achieve the self-evolution of the system.

[0139] Specifically, the model optimization process includes the following steps: After executing the handling suggestions, operations personnel can evaluate the suggestions through the terminal. Evaluation options can include "Accurate" (the handling suggestion is completely correct and resolved the fault), "Partially Accurate" (the handling suggestion is partially correct and needs to be supplemented or modified), "General" (the handling suggestion is too general and lacks specificity), "Mismatched" (the handling suggestion does not match the fault type, i.e., illusion), and "Incorrect" (the handling suggestion is completely incorrect and may cause secondary faults). For example, for the above Redis fault handling suggestion, operations personnel can evaluate it as "Accurate"; for a general "Please check the network" suggestion, operations personnel can evaluate it as "General". Record the fault handling result data, including: whether the fault was successfully resolved, the fault recovery time, whether there were any anomalies during the handling process, resource consumption, etc. For example, record "After executing the recommended solution, the Redis connection returned to normal within 3 minutes".

[0140] New or rare faults that occur during system operation are automatically recorded and stored, along with their descriptions and successful handling solutions. This new fault data can be used for subsequent incremental model training.

[0141] For feedback evaluation information that does not represent the expected target processing suggestions (i.e., evaluations are "general," "misaligned," or "incorrect"), analyze the reasons for the anomalies in the feedback evaluation information representation. Anomalies include classification defects in the classification model and / or knowledge deficiencies in the target expert model. If the feedback evaluation information indicates that the maintenance personnel pointed out an error in fault type identification (e.g., an actual database fault, but the classification model classifies it as a middleware fault), or multiple similar confidence levels lead to the erroneous classification of a single fault as a multi-technology stack intertwined fault (and vice versa), then the anomaly is determined to be a classification defect in the classification model.

[0142] If the feedback evaluation information indicates that the maintenance personnel pointed out that the handling suggestions were unprofessional, lacked specificity, omitted key steps, or contained "illusionary" content that did not match the fault type, then the cause of the anomaly was determined to be a knowledge deficiency in the target expert model. Specifically, this can be aided by comparing the handling suggestions output by the expert model with the standard handling template (obtained from the knowledge graph): if key steps are missing, technical terms are incorrect, or handling content that does not belong to this technology stack is generated, then it is confirmed as a knowledge deficiency.

[0143] Based on the identified causes of anomalies, targeted optimization measures are taken. If the cause of the anomaly is a classification defect in the classification model, at least one of the following optimization operations is performed: Analyze the misclassified fault samples, extract their fault features, and supplement them as boundary samples to the training set of the classification model. Boundary samples refer to samples located near the classification decision boundary, such as samples with a confidence level between 0.5 and 0.8. By supplementing these samples and retraining, the model's classification boundary can be made more accurate.

[0144] Alternatively, analyze the reasons for classification errors to determine if they are caused by improper allocation of attention weights. For example, the model may focus too much on the generalized keyword "timeout" while ignoring the specific technology stack keyword "Redis". By adding a regularization term to the loss function or using focal loss instead of cross-entropy loss, the learning process of attention weights can be adjusted, making the model pay more attention to features with strong discriminative power.

[0145] Specifically, the following adjustment can be made: treat misclassified samples as hard examples and increase their loss weight during retraining, so that the model pays more attention to the classification of these hard examples in subsequent iterations.

[0146] Correspondingly, if it is determined to be a knowledge deficiency in the target expert model, the fault knowledge data of the corresponding fault type in the target expert model is added to the training dataset of the target expert model, and the parameters of the adjustment layer in the target expert model are updated based on the supplemented training data.

[0147] The system extracts correct handling steps from feedback and evaluation information, new "fault phenomenon-handling suggestion" mapping pairs from newly added fault cases, and the latest fault handling rules from updated technical documents. After preprocessing, this data is converted into training sample pairs and added to the specialized training dataset of the expert model.

[0148] For example, for middleware expert models, if the operation and maintenance personnel omit the crucial step of "checking the jedis.pool.blockWhenExhausted configuration" in their handling suggestions for "Redis connection pool exhausted", the system will add this step to the standard handling suggestions to form new training samples.

[0149] Optionally, incremental learning techniques can be employed to incrementally update the parameters of the adjustment layer using a supplemented training dataset while maintaining the original model parameters. Incremental updates can use a small learning rate (e.g., 1 / 10 of the original learning rate) and a small number of iterations (e.g., 1-3 epochs) to avoid catastrophic forgetting (i.e., destroying existing knowledge when learning new knowledge). For models using LoRA parameter efficient fine-tuning, incremental updates only require updating the parameters of the low-rank matrices A and B, resulting in low computational cost and fast convergence.

[0150] The same batch of test samples (including samples that were misclassified or had poor output before optimization) are inferred using both the unoptimized and optimized models. The classification accuracy and the accuracy of the proposed actions are compared. If the performance of the optimized model does not meet the preset requirements (e.g., the classification accuracy is still below 95%, or the accuracy of the proposed actions is still below 96%), the above steps of feedback data collection, defect analysis, and model optimization are repeated until the model performance meets the preset requirements.

[0151] In some embodiments, acquiring fault description data from a power information system and preprocessing the fault description data to obtain fault characteristics corresponding to the fault description data includes:

[0152] The fault description data is cleaned to remove invalid and duplicate data and fill in missing values ​​to obtain cleaned data.

[0153] The cleaned data is standardized to obtain standardized descriptive data;

[0154] Text features of fault phenomena and fault causes are extracted from the standardized description data, and entities involved in the fault description data are retrieved in the preset fault knowledge graph, and the type vector and association vector of the entities are extracted.

[0155] The text features are fused with the type vector and the association vector to obtain the fault features.

[0156] The process begins with data cleaning of the fault description data, removing invalid and duplicate data. Missing fault cause values ​​are then filled using a similar fault association method, and missing values ​​for associated equipment parameters are filled using mean or interpolation methods. For example, for data with incomplete fault descriptions, intelligent completion can be performed based on association rules of similar historical faults. Invalid data refers to data with vague fault descriptions, incorrect technical stack labeling, or complete absence of key information (such as equipment name and fault type). Duplicate data refers to duplicate records resulting from multiple reports of the same fault event, which need to be deduplicated during the cleaning phase.

[0157] Standardize the cleaned data to obtain standardized descriptive data. The standardization process includes: encoding categorical data such as fault types, technology stack categories, and disposal effects. For example, encode "middleware" as 1, "database" as 2, "microservice" as 3, and "network" as 4; convert time data such as fault occurrence time and disposal time to Unix timestamp format. For example, convert "May 20, 2024, 14:30:25" to "1716193825"; perform word segmentation and stop word removal on text data such as fault phenomena, fault causes, and disposal steps. For example, segment "Database connection failed, unable to read data normally" into ["database", "connection", "failed", "unable", "normal", "read", "data"], and remove meaningless stop words such as "de", "le", "ma", etc., to unify the text expression specification.

[0158] Use the TF-IDF (Term Frequency-Inverse Document Frequency) algorithm or the Word2Vec (Word to Vector) algorithm to extract the text features of fault phenomena and fault causes. The TF-IDF algorithm evaluates the importance of a word for a document by calculating the product of the frequency of the word in a single document and the inverse document frequency in the entire corpus, and uses it as a text feature. The Word2Vec algorithm maps words to a high-dimensional vector space through a neural network, and words with similar semantics are close in the vector space. At the same time, retrieve the entities involved in the fault description data in the preset fault knowledge graph, and extract the type vector and association relationship vector of the entity. For example, for the entity "Redis" included in the fault description data, retrieve its type as "middleware-key value storage" in the fault knowledge graph, and the association relationships include "dependent party: microservice A" and "dependency party: cache layer". Extract the above type vector and association relationship vector to enrich the semantic information of the fault features. Finally, splice or weighted fuse the text features with the type vector and association relationship vector to construct a complete fault feature vector. The fault feature vector can be represented as a vector of 128 to 512 dimensions, and the specific dimension can be dynamically adjusted according to the data scale and model complexity.

[0159] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0160] Based on the same inventive concept, this application also provides a power information system fault handling device for implementing the power information system fault handling method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more power information system fault handling device embodiments provided below can be found in the limitations of the power information system fault handling method described above, and will not be repeated here.

[0161] In one exemplary embodiment, such as Figure 3 As shown, a multi-expert hybrid paradigm power information system fault handling device 300 is provided, the device comprising:

[0162] The first acquisition module 302 is used to acquire fault description data from the power information system, preprocess the fault description data, and obtain the fault characteristics corresponding to the fault description data.

[0163] Input module 304 is used to input the fault features into the fault classification model to obtain the confidence level of the fault description data belonging to each candidate fault type;

[0164] The determining module 306 is used to determine the target fault type corresponding to the fault description data from the candidate fault types based on the confidence level and the confidence threshold.

[0165] The second acquisition module 308 is used to send the fault description data to the target expert model corresponding to the target fault type, so as to analyze the fault description data through the target expert model and obtain the fault handling suggestions output by the target expert model; wherein, the target expert model is trained on a large language model based on the fault handling knowledge of the target fault type;

[0166] The verification module 310 is used to integrate and verify the fault handling suggestions output by the target expert model, and obtain and output the target handling suggestions corresponding to the fault description data.

[0167] Each module in the aforementioned multi-expert hybrid paradigm power information system fault handling device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0168] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a fault handling method for a power information system. The display unit is used to form a visually visible image and can be a display screen, projection device, or virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0169] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0170] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps included in any of the foregoing method embodiments.

[0171] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0172] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0173] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0174] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0175] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0176] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A fault handling method for a multi-expert hybrid paradigm power information system, characterized in that, The method includes: Obtain fault description data from the power information system, preprocess the fault description data, and obtain the fault characteristics corresponding to the fault description data; The fault features are input into the fault classification model to obtain the confidence level of the fault description data belonging to each candidate fault type. The target fault type corresponding to the fault description data is determined from the candidate fault types based on the confidence level and the confidence threshold. The fault description data is sent to the target expert model corresponding to the target fault type, so that the target expert model can analyze the fault description data and obtain the fault handling suggestions output by the target expert model; wherein, the target expert model is trained on a large language model based on the fault handling knowledge of the target fault type; The fault handling suggestions output by the target expert model are integrated and verified to obtain and output the target handling suggestions corresponding to the fault description data.

2. The method according to claim 1, characterized in that, The fault classification model comprises an input layer, a feature attention layer, and a classification output layer connected in sequence. The feature attention layer calculates the correlation score between the fault feature and the candidate fault type, and uses the correlation score as an attention weight to perform a weighted summation of the fault features to obtain a weighted classification feature. The classification output layer outputs the confidence level that the fault feature belongs to the candidate fault type based on the weighted classification feature. The training process of the fault classification model includes: performing feature analysis on the historical fault data of the power information system, and constructing training sample pairs based on the candidate fault type labels corresponding to the historical fault features; the training sample pairs represent the mapping relationship between fault features and candidate fault types. The preset classifier model is trained based on the training samples, with the cross-entropy loss function as the optimization objective, and the gradient descent algorithm is used to optimize the parameters of the feature attention layer until the preset termination condition is met.

3. The method according to claim 1, characterized in that, The candidate fault types are categorized based on the technology stack to which the fault belongs; the candidate fault types include at least two of the following: middleware fault types, database fault types, microservice fault types, and network fault types. The fault handling knowledge includes at least one of the following: technical stack expertise, fault handling rules, and historical fault handling data; For each of the aforementioned candidate fault types, the candidate expert model corresponding to the current candidate fault type includes a large model layer and an adjustment layer connected in sequence; the large model layer is used to semantically encode the fault features to obtain an encoding result; the adjustment layer is used to decode the encoding result based on the technical stack knowledge corresponding to the current candidate fault type, and to perform natural language processing on the decoding result to obtain the fault handling suggestion; The technology stack knowledge includes the fault characteristics of the current technology stack and corresponding standard handling suggestions; The training process of the candidate expert model includes: based on the technology stack knowledge corresponding to the current candidate fault type, using the cross-entropy loss function as the optimization objective, and using the gradient descent algorithm to update the parameters of the adjustment layer, so that the candidate expert model learns the mapping relationship between the fault characteristics and processing suggestions of the technology stack corresponding to the current candidate fault type, until the preset convergence condition is met, and the trained candidate expert model is obtained.

4. The method according to claim 1, characterized in that, The step of determining the target fault type corresponding to the fault description data from the candidate fault types based on the confidence level and the confidence threshold includes: If the maximum value of the confidence score corresponding to the candidate fault type is greater than a preset threshold, the candidate fault types ranked in the preset position by descending confidence score are determined as the target fault type; If the maximum value of the confidence level is less than the preset threshold, all candidate fault types are determined as the target fault type. The step of sending the fault description data to the target expert model corresponding to the target fault type, so as to analyze the fault description data through the target expert model and obtain the fault handling suggestions output by the target expert model, includes: If the target fault type includes multiple types, the fault description data is split into fault data to be processed corresponding to each target fault type according to the fault knowledge graph; wherein, the fault knowledge graph includes a technology stack knowledge graph and a feature vector library; the technology stack knowledge graph includes entities representing at least one of technology stack components, faulty equipment, fault phenomena, and processing actions, as well as edges representing at least one of component dependencies, fault propagation relationships, and fault association relationships; the feature vector library includes at least one of technology stack type vectors, equipment features, processing features, and common fault features; The fault data to be processed is sent to the target expert model corresponding to each target fault type.

5. The method according to claim 4, characterized in that, The process of integrating and validating the fault handling suggestions output by the target expert model to obtain and output the target handling suggestions corresponding to the fault description data includes: Based on the fault correlation, determine the processing order corresponding to the fault handling suggestions of the target expert model: The fault handling suggestions are integrated according to the processing order to obtain the target handling suggestion; And / or, compare the target processing suggestion with the processing data corresponding to historical multi-technology stack failures to obtain the feasibility assessment result of the target processing suggestion; The target expert model is optimized based on the feasibility assessment results; After integrating and verifying the fault handling suggestions output by the target expert model to obtain and output the target handling suggestions corresponding to the fault description data, the method further includes: Obtain at least one of the following: feedback evaluation information on the fault handling suggestions, fault handling effect data, and newly added fault data; For feedback evaluation information that does not conform to the expected target processing suggestion, analyze the reasons for the anomaly in the feedback evaluation information representation; If the cause of the anomaly includes a classification defect in the classification model, supplement boundary sample data to the training set of the classification model and / or adjust the attention weight parameters of the feature attention layer in the classification model; If the target expert model is determined to have a knowledge deficiency, the fault knowledge data corresponding to the fault type of the target expert model is added to the training dataset of the target expert model, and the parameters of the adjustment layer in the target expert model are updated based on the supplemented training data.

6. The method according to claim 1, characterized in that, The process of acquiring fault description data from the power information system, preprocessing the fault description data to obtain fault characteristics corresponding to the fault description data, includes: The fault description data is cleaned to remove invalid and duplicate data and fill in missing values ​​to obtain cleaned data. The cleaned data is standardized to obtain standardized descriptive data; Text features of fault phenomena and fault causes are extracted from the standardized description data, and entities involved in the fault description data are retrieved in the preset fault knowledge graph, and the type vector and association vector of the entities are extracted. The text features are fused with the type vector and the association vector to obtain the fault features.

7. A fault handling device for a multi-expert hybrid paradigm power information system, characterized in that, The device includes: The first acquisition module is used to acquire fault description data from the power information system, preprocess the fault description data, and obtain the fault characteristics corresponding to the fault description data. The input module is used to input the fault features into the fault classification model to obtain the confidence level of the fault description data belonging to each candidate fault type; The determination module is used to determine the target fault type corresponding to the fault description data from the candidate fault types based on the confidence level and the confidence threshold; The second acquisition module is used to send the fault description data to the target expert model corresponding to the target fault type, so as to analyze the fault description data through the target expert model and obtain the fault handling suggestions output by the target expert model; wherein, the target expert model is trained on a large language model based on the fault handling knowledge of the target fault type; The verification module is used to integrate and verify the fault handling suggestions output by the target expert model, and obtain and output the target handling suggestions corresponding to the fault description data.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images