Root cause confidence analysis method based on multi-dimensional evidence fusion and related equipment

Abstract

The embodiment of the application provides a root cause confidence analysis method based on multi-dimensional evidence fusion and related equipment, and belongs to the technical field of network intelligent operation and maintenance. The method comprises the following steps: receiving a target fault root cause and a root cause probability value of a diagnosis output of a root cause positioning system for a fault event, wherein the root cause probability value is a posterior probability obtained through a network fault diagnosis of a test task; performing verification dimension coverage rate analysis on a diagnosis process of the fault event to obtain a verification coverage rate; the verification coverage rate represents verification sufficiency of the diagnosis process; performing historical diagnosis data statistics on a fault type indicated by the fault event to determine a historical diagnosis accuracy rate; and determining a root cause confidence of the target fault root cause according to the root cause probability value, the verification coverage rate and the historical diagnosis accuracy rate. The application can improve the reliability of root cause confidence quantification, and further improve the network automatic operation and maintenance decision accuracy and operation and maintenance efficiency.

Description

Technical Field

[0001] This application relates to the field of network intelligent operation and maintenance technology, and in particular to a root cause confidence analysis method and related equipment based on multi-dimensional evidence fusion. Background Technology

[0002] Current network fault diagnosis systems typically only provide a "yes / no" judgment or a single posterior probability when outputting root causes. Automated operations and maintenance (O&M) demands extremely high reliability from root cause conclusions. A single posterior probability only reflects the strength of real-time evidence and cannot reflect the adequacy of the diagnostic process verification for root cause localization, nor does it consider the randomness of the current root cause localization. The current method of measuring root cause confidence solely based on the posterior probability of root cause localization has low accuracy, impacting the accuracy and efficiency of automated network O&M decisions. Summary of the Invention

[0003] The main objective of this application is to propose a root cause confidence analysis method and related equipment based on multi-dimensional evidence fusion, aiming to improve the reliability of root cause confidence quantification, thereby improving the accuracy of network automated operation and maintenance decisions and operation and maintenance efficiency.

[0004] To achieve the above objectives, one aspect of this application proposes a root cause confidence analysis method based on multi-dimensional evidence fusion, comprising the following steps: Receive the target fault root cause and its root cause probability value from the diagnostic output of the root cause localization system for the fault event, wherein the root cause probability value is the posterior probability of network fault diagnosis performed through the dial-up test task. A verification dimension coverage analysis is performed on the diagnostic process for the aforementioned fault event to obtain the verification coverage; the verification coverage represents the adequacy of the verification of the diagnostic process. Statistical analysis of historical diagnostic data is performed on the fault types indicated by the fault events to determine the historical diagnostic accuracy rate; The root cause confidence level of the target fault root cause is determined based on the root cause probability value, the verification coverage, and the historical diagnostic accuracy.

[0005] In some embodiments, the root cause localization system diagnoses the fault event through the following steps: Based on the failure event, multiple candidate root causes of failure are identified, and the root cause probability distribution of the multiple candidate root causes of failure is initialized. Based on the root cause probability distribution and the conditional probability of each testing task in the task set under different root causes of failure, calculate the dynamic task value of each testing task in the task set. Select the highest dynamic task value from the task set for execution to obtain the current observation results of the task. Update the root cause probability distribution based on the current observation results; Determine whether the root cause detection convergence condition has been met based on the root cause probability distribution or the number of task executions. If the current root cause detection convergence condition is met, select the candidate fault root cause with the highest root cause probability value as the target fault root cause according to the current root cause probability distribution and output the root cause probability value of the target fault root cause; otherwise, repeat the step of conditionally probable based on the root cause probability distribution and the observation results of each detection task in the task set under different fault root causes.

[0006] In some embodiments, the verification dimension coverage analysis of the diagnostic process for the fault event to obtain the verification coverage includes the following steps: The corresponding initial verification dimension list is determined based on the fault type indicated by the fault event, and the device context is determined based on the device involved in the fault event; Based on the device context, the initial verification dimension list is pruned to obtain the target verification dimension list; Obtain the test tasks that have been successfully executed in the diagnostic process for the fault event, and then query the task dimension mapping table based on the test tasks to determine the verification dimensions that have been covered. Perform statistical analysis on the verification dimensions already covered in the target verification dimension list to determine the verification coverage rate.

[0007] In some embodiments, the step of performing historical diagnostic data statistics on the fault type indicated by the fault event to determine the historical diagnostic accuracy includes the following steps: Query the historical occurrence count and historical correct diagnosis count of the fault type indicated by the fault event; The historical diagnostic accuracy rate is determined based on the number of correct historical diagnoses and the number of historical occurrences.

[0008] In some embodiments, the step of performing historical diagnostic data statistics on the fault type indicated by the fault event to determine the historical diagnostic accuracy rate further includes the following steps: In response to the diagnostic verification feedback of the fault event, the historical diagnostic accuracy is updated; the update formula for the historical diagnostic accuracy is as follows: ; in, This indicates the updated historical diagnostic accuracy. This indicates the historical diagnostic accuracy rate before the update. This value serves as an indicator of the accuracy of the diagnosis. This indicates the number of valid observations of the target fault root cause during this diagnosis. This represents the forgetting factor.

[0009] In some embodiments, the root cause confidence analysis method based on multi-dimensional evidence fusion further includes the following steps: The corresponding confidence threshold is determined based on the fault type, service type, or operation and maintenance strategy of the fault event; If the root cause confidence level is greater than or equal to the confidence threshold, automatic operation and maintenance shall be performed based on the target fault root cause. If the confidence level of the root cause is less than the confidence threshold, the target root cause of the fault is reviewed.

[0010] To achieve the above objectives, another aspect of this application proposes a root cause confidence analysis system based on multi-dimensional evidence fusion, comprising: The first module is used to receive the target fault root cause and its root cause probability value output by the root cause localization system for the fault event diagnosis. The root cause probability value is the posterior probability of network fault diagnosis after the dialing test task. The second module is used to perform a verification dimension coverage analysis on the diagnostic process of the fault event to obtain the verification coverage; the verification coverage represents the adequacy of the verification of the diagnostic process. The third module is used to perform historical diagnostic data statistics on the fault types indicated by the fault events and determine the historical diagnostic accuracy rate. The fourth module is used to determine the root cause confidence of the target fault root cause based on the root cause probability value, the verification coverage, and the historical diagnostic accuracy.

[0011] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0012] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0013] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0014] The embodiments of this application include at least the following beneficial effects: This application provides a root cause confidence analysis method and related equipment based on multi-dimensional evidence fusion. This scheme receives the target fault root cause and its root cause probability value from the diagnostic output of a root cause localization system for a fault event. The root cause probability value is the posterior probability of network fault diagnosis after a testing task. The scheme performs verification dimension coverage analysis on the fault event diagnosis process to obtain the verification coverage rate, and statistically analyzes historical diagnostic data for the fault type indicated by the fault event to determine the historical diagnostic accuracy rate. Then, it determines the confidence of the target fault root cause based on the root cause probability value, verification coverage rate, and the historical diagnostic accuracy rate. This scheme quantifies root cause confidence by combining verification coverage rate and historical diagnostic accuracy rate on the basis of the root cause posterior probability. The verification coverage rate represents the sufficiency of the verification of the current diagnostic process, and the historical diagnostic accuracy rate avoids the randomness of the current root cause localization, thereby avoiding the one-sidedness of a single dimension, improving the reliability of root cause confidence quantification, and thus improving the accuracy and efficiency of network automated operation and maintenance decisions. Attached Figure Description

