Multi-source data-based operating system abnormity intelligent diagnosis method

Abstract

The invention relates to an operating system abnormity intelligent diagnosis method based on multi-source data, which comprises the following steps: step 1, on the basis of standardization of historical fault knowledge and field adaptation of a large language model, through feature extraction and matching of current multi-source data, retrieval of related historical troubleshooting guide of a fault is realized, and a fault diagnosis result is obtained; outputting a historical fault case closest to the current anomaly and a standardized anomaly feature of the current anomaly; step 2, combining retrieved historical knowledge, standardized abnormal features and SOP by using LLM, automatically generating a preliminary diagnosis report, and forming a perfect diagnosis conclusion through multiple rounds of correction and supplementation driven by a model; and step 3, adopting an interactive HITL normal form, and supporting fine-grained reasoning interpretation and report refinement by introducing dynamic interaction between an on-duty engineer OCE and an LLM. According to the invention, operation and maintenance personnel are helped to timely discover and position abnormities.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of intelligent operation and maintenance and fault diagnosis, and relates to an intelligent diagnosis method for an operating system exception, in particular, an intelligent diagnosis method for an operating system exception based on multi-source data. BACKGROUND

[0002] In modern large-scale cluster environments, operating system stability problems have become a serious challenge that cannot be ignored. Statistical data shows that single-class abnormal cases may reach tens of thousands within 24 hours, and the number of early warning events may reach millions. This high-frequency abnormal phenomenon not only puts great pressure on the overall stability of the system, but also makes the operation and maintenance team face an unprecedented processing burden. With the continuous expansion of the cluster size, this problem shows an exponential growth trend, and the traditional manual processing method has been unable to meet the demand. Therefore, it is of great theoretical and practical significance to study how to effectively deal with operating system stability problems. However, the current implementation of effective operating system exception diagnosis faces the following challenges: 1. Difficulty in integrating multi-source heterogeneous data Effective diagnosis of operating system exception problems requires the integration and analysis of information from multiple data sources. These data sources include: (1) System monitoring data: including the usage of CPU, memory, disk, network and other basic resources, as well as system load, process state and other information. These data are the basis for diagnosing system exceptions.

[0003] (2) dmesg log: records the key information of kernel output during system startup and running, which is particularly important for diagnosing hardware failures and driver problems.

[0004] (3) Stack trace data: records the detailed record of function call sequence before the fault occurs.

[0005] However, these multi-source heterogeneous data are not only huge in quantity (may reach TB level per day), but also have different formats and time granularities, and how to effectively integrate and extract valuable information from them becomes a major challenge.

[0006] 2. Lack of explainability and interaction mechanism in traditional fault diagnosis methods Current mainstream automated fault diagnosis techniques are mostly based on statistical analysis, machine learning or deep learning models, focusing on identifying abnormal patterns from observable data and diagnosing fault types or root causes. However, these methods often run in a "black box" form, only outputting diagnosis results without a clear reasoning process. This lack of transparency limits its credibility and adoptability in actual operation and maintenance scenarios, making it difficult for operation and maintenance personnel to understand the model's judgment basis and verify its rationality, thereby affecting decision-making efficiency and response accuracy.

[0007] In addition, the current technology lacks effective interaction mechanisms, making it difficult for operation and maintenance personnel to modify, supplement, or customize diagnostic results based on their business scenarios and needs, limiting the flexibility and practicality of the model. Users only act as recipients of the results and do not participate in the generation and improvement of diagnostic knowledge, making it difficult for the system to continuously adapt to changing business environments and complex fault scenarios.

[0008] 3. Difficulty in integrating multi-domain knowledge in fault diagnosis process Solving operating system exception problems usually requires multi-domain professional knowledge and rich experience. The integration and application of these professional knowledge is crucial for accurate diagnosis and solution of operating system exception problems. Historical fault data, including historical work orders, knowledge base, and expert experience summary, provides important reference for fault diagnosis and provides important reference for rapid identification and reuse of similar problems. However, operating system faults have high diversity and high frequency characteristics, and their historical fault cases are usually recorded independently by engineers with different professional backgrounds, experience levels, and writing styles, resulting in significant inconsistencies in terminology use, symptom description, and troubleshooting process details. This heterogeneity makes the same fault phenomenon appear in different cases in different language forms, seriously weakening the effectiveness of traditional information retrieval methods, and hindering the efficient reuse of diagnostic knowledge.

[0009] In view of the above challenges, there is currently a need for an automated exception diagnosis method that combines statistical analysis, machine learning, deep learning, and other technologies, integrates multi-domain professional knowledge, and builds an exception diagnosis system for multi-modal data to help operation and maintenance personnel quickly identify and locate exceptions, thereby reducing system crashes, data corruption, service stoppages, and other problems, improving the reliability and stability of infrastructure, enhancing user experience, and ensuring the production and economic benefits of enterprises.

[0010] In large-scale cluster environments, the frequent occurrence of operating system stability problems has a serious impact on the stability and performance of the entire cluster. Abnormal problems on each server or node not only affect its own operation, but also may spread to other nodes through complex dependency relationships and interaction mechanisms, leading to a decline in the overall performance of the cluster, and even causing large-scale system failures and service interruptions. With the continuous expansion of the cluster size, the cumulative effect of single-machine operating system problems becomes more and more significant, and frequent faults may quickly escalate into global problems. Therefore, research and solution of single-machine operating system stability problems are of great significance to ensure the overall stability and efficient operation of the cluster.

[0011] Effective OS stability issue handling not only improves the reliability of individual nodes, but also reduces the spread of failures in clusters through predictive maintenance and rapid response, ensuring the continuity of critical business and service quality. As business demands grow rapidly and the technical environment becomes increasingly complex, establishing a sound OS problem diagnosis and handling mechanism has become an important means to maintain the high availability of large-scale clusters. This not only helps to improve the efficiency of the system, but also greatly reduces the operation and maintenance cost, enhances user experience and satisfaction.

[0012] Root cause analysis has become a popular research topic in the system and software engineering community. The goal is to find the root cause of failures and performance problems based on various data sources such as metrics, logs, and call chains. Previous research has proposed different methods for root cause analysis using one of these data sources. For example, some methods rely on metrics to extract failure patterns or build service dependency graphs. Other methods use logs to analyze subsets of log information or examine the details of each log message. In addition, some techniques use call chains to locate faulty services.

[0013] The rapid development of natural language processing, especially the emergence of large language models (LLM), provides new opportunities for improving fault diagnosis. Although LLMs have demonstrated strong reasoning and representation capabilities, their practical application in fault diagnosis is still limited by ongoing challenges.

[0014] Relying solely on single-modal monitoring data for root cause localization often leads to underutilization of other data sources and low localization accuracy. Many recent studies have attempted to perform root cause localization by fusing multi-modal data and have achieved certain results. For example, CloudRCA extracts important features from metrics data and log data, and then uses a knowledge-guided hierarchical Bayesian network to perform root cause analysis on the extracted features. Edro uses call chains, logs, and metrics to simulate the complex dynamics of internal service behavior and inter-service dependencies. It implements anomaly detection and root cause localization based on multi-modal data to troubleshoot large-scale microservice systems. Nezha converts heterogeneous multi-modal data into a homogeneous event representation and constructs an event graph to extract event patterns, then compares non-faulty event patterns with faulty event patterns to locate the root cause. DiagFusion uses embedding techniques and data augmentation to implement multi-modal representation of microservice instances, and uses graph neural networks to diagnose fault types. Mulan extracts representations of multi-modal data in a shared latent space by a contrastive learning-based method to locate the root cause. HeMiRCA uses Spearman correlation to perform hierarchical root cause analysis on heterogeneous data. These research results show that the integrated use of multi-modal data not only improves the observability of the system, but also effectively improves the accuracy and comprehensiveness of root cause localization.

