Batch fault abnormity positioning method based on man-machine cooperation and comparative analysis

Abstract

The invention relates to a batch fault abnormity positioning method based on man-machine cooperation and comparative analysis, and the method comprises the following steps: 1, collecting multi-source original fault data, evaluating whether the data meets the feasible conditions of batch fault diagnosis or not, obtaining a final evaluation result, and generating a standardized table mapping suggestion; 2, through structure and integrity verification, semantic check and automatic repair and executable verification, obtaining tabular data which is subjected to structure and semantic verification and potential problem correction and is confirmed to be generated and can be directly executed; and step 3, obtaining historical experience most similar to the current scene through searching a historical scene library and matching, obtaining a recommended diagnosis strategy, performing lightweight trial operation on each candidate strategy, comparing to obtain a most suitable strategy, and further performing a final search process on complete data, discovering a key attribute mode and a complete anomaly positioning report. According to the invention, an end-to-end intelligent diagnosis process from scene identification, data verification to abnormal positioning can be realized.

Description

Technical Field

[0001] This invention belongs to the field of intelligent operation and maintenance and anomaly location technology, and relates to a batch fault and anomaly location method, especially a batch fault and anomaly location method based on human-machine collaboration and comparative analysis. Background Technology

[0002] With the rapid development of cloud computing technology, large-scale cloud platforms have become the infrastructure of modern computing systems, widely supporting critical services globally. These systems typically integrate various hardware and software components, providing computing, storage, and online business support to millions of users. However, the complexity of the systems and the expansion of the user base also bring operational risks—infrastructure failures or misconfigurations of business logic can often trigger large-scale service outages in a very short time, affecting tens of thousands of users.

[0003] In cloud platform operations and maintenance, a large number of simultaneous failures occurring on the same system object within a concentrated timeframe are termed batch failures. These failures typically originate from a single root cause (such as configuration errors, resource contention, or underlying component failure), and can propagate rapidly, leading to severe performance degradation or service unavailability. Efficiently locating and diagnosing these batch failures (i.e., "anomaly localization") becomes a critical task for ensuring the stable operation of the cloud platform.

[0004] In recent years, academia and industry have proposed a series of anomaly localization methods based on comparative analysis. For example, the CONAN framework can perform unified modeling and localization of batch faults through feature difference mining. However, in engineering practice, when operations engineers try to integrate such algorithms into actual diagnostic processes, they still face several challenges that urgently need to be addressed: 1. Ambiguous Scene Judgment: After receiving alarms or incident reports, engineers often find it difficult to determine whether the current fault belongs to a batch scenario and whether the existing data meets the applicable conditions for comparative analysis methods. Due to the diverse formats and complex semantics of raw data in cloud systems (such as logs, call chains, metrics, structured reports, etc.), the scene recognition and data mapping process is highly dependent on human experience.

[0005] 2. Unreliable Data Quality: Anomaly localization for batch failures relies on converting raw operational data into structured tables for differential analysis. However, in practice, data often suffers from imbalanced labels, inconsistent attribute definitions, and hidden missing values, leading to unstable or even failed localization algorithms. Existing methods generally assume good input data quality but lack executable verification and remediation mechanisms for real-world environments.

[0006] 3. Difficulty in adapting diagnostic strategies: Even with compliant data, it is still necessary to select appropriate objective functions and search strategies for different fault types, and to reasonably configure parameters (such as the number of iterations, pattern size, search range, etc.). Currently, most research focuses on algorithm design itself, lacking strategy recommendations and parameter adaptation guidance for engineering practice, resulting in problems such as low diagnostic efficiency and large result bias.

[0007] In summary, existing batch fault diagnosis technologies are still insufficient to achieve a unified end-to-end process from scene recognition and data verification to anomaly localization. There is an urgent need for an intelligent diagnostic framework with human-machine collaboration capabilities to reduce the cognitive burden on engineers and improve the automation and accuracy of batch fault handling.

[0008] Research revealed that the domestic and international academic and industrial communities have conducted extensive research on the automated diagnosis and anomaly localization of batch faults in large-scale cloud platforms, which can be mainly divided into the following three directions: 1. An exception location method based on logs and call chains.

[0009] These methods reconstruct anomaly propagation paths by analyzing system logs, call relationships, or distributed tracing information, thereby pinpointing potential root causes. For example, the HALO (Hierarchy-Aware Fault Localization) framework proposed by Zhang et al. addresses the complex hierarchical structure of multidimensional telemetry data in cloud systems, proposing a hierarchical-aware fault localization method. This method automatically learns the hierarchical relationships between system attributes and combines anomaly clustering patterns of feature value combinations to achieve efficient and fine-grained fault attribution. The CrashLocator system proposed by Wu et al. focuses on software crash scenarios, locating suspicious functions by analyzing call stack information in crash reports. This method uses a static call graph to expand the crash stack to infer possible abnormal execution paths and ranks and recommends functions based on their "suspiciousness" score, thus helping developers quickly identify potential fault sources. [Zhang, Xu, et al. "Halo: Hierarchy-aware fault localization for cloud systems." Proceedings of the 27th ACM SIGKDD Conference onKnowledge Discovery&Data Mining. 2021.][Wu, Rongxin, et al. "Crashlocator: Locating crashing faults based on crash stacks." Proceedings of the 2014International Symposium on Software Testing and Analysis. 2014.] Method limitations: This type of method can only effectively handle log-based and call chain-based exception scenarios, and it relies on precise log structures and complete call chain data, making it difficult to adapt to heterogeneity and data loss issues between different systems.

[0010] 2. Fault diagnosis method based on performance indicators and statistical modeling.