[0015] Figure 1 This is a flowchart of the root cause confidence analysis method based on multi-dimensional evidence fusion provided in the embodiments of this application; Figure 2 yes Figure 1 Schematic diagram of the diagnostic method of the root cause localization system; Figure 3 yes Figure 1 The flowchart of step S102 in the document; Figure 4 yes Figure 1 The flowchart of step S103 in the process; Figure 5 This is a flowchart of a root cause confidence analysis method based on multi-dimensional evidence fusion provided in another embodiment of this application; Figure 6 This is a schematic diagram of a root cause confidence analysis system based on multi-dimensional evidence fusion provided in an embodiment of this application; Figure 7 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0016] 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 of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0018] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0019] The posterior probability, the root cause probability value obtained through Bayesian belief update, can specifically refer to the root cause probability value with the highest probability among all candidate root causes of failure; it can come from any root cause localization system, and this application embodiment does not make specific limitations.

[0020] Validation coverage is a metric that measures the adequacy of validation in the diagnostic process, with a value ranging from [0,1]. It can be calculated by dividing the number of validation dimensions already covered in the current diagnostic process by the total number of dimensions that should be validated.

[0021] Historical diagnostic accuracy reflects long-term diagnostic reliability. Its initial value can be the number of correct historical diagnoses for the current fault type divided by the total number of historical diagnoses for that type of fault. This value can be dynamically updated subsequently. The statistical period can be set according to operational needs, such as the past 30 days or all historical data.

[0022] In related technologies, automated operation and maintenance (O&M) places extremely high demands on the reliability of root cause conclusions. A single posterior probability only reflects the strength of real-time evidence, neglecting the two crucial dimensions of "sufficient validation" and "reliable historical diagnoses." When validation is insufficient, a high posterior probability may stem from chance; for fault types with low historical accuracy, the credibility of real-time conclusions needs to be compromised. Currently, root cause localization results lack unified and interpretable confidence metrics, making it difficult to support automated O&M decisions. Furthermore, confidence levels for different fault types cannot be compared horizontally; insufficient evidence can easily lead to overconfidence, increasing the risk of operational errors; and validation sufficiency relies on subjective experience and cannot be objectively measured.

[0023] In view of this, this application provides a root cause confidence analysis method and related equipment based on multi-dimensional evidence fusion. This scheme receives the target fault root cause and its probability value from the diagnostic output of a root cause localization system for a fault event. The root cause probability value is the posterior probability of network fault diagnosis after a testing task. The scheme performs verification dimension coverage analysis on the fault event diagnosis process to obtain the verification coverage rate, and statistically analyzes historical diagnostic data for the fault type indicated by the fault event to determine the historical diagnostic accuracy rate. Then, it determines the confidence of the target fault root cause based on the root cause probability value, verification coverage rate, and the historical diagnostic accuracy rate. This scheme quantifies root cause confidence by combining verification coverage rate and historical diagnostic accuracy rate on the basis of the root cause posterior probability. The verification coverage rate represents the sufficiency of the current diagnostic process verification, and the historical diagnostic accuracy rate avoids the randomness of the current root cause localization, thus avoiding the one-sidedness of a single dimension, improving the reliability of root cause confidence quantification, and consequently improving the accuracy and efficiency of network automated operation and maintenance decisions.

[0024] The root cause confidence analysis method based on multi-dimensional evidence fusion provided in this application relates to the field of intelligent network operation and maintenance technology. This root cause confidence analysis method based on multi-dimensional evidence fusion can be applied to terminals or servers. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network.

[0025] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0026] The method described in this application is applicable to root cause reliability assessment scenarios for various network faults (link failures, configuration errors, source station failures, etc.). The network elements involved include: a root cause localization system, a knowledge graph database, a confidence calculation unit, and an operation and maintenance decision-making system. The confidence calculation unit interfaces with the root cause localization system to obtain posterior probabilities, reads historical data from the knowledge graph database, and outputs the confidence score to the decision-making system.

[0027] Figure 1 This is an optional flowchart of the root cause confidence analysis method based on multi-dimensional evidence fusion provided in the embodiments of this application. Figure 1 The method may include, but is not limited to, steps S101 to S104.

[0028] S101, Receive the target fault root cause and its root cause probability value output by the root cause localization system for the fault event diagnosis. The root cause probability value is the posterior probability of network fault diagnosis after dialing test task. S102, Perform a verification dimension coverage analysis on the diagnostic process for fault events to obtain the verification coverage; the verification coverage indicates the adequacy of the verification of the diagnostic process. S103, Perform historical diagnostic data statistics on the fault types indicated by the fault events to determine the historical diagnostic accuracy rate; S104. Determine the root cause confidence of the target fault root cause based on the root cause probability value, validation coverage, and historical diagnostic accuracy.

[0029] Steps S101 to S104 as shown in the embodiments of this application quantify the root cause confidence by combining the verification coverage and historical diagnostic accuracy on the basis of the root cause posterior probability. The verification coverage represents the sufficiency of the verification of the current diagnostic process, and the historical diagnostic accuracy avoids the randomness of the current root cause location, thereby avoiding the one-sidedness of a single dimension, improving the reliability of the root cause confidence quantification, and thus improving the accuracy of network automated operation and maintenance decisions and operation and maintenance efficiency.

[0030] In step S101 of some embodiments, the target fault root cause and its root cause probability value are received from the diagnostic output of the root cause localization system for the fault event. The root cause probability value is the posterior probability of network fault diagnosis after the dialing test task, which can measure the sufficiency of evidence for locating the target fault root cause in the diagnostic process. The target fault root cause and its root cause probability value can come from the output of any kind of root cause localization system, that is, the target fault root cause and its root cause probability value can be obtained by any kind of network fault localization method. The embodiments of this application do not impose specific limitations.

[0031] In some embodiments, please refer to Figure 2The root cause localization system in step S101 can diagnose fault events through, but is not limited to, the following steps: S201, determine multiple candidate root causes of failure based on the failure event, and initialize the root cause probability distribution of multiple candidate root causes of failure; S202, Calculate the dynamic task value of each test task in the task set based on the root cause probability distribution and the conditional probability of each test task in the task set under the observation results of different root causes of failure. S203, Select the highest dynamic task value from the task set for execution to obtain the current observation results of the task. S204, Update the root cause probability distribution based on the current observation results; S205, determine whether the root cause detection convergence condition has been met based on the root cause probability distribution or the number of task executions; S206, if the current root cause detection convergence condition is met, select the candidate fault root cause with the highest root cause probability value as the target fault root cause according to the current root cause probability distribution and output the root cause probability value of the target fault root cause; otherwise, return to step S202.

[0032] In this embodiment, the root cause localization system calculates the task value by combining the conditional probabilities of tasks under the observation results of different root causes of faults during the task orchestration process. Based on this, after selecting a suitable test task, it iteratively calculates the task value based on the actual fault observation results and selects a more suitable task for execution, realizing dynamic task orchestration and improving the flexibility of test task orchestration. At the same time, it sets convergence conditions for the detection process, improves diagnostic efficiency, and reduces resource waste. In each iteration, the root cause localization system updates the posterior probability of each candidate root cause based on the observation results of the test task, which can improve the accuracy of the output target fault root cause and its posterior probability.