[0015] However, these methods directly output the diagnosis results but fail to demonstrate the specific reasoning process or judgment basis. As a result, the operation and maintenance personnel cannot deeply understand the internal logic of the diagnosis system, nor can they question or make targeted adjustments to the diagnosis results. This problem significantly hinders the credibility and adoptability of models in actual operation and maintenance scenarios, limiting their auxiliary role in critical decision-making links. Secondly, these methods have limited integration of domain knowledge and expert experience. Efficient diagnosis of complex system abnormal problems usually relies on valuable resources such as historical fault data (such as work orders, knowledge bases, and expert experience summaries) and standard diagnostic processes (such as standard operating procedures, SOP). These resources provide important references for locating fault causes and developing solutions. However, many automated models fail to fully exploit, integrate, and utilize these domain knowledge, resulting in knowledge blind spots in the diagnosis process, making it difficult to effectively handle novel or complex abnormal scenarios and meet the needs of high dynamicity and high complexity business environments.

[0016] In recent years, the rise of large language models has brought new opportunities to the software system field, making it possible to summarize, repair, test, and root cause analysis through the integration of domain knowledge. mABC uses a polling structure organized by agents inspired by blockchain to diagnose faults through workflows. RCACopilot uses a large language model to summarize diagnostic data and utilizes Chain of Thought capabilities to predict and explain root causes. Flow-of-Action is an SOP-based system that guides the diagnosis process by summarizing typical diagnostic steps followed by engineers to assist in root cause identification. L4 is a diagnosis framework trained on a large amount of log data, aiming to identify fault-indicating log content and simplify the process. ScalaLog is a log-based industrial Internet of Things system diagnosis method that utilizes LLM-based summarization, sample enhancement, and Chain of Thought (CoT) prompts to improve accuracy without the need for model retraining or log parsing.

[0017] However, the above methods generally lack effective human-computer interaction mechanisms, further exacerbating their application limitations in actual operation and maintenance environments. Automated diagnostic systems usually operate in an end-to-end manner, and operation and maintenance personnel can only passively receive diagnostic results and cannot participate in or intervene in the reasoning process of the model. This one-way information flow pattern makes it difficult to form a collaborative decision-making loop between humans and systems. Specifically, when faced with complex fault scenarios, operation and maintenance personnel often rely on their domain experience to make assumptions and verify potential root causes, but existing models lack interactive interfaces to support users in making assumptions, feeding back prior knowledge, or conducting counterfactual reasoning, thereby limiting the effective injection of expert knowledge. At the same time, when the model output is ambiguous or does not match the on-site situation, operation and maintenance personnel cannot trace the diagnostic logic through interactive means, severely undermining the flexibility and adaptability of the system. More importantly, the lack of interactive mechanisms also hinders the dynamic explanation and feedback learning of diagnostic results, making it difficult for the system to continuously optimize based on actual operation and maintenance feedback. Therefore, the lack of human-computer interaction mechanisms not only affects the controllability and transparency of the diagnostic process, but also restricts the deep integration of human cognitive abilities and machine intelligence, becoming a key bottleneck in improving the practicality and credibility of intelligent fault diagnosis systems.

[0018] Through retrieval, although there are various solutions in the prior art, there are still defects and deficiencies: 1. A cloud service problem fine-grained intelligent tracing method based on logs (CN09861844B) based on cloud operating system historical abnormal data and fault injection technology, through time correlation analysis and machine learning, extracts system task execution patterns in cross-component logs, and constructs an abnormal knowledge base; use the knowledge base to identify task patterns in new logs to achieve fine-grained automatic tracing of cloud service abnormalities. Through intelligent learning of historical data, the synergistic effect of multiple components is captured, and it is suitable for intelligent diagnosis and positioning of abnormal problems in cloud computing environment.

[0019] Method defects: difficult to integrate multi-modal data, lack of model interpretability and human-computer interaction mechanism, and unable to effectively integrate domain knowledge.

[0020] 2. Eadro is an end-to-end troubleshooting framework for microservice systems, aiming to cooperatively implement anomaly detection and root cause localization based on multi-source monitoring data. This method learns intra-service behavior from system logs, key performance indicators (KPIs), and call chain traces through modality-specific modeling, and uses a graph attention network (GAT) to model inter-service dependencies combined with historical call relationships. Then, through a multi-task learning mechanism, the anomaly detection and root cause localization tasks are jointly optimized, sharing intermediate representations and learning objectives, effectively alleviating the problem of performance degradation caused by detection error propagation in traditional two-stage methods. Lee, Cheryl, et al. "Eadro: An end-to-end troubleshooting framework for microservices on multi-source data." 2023 IEEE / ACM 45th International Conference on Software Engineering (ICSE). IEEE, 2023. ] Method defects: lack of model explainability and human-computer interaction mechanism, and unable to effectively integrate domain knowledge.

[0021] 3、Flow-of-Action is a large language model multi-agent system based on SOP enhancement, which is used for root cause analysis under microservice architecture. The method introduces SOP knowledge base and SOP process mechanism to impose soft constraints on the reasoning process of large language model, effectively alleviating the problem that traditional ReAct framework is prone to hallucination and invalid action in complex diagnosis task. The system designs a multi-agent collaborative architecture with the main agent as the core, combined with ActionAgent, ObAgent, JudgeAgent and other auxiliary agents, which are responsible for generating candidate action set, extracting key observation information and judging whether the root cause is located, respectively, so as to improve the accuracy and robustness of diagnosis. At the same time, a new interaction paradigm of "thinking-action set-action-observation" is proposed, which generates a set of actions with reasons first and then makes decisions, enhancing the planning ability of the model in the multi-feasible path scenario. Pei, Changhua, et al. "Flow-of-Action: SOP Enhanced LLM-Based Multi- Agent System for Root Cause Analysis." Companion Proceedings of the ACM on Web Conference 2025. 2025. ] Method defects: lack of human-computer interaction mechanism.

[0022] To solve the above technical problems, the present application provides an operating system abnormality intelligent diagnosis method based on multi-source data. SUMMARY

[0023] The present application proposes an operating system abnormality intelligent diagnosis method based on multi-source data to solve the problems of the prior art. By combining statistical analysis, machine learning, deep learning and other technologies, and integrating multi-domain professional knowledge, the operating system abnormality intelligent diagnosis method based on multi-source data is constructed to help operation and maintenance personnel to timely discover and locate abnormalities, thereby reducing the occurrence of system crash, data damage, service stop and other problems, improving the reliability and stability of infrastructure, and enhancing the user experience.

[0024] The above object of the present application is realized by the following technical scheme: An operating system abnormality intelligent diagnosis method based on multi-source data, comprising the following steps: Step 1, based on the standardization of historical fault knowledge and the domain adaptation of large language model, the relevant historical troubleshooting guide retrieval of the fault is realized by feature extraction and matching of the current multi-source data, and the most similar historical fault case of the current abnormality and the standardized abnormality features of the current abnormality are outputted; Step 2, based on the output obtained in step 1 and the standardized abnormal features of the current abnormality, the LLM combines the retrieved historical knowledge, standardized abnormal features, and SOP to automatically generate a preliminary diagnosis report, and through model-driven multiple rounds of modification and supplementation to form a perfect diagnosis conclusion.

[0025] Step 3, based on the final diagnosis report generated in step 2, an interactive HITL mode is adopted to support fine-grained reasoning and report refinement by introducing dynamic interaction between the on-duty engineer OCE and the LLM.

[0026] Moreover, the specific steps of step 1 include: (1) Fine-tune the large language model to obtain a fine-tuned language model with domain semantic alignment capability; (2) Use the fine-tuned language model of step 1 (1) to build a standardized knowledge base of historical fault cases, and obtain a standardized historical fault case library with consistent semantics and retrievability; (3) After real-time collection of multi-source data, extract abnormal features to obtain structured standardized abnormal features; (4) Use the structured standardized abnormal features obtained in step (3) to perform semantic retrieval in the standardized historical fault case library obtained in step (2), match the most relevant historical fault case, and generate an explanatory diagnosis conclusion.