[0011] Another type of research focuses on anomaly detection and causal analysis of multidimensional monitoring indicators. For example, Sun et al. proposed the HotSpot framework, which uses a potential scoring model based on the "ripple effect" to capture anomaly propagation relationships for key performance indicators (KPIs) with multidimensional attributes (such as operators, provinces, data centers, etc.). This framework combines Monte Carlo Tree Search with hierarchical pruning strategies to efficiently locate the root causes of performance degradation in a large-scale attribute combination space. Li et al.'s Generic (PSqueeze) model further proposes the "Generalized Ripple Effect" (GRE) property of multidimensional data root causes, constructing a general localization framework based on probabilistic clustering and heuristic search. This method can not only quickly identify anomalous attribute combinations in multidimensional space, but also, for the first time, emphasizes the importance of distinguishing between internal and external root causes and achieves automated discrimination. [Sun, Yongqian, et al. "Hotspot: Anomaly localization for additive kpis with multi-dimensionalattributes." IEEE Access 6 (2018): 10909-10923.][Li, Zeyan, et al. "Genericand robust root cause localization for multi-dimensional data in onlineservice systems." Journal of Systems and Software 203 (2023): 111748.] Method limitations: These methods perform well only on indicator data, but have limited capabilities when dealing with complex structured reports, crash logs, and other data; at the same time, they usually assume that data labels and feature spaces have been manually organized, and lack the ability to automatically verify data in real production environments.

[0012] 3. A unified diagnostic framework based on contrast analysis.

[0013] In recent years, researchers have begun to explore unified modeling approaches across different types of batch failure scenarios. A representative work is the CONAN framework proposed by Li et al., which aims to automate the root cause localization process for batch failures. Its core idea is to first transform multi-source data from logs, call chains, metrics, etc., into a unified "attribute-value pair" (AVP) format to describe the contextual features of each instance; then, by comparing the differences between the failure group and the background group (e.g., failure vs. success, anomaly vs. normal), it automatically searches for contrast patterns that can significantly distinguish between the two groups of instances. To this end, CONAN designs a pattern mining algorithm based on metaheuristic search and combines it with a hierarchical concept integration mechanism to efficiently discover interpretable feature combinations in high-dimensional space. The framework theoretically achieves unified modeling and difference analysis for multiple types of failure scenarios. [Li, Liqun, et al. "Conan: Diagnosing batch failures for cloud systems." 2023 IEEE / ACM 45thInternational Conference on Software Engineering: Software Engineering inPractice (ICSE-SEIP). IEEE, 2023.] Method limitations: Such methods only have good generality and scalability in theory, but have obvious limitations in engineering practice: First, it requires manual judgment to determine whether the current scenario meets the algorithm's preconditions; second, the data transformation, cleaning, and label definition processes are highly dependent on expert experience; third, the algorithm parameters and search strategies lack adaptive and interpretable guidance, which limits the actual diagnostic efficiency and accuracy.

[0014] In summary, while existing research has made some progress in algorithm design, the following prominent problems and shortcomings still exist in practical engineering applications: 1. The lack of automated scene recognition and applicability assessment mechanisms makes it difficult to guide engineers in determining appropriate diagnostic methods in multi-source, heterogeneous data environments; 2. The lack of executable data quality verification and semantic consistency check tools makes diagnostic results susceptible to data bias. 3. The lack of intelligent parameter configuration and strategy recommendation mechanisms makes the algorithm's effectiveness highly dependent on human experience and repeated trial and error.

[0015] Therefore, current batch fault intelligent diagnosis technology is still unable to achieve an end-to-end integrated closed loop from "scenario confirmation - data verification - anomaly location", and cannot meet the actual needs of cloud platforms for high reliability and high maintainability.

[0016] To address the aforementioned technical problems, this invention proposes a batch fault and anomaly localization method based on human-machine collaboration and comparative analysis. Summary of the Invention

[0017] To address the shortcomings of existing technologies, this invention proposes a batch fault anomaly localization method based on human-machine collaboration and comparative analysis. This method can uniformly manage and analyze a large amount of batch fault data generated during the operation of the cloud platform, and realize an end-to-end intelligent diagnostic process from scene recognition, data verification to anomaly localization.

[0018] The above-mentioned objective of this invention is achieved through the following technical solution: A batch fault anomaly localization method based on human-machine collaboration and comparative analysis includes the following steps: Step 1: Collect raw fault data from multiple sources, assess whether the conditions for batch fault diagnosis are met, obtain the final assessment results and generate standardized table mapping suggestions; Step 2: After confirming in Step 1 that the input multi-source data is suitable for batch diagnostic scenarios, the system performs structure and integrity verification, semantic inspection and automatic repair, and executability verification to obtain tabular data that has been verified for structure and semantics, corrected for potential problems, and confirmed to be directly executable. Step 3: Based on the directly executable tabular data generated in Step 2, the historical scenario library is searched to match the historical experience most similar to the current scenario, and a recommended diagnostic strategy is obtained. The most suitable strategy is compared by performing a lightweight trial run on each candidate strategy, and then the final search process is performed on the complete data to discover key attribute patterns and a complete anomaly localization report.

[0019] Furthermore, the specific steps of step 1 include: (1) Collect raw fault data from multiple sources and preprocess it to obtain a structured and readable set of multi-source data; (2) Perform field-level parsing on the multi-source dataset and generate a structured data summary file; (3) Based on the criterion evaluation protocol, the applicability of the structured data summary file is evaluated, the input data is quantitatively determined to be suitable for batch fault diagnosis, and a criterion evaluation report is generated; (4) Interactively confirm and revise the criterion evaluation report, and output the final evaluation result after user confirmation; (5) Based on the final evaluation results and structured data summary files, generate standardized table mapping suggestions.

[0020] Furthermore, the specific method for evaluating the applicability of structured data digest files based on the criterion evaluation protocol in step 1 (3) is as follows: ① The system calls the criterion evaluation protocol and executes the five key criteria sequentially: - C1 Subject Consistency: Analyze the values ​​in the fields related to product, service, or system identifiers to determine if multiple subjects exist; - C2 Batch Size: Counts the number of instances and determines whether a preset threshold has been reached; - C3 Background Class Presence: Detects whether there is a category that can be used as a control (such as a non-target group or normal sample). - C4 Contextual Integrity: Analyze the contextual relationships between fields to determine whether key influencing attributes can be extracted; - C5 Attribute Semantic Clarity: Determines whether the field name and value have interpretable semantics.

[0021] ②If any criterion does not meet the requirements, the system records an "Inapplicable" status and a prompt for the data type to be supplemented; ③ If all criteria are met, mark it as a "diagnosable" scenario.