[0033] In step S201 of some embodiments, the alarm access module receives real-time alarm data from an external alarm system, performs preprocessing such as standardization (unified field format, alarm type normalization) and deduplication, and then merges and aggregates similar alarm data from the same device or devices with direct dependencies based on a preset time window (default 60 seconds, configurable) and the device dependencies indicated in the knowledge graph, generating a single fault event. This fault event includes core information such as event identifier, involved devices, and associated services. This embodiment uses a preset time window and aggregation rules associated with device dependencies to merge similar alarms from the same device or devices with direct dependencies, generating a single fault event. The aggregation result can then be directly linked to fault hypothesis matching and initial prior probability assignment, solving the problems of alarm redundancy, disconnect between diagnostic input and subsequent processes, and numerous interference items, providing accurate input for subsequent diagnostic processes and reducing invalid calculations.

[0034] Based on the fault events, possible candidate root causes and their historical occurrence frequencies are queried from the knowledge graph database. The historical occurrence frequencies are normalized to obtain the initial prior probability of each candidate root cause, i.e., the root cause probability value, which represents the initial confidence probability of the fault hypothesis. The initial prior probabilities of each candidate root cause form the root cause probability distribution. This embodiment generates fault root cause hypotheses by linking fault events and determines their initial prior probabilities based on the historical occurrence frequencies of each root cause hypothesis. This improves the accuracy of root cause probability value initialization, reduces the number of subsequent iterations, and improves diagnostic efficiency.

[0035] In other embodiments, this embodiment also sets cold start processing rules. If there is no historical frequency data of the corresponding fault in the knowledge graph, an initial prior probability of equal value can be assigned to each candidate fault based on expert experience, or a value can be assigned according to the general industry occurrence probability of the fault type.

[0036] In step S202 of some embodiments, multiple testing tasks are selected according to the fault event, and testing tasks that have been successfully executed and those that are unavailable are removed from the multiple testing tasks to form a task set; for each testing task in the task set, the posterior probability of the testing task under different observation results is calculated based on the conditional probability and root cause probability distribution of the testing task under different observation results, and the dynamic task value of the testing task is calculated based on the posterior probability under different observation results and the execution cost of the testing task.

[0037] Specifically, unavailable test tasks refer to test tasks that fail to execute due to system-level anomalies. That is, if a task fails to return a valid result after execution due to probe malfunction, timeout, or other anomalies, it is marked as unavailable. Unavailable tasks will not appear in the subsequent set of tasks awaiting orchestration, and therefore their task value will not be calculated for repeated execution, nor will they participate in root cause distribution probability updates or be included in the maximum task count. By excluding test tasks with execution anomalies, problems such as interruptions in subsequent diagnostic processes and poor project availability can be avoided, ensuring the continuity and stability of fault diagnosis. Successful execution means that the test task instruction is normally issued, executed, and returns a clear business observation result, regardless of whether the returned result is positive (e.g., Ping successful) or negative (e.g., Ping timeout).

[0038] Obtain the execution cost and conditional probability of each task in the above task set under different failure assumptions; calculate the entropy value H(P) based on the current root cause probability distribution to measure the uncertainty of the current root cause of the failure; for each candidate test task, calculate the marginal probability, posterior entropy, conditional entropy, and information gain in sequence, and finally calculate the dynamic task value of each task using the formula Value(T)=IG(T) / Cost(T). IG(T) represents the information gain of test task T, and Cost(T) represents the execution cost of test task T.

[0039] In step S203 of some embodiments, the testing task with the highest dynamic task value in the task set is selected and sent to the distributed testing executor cluster. Further, the following fault-tolerant processing rules can be set to determine the next operation: If the currently selected test task is successfully executed and returns a valid business observation result, proceed to step S204; If a task fails to return a valid business observation result (regardless of the underlying reason), the task is marked as unavailable, and no belief update is performed in this round. The task with the second highest current value score is automatically selected for execution. If the second highest value task also fails to return a valid result, this fault tolerance rule is repeated. If all candidate test tasks are marked as unavailable, terminate the diagnostic process directly, record the exception log, and report to the operations and maintenance personnel for manual intervention.

[0040] By adopting a fault-tolerant replacement strategy for testing tasks, the problem of diagnostic process interruption and poor engineering availability caused by abnormal execution of testing tasks in existing technologies is solved, ensuring the continuity and stability of fault diagnosis.

[0041] In step S204 of some embodiments, the conditional probabilities of the current round of testing tasks under the current observation results of different root causes of faults are obtained; based on the obtained multiple conditional probabilities, the posterior probability of each candidate root cause of fault under the current observation results of the testing task is calculated using Bayes' theorem; and the root cause probability distribution is updated based on the posterior probability of each candidate root cause of fault. This embodiment is based on the fault hypothesis-testing task conditional probability table pre-stored in the knowledge graph. Using Bayes' theorem, the posterior probability of each fault hypothesis is updated in real time with the valid observation results returned by the testing task. The updated probability distribution is used as the calculation benchmark for the value assessment of the next round of tasks. This solves the problems of existing technologies where the root causes of faults cannot be quantified and converged, rely on static rules, and have poor diagnostic accuracy. It achieves dynamic focusing of the root causes of faults, and the entire diagnostic process is quantifiable and interpretable.

[0042] In steps S205 to S206 of some embodiments, it can be determined whether the detection convergence condition has been met based on the root cause distribution probability or the number of tasks executed. The diagnostic decision engine verifies whether any of the following termination conditions are met: Condition 1: The updated root cause distribution probability has a root cause probability value (i.e., posterior probability) of a certain fault hypothesis ≥ the preset termination threshold (default 0.8). Condition 2: The number of successfully executed test tasks has reached the preset maximum number of tasks (default 5 times, configurable). If any termination condition is met, select the candidate fault root cause with the highest root cause probability value as the target fault root cause based on the current root cause probability distribution and output the root cause probability value of the target fault root cause; if not met, return to step S202, recalculate the value score of the remaining tasks based on the updated probability distribution, and start the next round of iteration.

[0043] In some embodiments, the root cause localization system is further used to obtain the verification result of the target fault root cause; if the verification result is valid, the conditional probability of the successfully executed test task in this fault event under the target fault root cause is updated based on the forgetting factor.

[0044] In this embodiment, a valid verification result means that the action is only taken when the root cause conclusion is confirmed to be valid. Validity determination rules: 1. Root causes manually reviewed and marked as correct; 2. Root causes with high confidence that are terminated from output, and whose conclusion is not overturned by subsequent fault recovery verification and business recovery results, are considered valid; Root causes that have reached the maximum number of tasks and are used as a fallback output do not automatically trigger knowledge updates and must be manually confirmed as valid before the update can be executed; If the root cause conclusion is subsequently determined to be an incorrect diagnosis, this update will not be executed; If a conditional probability update has been completed, the corresponding probability value must be rolled back to its original value before this update to avoid erroneous data contamination.

[0045] The observation results of all successfully executed testing tasks in this diagnosis are extracted. Based on an update formula with a forgetting factor, the conditional probabilities corresponding to the confirmed root cause hypothesis in the knowledge graph are updated. Simultaneously, the probabilities of complementary results are updated to ensure probability normalization. The update formula can be an exponentially weighted moving average method with a forgetting factor; the specific update formula will be explained in subsequent embodiments.

[0046] In some embodiments, the complete process of the root cause localization system for diagnosing backbone link congestion faults is as follows: Scenario Description: In a certain operator's backbone network, the network management system received three alarms in succession within 60 seconds: "CE01 BGP neighbor reset", "PE02 to CE01 link utilization > 90%", and "Multiple video services are stuck". The root cause of the fault needs to be diagnosed using this method.

[0047] The preceding data includes: Historical frequency of knowledge graph failures: 50 times due to link failures, 30 times due to origin server failures, and 20 times due to BGP configuration errors. The preset termination threshold is 0.8, and the maximum number of tasks is 5. The predefined testing tasks, costs, and conditional probabilities are shown in Table 1: Table 1