[0027] Moreover, the specific method of step 1 (1) is: ① Systematically search and screen the recorded fault events in the historical knowledge base to ensure that the selected samples cover different fault categories and are representative; ② Experts construct standardized instruction templates based on case content to convert unstructured text into a unified description format; ③ Use the above standardized samples to supervise the fine-tuning of the basic language model to make it have understanding and generation ability for specific systems: use the supervised fine-tuning method, use the constructed instruction-response pair as training data, and through the standard deep learning training process, iteratively optimize the pre-trained language model until the model's generation accuracy and semantic consistency on the fault-related task on the validation set reach the expected threshold. The output of this stage is a fine-tuned language model with domain semantic alignment capability.

[0028] Moreover, the specific method of step 1 (2) is: ① Summarize historical fault document records; ② Use the fine-tuned language model of step 1 (1) to standardize the narrative of the original cases, unify the terminology, hierarchical structure, and semantic expression; ③ Generate a standardized historical fault case set, perform quality check on all standardized case texts after model, confirm format compliance and content integrity, encode as semantic vector after, store in vector database in vector form, and obtain semantic consistent and retrievable standardized historical fault case library.

[0029] Moreover, the specific method of step 1, step (3) is: ① Collect multi-modal operation data; ② Preprocess and clean the collected raw data, eliminate noise and unify time scale.

[0030] ③ Use anomaly detection method to extract abnormal features in data, and use fine-tuned language model to standardize features, and obtain structured standardized abnormal features.

[0031] Moreover, the specific method of step 1, step (4) is: ① Based on standardized abnormal features, locate the Top-5 closest historical cases to the current anomaly through semantic similarity calculation or vector retrieval; ② Take the Top-5 closest historical cases and structured standardized abnormal features as output.

[0032] Moreover, the specific steps of step 2 include: (1) Use LLM to combine the retrieved historical knowledge, standardized abnormal features and SOP to generate an initial diagnosis report; (2) Iteratively verify and correct SOP guidance to obtain a final diagnosis report with high consistency and complete semantics.

[0033] Moreover, the specific steps of step 2, step (1) include: ① Take standardized abnormal features, matched historical fault cases and SOP document templates as input.

[0034] ② Through LLM, combine multiple sources of information, and generate a structured initial diagnosis report under the guidance of CoT prompts generated based on SOP templates, covering diagnosis process, possible causes and preliminary treatment suggestions.

[0035] Moreover, the specific steps of step 2, step (2) include: ① The system automatically divides the report text according to the content theme; ② The large language model reviews each cut block and identifies parts that are inconsistent with SOP specifications or lack content; ③ The large language model supplements the necessary information according to the previously improved cut block, related SOP and historical cases; ④ Sequentially splicing and formatting the report snippets to ensure the coherence of the structural hierarchy and logical connection; ⑤ Generating a "corrected and supplemented diagnostic report" as the final diagnostic report output result.

[0036] Moreover, the specific steps of step 3 include: (1) Quantifying the confidence of the final diagnostic result and associating it with traceable evidence to generate an interpretable diagnostic report with confidence annotation and evidence traceability link; (2) Through the dynamic interaction of OCE and LLM, fine-grained reasoning and report refinement are supported; The specific steps of step 3 (1) include: ① Based on the semantic similarity, historical case consistency and context matching degree generated in the model reasoning process, the confidence score of the diagnostic conclusion is calculated.

[0037] ② For each conclusion, a corresponding traceable hyperlink is generated, pointing to its supporting evidence, including the retrieved historical fault records and related SOP documents; ③ The confidence score and evidence link are embedded in the diagnostic report, making the report transparent and verifiable in structure, and thus generating an interpretable diagnostic report with confidence annotation and evidence traceability link; The specific steps of step 3 (2) include: ① OCE can selectively request the model to further explain the specific reasoning steps, conclusion sources or context based on the confidence distribution and evidence link attached in the diagnostic report; ② LLM responds to the request in real time, generates explanatory answers or supplementary explanations by combining the dialogue context and knowledge base content; ③ The system maintains a complete interactive session record, making each explanation, supplement and correction traceable and capable of continuous learning, supporting fine-grained reasoning and report refinement.

[0038] The present application has the advantages and positive effects: 1. The present application proposes a multi-modal collaborative anomaly diagnosis method: first, according to the characteristics of each type of data modality, adopt appropriate preprocessing and anomaly detection technology to accurately extract its key abnormal features; then, use the fine-tuned large language model (LLM) to unify these heterogeneous abnormal features into natural language description with clear structure and consistent semantics, so as to realize semantic alignment and fusion of cross-modal information, and provide high-quality and interpretable input basis for subsequent fault attribution, root cause positioning and diagnostic decision-making.

[0039] 2、The application introduces a "human-in-the-loop" (HITL) mechanism to build a dynamic collaborative diagnosis process between an on-duty engineer (OCE) and a large language model (LLM). On the one hand, the mechanism generates a reasoning chain and diagnostic basis in the form of fine-grained natural language through the LLM, significantly improving the transparency and explainability of model decision-making. On the other hand, it supports real-time feedback, correction and supplementation of the diagnosis result by operation and maintenance personnel based on business context, realizing iterative refinement of the diagnosis report.

[0040] 3、The application proposes a knowledge standardization method based on a large language model (LLM). To solve the semantic heterogeneity problem caused by differences in engineer background, terminology habits and description style in historical fault cases, we systematically build a fine-tuning dataset based on real work orders to adapt the LLM to the field. This model can map fault descriptions of different sources and different expressions to a consistent semantic space, effectively eliminating expression differences and achieving standardized understanding and high-precision retrieval of historical knowledge. Through this mechanism, the accuracy of cross-case similarity matching is improved, and the fusion and efficient reuse of multi-source heterogeneous diagnostic knowledge are promoted, laying a semantic consistent knowledge foundation for subsequent root cause analysis and decision support. BRIEF DESCRIPTION OF DRAWINGS

[0041] Figure 1 is an abnormal diagnosis flowchart of the application; Figure 2 is a data analysis and knowledge retrieval flowchart of the application; Figure 3 is an abnormal diagnosis flowchart based on SOP of the application; Figure 4 is a diagnosis report schematic diagram of the application; Figure 5 is a schematic diagram of an embodiment of the application. DETAILED DESCRIPTION

[0042] The structure of the application will be further described below in conjunction with the drawings and through embodiments. It should be noted that the embodiments are descriptive rather than limiting.

[0043] A multi-source data-based operating system abnormality intelligent diagnosis method, as shown in Figures 1-3 , includes the following steps: Step 1, based on the standardization of historical fault knowledge and the field adaptation of a large language model, through feature extraction and matching of current multi-source data, the relevant historical troubleshooting guide is retrieved for the fault, and the most similar historical fault case and the standardized abnormal features of the current abnormality are outputted; The specific steps of step 1 include: (1) Fine-tune the large language model to obtain a fine-tuned language model with domain semantic alignment capability; The specific method of step 1 (1) is: ① Systematically retrieve and screen the recorded fault events in the historical knowledge base to ensure that the selected samples cover different fault categories and are representative; ② Experts construct standardized instruction templates based on case content to convert unstructured text into a unified description format; ③ Use the above standardized samples to supervise the fine-tuning of the basic language model to make it have understanding and generation ability for specific systems: use the supervised fine-tuning method, use the constructed instruction-response pair as training data, and through the standard deep learning training process, iterate and optimize the pre-trained language model until the model reaches the expected threshold on the validation set. The accuracy and semantic consistency of the generation of fault-related tasks, the output of this stage is a fine-tuned language model with domain semantic alignment capability.

[0044] (2) Use the fine-tuned large language model of step 1 (1) to build a standardized knowledge base of historical fault cases, and obtain a standardized historical fault case library with consistent semantics and retrievability; The specific method of step 1 (2) is: ① Summarize historical fault document records; ② Use the fine-tuned language model of step 1 (1) to standardize the narrative of the original cases, unify the terminology, hierarchical structure and semantic expression; ③ Generate a standardized historical fault case set, perform quality checking on all standardized case texts, confirm that the format is compliant and the content is complete, then encode them into semantic vectors and store them in a vector database in the form of vectors, and then obtain a standardized historical fault case library with consistent semantics and retrievability.