[0022] Furthermore, the specific steps of step 2 include: (1) Based on the tabular data of confirmed scenario applicability output in step 1 and the pre-set field check rule set, obtain tabular data that has been verified for structure and integrity; (2) Based on the semantic verification and repair toolset, perform semantic verification and automatic repair to obtain semantic check result logs and repaired intermediate data files; (3) Based on the tabular data that has passed semantic verification and repair, perform executability verification and trial operation to confirm that the generated tabular data can be directly executed.

[0023] Furthermore, the specific steps of step 3 include: (1) Construct a searchable historical scene library and generate a semantic vector and structural feature mapping table for each historical case; (2) Based on the constructed searchable historical scene library, the historical experience closest to the current scene is automatically identified through semantic retrieval, and a sorted set of similar scenes and recommended diagnostic strategy suggestions are obtained, including the objective function and search strategy and their parameter configuration, so as to realize the experience transfer and rapid positioning at the strategy level; (3) Based on the obtained set of similar scenarios and strategy suggestions, as well as the tabular data and diagnostic objectives of the current scenario, the strategy with the best performance and highest stability is obtained by performing a lightweight trial run on each candidate strategy. Finally, the final search process is performed on the complete data according to the strategy to discover key attribute patterns and obtain a complete anomaly localization report.

[0024] The advantages and positive effects of this invention are as follows: 1. This invention proposes a batch fault anomaly localization method based on human-machine collaboration and comparative analysis. Through a multi-stage human-machine collaborative process of "scenario confirmation—data verification—anomaly localization," an end-to-end integrated closed-loop batch fault diagnosis system is constructed. This method effectively overcomes the key bottlenecks of existing research, such as "strong reliance on manual intervention, difficulty in adapting to heterogeneous data, and difficulty in guiding strategies," achieving intelligent closed-loop decision-making from scenario to algorithm, significantly improving the accuracy, efficiency, and engineering reusability of anomaly localization. This invention can generate a complete anomaly localization report, covering similar anomalies, potential anomaly causes, and corresponding solutions. Through this invention, engineers can quickly obtain clear and actionable diagnostic suggestions, reducing the time cost of manual analysis and strategy adjustment, and improving the efficiency and accuracy of fault handling. Addressing the problem of "lack of automated scenario identification and applicability judgment mechanisms," this invention automatically parses the input data type, attribute relationships, and tag semantics through scenario confirmation and structured summarization steps to determine whether the current scenario is suitable for batch anomaly localization, thereby achieving automatic identification and method adaptation for multi-source heterogeneous data.

[0025] 2. This invention addresses the problem of "lack of data quality verification and semantic consistency checks" by designing a multi-dimensional checking mechanism in the data verification stage. This mechanism covers aspects such as sample size, existence of background classes, attribute completeness, and time consistency, automatically identifying data defects and generating correction suggestions, thereby ensuring the structural rationality and semantic consistency of diagnostic input.

[0026] 3. This invention addresses the problem that "diagnostic methods are difficult to adapt to heterogeneity and data loss between different systems." It adopts a unified data mapping and abstract representation framework to transform data from different sources such as logs, metrics, and crash reports into a unified tabular structure, supporting missing value detection and field hierarchical analysis, effectively improving the cross-scenario applicability and robustness of the algorithm.

[0027] 4. In response to the problem that "parameter configuration and strategy recommendation rely on human experience", this invention introduces an automatic strategy recommendation mechanism based on retrieval augmentation generation (RAG) during the anomaly localization stage. By constructing a historical scene library, semantically retrieving similar cases, and a lightweight trial operation process, the optimal objective function and search strategy are intelligently selected, thereby significantly reducing the burden of manual parameter tuning.

[0028] 5. This invention addresses the problem of "lack of interpretability and engineering usability of algorithm results" by providing a structured anomaly location report during the result output stage. This helps engineers quickly understand the causes of anomalies and corresponding solutions, thereby achieving transparency and operability of the results. Attached Figure Description

[0029] Figure 1 This is a method framework diagram of the present invention; Figure 2This is a flowchart of the scenario confirmation stage of the present invention; Figure 3 This is a flowchart of the data verification stage of the present invention; Figure 4 This is a flowchart of the anomaly localization stage of the present invention; Figure 5 This is a schematic diagram of the anomaly location report of the present invention; Figure 6 This is a schematic diagram of the implementation stages of the present invention. Detailed Implementation

[0030] The structure of the present invention will be further described below with reference to the accompanying drawings and embodiments. It should be noted that these embodiments are descriptive and not limiting.

[0031] A batch fault and anomaly localization method based on human-machine collaboration and comparative analysis, such as Figures 1 to 5 As shown, it includes the following steps: Step 1: Collect raw fault data from multiple sources, assess whether the conditions for batch fault diagnosis are met, obtain the final assessment results and generate standardized table mapping suggestions; The specific steps of step 1 include: (1) Collect raw fault data from multiple sources and preprocess it to obtain a structured and readable set of multi-source data; (2) Perform field-level parsing on the multi-source dataset and generate a structured data summary file; (3) Based on the criterion evaluation protocol, the applicability of the structured data summary file is evaluated, the input data is quantitatively determined to be suitable for batch fault diagnosis, and a criterion evaluation report is generated; The specific method for evaluating the applicability of structured data digest files based on the criterion-based evaluation protocol in step 1 (3) is as follows: ① The system calls the criterion evaluation protocol and executes the five key criteria sequentially: - C1 Subject Consistency: Analyze the values ​​in the fields related to product, service, or system identifiers to determine if multiple subjects exist; - C2 Batch Size: Counts the number of instances and determines whether a preset threshold has been reached; - C3 Background Class Presence: Detects whether there is a category that can be used as a control (such as a non-target group or normal sample). - C4 Contextual Integrity: Analyze the contextual relationships between fields to determine whether key influencing attributes can be extracted; - C5 Attribute Semantic Clarity: Determines whether the field name and value have interpretable semantics.

[0032] ②If any criterion does not meet the requirements, the system records an "Inapplicable" status and a prompt for the data type to be supplemented; ③ If all criteria are met, mark it as a "diagnosable" scenario.

