Abnormality diagnosis method and device, electronic equipment, medium and program product

Abstract

The invention provides an abnormality diagnosis method and device, electronic equipment, a medium and a program product, and can be applied to the technical field of artificial intelligence. The method comprises the following steps: acquiring multi-modal log data of a target system, performing parallel analysis on the multi-modal log data by utilizing a plurality of agents with different diagnostic capabilities, and generating a plurality of root cause hypotheses and a plurality of corresponding confidence coefficients; calculating a confidence coefficient difference based on the plurality of confidence coefficients, and determining whether to trigger an evidence debate process or not according to the confidence coefficient difference; in response to an evidence debate process needing to be triggered, executing multiple rounds of evidence exchange and confidence coefficient updating until a confidence coefficient difference is lower than a first preset threshold value, and obtaining a convergent confidence coefficient result; and executing a weighted voting decision based on the convergent confidence result and the historical contribution degrees of the plurality of agents to obtain an anomaly diagnosis result of the target system.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and more specifically to an anomaly diagnosis method, apparatus, device, medium, and program product. Background Technology

[0002] Existing fault log analysis technologies mainly rely on fixed rules and template matching, which are difficult to adapt to the actual scenarios of diverse log formats and complex data sources in distributed systems. They suffer from problems such as fragmented multimodal data, poor log correlation, limitations of static rules, low efficiency in root cause localization, and insufficient reasoning ability.

[0003] Specifically, traditional methods cannot effectively integrate multimodal information such as text logs, numerical indicators and topological data, making it difficult to reveal the semantic and temporal relationships between abnormal events; predefined rules are difficult to cover new fault modes, resulting in high false alarms and low accuracy; at the same time, the system lacks causal reasoning and explanation mechanisms, and can only identify whether it is abnormal, but cannot answer why it is abnormal, thus making it difficult to achieve high-precision fault detection and root cause localization of complex systems. Summary of the Invention

[0004] In view of the above problems, this application provides methods, apparatus, devices, media and program products for abnormal diagnosis.

[0005] According to a first aspect of this application, an anomaly diagnosis method is provided, the method comprising: acquiring multimodal log data of a target system; performing parallel analysis of the multimodal log data using multiple agents with different diagnostic capabilities to generate multiple root cause hypotheses and corresponding multiple confidence levels; calculating confidence differences based on the multiple confidence levels; determining whether to trigger an evidence debate process based on the confidence differences; in response to the need to trigger an evidence debate process, performing multiple rounds of evidence exchange and confidence level updates until the confidence differences are lower than a first preset threshold to obtain a converged confidence level result; and performing a weighted voting decision based on the converged confidence level result and the historical contributions of the multiple agents to obtain an anomaly diagnosis result for the target system.

[0006] According to an embodiment of this application, the step of responding to the need to trigger an evidence debate process and performing multiple rounds of evidence exchange and confidence updates until the confidence difference is lower than a first preset threshold includes: responding to detecting that the maximum confidence difference among the confidence differences exceeds a second preset threshold, initiating an evidence debate process; in the evidence debate process, a master coordinator sends evidence exchange requests to the multiple agents and obtains debate information returned by the multiple agents, wherein each agent performs a confidence update based on the debate information; and using the master coordinator to recalculate and update the confidence difference based on the debate information, and responding to the updated confidence difference being higher than the first preset threshold, repeatedly performing the operation of initiating the evidence debate process and updating the confidence difference until the confidence difference is lower than the first preset threshold.

[0007] According to an embodiment of this application, performing a confidence update includes: in each round of evidence debate, each agent determines the direction of influence of the evidence information in the debate information on the corresponding root cause hypothesis; when the evidence information is supporting evidence, the corresponding agent increases its confidence value to perform a confidence update; when the evidence information is disproving evidence, the corresponding agent decreases its confidence value to perform a confidence update.

[0008] According to an embodiment of this application, the weighted voting decision based on the converged confidence result and the historical contributions of the multiple agents includes: assigning an initial contribution to each agent and recording the corresponding historical contribution; calculating a basic weight for each agent based on the initial contribution and the historical contribution; dynamically adjusting the basic weights according to the confidence changes and debate rounds for each agent during multiple rounds of evidence debate to form updated weights; and, in response to obtaining the converged confidence result, calculating a comprehensive score based on the initial contribution and the updated weights, and performing a weighted voting decision based on the comprehensive score.

[0009] According to an embodiment of this application, calculating the basic weight of each agent based on the initial contribution and the historical contribution includes: determining the static domain weight of each agent based on the initial contribution; and performing long-term performance correction on the static domain weight based on the historical contribution to obtain the basic weight.

[0010] According to an embodiment of this application, the step of dynamically adjusting the basic weights based on the confidence change and debate rounds corresponding to each agent to form updated weights includes: after each round of evidence debate, detecting the confidence change magnitude of each agent to determine the corresponding basic weight adjustment direction; and setting a decay factor according to the debate rounds, and dynamically adjusting the basic weights based on the decay factor and the basic weight adjustment direction to form the updated weights.

[0011] According to an embodiment of this application, the weighted voting decision based on the comprehensive score includes: assigning a corresponding vote value to each root cause hypothesis based on the comprehensive score; and comparing and ranking the vote values, and taking the root cause hypothesis with the highest vote value as the target root cause to obtain the abnormal diagnosis result of the target system.

[0012] According to an embodiment of this application, the method further includes: in response to obtaining the abnormal diagnosis result, extracting the target root cause corresponding to the abnormal diagnosis result, the evidence information provided by each agent, and the converged confidence result; and constructing a root cause map containing root cause nodes, evidence nodes, and corresponding causal relationships based on the target root cause, the evidence information provided by each agent, and the converged confidence result, wherein the root cause map is used to visually display the abnormal diagnosis result and the corresponding evidence relationships.

[0013] A second aspect of this application provides an anomaly diagnosis device, comprising: a data acquisition module, configured to: acquire multimodal log data of a target system, perform parallel analysis of the multimodal log data using multiple agents with different diagnostic capabilities, and generate multiple root cause hypotheses and corresponding multiple confidence levels; an evidence debate process triggering module, configured to: calculate confidence differences based on the multiple confidence levels, and determine whether to trigger an evidence debate process based on the confidence differences; an evidence debate module, configured to: in response to the need to trigger an evidence debate process, perform multiple rounds of evidence exchange and confidence level updates until the confidence differences are lower than a first preset threshold, and obtain a converged confidence level result; and an anomaly diagnosis module, configured to: perform weighted voting decisions based on the converged confidence level result and the historical contributions of the multiple agents to obtain an anomaly diagnosis result for the target system.

[0014] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0015] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0016] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0017] According to embodiments of this application, by introducing multiple agents with different diagnostic capabilities to perform parallel analysis of multimodal log data, collaborative understanding of multi-source data such as text logs, time-series indicators, and call chain information is achieved. This enables the generation of multiple root cause hypotheses and the formation of comparable confidence quantification results in the initial stage. Based on this, an evidence debate process based on confidence differences is implemented, enabling evidence exchange and dynamic confidence correction among agents. This allows the system to gradually converge to a consistent confidence result based on real-time evidence information, improving the stability and consistency of anomaly detection. Furthermore, by adjusting the weights of agents using historical contributions and performing weighted voting decisions based on the converged confidence results, the diagnostic process can comprehensively determine the final root cause by integrating current evidence with the historical performance of agents, thereby improving the reliability of anomaly diagnosis while maintaining the interpretability of the decision. Attached Figure Description

[0018] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0019] Figure 1 The illustrations depict application scenarios of anomaly diagnosis methods, apparatus, devices, media, and program products according to embodiments of this application.

[0020] Figure 2 A flowchart illustrating an anomaly diagnosis method according to an embodiment of this application is shown schematically.

[0021] Figure 3 A flowchart illustrating a method for performing weighted voting decisions according to some exemplary embodiments of this application is shown schematically.

[0022] Figure 4 The illustration shows a schematic diagram of a method for dynamically adjusting basic weights according to some exemplary embodiments of this application;