[0048] The diagnostic execution process is as follows: Step 1: Alarm Access and Aggregation The alarm access module receives the above three alarms, completes standardization and deduplication, and merges them through a 60-second time window and device dependency relationship to generate fault event EV001, which is then pushed to the diagnostic decision engine.

[0049] Step 2: Fault Hypothesis Generation and Initial Probability Assignment: The diagnostic decision engine queries the knowledge graph for historical frequencies of similar faults, normalizes the frequencies, and obtains three candidate fault hypotheses (in this embodiment, these refer to candidate fault root causes H). i The initial prior probability of ) H1 (CE01-PE02 link congestion / failure): 50 / (50+30+20)=0.5; H2 (Video source station egress congestion): 30 / (50+30+20)=0.3; H3 (CE01BGP configuration error): 20 / (50+30+20)=0.2; The current fault hypothesis probability distribution is P=[p1,p2,p3]=[0.5,0.3,0.2]. There are no hypotheses that meet the termination condition, so the iterative diagnosis process begins.

[0050] First iteration: Value assessment → Task execution → Belief update (root cause probability distribution update) → Termination judgment.

[0051] 1. Calculate the current entropy H(P). The entropy formula is expressed as follows: ; in, It is the first The initial prior probabilities of each candidate fault hypothesis.

[0052] Substituting the values, we calculate: H(P) = -[0.5 × log₂₀.₅ + 0.3 × log₂₀.₃ + 0.2 × log₂₀.₂] = -[0.5 × (-1) + 0.3 × (-1.737) + 0.2 × (-2.322)] = -[-0.5 - 0.5211 - 0.4644] = 1.4855; 2. Taking the test task T1 as an example, the complete process of its task value scoring is as follows: (1) Calculate the marginal probability of the result T1; The marginal probability formula is expressed as follows: ; in, It is the first The initial prior probabilities of the candidate fault hypotheses Based on candidate failure assumptions Under the given conditions, the execution result of the test task T1 is: The conditional probability can be obtained by looking up Table 1.

[0053] Marginal probability of success: P(success) = p1 P(success|H1)+p2 P(success|H2)+p3 P(success|H3) = 0.5 × 0.7 + 0.3 × 0.9 + 0.2 × 0.9 = 0.35 + 0.27 + 0.18 = 0.80; The marginal probability of failure is: P(failure) = 1 - P(success) = 0.20.

[0054] (2) Calculate the posterior probability and posterior entropy for different outcomes (success and failure): The posterior probabilities (Bayes' theorem) for a successful outcome (under different candidate failure hypotheses) are as follows: ; in, Candidate fault hypothesis under successful observation results The posterior entropy, This represents the marginal probability of a successful observation.

[0055] P(H1|Success) = [P(Success|H1)] p1] / P(success) = (0.7 × 0.5) / 0.80 = 0.4375; P(H2|Success) = [P(Success|H2)] p2] / P(success) = (0.9 × 0.3) / 0.80 = 0.3375; P(H3|Success) = [P(Success|H3)] p3] / P(success) = (0.9 × 0.2) / 0.80 = 0.2250; Among them, the posterior entropy under successful observation results: H(P|success) = -[0.4375×log20.4375+0.3375×log20.3375+0.2250×log20.2250]≈1.543; Posterior probability of a failed observation: P(H1|failure) = (0.3 × 0.5) / 0.20 = 0.75; P(H2|failure) = (0.1 × 0.3) / 0.20 = 0.15; P(H3|failure) = (0.1 × 0.2) / 0.20 = 0.10; Posterior entropy under failed observations: H(P|failure) = -[0.75×log20.75 + 0.15×log20.15 + 0.10×log20.10] ≈ 1.014.

[0056] (3) Calculate the conditional entropy of the test task T1: According to the conditional entropy formula: H(P|T1) = P(success) H(P|Success) + P(Failure) H(P|failure); Substituting the values: H(P|T1)=0.80×1.543+0.20×1.014=1.2344+0.2028=1.4372.

[0057] (4) Calculate the information gain of the test task T1: According to the information gain formula: IG(T1) = H(P) - H(P|T1); Substituting the values: IG(T1) = 1.4855 - 1.4372 = 0.0483.

[0058] (5) Calculate the task value score of the test task T1: According to the task value scoring formula: Value(T1)=IG(T1) / Cost(T1), where Cost(T1) is the task cost and T1 cost is 1, therefore Value(T1)=0.0483 / 1=0.0483.

[0059] 3. Value score calculation for other tasks (same as T1 calculation logic). The calculation results for different testing tasks are shown in Table 2.

[0060] Table 2

[0061] 4. Optimal task execution and fault tolerance.

[0062] Comparing the value scores of each task, T1 has the highest score of 0.0483, so T1 is executed in the first round. In this example, T1 executes normally and returns a valid result of "success".

[0063] 5. Bayesian belief update (i.e., root cause distribution probability update).

[0064] Based on the "success" result of T1, the calculation has been completed using the Bayesian formula mentioned above. The updated probability distribution of the failure hypothesis is: P=[0.4375,0.3375,0.2250] 6. Termination condition determination.

[0065] The current maximum probability is 0.4375, which is less than the preset termination threshold of 0.8; the number of tasks executed is 1, which is less than the maximum number of tasks of 5. The termination conditions are not met, and the second round of iteration will begin.

[0066] Second iteration: Re-evaluate based on new probabilities → Task execution → Belief update → Termination judgment.

[0067] 1. Recalculate the value score of the remaining tasks.

[0068] Based on the updated probability distribution [0.4375, 0.3375, 0.2250], and following the complete calculation logic of the first round, the value scores for T2, T3, T4, and T5 were recalculated, and the results are shown in Table 3. Table 3

[0069] 2. Tasks will be selected based on their merit.

[0070] T2 has the highest value score of 0.042 among the remaining tasks, so it is executed in the second round. In this example, T2 executes normally and returns a valid result "failure".

[0071] 3. Bayesian belief renewal.

[0072] The current prior probability P = [0.4375, 0.3375, 0.2250].

[0073] The conditional probabilities of T2 (failure scenario): P(failure|H1)=0.7, P(failure|H2)=0.1, P(failure|H3)=0.2; Step 1: Calculate the marginal probability of failure.