[0033] (4) Interactively confirm and revise the criterion evaluation report, and output the final evaluation result after user confirmation; (5) Based on the final evaluation results and structured data summary files, generate standardized table mapping suggestions; In this embodiment, step 1: scene confirmation The scenario verification phase aims to determine whether the input data meets the feasibility conditions for batch fault diagnosis, ensuring that subsequent data verification and anomaly localization are carried out on an appropriate basis. By analyzing multi-source heterogeneous data, this phase can identify scenarios unsuitable for batch diagnosis in advance, avoid invalid calculations, and provide standardized data mapping suggestions. The outputs of this step are: diagnosticability conclusions for the input data and tabular data mapping suggestions.

[0034] Sub-steps: S1: Multi-source data reception and preprocessing Input: Raw fault data from multiple sources in the cloud platform operation and maintenance system, including but not limited to log files, JSON format reports, monitoring indicator files and statistical tables.

[0035] operate: 1. The system automatically identifies the type and encoding format of the input file; 2. Perform lightweight data preprocessing operations, including character encoding standardization, format correction, and file count; 3. Establish a data source index to provide a data access path for subsequent parsing stages.

[0036] Output: A structured, readable collection of multi-source data.

[0037] Function: To provide a unified input interface for subsequent structured parsing, solving the problem of difficulty in directly parsing multi-source heterogeneous data.

[0038] S2: Input Parsing and Structured Summarization Generation Input: The multi-source data set output from step S1.

[0039] operate: 1. Perform field-level parsing on various input files to extract the file hierarchy and field names; 2. Extract a representative sample of rows and generate examples of field values ​​and data type inference results; 3. Organize the parsed results into a "data structure summary table", which includes field names, data types, sample values, and source file information; 4. Store the generated summary table as input for subsequent criterion evaluation.

[0040] Output: Structured data summary file (including field metadata and sample statistics).

[0041] Function: To achieve a unified representation of heterogeneous data, so that a structured overview can be obtained without manually viewing the file content.

[0042] S3: Criterion-driven applicability assessment Input: Structured data summary file.

[0043] operate: 1. The system invokes the criterion evaluation protocol, executing five key criteria sequentially: - C1 Subject Consistency: Analyze the values ​​in the fields related to product, service, or system identifiers to determine if multiple subjects exist; - C2 Batch Size: Counts the number of instances and determines whether a preset threshold has been reached; - C3 Background Class Presence: Detects whether there is a category that can be used as a control (such as a non-target group or normal sample). - C4 Contextual Integrity: Analyze the contextual relationships between fields to determine whether key influencing attributes can be extracted; - C5 Attribute Semantic Clarity: Determines whether the field name and value have interpretable semantics.

[0044] 2. If any criterion fails to meet the requirements, the system records an "Inapplicable" status and a prompt indicating the data type that needs to be supplemented; 3. If all criteria are met, mark the scenario as "diagnosable".

[0045] Output: - Criterion evaluation report (including pass / fail results for five criteria); - Preliminary diagnostic conclusion (diagnosable / undiagnosable).

[0046] Function: Through a formalized Fault Tree Analysis (FTA) protocol, it quantitatively determines whether the input data is suitable for batch fault diagnosis, avoiding invalid calculations.

[0047] S4: Interactive Confirmation and Correction Input: Criterion evaluation report from step S3.

[0048] operate: 1. Present the evaluation results of the criteria in a visual manner (e.g., display the pass status of each criterion and suggested supplementary items through the interface); 2. Allow engineers to correct system judgments item by item (such as manually confirming subject consistency, supplementing sample label information, etc.); 3. Record the engineer's corrective actions and update the final diagnostic conclusions.

[0049] Output: The final evaluation result after user confirmation.

[0050] Function: To retain a human intervention channel on the basis of automated judgment, thereby improving the accuracy and interpretability of the judgment.

[0051] S5: Output Results and Tabular Mapping Generation Input: Confirmed diagnostic findings and structured summary.

[0052] operate: 1. If a scenario is determined to be "diagnosable," the system automatically generates a tabular mapping suggestion, including: - Instance definition (the semantic unit of each record); - List of attribute fields; - Label column definition (such as fault group, severity, or aggregate metric); 2. If the scenario is "not applicable", output the reason and suggestions for data supplementation.

[0053] Output: - Final diagnostic conclusion (diagnosable / undiagnosable); - Standardized table mapping suggestions can be directly used as data validation input for the next stage.

[0054] Function: To provide a standard data input format that seamlessly connects with subsequent stages, forming an automated closed loop.

[0055] The principle behind step 1 is as follows: Addressing the challenges in cloud platform operation and maintenance—specifically, the ambiguity of scenario judgment (engineers struggle to determine whether a current fault belongs to a batch scenario) and the multi-source heterogeneity and semantic complexity of raw data, leading to a high reliance on human experience for scenario identification—this phase achieves automated judgment through structured parsing combined with a criterion-driven applicability protocol. This protocol formalizes the preconditions for batch diagnosis, quantifying the assessment of subject consistency, batch size, existence of background classes, contextual completeness, and semantic clarity of attributes, thereby overcoming the shortcomings of existing methods in lacking automated scenario identification and applicability judgment. Simultaneously, interactive confirmation preserves the engineer's judgment ability, effectively combining automation with human experience to ensure the accuracy and interpretability of diagnostic judgments.

[0056] Step 1 forms a closed-loop operation through five sub-steps, significantly improving the automation level of scene recognition. In the steps of multi-source data reception and preprocessing, and input parsing and structured summary generation, the system automatically identifies multi-source heterogeneous data and generates structured summaries, reducing the burden of manual processing. In the criterion-driven applicability evaluation step, the preconditions for batch diagnosis are formally expressed, enabling the system to automatically determine whether the data is suitable for anomaly localization, avoiding invalid calculations and inefficient processes. In the interactive confirmation and correction step, engineers can visually confirm or correct the judgment results, achieving an organic combination of automation and human experience. Overall, this module not only solves the problems of ambiguous scene judgment and reliance on human experience in traditional methods, but also provides standardized and directly executable inputs for subsequent data verification and anomaly localization, laying a reliable foundation for the entire diagnostic process.

[0057] Specifically, in step 1: 1. S1 and S2 generate structured summaries through unified formatting and automatic extraction of field structure, data type and sample information, reducing the burden of manual processing and thus solving the problem of "complex multi-source heterogeneous input structure and time-consuming manual parsing".