[0023] Figure 5 A schematic diagram illustrating the structure of an anomaly diagnostic device according to an embodiment of this application is shown; and

[0024] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing an anomaly diagnosis method according to an embodiment of this application. Detailed Implementation

[0025] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0026] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0027] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0028] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0029] As network devices and distributed application systems continue to expand in scale, the quantity and complexity of fault logs generated during system operation are growing exponentially. Various servers, containers, databases, middleware, and microservice components record operational status, abnormal events, and performance metrics in log files at different levels and in different formats. This log data typically includes multimodal information such as text-based operational records, numerical time-series metrics, and structured call relationship topologies. How to quickly and accurately identify the root causes of faults from massive, multi-source, and multimodal log data has become an important research direction for intelligent operations and maintenance.

[0030] Traditional fault log analysis methods primarily rely on static rules and template matching. For example, they identify abnormal logs by predefined keywords or regular expressions, or extract structured fields from logs using fixed templates for statistical analysis. However, with increasing system architecture complexity and diverse log formats, the adaptability of these methods gradually decreases. On the one hand, log formats, metric types, and service topologies change frequently, making it difficult to update fixed templates and static rules in a timely manner, leading to frequent false negatives and false negatives. On the other hand, anomalies in system operation often exhibit correlations between multimodal data. For instance, "request timeout" in text logs is often accompanied by abnormal peaks in CPU utilization or sudden changes in network traffic; traditional single-modal analysis cannot reveal such cross-modal relationships.

[0031] Existing solutions have some problems in multimodal data fusion and automated processing. First, the problem of fragmented multimodal data is prominent. Most current log analysis systems design independent processing flows for text logs or time-series indicators, lacking a unified representation and modeling mechanism, and thus failing to effectively capture the semantic and statistical correlations between different modalities.

[0032] Secondly, multimodal logs have poor correlation. In a microservice architecture, faults may span multiple service nodes, links, and call stacks. Traditional methods often rely on manually constructed topology maps or single-source logs, making it difficult to achieve cross-system and cross-modal event tracing and causal chain reasoning, resulting in a lengthy process for locating complex faults.

[0033] Third, static rules have obvious limitations. Existing solutions typically rely on rule bases built upon accumulated experience to match common error types or abnormal indicator thresholds. When new components are added to the system or new failure modes emerge, rules must be manually expanded or modified; otherwise, a false alarm rate of over 30% will result. Due to high maintenance costs, rule updates often lag behind system evolution, further reducing the accuracy and coverage of detection.

[0034] Fourth, root cause localization is inefficient. Rule-driven or static machine learning models can only perform pattern matching based on historical samples, lacking generalization ability for unknown or variant faults, resulting in a low root cause identification rate. When faced with complex dependencies or chain anomalies, existing models struggle to combine contextual and temporal information for comprehensive judgment, leading to a significantly insufficient average localization accuracy.

[0035] Fifth, insufficient reasoning ability. Traditional log analysis and alerting systems are mostly limited to anomaly detection, only outputting a judgment of "whether an anomaly exists," lacking explanatory reasoning mechanisms and unable to answer "why the anomaly occurred" and "where the anomaly might originate." In operational practice, such results are difficult to provide engineers with useful decision-making basis, requiring further investigation based on human experience, which seriously affects the efficiency of problem closure.

[0036] Based on this, embodiments of this application provide an anomaly diagnosis method, the method comprising: acquiring multimodal log data of a target system; utilizing multiple agents with different diagnostic capabilities to perform parallel analysis on the multimodal log data to generate multiple root cause hypotheses and corresponding multiple confidence levels; calculating confidence differences based on the multiple confidence levels; determining whether to trigger an evidence debate process based on the confidence differences; in response to the need to trigger an evidence debate process, executing multiple rounds of evidence exchange and confidence level updates until the confidence differences are lower than a first preset threshold to obtain a converged confidence level result; and performing a weighted voting decision based on the converged confidence level result and the historical contributions of the multiple agents to obtain an anomaly diagnosis result for the target system. According to embodiments of this application, by introducing multiple agents with different diagnostic capabilities to perform parallel analysis on multimodal log data, collaborative understanding of multi-source data such as text logs, time-series indicators, and call chain information is achieved, enabling the generation of multiple root cause hypotheses and the formation of comparable confidence quantification results in the initial stage. Building upon this foundation, an evidence debate process based on confidence level differences enables evidence exchange and dynamic confidence level correction among agents. This allows the system to gradually converge to a consistent confidence level based on real-time evidence information, improving the stability and consistency of anomaly detection. Furthermore, by adjusting the weights of agents using historical contributions and combining this with weighted voting decisions based on the converged confidence level, the diagnostic process can comprehensively determine the root cause by integrating current evidence with the agents' historical performance. This approach maintains the interpretability of decisions while enhancing the reliability of anomaly diagnosis.

[0037] It should be noted that the anomaly diagnosis methods, apparatus, devices, media, and program products defined in this application can be used in the fields of artificial intelligence technology and fintech, and can also be used in a variety of other fields besides artificial intelligence technology and fintech. The application fields of the anomaly diagnosis methods, apparatus, devices, media, and program products provided in the embodiments of this application are not limited.

[0038] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0039] In scenarios where personal information is used for automated decision-making, the methods, devices, and systems provided in this application all offer users corresponding operation entry points, allowing them to choose to agree to or reject the automated decision results; if the user chooses to reject, the process proceeds to expert decision-making. Here, "expert decision-making" refers to the decision-making activities of personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0040] Figure 1 The illustration shows an application scenario diagram of the anomaly diagnosis method, apparatus, device, medium, and program product according to embodiments of this application.

[0041] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0042] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0043] In the embodiments of this application, the first terminal device 101 can be an example of the first device, and the second terminal device 102 and / or the third terminal device 103 can be an example of at least one second device. The first device and the second device can communicate collaboratively through an internal client mechanism to implement the data distribution and rendering logic described in the anomaly diagnosis method.

[0044] In some embodiments, the first device and at least one second device may be different display modules, windows or screens on the same computing terminal (such as a host), or multiple physical devices that work together through a network, such as different client instances deployed on a desktop computer, tablet terminal or mobile device respectively.

[0045] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smart mobile terminals, tablet computers, laptop computers, and desktop computers.

[0046] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0047] It should be noted that the anomaly diagnosis method provided in this application embodiment can generally be executed by server 105. Correspondingly, the anomaly diagnosis device provided in this application embodiment can generally be located in server 105. The anomaly diagnosis method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the anomaly diagnosis device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0048] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0049] The following will be based on Figure 1 The described scene, through Figures 2-4 The anomaly diagnosis method of the disclosed embodiments will be described in detail.

[0050] Figure 2 A flowchart illustrating an anomaly diagnosis method according to an embodiment of this application is shown schematically.

[0051] like Figure 2 As shown, the abnormal diagnosis method 200 of this embodiment includes operations S210 to S240.

[0052] In operation S210, multimodal log data of the target system is acquired, and multiple agents with different diagnostic capabilities are used to perform parallel analysis on the multimodal log data to generate multiple root cause hypotheses and corresponding confidence levels.

[0053] In the embodiments of this application, multimodal runtime log data may include text logs, performance metrics, call chain information, and resource usage records. After this data is input into the agent cluster, multiple agents with different diagnostic capabilities will independently analyze the same data segment and generate their own root cause hypotheses and corresponding confidence levels in the initial stage. For example, when the log shows information about upstream call timeouts in the order service, the container runtime analysis agent can output the hypothesis "container resource limitations cause latency" based on processor rate limiting data and give the corresponding confidence level; the performance metric analysis agent can output the hypothesis "sudden increase in payment interface latency" based on abnormal changes in payment interface response time; the call chain analysis agent can propose the hypothesis "inventory service response timeout" based on the propagation trend of inter-service latency; and the database diagnostic agent can point out the situation of "data table lock wait accumulation". Each agent will also include evidence information obtained from its internal analysis as the basis for subsequent confidence level comparisons.