[0074] P(failure) = 0.4375 × 0.7 + 0.3375 × 0.1 + 0.2250 × 0.2 = 0.30625 + 0.03375 + 0.045 = 0.385; Step 2: Calculate the posterior probability of each hypothesis (Bayes' theorem).

[0075] P(H1|failure) = (0.4375 × 0.7) / 0.385 = 0.7955; P(H2|failure) = (0.3375 × 0.1) / 0.385 = 0.0877; P(H3|failure) = (0.2250 × 0.2) / 0.385 = 0.1169; The updated probability distribution is: P = [0.7955, 0.0877, 0.1169].

[0076] 4. Termination condition determination.

[0077] The current maximum probability is 0.7955, which is still less than the termination threshold of 0.8; the number of tasks executed is 2, which is less than 5. The termination condition is not met, so proceed to the third iteration.

[0078] Third iteration: Reassessment → Task execution → Belief update → Termination of judgment.

[0079] 1. Recalculate the value score of the remaining tasks.

[0080] Based on the current probability distribution [0.7955, 0.0877, 0.1169], the value scores for T3, T4, and T5 were recalculated, and the results are shown in Table 4. Table 4

[0081] 2. Tasks will be selected based on their merit.

[0082] T4 has the highest value score of 0.025 among the remaining tasks, so it is executed in the third round. In this example, T4 executes normally and returns a valid result "Path interrupted".

[0083] 3. Bayesian belief renewal.

[0084] The current prior probability P = [0.7955, 0.0877, 0.1169]; The conditional probabilities of T4 (interruption scenario): P(interruption|H1)=0.8, P(interruption|H2)=0.2, P(interruption|H3)=0.2.

[0085] Step 1: Calculate the marginal probability of the interruption result.

[0086] P(interruption) = 0.7955 × 0.8 + 0.0877 × 0.2 + 0.1169 × 0.2 = 0.6364 + 0.01754 + 0.02338 = 0.67732.

[0087] Step 2: Calculate the posterior probability of each hypothesis.

[0088] P(H1|Interruption) = (0.7955 × 0.8) / 0.67732 = 0.9396; P(H2|Interruption) = (0.0877 × 0.2) / 0.67732 = 0.0259; P(H3|Interrupt) = (0.1169 × 0.2) / 0.67732 = 0.0345; The updated probability distribution is: P = [0.9396, 0.0259, 0.0345].

[0089] 4. Termination condition determination The current maximum probability = 0.9396 ≥ the termination threshold of 0.8, which satisfies the termination condition, and the iteration loop ends.

[0090] Step 7: Root cause output.

[0091] Root cause: H1 (CE01-PE02 link congestion / failure), posterior probability 0.9396.

[0092] Step 8: Knowledge Update.

[0093] The diagnosis ultimately confirmed that the true root cause was H1 (CE01-PE02 link congestion). The T4 task observed an "interruption" result, so an update was performed on P(interruption|H1) under the H1 assumption.

[0094] Updated formula: ; in, Forgetting factor, This represents the number of root cause observations that match the target fault in this process. =0.95, =0.8, n=1 (1 interruption was observed this time), substitute into the numerical calculation: P(interruption|H1)_new=(0.95×0.8+1) / (0.95+1)=(0.76+1) / 1.95=1.76 / 1.95≈0.903.

[0095] The system replaces the old value in the knowledge graph with this new value, and at the same time updates the probability of the complementary result P(complete|H1)=1-0.903=0.097 to ensure probability normalization.

[0096] In step S102 of some embodiments, the verification coverage C of this diagnosis is obtained. The verification coverage C is a real number between [0,1], representing the proportion of the dimensions that have been verified to the dimensions that should be verified during the diagnosis process. If it cannot be calculated due to lack of templates or task records, a default value can be taken according to the operation and maintenance strategy: the default value of 0.5 is suitable for the scenario of "no explicit verification dimension", and the default value of 1.0 is suitable for the scenario of "mandatory automatic decision-making". The specific selection is determined by the operation and maintenance risk preference.

[0097] In some embodiments, please refer to Figure 3 Step S102 may include, but is not limited to, the following steps: S301, determine the corresponding initial verification dimension list based on the fault type indicated by the fault event, and determine the device context based on the device involved in the fault event; S302, trim the initial verification dimension list according to the device context to obtain the target verification dimension list; S303, obtain the test tasks that have been successfully executed in the diagnostic process for the fault event, and then query the task dimension mapping table based on the test tasks to determine the verification dimensions that have been covered. S304. Perform statistical analysis on the verification dimensions already covered in the target verification dimension list to determine the verification coverage rate.

[0098] In this embodiment, an initial verification dimension list is determined based on the fault type indicated by the fault event, and a device context is determined based on the devices involved in the fault event. Then, the initial verification dimension list is pruned according to the device context to obtain a target verification dimension list. This target verification dimension list is adapted to the specific device capabilities, avoids interference from invalid dimensions, accurately provides the dimensions to be verified, and improves diagnostic efficiency. Successfully executed test tasks in the diagnostic process for the fault event are obtained (the definition of a successfully executed test task is the same as in the previous embodiment). Then, the task dimension mapping table is queried based on the test task to determine the covered verification dimensions. Finally, statistical analysis is performed on the covered verification dimensions in the target verification dimension list to determine the verification coverage rate, achieving a reliable measurement of the adequacy of verification in the fault diagnosis process.

[0099] In step S301 of some embodiments, the fault event is obtained based on network alarm data, which indicates one or more fault types of the current fault event. The corresponding initial verification dimension list can be determined by querying the fault type. The initial verification dimension list defines the verification dimensions that should be completed when diagnosing the fault event. The fault event-related data also indicates the network devices involved in this network fault and their context. The device context includes device roles, supported management protocols, network topology location, etc.

[0100] Specifically, the system predefines standard verification dimension templates for each fault type. Each verification dimension includes information such as dimension ID, dimension description, default verification method, and applicable conditions. Standard verification dimension templates can be obtained from expert experience or historical data mining and support dynamic updates. Fault types can be flexibly defined and expanded according to actual operation and maintenance scenarios, and are not limited to the types listed in this embodiment.

[0101] When a fault event has only one fault type, the corresponding standard verification dimension template is queried according to the fault type, and the standard verification dimension template is the initial verification dimension list.

[0102] When a fault event involves multiple fault types, the system merges the standard verification dimension templates corresponding to these fault types and removes duplicate verification dimensions to form an initial verification dimension list. In another example, the system can directly merge the standard verification dimension templates corresponding to multiple fault types to form the initial verification dimension list. Subsequently, for each fault type in the initial verification dimension list, the standard verification dimension template is instantiated and trimmed based on the corresponding device context. All trimmed dimension lists are then merged, and duplicate dimensions are removed to obtain the target verification dimension list. It is understood that if the verification method or applicable conditions for the same dimension differ in different templates, all differing items are retained as independent dimensions, and coverage is subsequently calculated separately.

[0103] The criteria for determining dimension deduplication are as follows: if the core verification object of two verification dimensions is the same (e.g., both are "device survival"), and the difference in verification methods does not change their essential verification objective, then they are considered as the same dimension and deduplicated; if the difference in verification methods causes an essential change in the verification objective (e.g., one verifies "device survival" and the other verifies "device performance"), then they are retained as independent dimensions.

[0104] This embodiment provides a predefined standard verification dimension template for each type of fault, offering a unified verification checklist for different fault types, avoiding bias from human experience, and improving the standardization and reproducibility of the diagnostic process.

[0105] In step S302 of some embodiments, inapplicable dimensions are trimmed according to the device role, supported protocols, topology location and applicable conditions of the verification dimensions in the device context, and a list of dimensions to be verified (i.e., the target verification dimension list) is dynamically generated to adapt to specific device capabilities, avoid interference from invalid dimensions, ensure the accuracy of the verification list, and improve diagnostic efficiency.

[0106] Specifically, the initial verification dimension list is pruned according to the device role, supported protocols, and network topology location indicated by the device context to obtain an intermediate verification dimension list. Based on the applicable conditions indicated in the intermediate verification dimension list, the verification data related to the device context is verified to see if it meets the applicable conditions. If it does not meet the applicable conditions, the verification dimension corresponding to the applicable conditions is deleted from the intermediate verification dimension list to obtain the target verification dimension list.

[0107] For example, the fault template is trimmed according to the device context. The core actions include: Remove dimensions that do not support the protocol of the device (e.g., remove the "interface status" dimension if SNMP is not supported). Remove dimensions that are irrelevant to the device role (e.g., edge devices do not need to verify the backbone link). Based on the predefined applicable conditions for each verification dimension, the relevant verification data queried based on the device context is validated. If the current fault scenario represented by the verification data does not meet the applicable condition (e.g., "related service does not exist"), the dimension is removed from the initial verification dimension list. The verification data for the applicable conditions comes from fault alarm information of devices related to the device context, the device context itself, the configuration management database (CMDB), and other basic operational data related to the faulty device. All applicable dimensions are retained to generate a verification dimension list for this diagnostic target, and the total number of dimensions after instantiation is recorded. .

[0108] It should be noted that static validation of the applicable conditions for dimensions is performed during pruning, meaning that the basic operational data at the time of pruning is used as the standard. Changes in the basic operational data regarding the applicable conditions during task execution (such as the temporary shutdown of related services) will not affect the already generated list of target validation dimensions. Accordingly, after pruning is completed, The process remains constant throughout the entire diagnostic cycle; regardless of subsequent changes in the underlying data regarding the device context and applicable conditions, the trimming and modification will not be re-executed. Static validation rules ensure consistency in coverage calculations, avoiding statistical biases caused by dynamic changes.

[0109] In some embodiments, S303, the task dimension mapping table is pre-established and supports dynamic expansion. The task dimension mapping table can adopt a many-to-many relationship design, that is, one task can be associated with multiple dimensions, and one dimension can be covered by multiple tasks. In the diagnostic process for fault events, the pre-established task dimension mapping table is queried based on the successfully executed test tasks to determine the covered verification dimensions. The covered verification dimensions in the target verification dimension list can be marked for subsequent statistics.

[0110] Specifically, for each successfully executed test task, the task dimension mapping table is queried to determine the verification dimension associated with the test task, obtaining the query result of the test task. The query results of each successfully executed test task are then deduplicated to determine the covered verification dimensions. In this embodiment, for each successfully executed test task, the mapping table is queried to obtain its associated verification dimensions, and these verification dimensions are marked as covered in the target verification dimension list. If multiple test tasks cover the same verification dimension, the same verification dimension is deduplicated, meaning that verification dimensions covered by multiple test tasks in the target verification dimension list are only marked once. This dimension deduplication rule avoids subsequent errors in the number of covered dimensions. Duplicate statistics are not included. Tasks that fail to execute (i.e., tasks that are not completed due to system-level exceptions) are not associated with any validation dimensions and are not included in the statistics of covered dimensions.

[0111] Understandably, the verification dimension coverage marker for the same fault event remains in effect throughout the entire diagnostic process and will not be reset due to supplementary task execution or task retries. Once a dimension is marked as covered, it remains permanently effective throughout the entire fault event's diagnostic cycle and will not be reset due to subsequent execution anomalies in the same dimension (including system-level anomalies causing task incompleteness). The retry strategy for a single probing task does not affect the verification dimension coverage marker and coverage statistics logic. Only when the result of an executed task is manually determined to be invalid or erroneous can the corresponding dimension's coverage marker be manually reset, and the number of covered dimensions and verification coverage be recalculated.

[0112] This embodiment establishes a task dimension mapping table, counts the dimensions covered by executed testing tasks, and obtains the number of covered dimensions through deduplication rules, achieving automatic statistics of covered dimensions. It supports deduplication of multiple tasks covering the same dimension, improving statistical accuracy. The many-to-many mapping relationship allows multiple dimensions to be verified simultaneously in a single task execution, avoiding dimension coverage omissions and redundant task execution caused by one-to-one mapping. The rule of marking permanent effect ensures the stability of statistical results, and the manual intervention rule provides anomaly handling capabilities.

[0113] In step S304 of some embodiments, statistical analysis is performed on the verification dimensions already covered in the target verification dimension list to determine the verification coverage rate. The verification coverage rate is used to measure the adequacy of the verification in the current diagnostic process.

[0114] Specifically, statistical analysis is performed on the verification dimensions already covered in the target verification dimension list to determine the number of covered dimensions; based on the number of covered dimensions and the total number of dimensions in the target verification dimension list, the basic coverage rate used to measure the verification coverage rate is calculated.

[0115] For example, the base coverage is calculated as the validation coverage according to the following rules: like ,but ; The number of dimensions already covered. This represents the total number of dimensions. like Then, the value retrieval method is selected according to the business rules: If no verification method is available due to device limitations (e.g., the device does not support any protocol), the coverage is recorded as 1.0, indicating that further verification is not possible under the current conditions. If the fault type itself does not require verification in this scenario (e.g., edge devices do not need to verify backbone links), it is marked as "not applicable".

[0116] This embodiment provides objective and reproducible diagnostic process validation adequacy metrics, and clarifies extreme scenarios ( The processing rules ensure the integrity of the solution and avoid statistical ambiguity in boundary cases.

[0117] Furthermore, when the verification coverage (such as basic coverage) falls below a preset threshold, the system can automatically match the corresponding probing tasks based on the uncovered dimensions, generate supplementary diagnostic task suggestions, and push them to the upstream diagnostic decision engine, which will then decide whether to execute the supplementary tasks and their execution order. After the supplementary tasks are successfully executed, the system updates the covered verification dimensions in real time, thereby updating the verification coverage.

[0118] The system updates the covered dimension markers and verification coverage in real time based on the execution progress of the testing tasks, and synchronizes this information to the diagnostic management interface. This allows maintenance personnel to monitor the adequacy of the diagnostics in real time and trigger supplementary diagnostics in advance. If the fault diagnosis process is terminated or closed midway, the system calculates the current verification coverage based on the tasks that have been successfully executed, and synchronizes this information to the fault work order archive.

[0119] Based on historical diagnostic data, standard verification dimension templates are dynamically optimized. For example, frequently missed verification dimensions are automatically added to the corresponding fault type's standard verification dimension template based on statistics from historical successful diagnostic cases; or, based on the frequency of clipping in device context, the applicability conditions of verification dimensions are dynamically adjusted. If a verification dimension is clipped in 80% of scenarios (80% is an example threshold, which can be flexibly adjusted according to actual operation and maintenance scenarios), then that verification dimension is marked as "non-core" or its weight is adjusted. Template optimizations must be manually reviewed and confirmed before taking effect to avoid verification standard deviations caused by automatic adjustments.

[0120] In step S103 of some embodiments, historical diagnostic data is statistically analyzed for the fault type indicated by the fault event to determine the historical diagnostic accuracy. During the root cause confidence analysis of the initial diagnostic process, the historical diagnostic accuracy for the fault type can be determined by counting the number of correct historical diagnoses and the number of historical occurrences for that fault type, and dividing the number of correct historical diagnoses by the number of historical occurrences. After the diagnostic process is completed, the historical diagnostic accuracy can be updated based on diagnostic verification feedback and stored in the knowledge graph library. In the root cause confidence analysis of the next diagnostic process, if the diagnostic process also involves the same fault type, the historical diagnostic accuracy of the fault type updated in the previous round can be directly read from the knowledge graph library for root cause confidence analysis, and the historical diagnostic accuracy of the fault type in the knowledge graph library is updated again based on the diagnostic verification feedback of the current diagnostic process. Subsequently, the historical diagnostic accuracy used for root cause confidence analyses of other diagnostic processes with the same fault type is obtained from the knowledge graph library.

[0121] In some embodiments, please refer to Figure 4 Step S103 may include, but is not limited to, the following steps: S401, query the historical occurrence count and historical correct diagnosis count of the fault type indicated by the fault event; S402, determine the historical diagnostic accuracy rate based on the number of correct diagnoses and the number of occurrences in the past; S403 updates the historical diagnostic accuracy in response to diagnostic verification feedback on fault events.

[0122] In this embodiment, the historical diagnostic accuracy of this type of fault is read from the knowledge graph database. : ; in, This indicates the historical occurrence count of the current fault type. This indicates the number of times the current fault type has been correctly diagnosed in the past.

[0123] The historical diagnostic accuracy can be dynamically updated with each diagnostic result. The update formula uses an exponentially weighted moving average with a forgetting factor. The update formula for the historical diagnostic accuracy is expressed as follows: ; in, This indicates the updated historical diagnostic accuracy. This indicates the historical diagnostic accuracy rate before the update. This represents the forgetting factor, which can be set to 0.95 by default, consistent with the forgetting factor value in the conditional probability update formula of the root cause localization system mentioned above.

[0124] This value indicates the correctness of the diagnosis. It is determined based on the diagnostic verification feedback of the fault event. This feedback can be obtained through manual confirmation, automatic repair verification, or subsequent cross-validation. It indicates whether the root cause conclusion of the diagnosis is correct; 1 represents correct, and 0 represents incorrect. The specific methods for obtaining diagnostic verification feedback are explained below: Manual confirmation: Operations and maintenance personnel mark the diagnostic results as correct through the feedback interface; Automatic repair verification: After the system performs the repair operation based on the root cause, it verifies whether the fault has been eliminated by dialing again. If the fault has been eliminated, it is judged as correct; otherwise, it is judged as incorrect. Cross-validation: Combine subsequent diagnostic results or third-party monitoring data for comprehensive judgment. The comprehensive judgment can be based on confidence thresholds.

[0125] This represents the number of valid observations for the same fault hypothesis (i.e., the root cause) during this diagnosis, typically 1. If the same fault is tested multiple times during the same diagnosis, the actual number of observations can be used. (Formula) The number of times the impact of this observation is used to weight the data, so that the system can flexibly adapt to different observation frequencies and scenarios, and the more recent the data, the greater the weight.

[0126] In step S104 of some embodiments, based on the root cause probability value Validation coverage and historical diagnostic accuracy Determine the root cause confidence level of the target failure root cause. : .

[0127] In some embodiments, please refer to Figure 5 The root cause confidence analysis method based on multi-dimensional evidence fusion in this application may also include, but is not limited to, the following steps: S501, determine the corresponding confidence threshold based on the fault type, service type, or operation and maintenance strategy of the fault event; S502, when the root cause confidence level is greater than or equal to the confidence threshold, perform automatic operation and maintenance based on the target fault root cause; S503, when the root cause confidence level is less than the confidence level threshold, the root cause of the target fault is reviewed.

[0128] In this embodiment, the confidence threshold can be a default value, such as 0.6, or it can be dynamically configured within the range of [0,1] based on the fault type, business importance, and operation and maintenance strategy. Lowering the threshold will increase the proportion of automatic decision-making, but may also increase the risk of misoperation, and needs to be combined with an assessment of business importance. For example, the default threshold of 0.6 can be retained for core business faults, while it can be appropriately lowered for non-core business faults, but a fault rollback mechanism is required to deal with possible misjudgments.

[0129] like ≥0.6, perform automatic maintenance operations (such as alarm suppression and automatic repair) based on the root cause of the target fault; like If the value is less than 0.6, the root cause conclusion can be manually verified through a front-end visual interactive interface.

[0130] The methods of this application embodiment will now be described in detail with reference to specific scenarios.

[0131] Example 1: High confidence scenario of link failure confidence quantification.

[0132] Scenario: During a link fault diagnosis, the root cause localization system outputs root cause H1 (CE01-PE02 link congestion), with a posterior probability. =0.8383.

[0133] Step 1: Obtain the posterior probability. =0.8383.

[0134] Step 2: Obtain verification coverage. The standard verification dimension template for link failures can include three verification dimensions: Link connectivity (corresponding to task TracerouteCE01→PE02); Both devices are alive (corresponding task PingCE01Loopback); Impact on travel business (corresponding task: HTTPGet video source site); The above three verification dimensions have been fully covered by the tasks described above, therefore the coverage rate C = 1.0. Those skilled in the art will understand that verification coverage can also be determined through other methods; this embodiment only uses the results from those methods.

[0135] Step 3: Obtain historical accuracy. The knowledge graph shows the link fault historical diagnosis records: 90 correct, out of a total of 100, so A=0.90 (not yet updated at the time of diagnosis).

[0136] Step 4: Calculate the confidence level, Confidence = 0.8383 × 1.0 × 0.90 = 0.7545 ≈ 0.75.

[0137] Step 5: Decision output, confidence level 0.75 ≥ 0.6, it is recommended to automatically execute subsequent operations.

[0138] Step 6: Historical accuracy update (after diagnosis). Assuming the diagnosis is correct (e.g., confirmed by operations personnel), then... =1, n=1, update historical accuracy: =(0.95×0.90+1) / (0.95+1)=1.855 / 1.95≈0.951. This updated value will be used for subsequent diagnosis.

[0139] Example 2: Low confidence and insufficient verification coverage scenario for source station failure confidence quantification.

[0140] Scenario: During a source station fault diagnosis, the root cause localization system outputs root cause H2 (source station egress congestion), with a posterior probability. =0.81.

[0141] Step 1: Obtain the posterior probability. =0.81.

[0142] Step 2: Obtain verification coverage. As an example, the standard verification dimension template for origin server failures can include 4 verification dimensions: The origin site is reachable (corresponding to the HTTPGet video origin site for the task). Authoritative DNS (corresponding task: dig@authoritativeDNS); Local DNS (not overridden); Path quality (not covered); This diagnosis only executed HTTPGet and dig@authoritativeDNS, covering the first two dimensions, therefore... =2, =4, verification coverage C=2 / 4=0.5.

[0143] Step 3: Obtain historical accuracy. The historical accuracy of source station faults in the knowledge graph is A=0.88 (not yet updated at the time of diagnosis).

[0144] Step 4: Calculate the confidence level: Confidence = 0.81 × 0.5 × 0.88 = 0.3564 ≈ 0.36 Step 5: Decision output, root cause confidence level 0.36 < 0.6, manual review is recommended.

[0145] Example 3: Scenarios where threshold boundaries and historical accuracy updates affect the following scenarios.

[0146] Scenario A (Threshold Boundary): Posterior probability of a certain link fault diagnosis. =0.65, coverage C=0.9, historical accuracy A=0.95 (historical accuracy of link failure, not yet updated at the time of diagnosis).

[0147] Step 1: Obtain the posterior probability. =0.65.

[0148] Step 2: Obtain the verification coverage, C=0.9.

[0149] Step 3: Obtain the historical accuracy rate, A=0.95.

[0150] Step 4: Calculate the confidence level, Confidence = 0.65 × 0.9 × 0.95 = 0.55575 ≈ 0.556.

[0151] Step 5: Decision output, default threshold 0.6, confidence level 0.556 < 0.6, manual review is recommended. If the operation and maintenance strategy lowers the threshold to 0.5, it can be processed automatically (risk assessment required).

[0152] Scenario B (Impact of Historical Accuracy Update): Based on the update results of Example 1, the historical accuracy of the link failure has been updated from 0.90 to 0.951. Now, another link failure occurs. =0.85, C=1.0.

[0153] Step 1: Obtain the posterior probability. =0.85.

[0154] Step 2: Obtain the verification coverage, C=1.0.

[0155] Step 3: Obtain the historical accuracy rate, which has now been updated to A=0.951.

[0156] Step 4: Calculate the confidence level, Confidence = 0.85 × 1.0 × 0.951 = 0.808 ≈ 0.81.

[0157] Step 5: Decision output, confidence level 0.81 ≥ 0.6, automatic processing is recommended. This example shows that historical accuracy updates directly affect the confidence level of subsequent diagnoses.

[0158] Please refer to Figure 6 This application also provides a root cause confidence analysis system based on multi-dimensional evidence fusion, comprising: The first module is used to receive the target fault root cause and its root cause probability value from the diagnostic output of the root cause localization system for the fault event. The root cause probability value is the posterior probability of network fault diagnosis after the dial-up test task. The second module is used to perform verification dimension coverage analysis on the diagnostic process of fault events to obtain the verification coverage; the verification coverage indicates the adequacy of the verification of the diagnostic process. The third module is used to perform historical diagnostic data statistics on the fault types indicated by fault events and determine the historical diagnostic accuracy. The fourth module is used to determine the root cause confidence of the target fault root cause based on the root cause probability value, validation coverage, and historical diagnostic accuracy.

[0159] It is understood that the methods described in the above method embodiments are applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0160] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above. This electronic device can be any smart terminal, including a tablet computer.

[0161] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0162] Please see Figure 7 , Figure 7 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 901 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 902 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 902 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called and executed by the processor 901. The input / output interface 903 is used to implement information input and output; The communication interface 904 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 905 transmits information between various components of the device (e.g., processor 901, memory 902, input / output interface 903, and communication interface 904); The processor 901, memory 902, input / output interface 903, and communication interface 904 are connected to each other within the device via bus 905.