[0058] 2.S3 uses an automated evaluation mechanism based on a criterion protocol to formally express the preconditions for batch fault diagnosis, quantify the consistency of the judgment subjects, the batch size, and the semantic clarity of attributes, thereby solving the problem that "engineers have difficulty accurately determining whether the current fault belongs to a batch scenario".

[0059] 3.S4 introduces a visual interaction and manual verification mechanism, enabling engineers to review and correct the system's judgment results, thereby solving the problems of "lack of interpretability in automated judgment and high risk of misjudgment".

[0060] 4.S5 solves the problem of "lack of standardized output and inability to use it directly in subsequent stages" by automatically generating tabular mapping schemes, clarifying instance definitions, attribute fields and label columns, and forming a standard input format that can be directly used for data validation and anomaly location.

[0061] 5. S1–S5 achieves closed-loop processing from multi-source inputs to diagnostic conclusions and mapping outputs through full-process automation design, thereby solving the problems of "low efficiency in scenario confirmation and non-reusable processes".

[0062] Step 2: After confirming in Step 1 that the input multi-source data is suitable for batch diagnostic scenarios, the system performs structure and integrity verification, semantic inspection and automatic repair, and executability verification to obtain tabular data that has been verified for structure and semantics, corrected for potential problems, and confirmed to be directly executable. The specific steps of step 2 include: (1) Based on the tabular data of confirmed scenario applicability output in step 1 and the pre-set field check rule set, obtain tabular data that has been verified for structure and integrity; (2) Based on the semantic verification and repair toolset, perform semantic verification and automatic repair to obtain semantic check result logs and repaired intermediate data files; (3) Based on the tabular data that has passed semantic verification and repair, perform executability verification and trial operation to confirm that the generated tabular data can be directly executed.

[0063] In this embodiment, step 2, data verification After confirming the applicability of the input data to batch diagnostic scenarios, this stage aims to ensure the structural integrity and semantic rationality of the tabular data, providing reliable and executable input for anomaly localization. The output of this step is: tabular data that has undergone structural and semantic verification, potential problem correction, and is ready for direct execution.

[0064] Sub-steps: S1: Structure and Integrity Verification enter: - Tabular data output from the previous stage ("Scenario Confirmation") (Scenario applicability confirmed). - A predefined set of field checking rules, including: label column, attribute column, time column, and a list of required fields.

[0065] operate: 1. The system automatically scans the table structure, generates a field structure summary, and counts the field names, types, missing rates, and number of unique values.

[0066] 2. Check if the label column exists and if there is sufficient sample contrast (if the difference in the number of rows between the target class and the background class is too large, mark it as "weak label contrast").

[0067] 3. Check if there are any missing or incorrectly defined attribute columns (such as numeric fields being incorrectly labeled as string fields, or incorrect units), and record the exceptions.

[0068] 4. Check the time field: If there are misaligned or unstandardized time formats, generate standardization suggestions.

[0069] 5. If a hidden missing value is detected (such as an empty string, the string "NaN", etc.), the system will automatically replace it with a standard missing value identifier.

[0070] Output: - Preliminary report on structure and integrity, including field anomaly statistics, label distribution, and potential risk items; - An updated copy of the table data, for use in subsequent semantic validation.

[0071] effect: Before data enters semantic verification, potential structural problems are identified and located to ensure the integrity and basic consistency of the input data, thereby reducing the cost of manual inspection.

[0072] S2: Semantic Inspection and Automatic Repair enter: - Structure-validated tabular data; - A semantic verification and repair toolset, including: - count_rows_by_col (label discrimination statistics); - describe_column (attribute statistical feature extraction); - count_sum_by_col (validation of aggregate field validity); - Repair functions such as continuous value discretization and hierarchical structure reorganization.

[0073] operate: 1. Call the semantic validation function set to perform semantic consistency checks on each field: - Tag semantic check: Verify whether the target class and the background class can be distinguished; - Attribute validity check: Whether the field type and meaning match the expectations; - Time attribute determination: Determines whether to retain, align, or use it to divide data segments.

[0074] 2. Automatic repair process: - Perform discretization or normalization on continuous values; - Perform reorganization on fields with hierarchical relationships (such as node → cluster → data center); - Implement supplementation or deletion strategies for missing or invalid fields.

[0075] 3. The execution order is automatically controlled by the system to ensure that dependencies are repaired correctly (fields are repaired first, then tags).

[0076] Output: - Semantic inspection result log; - The repaired intermediate data files can be directly put into the trial operation phase.

[0077] effect: Automated repair is achieved through a systematic and executable semantic verification toolset, avoiding the arbitrariness and omissions of manual operation and ensuring that the data meets the semantic requirements for anomaly location.

[0078] S3: Execution verification and trial operation enter: - Semantically validated tabular data; - Default target function and quick verification parameter configuration.

[0079] operate: 1. Extract Attribute-Value Pair Collection (AVP) to verify the executability of data.

[0080] 2. Automatically select the default objective function (such as aggregate or fractional) and perform a lightweight trial run: - Run a fast dry test search algorithm; - Verify whether the pattern score output is reasonable; - Record runtime logs and intermediate results.

[0081] 3. The system generates a verification report and prompts for manual confirmation.

[0082] Output: - Executability verification result (success / requires repair); - Verification report and log files; - The final table data that can be directly accessed by the anomaly location module.

[0083] effect: Before formal operation, the algorithm's executability is verified to ensure that the data is not only "structurally correct" but also "semantically usable and reliably executed," providing stable input for anomaly localization.

[0084] Step 2 describes the method's principle: Addressing the challenges of unreliable data quality in cloud platform operations and maintenance—specifically, the often unbalanced labels, inconsistent attribute definitions, and hidden missing values ​​in raw operational data leading to unstable or even invalid anomaly localization results—this phase employs a systematic and executable toolset to uniformly verify and repair structural integrity, semantic rationality, and executability. Compared to existing methods, this mechanism avoids the limitations of traditional methods that assume perfect data or rely on manual checks, ensuring the stability and reliability of the anomaly localization algorithm.