[0054] In some embodiments, multiple agents can provide root cause hypotheses with different granularities and levels of interpretation to enhance the coverage of multimodal anomaly understanding. For example, when faced with the same service timeout log, a text parsing agent might semantically suggest that "the upstream service in the service call chain is unavailable"; a performance metrics agent might infer that "increased thread pool utilization leads to prolonged queuing time"; a call chain analysis agent might discover that latency amplifies step-by-step in the dependency chain and propose the hypothesis of "latency cascading propagation"; and a resource analysis agent might detect short-term processor jitter and determine that "processor jitter triggers instantaneous insufficient capability." The hypotheses of the various agents may support each other or conflict, and the difference in initial confidence values ​​precisely reflects this information divergence.

[0055] In the embodiments of this application, the agent generates root cause hypotheses not only based on current instantaneous log content but also on long-term system operation history. For example, when the agent detects a sudden increase in latency of an interface, it can automatically refer to baseline metrics from the past seven days, changes in the call chain structure, and container deployment strategies to provide a more reasonable confidence assessment. For instance, if a payment interface has repeatedly exhibited similar latency patterns during peak periods, the performance metric analysis agent may therefore generate a higher confidence level; while if the container analysis agent finds that the current node has not experienced a resource bottleneck during this period, its confidence level for the hypothesis that "container resources cause latency" may be set to a lower level.

[0056] In some embodiments, the system allows agents to enhance the generation process of root cause hypotheses based on external context. For example, when a call chain analysis agent discovers a synchronous surge in inter-service latency within a short period of time, it can further call cluster event information to determine whether there are background events such as network jitter, node migration, or batch deployment. If the log agent captures a large number of text fragments such as "connection reset" and "read / write timeout," it may corroborate the aforementioned background events, thereby increasing the confidence level.

[0057] In embodiments of this application, the intelligent agent may provide interpretable pieces of evidence as the basis for root cause hypotheses, and this evidence may be invoked in subsequent debate phases. For example, a performance metrics agent may provide interface latency heatmaps, call peak change trends, etc., as supporting evidence; a container analysis agent may provide processor rate limiting time series, memory reclamation cycles, and restart events; a call chain analysis agent may provide latency propagation paths across services; and a database diagnostic agent may provide lock wait counts, transaction backlog details, etc.

[0058] In some embodiments, to enhance the scalability of the agents during the initial analysis phase, each agent can employ different analysis models, such as rule-based discrimination logic, statistical feature-based anomaly detection algorithms, deep learning-based representation models, or historical case-based similarity inference models. For example, a call chain analysis agent can use a path building model based on distributed tracing to identify delayed transmission paths; a database diagnostic agent can use a lock dependency graph model to identify blocked links; and a container diagnostic agent can use a resource change interpretation model to determine whether resource mutations align with business peaks.

[0059] In the embodiments of this application, the agent can record time-series information related to its inference while generating root cause hypotheses, which can be used to determine whether the evidence has causal logic in subsequent debate stages. For example, if the performance metrics agent finds that the increase in interface latency precedes the occurrence of resource bottlenecks, it may assign a lower confidence level to the hypothesis of insufficient container resources; if the call chain analysis agent observes that the latency spreads from downstream services to upstream, it may assign a lower confidence level to the hypothesis of upstream service node failure. By storing time-series data as part of the evidence, the system can provide a stronger interpretability basis for subsequent evidence debate.

[0060] In operation S220, confidence differences are calculated based on the multiple confidence levels, and it is determined whether to trigger the evidence debate process based on the confidence differences.

[0061] In the embodiments of this application, after multiple agents complete the initial analysis of multimodal log data and generate root cause hypotheses and confidence levels respectively, the confidence levels provided by each agent can be aggregated to further calculate their degree of difference. In this process, the system can first extract the maximum and minimum values ​​among all confidence levels and measure the disagreement among the agents based on the difference between them. When this difference exceeds a preset confidence level difference threshold, the system considers that there is a significant inconsistency among the multiple agents in their root cause judgments, thereby determining that an evidence debate process needs to be triggered.

[0062] In some embodiments, the system can use various methods, not limited to the difference between the maximum and minimum values, to calculate confidence differences. For example, the system can statistically analyze the variance, skewness, or distribution fluctuations of each agent's confidence to measure the dispersion of the overall opinion. In this embodiment, if the variance exceeds a preset threshold, or if the confidence distribution exhibits a clear divergence peak pattern, the system can determine that the current agents' root cause judgments lack consistency, thereby triggering further evidence exchange and debate.

[0063] In the embodiments of this application, to avoid the impact of abnormal confidence levels output by a single agent on the overall judgment, the system can employ robust statistical methods to calculate confidence level differences. For example, the system can use the difference between the median and extreme confidence levels as a criterion. When the difference between an agent's maximum confidence level and the median exceeds a threshold, the system can determine that the viewpoint of the high-confidence agent needs further verification, thereby initiating the evidence debate process. This approach effectively reduces the disturbance of special cases to the overall judgment.

[0064] In some embodiments, the system can simultaneously record the source of the difference and the associated agent when calculating the confidence difference. For example, when the system detects that the confidence difference between the payment interface analysis agent and the container diagnosis agent is significantly greater than that of other agent combinations, the system can identify the most likely conflicting viewpoints and prioritize the exchange of evidence related to that conflict in subsequent operations.

[0065] In the embodiments of this application, when determining whether to trigger the evidence debate process, the system can also consider the agent type, the category of root cause hypothesis, and the differences in evidence sources. For example, when multiple agents' hypotheses come from completely different root cause categories (such as system resource bottlenecks, call chain propagation, abnormal business load, database lock waits, etc.) and their confidence levels differ significantly, the system will be more inclined to initiate evidence debate. However, when the differences between agents are mainly reflected in the details of the same type of root cause, such as both pointing to the resource layer but with different confidence levels, the system can choose to postpone the debate and continue collecting more data to reduce the probability of invalid debate.

[0066] In some embodiments, the system may conclude that "no debate process needs to be initiated" after calculating the confidence level differences. For example, when the confidence levels given by each agent are all at a moderate level and the differences are small, the system may consider that the differences in opinions between agents are not significant. In this case, there is no need to initiate evidence exchange, and these confidence levels can be directly used as the basis for subsequent voting decisions. In addition, when the root cause hypothesis itself is highly consistent (e.g., multiple agents all point to an abnormal response to a specific service), a small difference in confidence level can also be directly regarded as a consensus signal.

[0067] In the embodiments of this application, the system can extend the confidence difference judgment logic to adapt to system environments of varying complexity. For example, in high-concurrency business systems, performance-related faults may generate significant distribution differences, so the threshold can be appropriately increased; while in resource-sensitive systems, even small differences can trigger evidence debate. The system can dynamically adjust this threshold based on business scenarios, historical performance, and root cause distribution to achieve more stable anomaly identification results in different scenarios.

[0068] In some embodiments, the system can also visualize the confidence differences to provide a reference for subsequent human-machine collaboration or manual verification. For example, the system can generate bar charts, line charts, or heatmaps to display the confidence distribution of each agent and indicate whether a debate has been triggered.

[0069] In operation S230, in response to the need to trigger the evidence debate process, multiple rounds of evidence exchange and confidence updates are performed until the confidence difference is lower than the first preset threshold, and a converged confidence result is obtained.

[0070] In the embodiments of this application, when the system determines that an evidence debate process needs to be triggered based on the confidence level difference, the master coordinator can organize multiple agents to enter the evidence exchange phase. In this phase, the master coordinator can initiate evidence requests to relevant agents based on the root cause hypotheses and corresponding evidence proposed by different agents, and receive response information from the agents. Each agent judges whether its original root cause hypothesis is still reasonable based on the received evidence, and accordingly increases or decreases its own confidence level. After each round of evidence exchange, the system recalculates the confidence level difference and decides whether to initiate the next round of debate, until the confidence level difference is lower than a preset threshold.