[0045] (3) Extract structured standardized abnormal features after real-time collection of multi-source data; The specific method of step 1 (3) is: ① Collect multi-modal operation data; ② Preprocess and clean the collected raw data to eliminate noise and unify the time scale.

[0046] ③ Use the abnormal detection method to extract abnormal features from the data, and use the fine-tuned language model to standardize the features, and then obtain structured standardized abnormal features.

[0047] (4) Using the structured and standardized anomaly features obtained in step (3), perform semantic retrieval in the standardized historical fault case library obtained in step (2), match the most relevant historical fault cases, and generate explanatory diagnostic conclusions; The specific method for step (4) of step 1 is as follows: ① Based on standardized anomaly features, locate the Top-5 historical cases most similar to the current anomaly through semantic similarity calculation or vector retrieval; ② The top-5 most similar historical cases and structured standardized anomaly features are used as output.

[0048] In this embodiment, step 1, based on the standardization of historical fault knowledge and domain adaptation of the large language model, achieves the retrieval of relevant historical troubleshooting guidelines for faults through feature extraction and matching of current multi-source data. The output of this step is the Top-5 historical fault cases most similar to the current anomaly and the standardized anomaly features of the current anomaly.

[0049] (1) Domain fine-tuning of the large language model. For the target system domain, high-quality training samples are constructed using historical fault data to perform targeted fine-tuning of the basic language model, enhancing its ability to generate fault descriptions: (a) Typical fault case samples are collected from the historical knowledge base, covering multiple anomaly types. Specifically, this involves systematically retrieving and filtering recorded fault events in the historical knowledge base to ensure that the selected samples cover different fault categories and are representative, avoiding sample bias. (b) Experts construct standardized instruction templates based on case content, transforming unstructured text into a unified description format (including fault phenomena, causes, and solutions). Specifically, domain experts manually review the original fault descriptions, reorganizing the language according to predefined structured fields (i.e., fault phenomena, root causes, and solutions) to form training samples in the form of instruction-response pairs, ensuring semantic clarity, consistent terminology, and logical completeness. (c) The basic language model is then fine-tuned using the aforementioned standardized samples to enable it to understand and generate specific system-specific information. The specific operation involves using Supervised Fine-Tuning (SFT) to iteratively optimize the pre-trained language model using the constructed instruction-response pairs as training data. This optimization is performed through standard deep learning training procedures (including loss calculation, backpropagation, and parameter updates) until the model achieves the expected thresholds in terms of generation accuracy and semantic consistency for fault-related tasks on the validation set. The output of this stage is a fine-tuned language model with domain semantic alignment capabilities.

[0050] (2) Standardization of historical failure cases and construction of knowledge base. After the model has a preliminary understanding of the field, the historical failure documents are standardized and structured at the semantic level to form knowledge resources that can be efficiently retrieved and reused: (a) Summarize historical failure document records. The specific operation is: collect all original documents such as historical failure reports, operation and maintenance work orders, and event logs that have not been structured, establish a unified original case set, and ensure data integrity and timeliness. (b) Use the fine-tuned language model to standardize the narrative of the original cases, unify the terminology, hierarchical structure, and semantic expression. The specific operation is: input the original unstructured text into the fine-tuned language model obtained in step (1), and the model automatically rewrites the input text into a standardized narrative containing the three elements of “failure phenomenon, cause, and solution”, replaces non-standard terms with domain standard terms, and adjusts the sentence structure to maintain consistency. (c) Generate a standardized historical failure case set to provide semantic consistency for subsequent similar case retrieval and knowledge transfer. The specific operation is: quality check (which can be manually sampled or rule checked) all the standardized case texts after the model, confirm the format compliance and content integrity, encode them into semantic vectors (such as through Sentence-BERT or the embedding layer of the fine-tuned model itself), and store them in the vector database in the form of vectors to support subsequent fast retrieval based on semantic similarity. The output of this stage is a standardized historical failure case library (stored in the form of vectors) that is semantically consistent and retrievable.

[0051] (3) Real-time multi-source data collection and abnormal feature extraction. During the system running process, potential faults that occur at the moment are extracted from multi-source data to provide the basis for subsequent comparison and diagnosis: (a) Collect multi-modal running data, including logs, indicators, and stack trace data, etc. The specific operation is: through the monitoring agent or system interface, the runtime data stream of the target system is obtained in real time. (b) Preprocess and clean the original data to eliminate noise and unify the time scale. The preprocessing of indicator data includes standardization to ensure the consistency of different scales and time series, and time series alignment to realize the effective correlation of multi-source data. The specific operation is: Min-Max normalization is performed on the indicator data to eliminate the dimension difference; the time series with different sampling frequencies are aligned through interpolation or sliding window to make each indicator comparable at the same timestamp. Log data is usually semi-structured, recording key events and system status, providing context information needed for fault diagnosis. To preserve the core semantics of log entries, we use the Drain log parsing algorithm to extract log templates. These templates encapsulate the essential structural patterns of log messages, abstracting out the variable content. The specific operation is: input the original log stream into the Drain algorithm, which automatically clusters similar logs based on a fixed-depth parse tree, and outputs the template corresponding to each log (such as "Error in module<module_id>: timeout after<timeout_ms>ms") and parameter values. Stack trace data provides detailed records of function call sequences before a fault occurs, making it suitable for locating execution bottlenecks. The preprocessing of stack trace data includes extracting the hierarchical relationship between function calls, thereby providing execution paths for subsequent analysis tasks. The specific operation is: parse the original stack text, identify function names, call levels, and call order, build call trees or call chain lists, and preserve call depth and parent-child relationships. (c) Use anomaly detection methods to extract abnormal features from data, and use fine-tuned language models to standardize the features. Indicator data: we use the 3-sigma rule as the anomaly detection standard. Due to its simplicity, computational efficiency, and robustness, this method is widely used in time series anomaly detection. The specific operation is: calculate the mean and standard deviation of each indicator time series within the sliding window, and if the current value exceeds the mean ± 3 times the standard deviation, mark it as an anomaly point; at the same time, extract trend features (such as continuous rise, sudden drop, etc.) through sliding window slope analysis. When combined with the interpretation of the physical meaning of the corresponding indicators, these trend features can provide context information, thereby improving the accuracy of diagnosis. Log data: we first embed log templates into semantic vectors and cluster them based on cosine similarity to group semantically similar templates. The specific operation is: use a pre-trained semantic encoder (such as Sentence-BERT) to convert each log template into a fixed-dimensional vector, and then group them by cosine similarity through K-means or hierarchical clustering.For each cluster, we extract two key features: (i) the center embedding, representing the dominant semantic pattern; (ii) the aggregate count of templates within the cluster, reflecting its frequency. These features are input into an Isolation Forest algorithm to identify anomalous clusters. Specifically, we compose a feature vector for each cluster by concatenating its center vector and frequency, and feed it into the Isolation Forest model, which outputs an anomaly score based on path length. The combination of semantic and statistical attributes improves the model's ability to detect anomalous logs. Stack trace data: We analyze stack traces by computing the frequency distribution of function calls, focusing on leaf functions at the end of the call chain. An increase in the call frequency of a specific leaf function often indicates a performance bottleneck. Specifically, we count the occurrences of each leaf function (i.e., a function with no child calls) in all stacks, compute its call frequency per unit time, and compare it to historical baselines to identify significantly growing functions. Additionally, we quantify the frequency of specific keywords (e.g., "do_anonymous_page") in stack traces, which can serve as potential indicators of system failures. Specifically, we predefine a list of keywords related to known failures, scan all stack texts, count the occurrences of the keywords, and compute their proportion or change rate in the total stack. The output of this stage is structured, standardized anomaly features.