[0085] Step 2 combines verification and remediation into a three-step closed-loop process, identifying potential problems and providing automated correction. Specifically, structural and integrity checks reduce manual investigation costs, semantic checks and automatic remediation ensure fields and tags meet anomaly localization requirements, and trial runs verify data executability. Overall, the system not only solves the problem of unstable diagnosis caused by data deviation in traditional methods, but also systematizes and repeats the data verification process through lightweight, callable tools, providing a solid foundation for subsequent anomaly localization while significantly reducing the cognitive burden on engineers.

[0086] Specifically, in step 2: 1.S1 automatically extracts field structure, data type, and sample information through unified formatting and structured summary generation, reducing the burden of manual processing and thus solving the problem of "complex multi-source heterogeneous input structure and time-consuming manual parsing".

[0087] 2.S2 utilizes a set of semantic inspection functions (field type identification, statistical description, aggregation validation, etc.) to automatically determine the consistency of field meanings and repair abnormal mappings, thereby solving the problem of "algorithm failure caused by unclear attribute semantics and inconsistent definitions". Furthermore, through continuous value discretization and hierarchical structure reorganization functions, it transforms original complex fields (such as node → cluster → data center) into analyzable features, thus solving the problem of "complex field structures not being able to directly participate in anomaly localization".

[0088] 3.S3 introduces lightweight dry running tests in the data verification closed loop. By quickly executing the default objective function and pattern search, it can discover unexecutable data problems in advance, thereby solving the problem of "the data structure is correct but the algorithm fails or the results are unstable".

[0089] 4. The sequential execution of S1–S3 forms a complete closed loop of structure inspection, semantic repair, and executability verification, reducing human intervention and reliance on experience, thus solving the problems of "manual repair being prone to omissions and verification not being repeatable." Furthermore, the entire process (S1–S3) ensures the dual consistency of the input data structure and semantics through a unified verification-repair-trial operation mechanism, thereby solving the problem of "data quality fluctuations leading to unstable anomaly localization results."

[0090] Step 3: Based on the directly executable tabular data generated in Step 2, the historical scenario library is searched to match the historical experience most similar to the current scenario, and a recommended diagnostic strategy is obtained. The most suitable strategy is compared by performing a lightweight trial run on each candidate strategy, and then the final search process is performed on the complete data to discover key attribute patterns and a complete anomaly localization report. The specific steps of step 3 include: (1) Construct a searchable historical scene library and generate a semantic vector and structural feature mapping table for each historical case; (2) Based on the constructed searchable historical scene library, the historical experience closest to the current scene is automatically identified through semantic retrieval, and a sorted set of similar scenes and recommended diagnostic strategy suggestions are obtained, including the objective function and search strategy and their parameter configuration, so as to realize the experience transfer and rapid positioning at the strategy level; (3) Based on the obtained set of similar scenarios and strategy suggestions, as well as the tabular data and diagnostic objectives of the current scenario, the strategy with the best performance and highest stability is obtained by performing a lightweight trial run on each candidate strategy. Finally, the final search process is performed on the complete data according to the strategy to discover key attribute patterns and obtain a complete anomaly localization report.

[0091] In this embodiment, step 3, anomaly location After data validation in the first two stages, this step automatically recommends and validates diagnostic strategies by combining historical scenario knowledge and semantic retrieval. It then executes the final search process on complete data to discover key attribute patterns. The output of this step includes: the finalized objective function and search strategy, and a complete anomaly localization report.

[0092] Sub-steps: S1: Building a Historical Scene Library enter: - Original records of historical fault cases and their manually confirmed diagnostic conclusions.

[0093] operate: 1. Standardize the format of historical cases and extract the following elements: - Scenario description text (including system environment, abnormal phenomena, scope of impact, etc.); - Instance definition and property list; - The objective function, search strategy, and parameter configurations already adopted; - Reasoning basis and summary of results for strategy selection.

[0094] 2. Jointly embed text and structured information into vectorized data: - Generate text vectors using a semantic encoding model; - Perform numerical normalization and attribute hashing on structured fields; - The text and structured features are concatenated and then embedded into a unified vector space.

[0095] 3. Establish a vector index to form a searchable historical scene database.

[0096] Output: - A complete vectorized historical scene library that supports efficient similarity retrieval; - A semantic vector and structural feature mapping table for each historical case.

[0097] effect: Unified storage of historical experience and parameter configurations provides an aligned knowledge base for subsequent semantic retrieval, enabling cross-scenario strategy migration.

[0098] S2: Semantic Retrieval and Similar Scene Matching enter: - Tabular data of new failure cases, i.e., the tabular data after verification from the previous stage ("data verification") (including attribute definitions, label types, statistical features, etc.). - The historical scene library output by S1.

[0099] operate: 1. Extract key semantic elements (system type, abnormal symptoms, indicator distribution, contextual attributes, etc.) from new cases; 2. Generate query vectors using a coding model consistent with the scene library; 3. Calculate the cosine similarity between the query vector and the scene library vectors to obtain the matching list; 4. Sort by similarity score and divide into three categories: - High similarity (Top-K): Directly reuse historical strategy parameters; - Moderate similarity: used for policy inspiration and parameter fine-tuning; - Low correlation: For supplementary reference only.

[0100] 5. Output a set of matching results with similarity levels.

[0101] Output: - The sorted set of similar scenes and their association levels (high / medium / low); - Suggested objective function and strategy configuration for each similar case.

[0102] effect: By automatically identifying historical experiences most closely related to the current scenario through semantic retrieval, we can achieve strategy-level experience transfer and rapid positioning.

[0103] S3: Strategy Generation, Trial Run, and Final Execution enter: - S2 outputs a set of similar scenarios and strategy suggestions; - Tabular data and diagnostic objectives for the current scenario.

[0104] operate: 1. Based on the search results, select a set of candidate strategies from the objective function pool; 2. Perform a lightweight trial run for each candidate strategy, including: - Sample subset extraction (e.g., 10% of the data); - Core attribute combination search and score evaluation; - Performance metrics (accuracy, execution time) measurement.

[0105] 3. Select the strategy with the best performance and highest stability based on the trial operation results; 4. Perform the final search on the complete dataset, outputting the anomaly patterns: - Search for high-scoring attribute combinations; - Generate an anomaly location report (including pattern description, scope of impact, and explanatory features).