[0071] In some embodiments, the evidence exchange may include metric trends, call chain latency paths, resource usage changes, database lock wait status, key semantic fragments in logs, and runtime event time alignment information. For example, when the master coordinator requests correlation evidence from the performance analysis agent, the agent can provide a heatmap of interface latency changes and time alignment with abnormal events; the container runtime analysis agent can provide processor rate limiting records, resource bursts, and their causal order with latency events; and the database analysis agent can provide lock wait accumulation and thread pool blocking log fragments. This evidence is integrated during the exchange and used for cross-validation between agents.

[0072] In the embodiments of this application, the evidence debate process can be conducted in a multi-round iterative manner to ensure that the causal logic between different data sources is fully compared. For example, when the evidence of a sudden increase in latency provided by the performance analysis agent is inconsistent with the resource status of the container analysis agent, the container analysis agent may return evidence that is not causally related to the latency, thereby reducing its own confidence. Similarly, when the database analysis agent provides evidence that lock waiting is causing congestion, if the evidence is consistent with the latency propagation situation of the call chain, its confidence can increase. Through multiple rounds of evidence exchange, the confidence of the agents will undergo a continuous adjustment process, eventually forming a more consistent judgment.

[0073] In some embodiments, to avoid prolonged debate between conflicting viewpoints, the system can introduce an evidence integration mechanism in each round of debate. This mechanism packages all exchanged evidence and broadcasts it to the participating agents, allowing each agent to re-evaluate their hypotheses based on complete information. This approach reduces repeated arguments caused by insufficient local evidence, enabling agents to make judgments on a unified information set, thereby accelerating the convergence of confidence levels.

[0074] In embodiments of this application, multi-round evidence exchange can also be combined with time sequence analysis to determine the causal relationship between different events. For example, when a delay event occurs within a time window after processor rate limiting, the container analysis agent may lower its compensatory confidence level; conversely, when a delay event occurs before resource fluctuations, the performance analysis agent may increase its confidence level in the hypothesis of a sudden increase in business traffic. By introducing time sequence judgment, the system can more accurately distinguish causal chains and avoid mistakenly treating correlation as causation.

[0075] In some embodiments, the number of iterations in the multi-round debate can be set as an adjustable parameter based on the business scenario or system complexity. For example, when processing data from a high-concurrency transaction system, a fault may involve multiple link nodes, so the number of debates can be set to be relatively high; while in a small system with relatively stable resources, fewer debate rounds can be set to quickly reach a judgment. After each round, the system can compare the current confidence level difference. If the difference is significantly reduced, the debate can be ended early, improving the efficiency of anomaly diagnosis.

[0076] In the embodiments of this application, to ensure the stability of the final confidence score, the system can uniformly calculate the latest confidence scores of all agents after each round of evidence exchange and compare their changing trends. For example, if an agent fails to provide new evidence or obtain support from other evidence in several consecutive rounds, its confidence score may remain unchanged; while the confidence scores of agents providing key evidence may continue to increase. When the system detects that the overall confidence score difference is gradually narrowing, it considers that the multi-round evidence exchange has converged and can stop the debate process at this point.

[0077] In some embodiments, when the system detects that the confidence difference is lower than a first preset threshold, this can be used as a condition for debate convergence. At this point, the opinions of multiple agents have become consistent or the conflicting differences have been fully explained, and the system uses these updated confidence levels as the basis for subsequent decisions.

[0078] In operation S240, a weighted voting decision is performed based on the converged confidence result and the historical contributions of the multiple agents to obtain the anomaly diagnosis result of the target system.

[0079] In the embodiments of this application, after multiple rounds of evidence exchange are completed and the confidence differences among the agents fall below a preset threshold, the converged confidence level can be used as input, combined with the historical contributions of each agent, to perform a weighted voting decision on multiple root cause hypotheses. During this process, the system can retrieve the diagnostic performance of each agent in similar scenarios from historical operation records and assign corresponding weights to them. Subsequently, the system combines the converged confidence level of each agent with its weights to calculate a comprehensive score for each root cause hypothesis, which serves as the basis for selecting the final diagnostic conclusion.

[0080] In some embodiments, when performing weighted voting, the system can consider the agent's long-term stable performance as an important component of the weight evaluation. For example, if an agent has maintained high accuracy in multiple past diagnostic events, its historical weight may be set higher; conversely, if an agent has frequently made misjudgments in past diagnostic processes, its historical contribution may be lower. In this embodiment, although the confidence levels of multiple agents have converged in the preceding steps, the final comprehensive score is still adjusted by historical experience, thereby making the decision result more robust.

[0081] In the embodiments of this application, when calculating the overall score, the system can also consider the performance of each agent in the current debate process, such as whether its root cause hypothesis is supported in the evidence exchange, whether it provides key evidence, and whether it proposes effective counter-evidence at key points. When an agent provides influential evidence in the debate, its corresponding weight can be increased accordingly; if an agent's hypothesis is refuted multiple times during the evidence exchange process, its weight may be appropriately reduced. By combining temporary performance with historical contributions, the system can assign more refined voting strength to each root cause.

[0082] In some embodiments, the system can calculate a composite score for each root cause hypothesis individually. For example, if an agent gives a high convergence confidence level for "sudden increase in payment interface latency" and has a high historical contribution, the composite score of this root cause hypothesis may be significantly higher than other hypotheses. Similarly, if another agent provides significant supporting evidence for "database lock wait accumulation" and performs exceptionally well in the debate, the composite score of this root cause hypothesis may also be increased. The system ultimately ranks all root cause hypotheses by score and selects the hypothesis with the highest score as the final diagnostic result.

[0083] In the embodiments of this application, the system can also combine multiple root causes for judgment during the weighted voting decision-making process. For example, when two root causes are supported by multiple intelligent agents during evidence exchange and are both associated with abnormal behavior in the time series, the system can generate a "composite root cause hypothesis" and calculate a comprehensive score for the composite root cause. In some scenarios, the anomaly diagnosis result ultimately selected by the system may be composed of two or more related root causes, thus more closely approximating the cause of actual business failures.

[0084] In some embodiments, the weighted voting process allows the system to perform further reliability checks on root causes with similar scores. For example, when the combined scores of two root cause hypotheses are small, the system can further compare their credibility based on factors such as the scope of business impact, the degree of evidence coverage, and the degree of log matching, and ultimately determine the most reasonable anomaly diagnosis result.

[0085] In the embodiments of this application, after determining the final anomaly diagnosis result, the system can structurally save the result along with key evidence and confidence records used for decision-making, so that it can be used for subsequent manual review, fault debriefing, or model retraining. For example, the system can save the convergence confidence, historical contribution changes, evidence usage, and final voting results for each agent in this task.

[0086] In some embodiments, after weighted voting decision-making is completed, the system can push the root cause to the operations and maintenance platform, business alarm system, or automated repair process, so that the anomaly diagnosis results can directly enter the business response stage. For example, for a "combined problem of payment interface delay and database lock wait", the system can trigger interface display, work order generation, or automatic repair strategy.

[0087] According to embodiments of this application, by introducing a multi-agent collaborative reasoning mechanism, the anomaly diagnosis process can start from multimodal log data, simultaneously generate multiple root cause hypotheses from different analytical perspectives, and quantify the reliability of each hypothesis in the form of confidence levels. By detecting differences in confidence levels, the system can promptly identify inconsistencies in the judgment results among agents, and then organize multiple rounds of evidence exchange. This allows agents to continuously adjust their confidence levels based on unified evidence, gradually narrowing the differences between different hypotheses, thereby enabling the diagnosis process to have dynamic adjustment and convergence capabilities. Finally, the system combines the converged confidence results with the historical contributions of each agent, and determines the root cause judgment that best fits the overall evidence through weighted voting. This ensures that the diagnosis result not only reflects the rationality of the current evidence but also takes into account the stability of the agents during long-term operation.

[0088] The anomaly diagnosis method of this application will be specifically described below by way of preferred embodiments.

[0089] In the embodiments of this application, to enable various intelligent agents to assume different analytical roles in the anomaly diagnosis process, the system can pre-configure corresponding intelligent agent types according to different diagnostic dimensions during the deployment phase, and specify the monitoring port and log collection channel for each type of intelligent agent, load the corresponding rule base, feature base, and historical case data, and, if necessary, access the semantic understanding and reasoning capabilities provided by a large language model. Through this initialization and configuration process, each intelligent agent forms diagnostic capabilities for different dimensions such as container operation, performance indicators, call chains, database behavior, and system resources, and generates root cause hypotheses and confidence levels based on multimodal data at runtime.