[0052] (4) Similar case retrieval and intelligent diagnosis. Finally, we use the standardized anomaly features to perform semantic retrieval in the historical case library, match the most relevant failure cases, and generate an explanatory diagnostic conclusion: (a) Based on the standardized anomaly features, we use semantic similarity calculation or vector retrieval to locate the Top-5 historical cases most similar to the current anomaly. Specifically, we encode the standardized anomaly features (which have been converted into natural language descriptions by the fine-tuned language model) into semantic vectors, use a vector database to perform approximate nearest neighbor search, calculate the cosine similarity between them and all vectors in the historical case library, and return the top 5 cases with the highest similarity. (b) The Top-5 most similar historical cases and the standardized anomaly features are output and passed to the next step. Specifically, we package the complete standardized content (including phenomena, causes, and solutions) of the 5 historical cases and the current standardized anomaly features into a structured diagnostic context for use by subsequent manual review or automated decision-making modules.

[0053] The working principle of step 1 is as follows: Historical failure cases often contain descriptions of failure symptoms and corresponding troubleshooting guidelines, which are valuable troubleshooting resources in manual diagnosis. A direct method is to use keyword-based or vector-based retrieval methods to retrieve relevant documents. However, there is considerable inconsistency in the way different engineers describe similar symptoms. These inconsistencies hinder accurate retrieval of relevant cases and hinder effective knowledge transfer of historical troubleshooting documents.

[0054] To solve this problem, the application utilizes the semantic alignment function of LLMs to align the current fault features with historical case symptoms, thereby achieving more robust and accurate retrieval. The semantic alignment strategy implemented by the application greatly improves the retrieval performance of vector-based methods and effectively captures the potential semantic relationship between fault descriptions and historical diagnostic knowledge.

[0055] The application solves the problem of insufficient troubleshooting knowledge based on LLM reasoning by integrating a knowledge alignment component, particularly the inconsistent, ambiguous, and non-standardized symptom descriptions in historical fault documents. The knowledge alignment component standardizes unstructured symptom narratives into a structured, machine-interpretable format consistent with operational semantics. By improving the accuracy of retrieval, accurately obtaining documents related to anomalies, and inputting these documents as domain knowledge into LLM, the application can effectively utilize historical troubleshooting information, enhance the model's understanding of fault situations, and thus support more accurate and reliable diagnostic decisions.

[0056] The application can solve challenge 1: difficulty in fusing multi-source heterogeneous data: (a) Clearly collect multi-modal operation data such as logs, indicators, and stack traces, and acknowledge their heterogeneity; (b) Design special preprocessing methods for different data types: standardize and time-align indicator data to eliminate dimension and sampling frequency differences; use the Drain algorithm to extract structured templates from logs, preserving semantic essence; and analyze function call hierarchy for stack traces to construct execution paths. This achieves preliminary alignment of heterogeneous data at the structural level; (c) Further extract abnormal features in each domain through a unified abnormality detection strategy (3-sigma for indicators, isolated forest for log clustering, and leaf function frequency analysis for stacks), and convert these features into standardized natural language descriptions using a fine-tuned language model. This key operation maps originally heterogeneous numerical, symbolic, and sequential data into a shared semantic space, laying the foundation for subsequent fusion with historical cases and SOP text knowledge.

[0057] Therefore, step (3) effectively solves the fusion problem of multi-source heterogeneous data through the triple mechanism of "special preprocessing + domain-adapted abnormality detection + language model-driven semantic standardization".

[0058] The application can solve challenge 2: the need to integrate domain knowledge in the fault diagnosis process: Step (1) (a) (b) (c) Construct a field instruction dataset using historical failure cases, and make the base language model master the terminology, failure logic and description specifications of the target system through supervised fine-tuning, giving it preliminary field semantic alignment capabilities; Step (2) (a) (b) (c) Further semantic standardization of all historical documents using the fine-tuned model to build a high-quality, structured field knowledge base, making implicit experience explicit and unstructured knowledge structured.

[0059] Step 2, based on the output obtained in step 1, the most similar historical failure case to the current abnormality and the standardized abnormality features of the current abnormality, use LLM to combine the retrieved historical knowledge, standardized abnormality features and SOP to automatically generate a preliminary diagnosis report, and through model-driven multiple rounds of revision and supplementation to form a complete diagnosis conclusion.

[0060] The specific steps of step 2 include: (1) Use LLM to combine the retrieved historical knowledge, standardized abnormality features and SOP to generate an initial diagnosis report; The specific steps of step 2 (1) include: ① Take the standardized abnormality features, matched historical failure cases and SOP document templates as input.

[0061] ② Through LLM, generate a structured initial diagnosis report under the guidance of the CoT prompt generated based on the SOP template, covering the diagnosis process, possible causes and preliminary treatment suggestions.

[0062] (2) Iterative SOP-guided verification and revision to obtain a high-consistency, semantically complete final diagnosis report; The specific steps of step 2 (2) include: ① The system automatically divides the report text according to the content theme; ② The large language model reviews each cut block and identifies parts that are inconsistent with SOP specifications or have missing content; ③ The large language model supplements necessary information based on the previously improved cut block, relevant SOP and historical cases; ④ Sequence splicing and formatting of report cut blocks to ensure the coherence of structure hierarchy and logical connection; ⑤ Generate a "revised and supplemented diagnosis report" as the final diagnosis report output result.

[0063] In this embodiment, after completing the abnormal feature standardization and similar case retrieval in step 2, the system enters the diagnostic knowledge generation phase. This phase aims to combine the retrieved historical knowledge, standardized abnormal features, and SOPs using LLM to automatically generate a preliminary diagnosis report and form a complete diagnosis conclusion through model-driven multiple rounds of revision and supplementation. The output of this step is the diagnosis report for the current abnormality.

[0064] (1) CoT generates an initial diagnosis report. Based on the results of the previous stage, generate preliminary diagnosis content: (a) Take the standardized abnormal features, matched historical fault cases, and SOP document templates as input. Specifically, take the generated standardized abnormal feature description (i.e., a structured natural language expression of the current abnormal phenomenon), the Top-5 similar historical fault cases (including their respective phenomena, causes, effects, and solutions), and the pre-defined standard operation procedure (SOP) document template (which specifies the chapter structure that the diagnosis report should include, such as "diagnostic process", "possible causes", "initial treatment suggestions", etc.) as input. Integrate these three types of information as the input context of the large language model (LLM). (b) Through LLM, generate a structured initial diagnosis report under the guidance of the CoT (Chain-of-Thought) prompt generated based on the SOP template, covering the diagnostic process, possible causes, and initial treatment suggestions. Specifically, construct a CoT prompt that includes explicit reasoning steps. The prompt first repeats the input abnormal features, then successively guides the model to "refer to the common causes in historical cases", "compare the diagnostic logic required by SOP", "deduce possible root causes", and "propose preliminary disposal measures that conform to the standard". LLM generates diagnosis content in accordance with the SOP structure based on this prompt, ensuring that each part is logically progressive and has evidence. The output of this stage is an "initial diagnosis report" with preliminary logical completeness.