[0163] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0164] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0165] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0166] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0167] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0168] The root cause confidence analysis method and related equipment based on multi-dimensional evidence fusion provided in this application have at least one of the following beneficial effects: (1) Comprehensively assess the reliability of root causes to avoid the one-sidedness of a single dimension, due to the adoption of a unified approach. The definitions of C and A allow for direct comparison of confidence results for different fault types, solving the problem that existing solutions cannot horizontally compare the confidence levels of various fault types.

[0169] (2) Adopt As a confidence multiplier, C∈[0,1], diagnostic integrity is introduced into the reliability assessment.

[0170] (3) General formula for exponentially weighted smoothing update based on forgetting factor (α=0.95) This reflects long-term diagnostic performance and improves confidence stability.

[0171] (4) Preset default thresholds, support dynamic adjustment within the range of [0,1] according to fault type and business importance, and provide risk warnings (such as core business retaining default values, non-core business can be appropriately lowered but a rollback mechanism is required), clarify the boundaries of automated operation and maintenance, and adapt to different business scenarios.

[0172] (5) This system only requires inputting three values: posterior probability, coverage, and historical accuracy. No modification is needed to the underlying diagnostic process (e.g., when connecting to a third-party system, only API access is required). This reduces integration costs and improves the versatility of the solution.