[0090] For example, the container runtime analysis agent continuously acquires runtime status information of each container instance by accessing the monitoring port and log collection channel of the container orchestration platform, including container restart events, resource rate limiting records, instance scheduling and migration records, and node load status. When generating this agent, the system first loads an exception pattern library and runtime feature templates related to container runtime to characterize common container-level abnormal behaviors; simultaneously, optionally, a large language model can be used as a backend semantic analysis capability to perform semantic parsing and classification of container log content, alarm information, and event descriptions.

[0091] For example, the performance metric analysis agent obtains continuous metric data such as interface latency, request throughput, error rate, and thread pool utilization by accessing the metric query port of the performance monitoring system, and can compare performance at different times in conjunction with a baseline model. When generating this agent, the system can load an anomaly detection model and empirical threshold configuration for it to identify abnormal patterns such as sudden increases, sudden decreases, and long-tail latency; at the same time, a large language model can be introduced to perform semantic attribution on log entries and alarm descriptions related to performance anomalies, such as aligning text descriptions such as "request queuing," "response timeout," and "connection exhaustion" with the abnormal segments of the corresponding metrics.

[0092] For example, the call chain analysis agent obtains the link structure of cross-service calls, the call time of each node, error markers, and upstream and downstream dependencies by accessing the tracing data port of the distributed call chain tracing system. When generating this agent, the system can load a call chain topology building module and latency propagation analysis rules for it, which are used to automatically reconstruct the propagation path of requests between multiple services and identify latency amplification points or abnormal interruption points in the path.

[0093] For example, the database diagnostic agent obtains information on lock wait status, transaction execution time, slow query records, and resource contention by accessing the database monitoring port and database log collection port. When generating this agent, the system can first load the database operation mode library, lock contention analysis rules, and common slow query feature templates to identify typical problems such as hot data row contention, long transaction blocking, and missing indexes. Simultaneously, the large language model can be configured as an auxiliary module for semantic parsing of complex structured query statements and error logs to automatically identify query intent, access objects, and their potential risks.

[0094] For example, the resource analysis agent obtains multi-dimensional resource indicators such as processor utilization, memory usage, disk I / O, and network bandwidth usage by accessing the system resource monitoring port, and analyzes them in conjunction with historical resource usage curves and business load patterns. When generating this agent, the system can load a resource feature library and a resource anomaly pattern library for it to identify situations such as continuous high resource usage, periodic fluctuations, and sudden contention. Furthermore, it can access a large language model to perform semantic classification of resource-related descriptions in resource alarm texts and system logs.

[0095] In the embodiments of this application, when the system detects that the confidence differences among multiple agents are significantly greater than a second preset threshold in the aforementioned steps, the master coordinator can automatically initiate an evidence debate process to further verify whether the root cause hypotheses proposed by each agent are consistent. After initiating the debate, the master coordinator first determines the content that needs to be supplemented for comparison based on the initial root cause hypotheses proposed by different agents and the evidence information they have provided, and sends evidence exchange requests to each agent to collect more comprehensive evidence materials. Upon receiving the request, each agent will return corresponding debate information based on the logs, metrics, call chains, or resource information it possesses.

[0096] In some embodiments, debate information collected by the master coordinator is broadcast to the participating agents, enabling them to determine whether their root cause assumptions remain reasonable based on complete and consistent evidence. After analyzing the updated evidence, agents can increase or decrease their confidence levels to reflect the degree to which the evidence supports or refutes their viewpoints.

[0097] In the embodiments of this application, after each round of evidence exchange, the master coordinator recalculates the overall confidence difference based on the latest confidence level submitted by the agent to determine whether another round of debate is still necessary. When the difference is still higher than a first preset threshold, the system continues to execute evidence request, evidence exchange, and confidence update operations; if the difference has decreased significantly but has not yet met the convergence condition, the system can still start a new round of debate to ensure that the final judgment has sufficient stability.

[0098] By automatically initiating the evidence debate process when the difference in confidence of the agents exceeds a second preset threshold, the embodiments of this application can organize multiple rounds of verification in a timely manner when there are obvious conflicts in multimodal evidence, so that the analysis results from different sources can be adjusted on a unified evidence set, thereby achieving the establishment of consistency in root cause judgment, avoiding the bias caused by a single source of evidence, and improving the stability and reliability of abnormal diagnosis.

[0099] In the embodiments of this application, after the evidence debate process begins, each agent can evaluate the evidence information broadcast by the master coordinator item by item to determine the direction of the evidence's impact on its current root cause hypothesis. For example, after receiving the interface latency change graph, the performance analysis agent will determine whether the time trend in the graph is consistent with its own hypothesis; after receiving resource load information, the container analysis agent will determine whether the resource fluctuations occur before or after the abnormal latency; after receiving lock wait information, the database analysis agent will determine whether the lock wait is sufficient to explain the current business blockage. Based on these judgments, the agents determine whether the evidence supports or contradicts their own viewpoint.

[0100] When an agent recognizes a semantic and temporal relationship between evidence in a debate and its root cause hypothesis, it considers that evidence as supporting evidence. For example, if a performance analysis agent detects that the timing of an increase in interface latency coincides with the peak change in requests it points out, it can consider that the evidence strengthens the credibility of its hypothesis, thus increasing its confidence level in this round of debate. Conversely, if a container analysis agent finds that the peak in resource utilization occurs after the interface latency, it considers that the evidence negates its hypothesis that "insufficient resources cause latency," thereby actively lowering its confidence level.

[0101] In the embodiments of this application, each agent can adjust its confidence level based on the sufficiency, reliability, and strength of the evidence when performing confidence level updates. For example, when the evidence is highly credible, directly reflects the source of business latency, and is corroborated by multiple data sources, the agent may significantly increase its confidence level; if the evidence only partially supports its viewpoint, the agent may only make a small adjustment; when the evidence clearly contradicts its hypothesis, it will significantly decrease its confidence level. As multiple rounds of evidence exchange progress, the agent's confidence level will gradually converge. For example, in the first round of debate, the performance analysis agent may increase its confidence level because the latency trend matches its hypothesis, while the container analysis agent may decrease its confidence level because the resource peak and latency have no causal relationship; the database analysis agent may increase its confidence level because the lock waiting evidence is clear and consistent with the call chain sequence.

[0102] By having each agent judge the direction of the influence of the evidence on the root cause hypothesis in each round of evidence debate, and actively increase or decrease their own confidence accordingly, the agents can continuously revise their judgments when faced with multimodal and contradictory evidence. This avoids bias caused by inaccurate evidence from a single source and promotes the gradual acquisition of higher confidence for reasonable root cause hypotheses.

[0103] Figure 3 A flowchart illustrating a method for performing weighted voting decisions according to some exemplary embodiments of this application is shown schematically.

[0104] like Figure 3 As shown, the method for performing weighted voting decisions includes operations S310 to S330.

[0105] In operation S310, an initial contribution is assigned to each agent, and the corresponding historical contribution is recorded. The basic weight of each agent is calculated based on the initial contribution and the historical contribution.

[0106] In embodiments of this application, to reasonably allocate the influence of multiple agents in weighted voting, the static domain weight of each agent can first be determined based on its initial contribution. The initial contribution can be set according to the diagnostic domain the agent is responsible for, its importance in the system architecture, and its sensitivity to multimodal data. For example, an agent responsible for interface performance analysis may be more important in high-concurrency scenarios, while an agent responsible for database diagnostics may be more important when data consistency anomalies are involved.

[0107] In some embodiments, after obtaining the static domain weights, the system can further adjust these weights based on the agent's historical contributions. Historical contributions can be derived from the agent's overall performance in past diagnostic tasks, including diagnostic accuracy, number of participations, frequency of providing key evidence, and the number of misjudgments. The system can increase or decrease the static domain weights based on these historical indicators to form a base weight that more closely reflects actual performance. For example, if an agent consistently maintains high accuracy in past diagnoses, its base weight can be adjusted upwards; conversely, if an agent makes many misjudgments, its base weight may be decreased.