[0065] (2) Iterative SOP-guided verification and revision. To improve the quality and controllability of the report, the initial report is decomposed into multiple semantic units or topic segments for fine-grained review. (a) The system automatically segments the report text according to the content topics (such as "diagnostic process", "cause analysis", "treatment suggestion", etc.). The specific operation is: according to the pre-defined chapter titles in the SOP template (for example, "1. Diagnostic process", "2. Possible cause analysis", "3. Preliminary treatment suggestion"), using rule matching or title-based text segmentation algorithm, the initial diagnostic report is divided into several independent segments according to semantic boundaries, and each segment corresponds to a topic unit. (b) The large language model reviews each segment and identifies parts that are inconsistent with SOP specifications or lack content. The specific operation is: input each segment into the fine-tuned LLM separately, and attach the corresponding SOP requirements. The model compares the content with the specification sentence by sentence, and marks out problems such as logical jumps, non-standard terminology, lack of basis, or missing key steps. (c) The model supplements necessary information such as missing operation points, repair steps or verification methods based on the previously completed segments (for example, the current segment is the third segment, and the first and second segments have been modified and supplemented), relevant SOP and historical cases. The specific operation is: when processing the kth segment, the system inputs the content of the first k-1 completed segments, the original text of the current segment, the corresponding SOP and related historical cases as joint context into the LLM, and the model generates the modified kth segment based on this, ensuring that it is logically coherent with the previous text, complete in content and in line with the specification; for example, in the "treatment suggestion" segment, if the SOP requires "verification method to repair the effect", but the initial report is missing, the model will supplement the verification method based on the common verification methods in historical cases. (d) The report segments are sequentially spliced and formatted to ensure the coherence of the structure hierarchy and logical connection. The specific operation is: recombine all the iteratively revised segments in the original order, unify the title level, numbering format and paragraph style, and check whether the transition between paragraphs is natural. If necessary, the model generates transition sentences to enhance the overall coherence. (e) Generate a "modified and supplemented diagnostic report" as the final output result to support subsequent expert review or automatic execution. The specific operation is: encapsulate the spliced and formatted complete text into a standard document format, and mark it as "final diagnostic report". The output of this stage is a high-consistency, semantically complete "final diagnostic report".

[0066] The working principle of step 2 is: Due to the limitations of general-purpose LLMs in capturing domain-specific knowledge, the preliminary output may contain inaccurate assumptions or flawed reasoning steps, which need to be further verified. To improve the accuracy of the initial diagnostic reasoning, we introduce a report verification component that can verify and correct each step in the initial report step by step. Unlike evaluating the entire report, the report verification component adopts an iterative correction strategy. For each step, the report verification component generates a search query composed of the current step and the previously verified steps. This query is then used to retrieve relevant SOPs from the knowledge base. By iteratively embedding and correcting each reasoning step one by one, a verified diagnostic report that is both accurate and executable is ultimately generated.

[0067] In operating system fault diagnosis, the same symptoms can come from different potential root causes, which poses a significant challenge to accurate fault location. In addition, most LLMs are pre-trained on general-purpose corpora, thus lacking sufficient exposure to domain-specific operational knowledge. The probabilistic nature of LLMs exacerbates this limitation, which often leads to inconsistent or ambiguous outputs, thereby undermining their reliability and applicability in real-world diagnostic tasks. Therefore, general-purpose LLMs often fail to draw accurate and actionable diagnostic conclusions, requiring a trial-and-error process that prolongs recovery time. SOPs can impose constraints on LLM reasoning, guiding the entire process in the right direction. The present invention ensures that each step of diagnostic reasoning is explicitly aligned with established SOP knowledge, significantly improving the reliability and practicality of the output generated by LLMs.

[0068] Challenge 3: The fault diagnosis process needs to integrate domain knowledge: solved by step (1) "CoT generates an initial diagnostic report" and step (2) "iterative SOP-guided verification and correction": Step (1) (a) (b) utilizes SOP templates and CoT technology to guide the model to reason step by step, significantly improving the accuracy, interpretability, and controllability of large language models in complex tasks. This structured guidance avoids the model jumping directly to a conclusion, but rather simulates the thinking process of expert diagnosis, ensuring that the output covers the necessary steps specified by the SOP, reducing omissions or logical breaks, thereby improving the accuracy and logical integrity of the preliminary diagnosis. In addition, since the CoT strictly follows the structure and reasoning order defined by the SOP template, the generated report naturally has modular features (such as "diagnostic process" and "cause analysis" segments), which provide a foundation for automatic segmentation, block-by-block review, and supplementation in step (2) "iterative SOP-guided verification and correction".

[0069] Step (2) (a) (b) (c) (d) (e) further utilizes SOPs to correct existing results, fully integrating domain knowledge to improve result accuracy.

[0070] Step 3, based on the final diagnostic report generated in Step 2, adopts an interactive HITL mode to support fine-grained reasoning and report refinement by introducing dynamic interaction between the on-call engineer (OCE) and the LLM. The specific steps of Step 3 include: (1) Quantify the confidence of the final diagnostic result and associate it with traceable evidence to generate an interpretable diagnostic report with confidence annotations and evidence traceability links. The specific steps of Step 3 (1) include: ① Based on the semantic similarity, historical case consistency, and context matching degree generated during model reasoning, calculate the confidence score of the diagnostic conclusion.

[0071] ② Generate a corresponding traceable hyperlink for each conclusion, pointing to its supporting evidence, including the retrieved historical fault records and related SOP documents. ③ Embed the confidence score and evidence links into the diagnostic report to make the report transparent and verifiable in structure, and then generate an interpretable diagnostic report with confidence annotations and evidence traceability links.

[0072] (2) Through dynamic interaction between OCE and LLM, support fine-grained reasoning and report refinement. The specific steps of Step 3 (2) include: ① OCE can selectively request the model to further explain specific reasoning steps, conclusion sources, or context based on the confidence distribution and evidence links attached in the diagnostic report. ② LLM responds to the request in real time and generates explanatory answers or supplementary explanations based on the dialogue context and knowledge base content. ③ The system maintains a complete interactive session record, making each explanation, supplement, and correction traceable and capable of continuous learning, supporting fine-grained reasoning and report refinement. In this embodiment, after completing the automatic generation and revision of the diagnostic report, the present application enters the trusted enhancement phase based on human-machine collaboration. This phase adopts an interactive HITL (Human-in-the-Loop) mode to alleviate the gap in interpretability caused by the limited overlap between LLM and human experts, thereby improving the transparency, traceability, and practicality of the diagnostic results.

[0073] (1) Confidence quantification of diagnosis results and association with traceable evidence. After the report is generated, the present application firstly performs confidence evaluation and evidence binding on each conclusion output by the LLM: (a) Based on the semantic similarity, historical case consistency and context matching degree generated in the model reasoning process, the confidence score of the diagnostic conclusion is calculated. The specific operation is: for each conclusion in the diagnostic report (such as "the possible cause is memory leak"), the system traces back the key input elements it relies on when generating the conclusion, including the average cosine similarity of the conclusion and the top-5 historical cases in the semantic vector space, whether the conclusion is supported by multiple historical cases (i.e. consistency count), and the matching strength of the conclusion and the standardized abnormal features in the input in the context logic (for example, measured by attention weight or keyword coverage); normalize and weight the above three dimensions to generate a confidence score between 0-1, the higher the score, the more reliable the conclusion.(b) Generate traceable hyperlinks for each conclusion, pointing to its supporting evidence, including the retrieved historical fault records and related SOP documents. The specific operation is: when generating the conclusion, the system records the specific historical case ID (from the retrieval result of step (4)) and the SOP chapter number (from the SOP template used in step (1)) relied on; then, automatically attach a hyperlink to the conclusion, the link format is the uniform resource identifier (URI) of the internal knowledge base, for example "hist_case: / / ID_2023_045" or "sop: / / section_5.2", which can directly jump to the original evidence content when clicked.(c) Embed the confidence score and evidence link in the diagnostic report, so that the report has transparency and verifiability in structure. The specific operation is: at the end of each conclusion sentence in the diagnostic report, insert the confidence value (such as "[confidence: 0.87]") and the clickable evidence link in the form of inline comments or footnotes, ensuring that users can instantly view the supporting evidence when reading, and the overall report remains structured and readable. The output of this stage is an interpretable diagnostic report with confidence annotation and evidence traceable link, providing a basis for subsequent human-machine interaction.