[0173] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0174] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0175] The system embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0176] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0177] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or modules is not necessarily limited to those steps or modules explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0178] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0179] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of modules described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0180] The modules described above as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0181] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0182] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0183] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A root cause confidence analysis method based on multi-dimensional evidence fusion, characterized in that, Includes the following steps: Receive the target fault root cause and its root cause probability value from the diagnostic output of the root cause localization system for the fault event, wherein the root cause probability value is the posterior probability of network fault diagnosis performed through the dial-up test task. A verification dimension coverage analysis is performed on the diagnostic process for the aforementioned fault event to obtain the verification coverage; the verification coverage represents the adequacy of the verification of the diagnostic process. Statistical analysis of historical diagnostic data is performed on the fault types indicated by the fault events to determine the historical diagnostic accuracy rate; The root cause confidence level of the target fault root cause is determined based on the root cause probability value, the verification coverage, and the historical diagnostic accuracy.

2. The root cause confidence analysis method based on multi-dimensional evidence fusion according to claim 1, characterized in that, The root cause localization system diagnoses the fault event through the following steps: Based on the failure event, multiple candidate root causes of failure are identified, and the root cause probability distribution of the multiple candidate root causes of failure is initialized. Based on the root cause probability distribution and the conditional probability of each testing task in the task set under different root causes of failure, calculate the dynamic task value of each testing task in the task set. Select the highest dynamic task value from the task set for execution to obtain the current observation results of the task. Update the root cause probability distribution based on the current observation results; Determine whether the root cause detection convergence condition has been met based on the root cause probability distribution or the number of task executions. If the root cause detection convergence condition is met, the candidate fault root cause with the highest root cause probability value is selected as the target fault root cause and output according to the current root cause probability distribution, and the root cause probability value of the target fault root cause is output. Conversely, repeat the steps described above, which involve calculating the conditional probability of each test task in the task set under different root causes of failure based on the root cause probability distribution and the observation results.