[0108] In the embodiments of this application, the system forms the basic weights for subsequent weighted voting decisions after completing long-term performance correction. These basic weights retain the inherent distinctions in diagnostic domains based on initial contributions while incorporating factual data on the long-term performance of each agent, resulting in better adaptability and stability in the subsequent comprehensive score calculation process. For different types of agents, regardless of their strengths in resource analysis, call chain analysis, or database analysis, a fair and evidence-based starting point for weights can be obtained through this basic weight mechanism.

[0109] During operation S320, in the process of multiple rounds of evidence debate, the basic weights are dynamically adjusted according to the changes in confidence level and debate rounds for each agent, to form updated weights.

[0110] After multiple agents have gone through several rounds of evidence debate, the master coordinator can dynamically adjust the base weights based on changes in each agent's confidence level and the number of rounds in the debate. For example, if an agent provides crucial evidence during the evidence exchange and gains more support for its root cause hypothesis, its weight will be appropriately increased; if an agent's hypothesis is repeatedly refuted by other evidence in multiple rounds of debate, its weight may decrease. Furthermore, as the number of debate rounds increases, the system can reduce the weights of some agents based on the number of rounds to facilitate faster convergence of the debate and the formation of updated weights.

[0111] In operation S330, in response to obtaining the converged confidence result, a comprehensive score is calculated based on the initial contribution and the updated weights, and a weighted voting decision is performed based on the comprehensive score.

[0112] Once the system obtains the convergent confidence score, it can calculate the corresponding comprehensive score based on the initial contribution and updated weights of each agent. For example, if the confidence score of a certain root cause hypothesis is high, and the historical contributions and current performance of the agents supporting the hypothesis are both excellent, then the comprehensive score of that hypothesis may be higher.

[0113] By calculating the base weight using both initial and historical contributions, the task suitability and long-term stability of the agents can be fully considered before weighted voting, ensuring a reliable base distribution for the voting mechanism. Dynamically adjusting the weights based on changes in confidence level and debate rounds allows the system to reflect changes in evidence quality and agent performance during the diagnostic process, giving greater influence to reasonable viewpoints and reducing the interference of erroneous viewpoints on the final result. Finally, by combining the convergence confidence level with the updated weights to calculate the comprehensive score, an effective fusion mechanism can be established among multi-source analysis results, making anomaly diagnostic results more consistent with the overall evidence structure and improving the system's ability and consistency in judging complex fault scenarios.

[0114] Figure 4 The illustration shows a schematic diagram of a method for dynamically adjusting basic weights according to some exemplary embodiments of this application.

[0115] like Figure 4 As shown, the method for dynamically adjusting the basic weights may include operations S410 to S420.

[0116] When operating S410, after each round of evidence debate, the change in confidence level of each agent is detected to determine the corresponding direction of basic weight adjustment.

[0117] Specifically, the master coordinator can compare the confidence levels of each agent before and after the current round of debate, and determine the direction of the basic weight adjustment for each agent based on the degree of increase or decrease. For example, if an agent provides key evidence and gains support from multiple parties, causing its confidence level to rise significantly in this round of debate, the system can determine that its weight adjustment direction is to increase; if an agent's evidence is refuted by other data in the debate, causing its confidence level to decrease, the system can determine that its weight adjustment direction is to decrease. In this way, the system can use the dynamic changes in confidence level to reflect the agent's contribution to the current debate.

[0118] In some embodiments, when determining the direction of basic weight adjustment, the system can also consider the reliability of different evidence sources, the temporal correlation of evidence, and the mutual reinforcement between evidence to improve the accuracy of the weight adjustment direction. For example, when the evidence from the performance analysis agent not only increases its own confidence but also corroborates the evidence from the call chain analysis agent and the database analysis agent, the agent's contribution in this round of debate may be considered stronger, and the system will tend to increase the agent's weight when determining its weight adjustment direction. Conversely, when an agent's evidence sources are limited or lack temporal support, its confidence decreases significantly, and the adjustment direction may be to reduce its weight.

[0119] In operation S420, a decay factor is set according to the debate round, and the basic weights are dynamically adjusted based on the decay factor and the basic weight adjustment direction to form the updated weights.

[0120] The decay factor can be used to limit the accumulation of weights across multiple rounds of debate, preventing any agent from gaining excessive influence as the number of debate rounds increases. For example, in the first round of debate, the decay factor is small, allowing the system to allow for larger weight adjustments; after multiple rounds of debate, the decay factor gradually increases, moderately suppressing the magnitude of weight adjustments, thereby promoting the convergence of overall confidence.

[0121] By detecting changes in the confidence levels of agents and determining the direction of weight adjustments after each round of evidence debate, the embodiments of this application can accurately reflect the actual contributions of different agents in the current debate, making weight allocation more dynamic and realistic. By setting a decay factor according to the debate rounds and appropriately suppressing the basic weights, the weights can be prevented from increasing or decreasing indefinitely in multiple rounds of debate, making the weight adjustment process convergent and stable. The final updated weights can more objectively reflect the contributions of each agent in the overall diagnostic process, making the basis for weighted voting decisions more reasonable and improving the credibility of anomaly diagnosis results.

[0122] In some embodiments, after the system obtains a composite score for multiple root cause hypotheses based on the aforementioned operations, the system can assign a corresponding vote value to each root cause hypothesis according to these composite scores. A higher composite score indicates that the root cause hypothesis is supported by more consistent and stronger evidence from multiple agents, and therefore the system can assign a higher vote value to that hypothesis. For example, when a root cause hypothesis is supported by multiple agents and its confidence and weight are both at a high level, its vote value may be significantly higher than other hypotheses.

[0123] In some embodiments, after assigning voting values ​​to different root cause hypotheses, the system can further compare and rank all voting values ​​to identify the most probable cause of the anomaly. During the ranking process, the system can sort the voting values ​​from high to low and select the root cause hypothesis with the highest voting value as the final target root cause based on the ranking result. For example, when the "sudden increase in interface latency" hypothesis has the highest voting value and significantly leads other hypotheses, the system will output it as the root cause of the current anomaly.

[0124] In the embodiments of this application, to maintain the stability of the judgment, the system may also internally retain information on the ranking criteria and voting value distribution, such as the comprehensive score of each root cause hypothesis, the results of voting value changes, and the final ranking. This information can be used for subsequent construction of root cause maps, manual review, or model iterative training, but will not affect the core process of weighted voting.

[0125] In some embodiments, when the voting values ​​of multiple root cause hypotheses are relatively close, the system can introduce business context information as a supplementary judgment criterion to improve the accuracy of the final root cause selection. Business context information may include the business type of the current request, the process stage it belongs to, user behavior patterns, and their correspondence with business peaks or business windows. For example, when two root cause hypotheses point to interface latency and database lock waiting respectively, and the current business is in a high-frequency request scenario, the system may be more inclined to select the interface latency root cause, which is more consistent with high concurrency characteristics, to ensure that the diagnostic results have a reasonable business relevance.

[0126] In some embodiments, the system can further differentiate root causes with similar voting values ​​based on the breadth of their impact. For example, when one root cause is assumed to affect only a single service or a local function, while another root cause is assumed to involve the entire call chain or coordination issues between multiple services, the system may consider the latter to have a more significant impact on the overall business. Therefore, when voting values ​​are similar, the root cause with a larger impact is prioritized as the output. This approach avoids errors caused by judging only local performance, making the diagnostic results more consistent with the overall system state.

[0127] In some embodiments, when determining root causes with similar voting values, the system may also consider the degree of evidence coverage, i.e., the comprehensive performance of different root cause hypotheses in terms of the quantity of evidence, the type of evidence source, and the consistency of evidence. For example, one root cause hypothesis may be supported by multiple agents from log analysis, call chain analysis, and performance metric analysis, while another root cause hypothesis may be supported by only a single agent. Even though the voting values ​​of the two are similar, the system can still determine that the former is more credible based on the breadth and diversity of evidence coverage, and thus prioritize it as the final root cause.