[0074] (2) Dynamic interaction between OCE and LLM. To bridge the gap between model output and human understanding, the system designs an interactive interface between OCE and LLM, supporting fine-grained reasoning explanation and report refinement: (a) OCE can selectively request the model to provide further explanation on specific reasoning steps, conclusion sources, or context based on the confidence distribution and evidence links attached in the diagnostic report. Specifically, when reviewing the diagnostic report, the operation and maintenance expert (OCE) can click the "Request Explanation" button next to a low-confidence conclusion (e.g., confidence < 0.7) or a complex reasoning chain, and the system automatically extracts the context corresponding to the conclusion (including the original abnormal features, the cited historical case fragments, the SOP clauses, and the intermediate reasoning steps generated when the model was generated), and constructs a clear query instruction (such as "Please explain why 'disk I / O bottleneck' is listed as the primary cause?") and sends it to the LLM.(b) LLM responds to the request in real time, generates explanatory answers or supplementary explanations based on the dialogue context and knowledge base content. Specifically, after receiving the query from OCE, LLM takes the dialogue history of the current interaction round as the context, calls the domain knowledge learned during the fine-tuning stage, and references the relevant content in the stored historical case library and SOP documents to generate natural language explanations, such as "The conclusion is mainly based on the similar I / O delay pattern in historical case ID_2022_112, and the 'await time surge' in the current abnormal feature is highly matched with the I / O bottleneck symptoms described in SOP section 4.3." The answer focuses on logical basis, evidence sources, and reasons for excluding other possibilities.(c) The system maintains complete interaction session records, making each explanation, supplement, and correction traceable and capable of continuous learning. Specifically, all OCE questions, LLM responses, timestamps, and associated diagnostic report versions are recorded in the session log and stored with the original report ID. This log not only supports post-auditing and review, but also serves as a feedback data source for future model iteration (under strict de-identification and authorization), for optimizing reasoning logic or supplementing training samples.

[0075] The working principle of step 3 is: To further improve the reliability and practicality of the diagnostic report, the present application supports direct interaction between OCE and the LLM that generates the diagnostic report. The interaction mechanism allows real-time explanation, refinement, and context adaptation of the diagnostic results. To support dynamic interaction, LLM maintains a complete dialogue history record for each diagnostic session.

[0076] Enhancing the explainability of the report helps to improve the credibility of the diagnosis result and facilitates the OCE to make wise decisions. The diagnostic analysis component assigns a confidence score to each inference result. In addition, it also provides hyperlinks pointing to the specific source documents referenced in the inference process, thus ensuring the traceability of the diagnostic conclusion. The invention supports multi-round conversations, preserves historical context, and allows engineers to iteratively improve queries or explore diagnostic hypotheses. This mechanism improves the accuracy of diagnosis and reduces the cognitive burden of OCE.

[0077] Solving Challenge 4: Traditional fault diagnosis methods lack explainability and interaction mechanism: solved by step (1) "confidence quantification of diagnosis results and association with traceable evidence" and step (2) "dynamic interaction between OCE and LLM": Step (1) (a) (b) (c) forces to bind a confidence score and clickable evidence hyperlink (pointing to historical cases and SOP) for each diagnostic conclusion, making the conclusion transparent and verifiable, solving the "unexplainable" problem; Step (2) (a) (b) (c) designs a two-way interaction interface between OCE and LLM: OCE can actively initiate fine-grained questioning based on confidence and evidence links, LLM generates explanations in real time combined with context and knowledge base, and the system records the conversation throughout. This not only provides dynamic explanation capability, but also supports user-driven report refinement, completely making up for the lack of interaction mechanism in traditional methods.

[0078] These two steps together build a "explainable output + interactive correction" closed loop, fundamentally improving the transparency and human-machine collaboration ability of the diagnosis process.

[0079] Figure 1is the abnormal diagnosis flowchart realized by the current patent, mainly including (1) data analysis and knowledge retrieval, (2) SOP-based fault diagnosis and (3) OCE-LLM loop feedback three main modules. First, the historical fault documents are standardized, and the differences in the expressions of different engineers in terms, symptom description and troubleshooting logic are unified through fine-tuning of the large language model (LLM) to establish a knowledge base with consistent semantics. When the abnormal alarm is triggered, the system automatically collects multi-source heterogeneous monitoring data, respectively adopts the pre-processing and abnormal detection methods suitable for each modality to extract key features, and uses the fine-tuned LLM to convert these features into standardized abnormal narratives in structured and natural language form. Subsequently, the standardized narratives are used as queries to retrieve the semantically aligned historical fault documents, and the retrieval results and abnormal narratives are jointly input into the LLM to generate an initial diagnosis report based on the SOP template. To further improve accuracy, the system processes the report in segments, performs iterative retrieval and content correction for each segment, and dynamically integrates the latest context information. The final output diagnosis report supports the on-duty engineer (OCE) to interact with the LLM through the "human-in-the-loop" (Human-in-the-Loop) mechanism, including questioning reasoning, supplementing context or adjusting conclusions, so as to realize the explainability, flexibility and continuous optimization of the diagnosis process.

[0080] Figure 2 is the data analysis and knowledge retrieval module flowchart realized by the current patent, mainly including constructing the instruction pair of standardized fault description to fine-tune LLM, using fine-tuned LLM to standardize the narratives of historical fault cases, multi-source data processing and feature extraction, and using fine-tuned LLM to standardize the feature narratives of multi-source data. First, the historical fault cases are sampled, and multiple field experts are organized to construct the instruction pair data set in the form of "original description-standardized narrative" to fine-tune the large language model (LLM), so that it has the ability to unify fault semantic expression; then, use the fine-tuned LLM to batch process all historical fault documents, convert the original heterogeneous and unstructured engineer records into standardized narratives with consistent semantics and clear structure, and construct a high-quality diagnostic knowledge base; at the same time, the system interfaces with multi-source monitoring data, extracts key abnormal features of each data source through modality-adapted preprocessing and abnormal detection methods, and calls the same fine-tuned LLM again to convert these technical features into standardized feature narratives in natural language form; finally, the standardized real-time feature narratives and standardized historical fault knowledge are efficiently retrieved and matched in the unified semantic space, providing accurate and explainable knowledge support for subsequent diagnosis report generation.

[0081] Figure 3is the SOP-based abnormal diagnosis process chart realized by the current patent, mainly including the standardized data abnormal features based on the current abnormality and the related historical fault cases, using the SOP document template and using CoT to let LLM generate an initial diagnosis report, and cutting the report, searching the relevant SOP documents for each cut, and using LLM to iteratively correct and supplement the current cut, and finally generating a corrected and supplemented diagnosis report. First, combine the standardized multi-modal feature description of the current abnormal event with the retrieved related historical fault cases as context input; then, guide the LLM to generate an initial diagnosis report with clear structure and logical coherence according to the pre-defined SOP document template and using the chain-of-thought reasoning mechanism. To improve the accuracy and detail completeness of the report, the system divides the initial report into several paragraphs according to semantics or function, retrieves the most relevant SOP chapters for each paragraph, and calls LLM again to iteratively correct, supplement or refine the current paragraph based on the newly retrieved authoritative guidance content. After several rounds of segmented optimization, the system integrates all updated paragraphs to output the final version of the diagnosis report, ensuring that it not only conforms to the standard operation and maintenance specifications, but also integrates historical experience and the specific features of the current abnormality, and has professional, explainable and practical.

[0082] Figure 4 is the diagnosis report generated by the current patent, mainly including three aspects of content: diagnosis process, root cause and solution measures.

[0083] The Top-3 accuracy of abnormal positioning is 0.713, and the Top-5 accuracy is 0.901%.

[0084] The average score of the readability of the generated abnormal report is 4.14 (total score 5), and the average score of the effectiveness is 3.84 (total score 5). The report content is divided into three core parts: diagnosis process, root cause and solution measures. Among them, the "diagnosis process" part presents the reasoning path executed by LLM combined with SOP template and multi-source abnormal features in a step-by-step and traceable manner, reflecting the logical chain from phenomenon observation to problem positioning; the "root cause" part is based on the semantic matching of standardized feature description and historical fault knowledge, clearly pointing out the specific components, configuration errors or system behaviors that cause the abnormality, and supplemented by related evidence (such as key log fragments or indicator abnormalities); the "solution measures" part provides specific and executable repair steps or avoidance schemes according to the standard operation recommendations in SOP and historical successful handling experience, and can be dynamically adjusted according to the feedback of the operation and maintenance personnel (OCE). The overall report has standardization, explainability and practicality, effectively supporting operation and maintenance decision-making and rapid response.