[0106] Output: - Defined objective function and search strategy; - Complete anomaly location report.

[0107] effect: By piloting candidate strategies, strategies can be validated and optimized, ensuring that efficient and interpretable anomaly localization results can be generated adaptively in different types of fault scenarios.

[0108] The principle behind step 3 is as follows: Addressing the challenges of anomaly localization in cloud platforms—specifically, the difficulty in adapting diagnostic strategies. Even with compliant data, appropriate objective functions and search strategies must be selected for different fault types, and parameters must be configured reasonably. Existing methods lack intelligent parameter configuration and strategy recommendation mechanisms, leading to a high reliance on human experience and repeated trial and error. This phase addresses these challenges by constructing a historical scenario library and combining it with semantic retrieval to achieve automatic strategy recommendation. The system embeds historical fault cases into vectors, uses similarity matching to identify strategies and experiences highly relevant to the current scenario, and evaluates the feasibility and performance of candidate strategies during the trial phase, thereby guiding the final strategy selection and execution. This mechanism overcomes the weaknesses of existing methods, such as weak strategy adaptability and low efficiency of manual parameter tuning, achieving automation, intelligence, and interpretability in strategy selection. Compared to the shortcomings of existing methods, which lack automated strategy recommendation and parameter adaptation, the RAG mechanism can quickly identify the most suitable strategy combination in diverse fault scenarios, thereby improving the efficiency and accuracy of anomaly localization.

[0109] The three-step sub-process in step 3 (construction of the historical scenario library, semantic retrieval and similar scenario matching, and strategy generation and trial operation) forms a closed loop, significantly reducing the burden of manual parameter tuning. In the scenario library construction phase, the system standardizes the format of historical cases and embeds them into a vector space, enabling semantic retrieval. In the similar scenario matching phase, highly relevant strategy experiences are automatically identified to avoid experience blind spots. In the strategy generation and trial operation phase, feasible solutions are screened through lightweight testing, and the optimal strategy is executed, ensuring that the anomaly localization algorithm can run efficiently under different fault types. Overall, this module overcomes the problems of high dependence on human experience and weak strategy adaptability in existing methods, realizing intelligent recommendation and adaptive execution of anomaly localization strategies, and providing a scalable and interpretable solution for end-to-end batch fault diagnosis.

[0110] In step 3: 1.S1 By constructing a unified and formatted historical scenario library, semantic and structured features are jointly embedded into historical cases to achieve feature alignment for different fault types, thereby solving the problems of "difficulty in adapting diagnostic strategies and inability to transfer experience between different scenarios".

[0111] 2.S2 automatically identifies historical strategy experiences that are highly relevant to the current case through semantic retrieval and similar scenario matching mechanisms, avoiding manual reliance on experience judgment, thereby solving the problem of "lack of intelligent recommendation mechanism for strategy selection".

[0112] 3.S3 automatically selects the optimal strategy configuration by performing lightweight trial runs and performance evaluations at the candidate strategy level, reducing repeated trial and error processes, thereby solving the problem of "parameter configuration relying on human experience and low parameter tuning efficiency".

[0113] 4. S1 and S2 work together to achieve unified encoding and retrieval of semantic and structural features, enabling the system to accurately match the optimal strategy in multi-source heterogeneous scenarios, thereby solving the problem that "existing methods have weak strategy adaptability and are difficult to cope with diverse scenarios".

[0114] S3 achieves full-process traceability of strategy decisions by outputting the source of the strategy, performance indicators, and impact attributes during the trial operation and final reporting phases, thereby solving the problem of "lack of interpretability in the existing anomaly localization process".

[0115] Figure 1 shows the overall three-stage process and human-machine collaboration module of the present invention, demonstrating the organic connection between scene confirmation, data verification and anomaly localization.

[0116] Figure 2 The system demonstrates how it automatically determines whether input data is suitable for batch diagnostics and outputs recommended data mapping schemes.

[0117] Figure 3 This describes a data validation toolset that checks the structure and semantics to ensure data quality and the feasibility of anomaly localization.

[0118] Figure 4 The RAG mechanism demonstrates how it optimizes the efficiency of abnormal pattern search and location by recommending strategies based on historical cases and similarity.

[0119] Figure 5 The example diagnostic report includes the potential causes of the anomaly, a score, and specific repair recommendations, making it easy for engineers to refer to and take action.

[0120] Figure 6 Implementation Phase Diagram The working principle of this invention is: This invention proposes a batch fault anomaly localization method based on comparative analysis and human-machine collaborative intelligent agents, which is used to uniformly manage and analyze a large amount of batch fault data generated during the operation of cloud platforms, and realize an end-to-end intelligent diagnostic process from scene recognition, data verification to anomaly localization.

[0121] As shown in Figure 1, the system of this invention comprises three main steps: scene confirmation, data verification, and anomaly localization. These stages are organically linked, allowing for independent operation or closed-loop operation under unified control.

[0122] 1. Scenario Confirmation Phase: This phase automatically determines whether the input data meets the batch diagnostic criteria through a "criteria-based applicability protocol." The system analyzes factors such as data source, sample size, label type, and contextual features to determine whether the basic conditions for comparative analysis are met, and outputs recommended data mapping suggestions.

[0123] 2. Data Validation Phase: This phase uses a "Semantic and Executable Validation Toolset" to perform structural and semantic validation on the input data. The toolset can detect the data's temporal attributes, continuous fields, hierarchical structure, missing values, and label consistency, ensuring the generation of directly executable tabular data to guarantee the reliability and interpretability of the subsequent anomaly localization process.

[0124] 3. Anomaly Localization Phase: This phase executes a search-based anomaly localization algorithm on data that meets the comparative analysis criteria. The algorithm uses attribute-value pairs as the smallest unit to establish a difference model between the target group and the background group. Guided by an objective function, it automatically discovers the feature combinations (i.e., anomaly patterns) that best distinguish the anomaly groups. The system introduces a "retrieval-enhanced generation (RAG) strategy selection mechanism," automatically recommending appropriate objective functions and search parameters based on historical cases and scene similarity, improving localization efficiency and accuracy.