[0128] In embodiments of this application, the system can further determine the root cause by considering the temporal consistency of the evidence. In multimodal logs, the order in which different events occur often has crucial causal significance. For example, when the votes for two root cause hypotheses are similar, if the key evidence for one hypothesis strictly precedes the occurrence of the anomalous behavior in time, while the evidence for the other hypothesis has a weaker temporal relationship or is inconsistent, the system will be more likely to select the former as the final root cause. This mechanism introduces temporal logic into the judgment process when votes are close, enabling the system to avoid misjudgments caused by a lack of causal order in the evidence fragments.

[0129] By assigning voting values ​​to each root cause hypothesis based on a comprehensive score, the embodiments of this application can quantify the judgment results formed by the agent under multimodal evidence into directly comparable numerical values, enabling the root cause inference process to have a clear weighted expression. By comparing and ranking the voting values ​​of each root cause hypothesis, the most representative target root cause that best conforms to global evidence can be selected from multiple candidate root causes, thereby ensuring the rationality and consistency of the abnormal diagnosis results. This weighted voting method enables the system to have robust decision-making capabilities in complex diagnostic scenarios with multiple information sources, helping to improve the accuracy and reliability of anomaly identification.

[0130] In the embodiments of this application, in order to present in a structured manner the reasoning chain, evidence support, and confidence changes generated during the anomaly diagnosis process, making the final diagnostic results interpretable and facilitating subsequent traceability, review, and knowledge accumulation, the system can construct a root cause graph after completing the anomaly diagnosis. The root cause graph is used to integrate key information generated by multiple agents during the analysis, debate, and confidence convergence stages, enabling users to understand the basis and causal relationships of anomaly judgments in a graphical way, and serving as an important knowledge carrier for the subsequent evolution of the system.

[0131] In the embodiments of this application, after the system determines the final anomaly diagnosis result, it can first extract the corresponding target root cause information based on the result. Simultaneously, the system can also extract evidence information submitted by each agent during the diagnosis process, including log fragments, call chain latency performance, resource statistics, database waiting information, and each agent's analysis conclusions on the evidence. Furthermore, the system will record the confidence score after the debate process converges, serving as a quantitative basis for the influence of nodes in the graph.

[0132] In some embodiments, the above information can be transformed into structured graph nodes, where the target root cause forms the core root cause node, and the evidence information provided by each agent forms multiple evidence nodes. Different evidence nodes can be labeled according to information such as the source of evidence, the nature of evidence, and the direction of evidence support, so as to reflect their role in the diagnostic process in the graph. Subsequently, the system constructs the causal relationship between nodes according to the association logic between evidence and root cause, including causal order, intensity of effect, and degree of mutual corroboration of multiple pieces of evidence.

[0133] In the embodiments of this application, when constructing causal relationships, the system can refer to the direction and degree of influence of evidence on confidence during the debate stage. For example, when a piece of evidence continuously increases the confidence of a root cause hypothesis in multiple rounds of evidence exchange, the system can establish a strong association between the evidence node and the root cause node; conversely, when the supporting role of a piece of evidence is limited or unstable, a weak association or conditional association is established. In this way, the root cause map not only presents structural relationships but also reflects the actual contribution of evidence to the final diagnostic conclusion.

[0134] In some embodiments, the completed root cause map is presented visually, including displaying root causes and evidence as nodes, representing causal relationships with lines, and using color, line thickness, or node size to indicate the strength of evidence, confidence level, or correlation strength. Users can view the source, time location, supporting direction, and role of each piece of evidence during the diagnostic process through the map. The map can also be saved to the system for subsequent anomaly review, manual review, automated repair scheduling, or agent retraining.

[0135] By constructing a root cause map after anomaly diagnosis, embodiments of this application can organize the target root causes, evidence information, and converged confidence results formed during the diagnostic process in a structured manner, clearly demonstrating the causal relationship between root causes and evidence. Compared to simply outputting the final conclusion, the root cause map provides a complete reasoning chain, making the diagnostic process interpretable and traceable, helping users understand the system's judgment basis, and reducing the uncertainty brought about by black-box decision-making. In addition, the root cause map can also serve as an important data foundation for subsequent review, fault auditing, and model iterative training, thereby improving the system's adaptability and continuous optimization capabilities in long-term operation.

[0136] For example, root cause mapping can be used in human review scenarios. After the system provides an anomaly diagnosis, human reviewers can open the corresponding root cause map to view evidence nodes, causal paths, and confidence evolution to determine whether the system's reasoning is sufficient. Through the causal chains and evidence relationships displayed in the map, human reviewers can quickly identify key logical steps in the diagnostic process, thereby reducing the manual cost of reviewing logs, metrics, and call chain data one by one. In some embodiments, reviewers can directly add notes, risk labels, or manual correction information to the map, and the system will subsequently incorporate this human feedback as supplementary knowledge into the training of the diagnostic model.

[0137] For example, the agent can learn typical causal patterns, evidence combination features, and common diagnostic paths in different scenarios based on root cause graphs, enabling it to form accurate hypotheses more quickly when encountering similar anomalies again. In some embodiments, the system also continuously updates the agent model based on the correction rules of human reviewers and voting biases, thereby improving the stability and robustness of the system in subsequent diagnoses.

[0138] Corresponding to the above-described anomaly diagnosis method, embodiments of this application also provide an anomaly diagnosis device.

[0139] Figure 5 A schematic block diagram of an anomaly diagnosis device according to an embodiment of this application is shown.

[0140] like Figure 5 As shown, the anomaly diagnosis device 500 of this embodiment includes a data acquisition module 510, an evidence debate process triggering module 520, an evidence debate module 530, and an anomaly diagnosis module 540.

[0141] The data acquisition module 510 can be used to acquire multimodal log data of the target system, and use multiple agents with different diagnostic capabilities to perform parallel analysis on the multimodal log data to generate multiple root cause hypotheses and corresponding confidence levels. In one embodiment, the data acquisition module 510 can be used to perform the operation S210 described above, which will not be repeated here.

[0142] The evidence debate process triggering module 520 can be used to calculate the confidence difference based on the multiple confidence levels, and determine whether to trigger the evidence debate process based on the confidence difference. In one embodiment, the evidence debate process triggering module 520 can be used to execute the operation S220 described above, which will not be repeated here.

[0143] The evidence debate module 530 can be used to execute multiple rounds of evidence exchange and confidence updates in response to the need to trigger the evidence debate process, until the confidence difference is lower than a first preset threshold, and a converged confidence result is obtained. In one embodiment, the evidence debate module 530 can be used to execute the operation S230 described above, which will not be repeated here.

[0144] The anomaly diagnosis module 540 can be used to perform weighted voting decisions based on the converged confidence results and the historical contributions of the multiple agents to obtain anomaly diagnosis results for the target system. In one embodiment, the anomaly diagnosis module 540 can be used to perform the operation S240 described above, which will not be repeated here.

[0145] According to an embodiment of this application, the evidence debate module 530 can also be used to initiate an evidence debate process in response to detecting that the maximum confidence difference among the confidence differences exceeds a second preset threshold; in the evidence debate process, the master coordinator sends an evidence exchange request to the plurality of agents and obtains the debate information returned by the plurality of agents, wherein each agent performs a confidence update based on the debate information; and the master coordinator recalculates and updates the confidence difference based on the debate information, and in response to the updated confidence difference being higher than the first preset threshold, the operation of initiating the evidence debate process and updating the confidence is repeated until the confidence difference is lower than the first preset threshold.

[0146] According to an embodiment of this application, the evidence debate module 530 can also be used in each round of the evidence debate process to determine the direction of influence of the evidence information in the debate information on the corresponding root cause hypothesis; when the evidence information is supporting evidence, the corresponding agent increases its confidence value to perform confidence update; when the evidence information is counter-evidence, the corresponding agent decreases its confidence value to perform confidence update.