[0085] Figure 5A schematic diagram illustrating an embodiment of the present application is shown. First, multi-source abnormal data from the operating system is collected, and the data is preprocessed and abnormal feature extraction is performed. Subsequently, the extracted abnormal features are converted into standardized natural language descriptions using a fine-tuned large language model (LLM), and relevant historical fault documents are retrieved based on the descriptions. In combination with the Chain-of-Thought (CoT) method, the LLM is guided to refer to the standard operating procedure (SOP) document template, and the abnormal feature description and historical fault information are integrated to generate an initial diagnosis report. Then, the LLM divides the initial report into multiple segments, retrieves the corresponding SOP documents for each segment and performs content verification, thereby generating a verified final diagnosis report. Users can raise questions or further requirements based on the report, and the LLM dynamically generates a customized report that better meets the user's needs accordingly.

[0086] Although embodiments of the present application and drawings are disclosed for illustrative purposes, those skilled in the art can understand that various alternatives, changes and modifications are possible without departing from the spirit of the present application and the appended claims, and therefore the scope of the present application is not limited to the disclosed embodiments and drawings.

Claims

1. A method for intelligent diagnosis of operating system anomalies based on multi-source data, characterized in that: Includes the following steps: Step 1: Based on the standardization of historical fault knowledge and the domain adaptation of the large language model, the relevant historical troubleshooting guides for faults are retrieved by extracting and matching features of current multi-source data, and the historical fault cases most similar to the current anomaly and the standardized anomaly features of the current anomaly are output. Step 2: Based on the historical fault cases most similar to the current anomaly obtained in Step 1 and the standardized anomaly features of the current anomaly, use LLM to combine the retrieved historical knowledge, standardized anomaly features and SOPs to automatically generate a preliminary diagnostic report, and form a complete diagnostic conclusion through model-driven multiple rounds of correction and supplementation. Step 3: Based on the final diagnostic report generated in Step 2, the interactive HITL paradigm is adopted. By introducing dynamic interaction between the on-call engineer (OCE) and the LLM, fine-grained reasoning interpretation and report refinement are supported.

2. The intelligent diagnostic method for operating system anomalies based on multi-source data according to claim 1, characterized in that: The specific steps of step 1 include: (1) Fine-tune the large language model to obtain a fine-tuned language model with domain semantic alignment capability; (2) Using the fine-tuned language model from step (1) of step 1, construct a standardized knowledge base of historical failure cases to obtain a semantically consistent and searchable standardized historical failure case library; (3) After real-time collection of multi-source data, abnormal features are extracted to obtain structured and standardized abnormal features; (4) Using the structured and standardized anomaly features obtained in step (3), perform semantic retrieval in the standardized historical fault case library obtained in step (2), match the most relevant historical fault cases, and generate explanatory diagnostic conclusions.

3. The intelligent diagnostic method for operating system anomalies based on multi-source data according to claim 2, characterized in that: The specific method for step (1) of step 1 is as follows: ① Systematically retrieve and filter recorded fault events in the historical knowledge base to ensure that the selected samples cover different fault categories and are representative; ② Experts construct standardized instruction templates based on case content, transforming unstructured text into a unified description format; ③ Use the above standardized samples to perform supervised fine-tuning of the basic language model, so that it has the ability to understand and generate for specific systems: Using the supervised fine-tuning method, the constructed instruction-response pairs are used as training data, and the pre-trained language model is iteratively optimized through the standard deep learning training process until the model reaches the expected threshold in terms of generation accuracy and semantic consistency of fault-related tasks on the validation set. The output of this stage is a fine-tuned language model with domain semantic alignment capability.

4. The intelligent diagnostic method for operating system anomalies based on multi-source data according to claim 2, characterized in that: The specific method for step (2) of step 1 is as follows: ① Compile historical fault documentation records; ②Use the fine-tuned language model from step 1 (1) to standardize the narrative of the original case, unifying terminology, hierarchical structure and semantic expression; ③ Generate a standardized set of historical failure cases. Perform quality checks on all case texts standardized by the model. After confirming that the format is compliant and the content is complete, encode them into semantic vectors and store them in the vector database in vector form, thereby obtaining a standardized historical failure case library that is semantically consistent and searchable.

5. The intelligent diagnostic method for operating system anomalies based on multi-source data according to claim 2, characterized in that: The specific method for step (3) of step 1 is as follows: ① Collect multimodal operation data; ② The collected raw data is preprocessed and cleaned to eliminate noise and standardize the time scale; ③ Use anomaly detection methods to extract anomalous features from the data, and use a fine-tuned language model to standardize the description of the features, thereby obtaining structured standardized anomalous features.

6. The intelligent diagnostic method for operating system anomalies based on multi-source data according to claim 2, characterized in that: The specific method for step (4) of step 1 is as follows: ① Based on standardized anomaly features, locate the Top-5 historical cases most similar to the current anomaly through semantic similarity calculation or vector retrieval; ② The top-5 most similar historical cases and structured standardized anomaly features are used as output.

7. The intelligent diagnostic method for operating system anomalies based on multi-source data according to claim 1, characterized in that: The specific steps of step 2 include: (1) Using LLM to combine retrieved historical knowledge, standardized abnormal features and SOPs, CoT generates an initial diagnostic report; (2) Iterative SOPs guide verification and correction, thereby obtaining a highly consistent and semantically complete final diagnostic report.

8. The intelligent diagnostic method for operating system anomalies based on multi-source data according to claim 7, characterized in that: The specific steps of step 2, step (1) include: ① Take standardized anomaly features, matched historical failure cases, and SOP document templates as input; ② By integrating information from multiple sources through LLM, a structured initial diagnostic report is generated under the guidance of CoT prompts generated based on SOP templates, covering the diagnostic process, possible causes, and preliminary treatment suggestions.

9. The intelligent diagnostic method for operating system anomalies based on multi-source data according to claim 7, characterized in that: The specific steps of step 2 (2) include: ① The system automatically segments the report text based on the content theme; ② The large language model reviews each segment to identify parts that are inconsistent with the SOP specifications or have missing content; ③ The large language model supplements necessary information based on the previously completed segments, relevant SOPs, and historical cases; ④ Sequentially assemble and format the report segments to ensure the coherence of the structural hierarchy and logical connections; ⑤ Generate a "corrected and supplemented diagnostic report" as the final diagnostic report output.

10. The intelligent diagnostic method for operating system anomalies based on multi-source data according to claim 1, characterized in that: The specific steps of step 3 include: (1) Quantify the confidence level of the final diagnosis and link it with traceable evidence to generate an interpretable diagnosis report with confidence level labeling and evidence traceability links; (2) Through the dynamic interaction between OCE and LLM, fine-grained reasoning interpretation and report refinement are supported; The specific steps of step 3, step (1) include: ① Calculate the confidence score of the diagnostic conclusion based on the semantic similarity, consistency of historical cases and context matching degree generated during the model reasoning process; ② Generate a corresponding traceable hyperlink for each conclusion, pointing to its supporting evidence, including retrieved historical fault records and relevant SOP documents; ③ Embed confidence scores and evidence links into the diagnostic report to make the report structurally transparent and verifiable, thereby generating an interpretable diagnostic report with confidence scores and evidence traceability links. The specific steps of step 3, step (2) include: ① OCE can selectively request the model to provide further explanation of specific reasoning steps, sources of conclusions, or context based on the confidence distribution and evidence links attached to the diagnostic report; ② LLM responds to requests in real time, generating explanatory answers or supplementary explanations based on the dialogue context and knowledge base content; ③ The system maintains complete records of interactive sessions, ensuring that each explanation, supplement, and correction is traceable and has continuous learning capabilities, supporting fine-grained reasoning, explanation, and report refinement.

Images