3. The root cause confidence analysis method based on multi-dimensional evidence fusion according to claim 1, characterized in that, The diagnostic process for the fault event involves performing a verification dimension coverage analysis to obtain the verification coverage, including the following steps: The corresponding initial verification dimension list is determined based on the fault type indicated by the fault event, and the device context is determined based on the device involved in the fault event; Based on the device context, the initial verification dimension list is pruned to obtain the target verification dimension list; Obtain the test tasks that have been successfully executed in the diagnostic process for the fault event, and then query the task dimension mapping table based on the test tasks to determine the verification dimensions that have been covered. Perform statistical analysis on the verification dimensions already covered in the target verification dimension list to determine the verification coverage rate.

4. The root cause confidence analysis method based on multi-dimensional evidence fusion according to claim 1, characterized in that, The step of performing historical diagnostic data statistics on the fault types indicated by the fault events to determine the historical diagnostic accuracy includes the following steps: Query the historical occurrence count and historical correct diagnosis count of the fault type indicated by the fault event; The historical diagnostic accuracy rate is determined based on the number of correct historical diagnoses and the number of historical occurrences.

5. The root cause confidence analysis method based on multi-dimensional evidence fusion according to claim 4, characterized in that, The step of performing historical diagnostic data statistics on the fault types indicated by the fault events to determine the historical diagnostic accuracy also includes the following steps: In response to the diagnostic verification feedback of the fault event, the historical diagnostic accuracy is updated; the update formula for the historical diagnostic accuracy is as follows: ； in, This indicates the updated historical diagnostic accuracy. This indicates the historical diagnostic accuracy rate before the update. This value serves as an indicator of the accuracy of the diagnosis. This indicates the number of valid observations of the target fault root cause during this diagnosis. This represents the forgetting factor.

6. The root cause confidence analysis method based on multi-dimensional evidence fusion according to any one of claims 1 to 5, characterized in that, The root cause confidence analysis method based on multi-dimensional evidence fusion also includes the following steps: The corresponding confidence threshold is determined based on the fault type, service type, or operation and maintenance strategy of the fault event; If the root cause confidence level is greater than or equal to the confidence threshold, automatic operation and maintenance shall be performed based on the target fault root cause. If the confidence level of the root cause is less than the confidence threshold, the target root cause of the fault is reviewed.

7. A root cause confidence analysis system based on multi-dimensional evidence fusion, characterized in that, include: The first module is used to receive the target fault root cause and its root cause probability value output by the root cause localization system for the fault event diagnosis. The root cause probability value is the posterior probability of network fault diagnosis after dialing test task. The second module is used to perform a verification dimension coverage analysis on the diagnostic process of the fault event to obtain the verification coverage; the verification coverage represents the adequacy of the verification of the diagnostic process. The third module is used to perform historical diagnostic data statistics on the fault types indicated by the fault events and determine the historical diagnostic accuracy rate. The fourth module is used to determine the root cause confidence of the target fault root cause based on the root cause probability value, the verification coverage, and the historical diagnostic accuracy.

8. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of 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 method of any one of claims 1 to 6.

Images