[0125] Furthermore, this system incorporates a human-machine collaboration module throughout the entire process. This module, through visual feedback and interactive suggestions, enables engineers to make judgments, corrections, and optimizations during algorithm execution, thereby significantly reducing the human burden and improving the interpretability and reliability of the diagnosis.

[0126] In principle, this invention is based on the idea of ​​"comparative analysis," transforming the root cause identification of batch failures into a computable feature difference search problem. Specifically, by comparing attributes between the target group (the set of instances that have failed) and the background group (the set of normal or other types of instances), it identifies attribute combinations with significant differences and uses these as candidate root cause patterns. This mechanism combines heuristic search and knowledge retrieval to automate and interpret anomaly localization.

[0127] like Figure 6As shown, in implementation, this invention first receives raw fault data, including logs, metrics, and reports. The scenario confirmation module then uses a criterion-based applicability protocol to determine whether the data is suitable for batch diagnosis and generates data mapping suggestions. Subsequently, the data verification module uses semantic and executable toolsets to validate the data structure, time attributes, continuous fields, hierarchical relationships, and missing values, confirming the generation of directly executable tabular data. During the anomaly localization phase, the system constructs a comparison model between the target group and the background group using attribute-value pairs as units. A search algorithm identifies high-contrast feature combinations, and a Retrieval Enhancement Generation (RAG)-based strategy selection mechanism recommends suitable objective functions and search parameters from historical cases. Throughout the process, the human-machine collaboration module allows engineers to confirm or correct judgments at any time, ensuring the results are reliable, interpretable, and guide subsequent repair operations.

[0128] In summary, the system of the present invention realizes intelligent processing of the entire batch fault handling process, which can not only adapt to multi-source heterogeneous data, but also ensure the accuracy and operability of the analysis results through human-machine collaboration mechanism.

[0129] Although embodiments and drawings of the present invention have been disclosed for illustrative purposes, those skilled in the art will understand that various substitutions, variations and modifications are possible without departing from the spirit and scope of the present invention and the appended claims. Therefore, the scope of the present invention is not limited to the contents disclosed in the embodiments and drawings.

Claims

1. A batch fault and anomaly localization method based on human-machine collaboration and comparative analysis, characterized in that: Includes the following steps: Step 1: Collect raw fault data from multiple sources, assess whether the conditions for batch fault diagnosis are met, obtain the final assessment results and generate standardized table mapping suggestions; Step 2: After confirming in Step 1 that the input multi-source data is suitable for batch diagnostic scenarios, the system performs structure and integrity verification, semantic inspection and automatic repair, and executability verification to obtain tabular data that has been verified for structure and semantics, corrected for potential problems, and confirmed to be directly executable. Step 3: Based on the directly executable tabular data generated in Step 2, the historical scenario library is searched to match the historical experience most similar to the current scenario, and a recommended diagnostic strategy is obtained. The most suitable strategy is compared by performing a lightweight trial run on each candidate strategy, and then the final search process is performed on the complete data to discover key attribute patterns and a complete anomaly localization report.

2. The batch fault anomaly localization method based on human-machine collaboration and comparative analysis according to claim 1, characterized in that: The specific steps of step 1 include: (1) Collect raw fault data from multiple sources and preprocess it to obtain a structured and readable set of multi-source data; (2) Perform field-level parsing on the multi-source dataset and generate a structured data summary file; (3) Based on the criterion evaluation protocol, the applicability of the structured data summary file is evaluated, the input data is quantitatively determined to be suitable for batch fault diagnosis, and a criterion evaluation report is generated.

3. The batch fault anomaly localization method based on human-machine collaboration and comparative analysis according to claim 2, characterized in that: The specific method for evaluating the applicability of structured data digest files based on the criterion-based evaluation protocol in step 1 (3) is as follows: ① The system calls the criterion evaluation protocol and executes the five key criteria sequentially: - C1 Subject Consistency: Analyze the values ​​in the fields related to product, service, or system identifiers to determine if multiple subjects exist; - C2 Batch Size: Counts the number of instances and determines whether a preset threshold has been reached; - C3 Background Class Presence: Detects whether there is a category that can be used as a control (such as a non-target group or normal sample). - C4 Contextual Integrity: Analyze the contextual relationships between fields to determine whether key influencing attributes can be extracted; - C5 Attribute Semantic Clarity: Determines whether the field name and value have interpretable semantics; ②If any criterion does not meet the requirements, the system records an "Inapplicable" status and a prompt for the data type to be supplemented; ③ If all criteria are met, mark the scenario as "diagnosable"; (4) Interactively confirm and revise the criterion evaluation report, and output the final evaluation result after user confirmation; (5) Based on the final evaluation results and structured data summary files, generate standardized table mapping suggestions.

4. The batch fault anomaly localization method based on human-machine collaboration and comparative analysis according to claim 1, characterized in that: The specific steps of step 2 include: (1) Based on the tabular data of confirmed scenario applicability output in step 1 and the pre-set field check rule set, obtain tabular data that has been verified for structure and integrity; (2) Based on the semantic verification and repair toolset, perform semantic verification and automatic repair to obtain semantic check result logs and repaired intermediate data files; (3) Based on the tabular data that has passed semantic verification and repair, perform executability verification and trial operation to confirm that the generated tabular data can be directly executed.

5. The batch fault anomaly localization method based on human-machine collaboration and comparative analysis according to claim 1, characterized in that: The specific steps of step 3 include: (1) Construct a searchable historical scene library and generate a semantic vector and structural feature mapping table for each historical case; (2) Based on the constructed searchable historical scene library, the historical experience closest to the current scene is automatically identified through semantic retrieval, and a sorted set of similar scenes and recommended diagnostic strategy suggestions are obtained, including the objective function and search strategy and their parameter configuration, so as to realize the experience transfer and rapid positioning at the strategy level; (3) Based on the obtained set of similar scenarios and strategy suggestions, as well as the tabular data and diagnostic objectives of the current scenario, the strategy with the best performance and highest stability is obtained by performing a lightweight trial run on each candidate strategy. Finally, the final search process is performed on the complete data according to the strategy to discover key attribute patterns and obtain a complete anomaly localization report.

Images