[0147] According to an embodiment of this application, the anomaly diagnosis module 540 can also be used to assign an initial contribution to each agent and record the corresponding historical contribution; calculate the basic weight of each agent based on the initial contribution and the historical contribution; dynamically adjust the basic weight according to the change in confidence and the debate round for each agent during multiple rounds of evidence debate to form an updated weight; and in response to obtaining the converged confidence result, calculate a comprehensive score based on the initial contribution and the updated weight, and perform a weighted voting decision based on the comprehensive score.

[0148] According to an embodiment of this application, the anomaly diagnosis module 540 can also be used to determine the static domain weight of each agent based on the initial contribution; and to perform long-term performance correction on the static domain weight based on the historical contribution to obtain the basic weight.

[0149] According to an embodiment of this application, the anomaly diagnosis module 540 can also be used to detect the change in confidence level of each agent after each round of evidence debate to determine the corresponding basic weight adjustment direction; and to set a decay factor according to the debate round, and dynamically adjust the basic weight based on the decay factor and the basic weight adjustment direction to form the updated weight.

[0150] According to an embodiment of this application, the anomaly diagnosis module 540 can also be used to assign a corresponding voting value to each root cause hypothesis based on the comprehensive score; and to compare and sort the voting values, and take the root cause hypothesis with the highest voting value as the target root cause, so as to obtain the anomaly diagnosis result of the target system.

[0151] According to an embodiment of this application, the anomaly diagnosis device 500 may further include a root cause display module. The root cause display module can be used to, in response to acquiring the anomaly diagnosis result, extract the target root cause corresponding to the anomaly diagnosis result, the evidence information provided by each agent, and the converged confidence result; and construct a root cause map containing root cause nodes, evidence nodes, and corresponding causal relationships based on the target root cause, the evidence information provided by each agent, and the converged confidence result. The root cause map is used to visually display the anomaly diagnosis result and the corresponding evidence relationships.

[0152] According to embodiments of this application, any multiple modules among the data acquisition module 510, the evidence debate process triggering module 520, the evidence debate module 530, and the anomaly diagnosis module 540 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the data acquisition module 510, the evidence debate process triggering module 520, the evidence debate module 530, and the anomaly diagnosis module 540 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the data acquisition module 510, the evidence debate process triggering module 520, the evidence debate module 530, and the anomaly diagnosis module 540 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0153] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing an anomaly diagnosis method according to an embodiment of this application.

[0154] like Figure 6As shown, an electronic device 600 according to an embodiment of this application includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0155] RAM 603 stores various programs and data required for the operation of electronic device 600. Processor 601, ROM 602, and RAM 603 are interconnected via bus 604. Processor 601 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 602 and / or RAM 603. It should be noted that the programs may also be stored in one or more memories other than ROM 602 and RAM 603. Processor 601 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0156] According to embodiments of this application, the electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output (I / O) interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output (I / O) interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0157] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0158] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 602 and / or RAM 603 and / or one or more memories other than ROM 602 and RAM 603 described above.

[0159] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the anomaly diagnosis method provided in the embodiments of this application.

[0160] When the computer program is executed by the processor 601, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0161] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0162] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from the removable medium 611. When the computer program is executed by the processor 601, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0163] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0164] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0165] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

[0166] The embodiments of this application have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of this application. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Without departing from the scope of this application, those skilled in the art can make various substitutions and modifications, all of which should fall within the scope of this application.

Claims

1. An abnormality diagnosis method, characterized in that, The method includes: Acquire multimodal log data of the target system, and use multiple agents with different diagnostic capabilities to perform parallel analysis on the multimodal log data to generate multiple root cause hypotheses and corresponding confidence levels. Calculate the confidence difference based on the multiple confidence levels, and determine whether to trigger the evidence debate process based on the confidence difference; In response to the need to trigger the evidence debate process, multiple rounds of evidence exchange and confidence updates are performed until the confidence difference is lower than a first preset threshold, thus obtaining a converged confidence result; and Based on the converged confidence results and the historical contributions of the multiple agents, a weighted voting decision is performed to obtain the anomaly diagnosis results of the target system.

2. The method according to claim 1, characterized in that, The response to triggering the evidence debate process involves performing multiple rounds of evidence exchange and confidence updates until the confidence difference falls below a first preset threshold, including: In response to the detection that the largest confidence difference among the confidence differences exceeds a second preset threshold, the evidence debate process is initiated; In the evidence debate process, the master coordinator sends evidence exchange requests to the multiple agents and obtains the debate information returned by the agents. Each agent then performs a confidence update based on the debate information. The main coordinator recalculates and updates the confidence difference based on the debate information. In response to the updated confidence difference being higher than the first preset threshold, the operation of initiating the evidence debate process and updating the confidence is repeated until the confidence difference is lower than the first preset threshold.

3. The method according to claim 1 or 2, characterized in that, Perform confidence updates, including: In each round of the evidence debate process, each agent determines the direction of the influence of the evidence information in the debate information on the corresponding root cause hypothesis; When the evidence information is supporting evidence, the corresponding agent increases its confidence value to perform a confidence update; When the evidence is contradictory, the corresponding agent lowers its confidence value to perform a confidence update.

4. The method according to claim 1 or 2, characterized in that, The weighted voting decision based on the converged confidence result and the historical contributions of the multiple agents includes: Assign an initial contribution to each agent and record the corresponding historical contribution. Calculate the basic weight of each agent based on the initial contribution and the historical contribution. During multiple rounds of evidence debate, the basic weights are dynamically adjusted based on the changes in confidence level for each agent and the number of debate rounds, resulting in updated weights; and In response to obtaining the converged confidence result, a comprehensive score is calculated based on the initial contribution and the updated weights, and a weighted voting decision is performed based on the comprehensive score.

5. The method according to claim 4, characterized in that, The calculation of the basic weight of each agent based on the initial contribution and the historical contribution includes: The static domain weight of each agent is determined based on the initial contribution. as well as The static domain weights are adjusted based on the historical contribution to obtain the base weights.

6. The method according to claim 4, characterized in that, The step of dynamically adjusting the basic weights based on the confidence changes and debate rounds for each agent to form updated weights includes: After each round of evidence debate, the change in confidence level of each agent is detected to determine the corresponding direction of basic weight adjustment. as well as A decay factor is set according to the debate rounds, and the basic weights are dynamically adjusted based on the decay factor and the adjustment direction of the basic weights to form the updated weights.

7. The method according to claim 4, characterized in that, The weighted voting decision based on the comprehensive score includes: Based on the comprehensive score, a corresponding vote value is assigned to each root cause hypothesis; as well as The voting values ​​are compared and ranked, and the root cause hypothesis with the highest voting value is taken as the target root cause to obtain the abnormal diagnosis result of the target system.

8. The method according to claim 1 or 7, characterized in that, The method further includes: In response to obtaining the abnormal diagnosis result, the target root cause corresponding to the abnormal diagnosis result, the evidence information provided by each agent, and the converged confidence result are extracted; as well as Based on the target root cause, the evidence information provided by each agent, and the converged confidence results, a root cause graph is constructed that includes root cause nodes, evidence nodes, and corresponding causal relationships. The root cause graph is used to visualize the abnormal diagnosis results and the corresponding evidence relationships.

9. An abnormality diagnostic device, characterized in that, The device includes: The data acquisition module is used to: acquire multimodal log data of the target system, perform parallel analysis on the multimodal log data using multiple agents with different diagnostic capabilities, and generate multiple root cause hypotheses and corresponding confidence levels. The evidence debate process triggering module is used to: calculate the confidence difference based on the multiple confidence levels, and determine whether to trigger the evidence debate process based on the confidence difference; The evidence debate module is used to: in response to the need to trigger the evidence debate process, execute multiple rounds of evidence exchange and confidence updates until the confidence difference is lower than a first preset threshold, thereby obtaining a converged confidence result; and An anomaly diagnosis module is used to: perform weighted voting decisions based on the converged confidence results and the historical contributions of the multiple agents to obtain anomaly diagnosis results for the target system.

10. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

Images