Multi-source alarm processing method, device, equipment, storage medium and program product

Abstract

This application provides a multi-source alarm processing method, apparatus, device, storage medium, and program product. The method includes: acquiring multi-source alarm data from a multi-source monitoring system; performing semantic parsing on the multi-source alarm data based on a large language model to generate a structured processing strategy; performing rule matching on the structured processing strategy based on a small model to determine an automated execution path; and calling the target system interface according to the automated execution path to complete the alarm processing. Through a collaborative reasoning mechanism between large and small models, an intelligent operation and maintenance system for intelligent multi-source alarm handling is constructed. The large language model drives semantic parsing and strategy generation, while the small model is responsible for rule matching and API calls. The system achieves self-evolution through a private knowledge base and a self-learning mechanism, thereby solving core problems in traditional alarm handling such as fragmented semantic understanding, difficulty in knowledge accumulation, and fragmented automation.

Description

Technical Field

[0001] This application relates to the field of system operation and maintenance, and in particular to a multi-source alarm processing method, device, equipment, storage medium and program product. Background Technology

[0002] In large-scale data center operations and maintenance systems, network maintenance on-call is a core component ensuring stable system operation. Maintenance personnel need to monitor network status 24 / 7 and handle massive amounts of alarms from multiple systems, including switches, routers, firewalls, servers, link monitoring, and service probes. With the increasing number of network devices and the growing complexity of services, traditional on-call alarm handling processes face multiple challenges, including a large volume of alarms, complex alarm semantics, and fragmented processing.

[0003] Currently, some systems rely on static rules or a single model to achieve automated operation and maintenance management. However, classifying and managing alarms based on manually defined rules suffers from high rule maintenance costs and poor semantic understanding capabilities. On the other hand, using a single model to perform intent recognition and root cause analysis on alarm texts can improve semantic parsing capabilities, but it suffers from high latency, high costs, poor interpretability, and limited generalization capabilities. Summary of the Invention

[0004] This application provides a multi-source alarm processing method, apparatus, device, storage medium, and program product, which solves the core problems of fragmented semantic understanding, difficulty in knowledge accumulation, and fragmented automation in traditional alarm processing.

[0005] In a first aspect, embodiments of this application provide a multi-source alarm processing method, the method comprising:

[0006] Acquire multi-source alarm data from a multi-source monitoring system;

[0007] Semantic parsing of multi-source alarm data is performed based on a large language model to generate structured processing strategies;

[0008] Based on a small model, rule matching is performed on the structured processing strategy to determine the automated execution path;

[0009] The target system interface is called according to the automated execution path to complete the alarm processing.

[0010] In one possible implementation, semantic parsing of multi-source alarm data is performed based on a large language model to generate a structured processing strategy, including:

[0011] Key features are extracted from multi-source alarm data, including alarm text, timestamp, device identifier, and performance metrics.

[0012] Natural language processing is performed on the extracted alarm text based on a large language model to generate semantic tags;

[0013] Combining semantic tags with performance metrics, timestamps, and device identifiers forms a structured processing strategy.

[0014] In one possible implementation, natural language processing is performed on the extracted alarm text based on a large language model to generate semantic tags, including:

[0015] Obtain device performance metrics and network topology diagrams from the monitoring system;

[0016] Based on a multimodal coding model, device performance indicators are mapped to a unified semantic space along with the network topology graph.

[0017] The data in the unified semantic space is jointly parsed with the alarm text to generate semantic tags.

[0018] In one possible implementation, rule matching is performed on the structured processing strategy based on a small model to determine the automated execution path, including:

[0019] Monitor system resource status, including CPU utilization, memory usage, and API response time;

[0020] Based on the system resource status, dynamically adjust the rule matching priority and prioritize the execution of low-complexity tasks;

[0021] Based on the adjusted rule matching priority, an automated execution path is generated.

[0022] In one possible implementation, invoking the target system interface according to the automated execution path includes:

[0023] Call at least one of the following interfaces: the link detection interface, the device health detection interface, and the work order system interface;

[0024] The link detection interface is used to obtain the device interface status, the device health detection interface is used to analyze the device CPU, memory and power status, and the work order system interface is used to generate disposal work orders.

[0025] In one possible implementation, after performing rule matching on the structured processing strategy based on a small model to determine the automated execution path, the method further includes:

[0026] The rule matching results are compared with historical processing records to generate difference features;

[0027] Knowledge distillation is performed on differential features based on a large language model to update the private domain knowledge base;

[0028] The updated private domain knowledge base will be used to generate subsequent structured processing strategies.

[0029] Secondly, embodiments of this application provide a multi-source alarm processing device, the device comprising:

[0030] The data acquisition module is used to acquire multi-source alarm data from the multi-source monitoring system.

[0031] The first processing module is used to perform semantic parsing on multi-source alarm data based on a large language model and generate structured processing strategies.

[0032] The second processing module is used to perform rule matching on the structured processing strategy based on the small model and determine the automated execution path.

[0033] The interface call and processing module is used to call the target system interface according to the automated execution path to complete the alarm processing.

[0034] Thirdly, embodiments of this application provide a computer device, including: a memory and a processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0035] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0036] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0037] The multi-source alarm processing method, apparatus, device, storage medium, and program product provided in this application include: acquiring multi-source alarm data from a multi-source monitoring system; performing semantic parsing on the multi-source alarm data based on a large language model to generate a structured processing strategy; performing rule matching on the structured processing strategy based on a small model to determine an automated execution path; and calling the target system interface according to the automated execution path to complete the alarm processing. Through a collaborative reasoning mechanism between large and small models, an intelligent operation and maintenance system for intelligent multi-source alarm handling is constructed. The large language model drives semantic parsing and strategy generation, while the small model is responsible for rule matching and API calls. The system achieves self-evolution through a private knowledge base and a self-learning mechanism, thereby solving core problems in traditional alarm handling such as fragmented semantic understanding, difficulty in knowledge accumulation, and fragmented automation. Attached Figure Description

[0038] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0039] Figure 1 Flowchart of the multi-source alarm processing method provided in this application Figure 1 ;

[0040] Figure 2 Flowchart of the multi-source alarm processing method provided in this application Figure 2 ;

[0041] Figure 3 Flowchart of the multi-source alarm processing method provided in this application Figure 3 ;

[0042] Figure 4 A schematic diagram of the multi-source alarm processing device provided in this application;

[0043] Figure 5 A schematic diagram of the structure of the computer device provided in this application.

[0044] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0045] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0046] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0047] First, let's explain the terms that appear in this article:

[0048] AI: Artificial Intelligence;

[0049] API: Application Programming Interface;

[0050] LLM: Large Language Model;

[0051] SLM: Small Language Model;

[0052] NLP: Natural Language Processing;

[0053] CPU: Central Processing Unit;

[0054] DNS: Domain Name System;

[0055] VS: Virtual Server;

[0056] Workflow: Workflow Automation;

[0057] RESTful: Representational State Transfer, an HTTP-based web interface design style;

[0058] HTTP: Hypertext Transfer Protocol;

[0059] ML: Machine Learning.

[0060] In large-scale data center operations and maintenance systems, network maintenance on-call duty is a core link in ensuring stable system operation. Maintenance personnel need to monitor network operation status 24 / 7 and handle massive amounts of alarms from multiple systems such as switches, routers, firewalls, servers, link monitoring, and service probes. With the increasing number of network devices and the increasing complexity of services, traditional on-call alarm handling processes face multiple challenges, including a massive number of alarms, complex alarm semantics, and fragmented processing. Specifically: the number of alarms is enormous and noisy, reaching hundreds of thousands per day, of which approximately 70% are duplicate or derivative alarms (such as multi-level alarms caused by link interruptions), making it difficult for manual personnel to quickly identify the root cause; alarm semantics are complex and the formats are inconsistent, with significant differences in alarm text between different vendors' equipment and monitoring systems (such as "Link Down," "Interface Status Down," "Port Unreachable," etc.), requiring reliance on experience for judgment; the handling process is fragmented, requiring on-call personnel to manually operate on multiple platforms such as work groups and work order systems, lacking a unified knowledge management and closed-loop mechanism, making it difficult to accumulate experience; and the degree of automation is low.

[0061] Existing technologies are mainly divided into two categories: static thresholding methods based on rule / expert systems and schemes based on single machine learning / large language models.

[0062] (1) Rule / Expert Systems and Static Thresholding Methods:

[0063] This solution categorizes and grades alarms using manually defined rules (such as keyword matching, regular expressions, and static thresholds), reduces duplicate alarms by combining deduplication and aggregation logic, and triggers work orders or automated scripts (such as service restarts and traffic switching) through a rule engine. Its advantages lie in interpretability and controllability, but it has significant drawbacks: high rule maintenance costs, requiring frequent manual updates to adapt to new devices or alarm format changes; poor semantic understanding, unable to handle abbreviations or scenarios with cross-alarm context dependencies; coarse-grained deduplication, prone to incorrectly merging "multiple alarms with the same cause" or "concurrent alarms with multiple causes"; lack of self-learning capability, unable to adapt to new fault modes; high automation risk, prone to misoperation in complex scenarios.

[0064] (2) Scheme based on a single ML / AI model:

[0065] This solution employs text classification, sequence labeling, or LLM (such as a general large model) to perform intent recognition and root cause analysis on alarm texts. For example, by inputting the alarm text, historical context, and monitoring metrics into the large model, classification results or handling suggestions are directly generated. Its advantage lies in its strong semantic parsing capabilities, but it suffers from the following problems: high latency and high cost, with large model inference being time-consuming and requiring high computing power; weak long-term context management, limited single input length, and difficulty in handling complex topological information; poor interpretability, as the black-box model cannot meet the transparency requirements of operational scenarios; and limited generalization ability, relying on a large amount of labeled data, requiring retraining for new alarm types.

[0066] Neither of the above two solutions can simultaneously meet the comprehensive requirements of high-precision semantic understanding, low-latency real-time response, knowledge self-learning and closed-loop optimization, and are difficult to cope with the challenges of handling alarms from multiple sources, multiple states and dynamic evolution in data centers.

[0067] To address the aforementioned technical issues, this application provides a multi-source alarm processing method applicable to large data center network operation and maintenance scenarios. Specifically, it includes alarm processing for multiple systems such as switches, routers, firewalls, servers, link monitoring, and service probes. In the network architecture, the monitoring system collects data such as device logs, performance indicators, and link status in real time. Alarm information is accessed through a RESTful API or command-line interface (CLI). Operation and maintenance personnel need to handle massive amounts of alarms 24 / 7, involving various scenarios such as bandwidth exceeding thresholds, VS down, line jitter, DNS resolution failure, and equipment failure. The system needs to automatically identify alarm semantics, associate context, and generate handling strategies from complex heterogeneous data, and execute operations (such as restarting services or switching links) through API calls, ultimately achieving alarm closure and knowledge accumulation.

[0068] In one embodiment, such as Figure 1 As shown, the multi-source alarm handling methods include:

[0069] Step 101: Obtain multi-source alarm data from the multi-source monitoring system;

[0070] Step 102: Perform semantic parsing on multi-source alarm data based on a large language model to generate a structured processing strategy;

[0071] Step 103: Based on the small model, perform rule matching on the structured processing strategy to determine the automated execution path;

[0072] Step 104: Call the target system interface according to the automated execution path to complete the alarm processing.

[0073] Among them, large language models refer to AI models with deep semantic understanding capabilities, which are used to parse alarm texts and generate handling strategies, such as LLM implemented through the Transformer architecture (such as GPT and PaLM).

[0074] Multi-source alarm data refers to raw alarm information from different monitoring systems, including device logs, performance indicators, link status, etc., such as switch logs and DNS resolution failure records.

[0075] A structured handling strategy refers to a decision tree that includes API call chains and execution logic, such as {"API1": "Link Detection", "Parameters": "Device ID=123", "Subsequent Steps": ["Call Device Health Detection API"]}.

[0076] Small models refer to lightweight AI models used to quickly match rules and perform high-frequency tasks, such as rule classifiers based on BERT or LSTM.

[0077] An automated execution path refers to a sequence of API calls generated by a small model, such as "calling the traffic collection interface → triggering the flow switching script".

[0078] The target system interface refers to the API of the monitoring, equipment management, or work order system that is called, such as a RESTful interface or CLI command.

[0079] This method processes multi-source alarm data, and the processing consists of three stages:

[0080] Semantic parsing stage: The large language model receives raw multi-source alarm data, such as "link jitter, packet loss rate exceeds 5%", and uses natural language processing technology to parse out key features, such as alarm type, object, time, and scope of impact, and generates structured handling strategies, such as "call link detection API → analyze device status → generate repair instructions".

[0081] Rule matching phase: The small model quickly judges the structured processing strategy based on predefined rules. For example, it matches "bandwidth exceeding the threshold" as a low-priority alarm and generates the corresponding API call path, such as "calling the traffic collection interface".

[0082] Interface execution phase: The system calls the target system interface (such as RESTful API or CLI command) according to the automated execution path, completes alarm handling operations (such as restarting the service or switching traffic), and feeds back the execution results for model optimization, such as API response status codes.

[0083] The above method addresses the contradiction between low semantic parsing accuracy and insufficient execution efficiency in alarm handling through a collaborative mechanism of large and small models. The large language model (LLM) uses deep semantic parsing capabilities to map heterogeneous alarm texts, such as logs from multiple vendors' devices and link status descriptions, into structured handling strategies, ensuring accurate identification of complex scenarios such as "link jitter + device CPU overload" composite faults. The small model (SLM) quickly processes high-frequency, low-complexity alarms, such as "bandwidth exceeding threshold," through rule matching, generating automated execution paths and calling APIs, avoiding response delays caused by the high latency of LLM. This technique, through layered division of labor, enables the system to handle both deep reasoning for complex scenarios and real-time responses for high-frequency tasks, thereby significantly improving the accuracy and efficiency of alarm classification and handling strategy generation, and solving the problems of misjudgment and missed judgments, and high latency of single models in traditional rule systems.

[0084] In one embodiment, semantic parsing of multi-source alarm data is performed based on a large language model to generate a structured processing strategy, including:

[0085] Key features are extracted from multi-source alarm data, including alarm text, timestamp, device identifier, and performance metrics.

[0086] Natural language processing is performed on the extracted alarm text based on a large language model to generate semantic tags;

[0087] Combining semantic tags with performance metrics, timestamps, and device identifiers forms a structured processing strategy.

[0088] Natural Language Processing (NLP) refers to parsing the semantics of text through algorithms. For example, LLM maps "link jitter" to "network quality anomaly".

[0089] Semantic tags refer to the classification labels for alarm text, such as "link jitter" or "device CPU overload".

[0090] A structured handling strategy refers to a decision tree that includes API call chains and execution logic, such as {"API1": "Link Detection", "Parameters": "Device ID=123", "Subsequent Steps": ["Call Device Health Detection API"]}.

[0091] This step processes multi-source alarm data. The process includes: first, extracting the alarm text, timestamp, device identifier, and performance metrics; second, parsing the alarm text using a large language model to generate semantic tags; and finally, combining the semantic tags with performance metrics, timestamps, and device identifiers to form a structured handling strategy. For example, when the alarm text is "Link jitter, packet loss rate exceeds 5%", the system extracts "link jitter" as a semantic tag and combines it with the device ID, timestamp, and packet loss rate metric to generate a handling strategy.

[0092] The method provided in the above embodiments, by extracting and combining key features step by step, makes the generation of structured handling strategies more accurate. For example, traditional solutions may only rely on text parsing, while this step, by combining semantic tags and performance indicators, can distinguish whether "link jitter" is a physical fault or a configuration error, thereby generating a handling strategy that is more in line with the actual scenario.

[0093] In one embodiment, such as Figure 2 As shown, natural language processing is performed on the extracted alarm text based on a large language model to generate semantic tags, including:

[0094] Step 201: Obtain device performance indicators and network topology diagram from the monitoring system;

[0095] Step 202: Based on the multimodal coding model, map the device performance indicators and network topology graph to a unified semantic space;

[0096] Step 203: Jointly parse the data in the unified semantic space with the alarm text to generate semantic tags.

[0097] Multimodal coding models are models that can process multiple types of data, such as text, numerical data, and images.

[0098] A unified semantic space refers to mapping heterogeneous data to the same feature vector space, such as encoding "CPU utilization" and "topology graph" into comparable vectors.

[0099] Existing alarm semantic parsing relies on single text features, making it difficult to handle the correlation analysis of multimodal data (such as monitoring indicators and topology maps), resulting in insufficient accuracy in complex fault identification. By introducing a multimodal data fusion mechanism, the cross-modal coding capability of LLM is used to map alarm text, device monitoring data, network topology maps, etc., into a unified semantic space.

[0100] Specifically, the system first acquires device performance metrics and network topology diagrams; second, it generates a unified semantic space using a multimodal coding model; and finally, it jointly analyzes the data in the unified semantic space with alarm texts. For example, when the alarm text is "Device CPU overload," the system combines the CPU utilization curve with the upstream and downstream dependencies of the device in the topology diagram to comprehensively determine whether it is a physical resource bottleneck.

[0101] The method provided in the above embodiments enables the system to handle complex fault scenarios through multimodal data association and parsing. For example, when the alarm text is "device CPU overload", the system simultaneously parses the device monitoring indicators (such as the CPU temperature curve) and the upstream and downstream dependencies of the device in the topology diagram to comprehensively determine whether it is a physical resource bottleneck or an abnormal load. This technical approach overcomes the limitations of single text parsing, significantly improves the discrimination accuracy of complex fault scenarios (such as the combined fault of "CPU overload + link congestion"), and solves the misjudgment problem caused by data silos in traditional solutions.

[0102] In one embodiment, rule matching is performed on the structured processing strategy based on a small model to determine the automated execution path, including:

[0103] Monitor system resource status, including CPU utilization, memory usage, and API response time;

[0104] Based on the system resource status, dynamically adjust the rule matching priority and prioritize the execution of low-complexity tasks;

[0105] Based on the adjusted rule matching priority, an automated execution path is generated.

[0106] System resource status refers to the current usage of resources such as CPU and memory in the system, such as "CPU utilization > 80%".

[0107] Low-complexity tasks refer to simple tasks that do not require deep reasoning, such as "bandwidth exceeding threshold" matching.

[0108] Existing alarm handling strategies rely on fixed templates, making it difficult to dynamically adjust API call paths to adapt to changes in system resource load, resulting in fluctuations in execution efficiency.

[0109] By designing a dynamic load-aware API call path optimization mechanism, and through real-time monitoring of system resources (such as CPU and memory) and model inference latency, the collaborative strategy between LLM and SLM is dynamically adjusted. Specifically, the system resource status is monitored first; then, the priority matching rules are adjusted according to the resource status; and finally, an automated execution path is generated. For example, when CPU utilization is high, the system prioritizes matching low-complexity tasks such as "bandwidth exceeding threshold" to avoid LLM resource contention under high load.

[0110] The method provided in the above embodiments optimizes API call paths under different load conditions through resource-aware scheduling. For example, during low-load periods, LLM can execute deep inference to generate multi-step handling strategies, such as "link detection → device health analysis → alarm merging"; during high-load periods, SLM prioritizes simple tasks, such as "obtaining device IP addresses," avoiding latency caused by LLM resource contention. This technique significantly improves the real-time performance and resource utilization of API calls, solving the efficiency degradation problem caused by resource contention in traditional fixed call paths.

[0111] In one embodiment, invoking the target system interface according to the automated execution path includes:

[0112] Call at least one of the following interfaces: the link detection interface, the device health detection interface, and the work order system interface;

[0113] The link detection interface is used to obtain the device interface status, the device health detection interface is used to analyze the device CPU, memory and power status, and the work order system interface is used to generate disposal work orders.

[0114] The link detection interface refers to the API used to query the status of network links, such as GET / api / link / status.

[0115] The device health monitoring interface refers to the API used to query the operating status of a device, such as GET / api / device / health.

[0116] The work order system interface refers to the API used to generate or update work orders, such as POST / api / ticket / create.

[0117] The system selects to call the link detection API, device health detection API, or work order system API based on the path. For example, when the path is "call link detection API → analyze device status", the system calls the link detection API and the device health detection API in sequence, and feeds back the results for work order generation.

[0118] The method provided in the above embodiments enables the system to cover more fault scenarios by combining multiple interface calls. For example, traditional solutions may only call a single interface, while this step, through combined calls, can simultaneously detect link status and device health, improving the comprehensiveness of fault diagnosis.

[0119] In one embodiment, such as Figure 3 As shown, after performing rule matching on the structured processing strategy based on the small model to determine the automated execution path, it also includes:

[0120] Step 301: Compare the rule matching results with historical processing records to generate difference features;

[0121] Step 302: Perform knowledge distillation on the differential features based on the large language model to update the private domain knowledge base;

[0122] Step 303: Use the updated private domain knowledge base for generating subsequent structured processing strategies.

[0123] The discrepancy feature refers to the inconsistency between the rule matching result and the historical processing record, such as the difference between "link detection API call failure" and historical successful cases.

[0124] Knowledge distillation refers to extracting key information from the differences in features through a large language model, such as extracting "interface availability check" as a new rule.

[0125] Existing alarm handling systems lack knowledge accumulation and self-learning capabilities, making it impossible to dynamically adapt to new fault modes or optimize historical handling experience. Based on a collaborative architecture of large and small models, a private domain knowledge self-learning capability and a "text-driven" Workflow-driven autonomous fault decision-making system can be built. This system extracts knowledge fragments from historical alarm and handling records using RAG (Retrieval Enhanced Generation) technology and generates executable Workflow templates using LLM (Low-Level Modeling).

[0126] Specifically, the system first compares the rule matching results with historical records to generate discrepancy features; second, it extracts key information from these discrepancy features using a large language model; and finally, it updates the private knowledge base for subsequent strategy generation. For example, when the rule matching result is "API call chain detection failed," the system compares historical successful records, finds the discrepancy feature as "interface not open," and generates a new rule, "add interface availability check," through knowledge distillation.

[0127] In one specific embodiment, the system is built around a "fault agent," forming a closed-loop system encompassing private domain knowledge accumulation, workflow generation, intent understanding, automated execution, and self-learning feedback. The system consists of the following key components:

[0128] (1) Private Knowledge Base Construction Layer: Extract core knowledge fragments from customers' private knowledge (such as product manuals, operation and maintenance guides, fault plans, operation logs, expert experience, etc.) to construct a standardized knowledge base. Support external knowledge injection, including importing historical cases and generating templated contingency plans, to ensure the richness and traceability of knowledge sources.

[0129] (2) Workflow Generation Layer (Wensheng Workflow): By combining manual revision with large model (LLM) generation, structured workflows are automatically generated from knowledge documents. The system utilizes RAG (Retrieval-Augmented Generation) to enhance the retrieval and generation capabilities of the large model, transforming unstructured text knowledge into executable process nodes.

[0130] (3) Manual writing / revision is used for precise control of high-risk scenarios; text generation Workflow is used to quickly build standard handling paths; RAG + LLM realizes semantic abstraction and template generalization of contingency plans, improving generation accuracy and coverage.

[0131] (4) Intent Understanding Layer: The intent understanding of the alarm commands or alarm texts of the on-duty personnel is realized through a dual semantic recognition mechanism (BERT intent classification + RAG graph classification). This layer can identify the alarm category, urgency, dependency relationship and processing priority, and trigger the corresponding Workflow instance.

[0132] (5) Automated execution layer: The fault agent calls the automated execution module to complete the task loop according to the Workflow instructions, including assisted execution (such as instruction suggestions and command line interpretation); autonomous execution (such as automatic issuance of CLI commands and tool linkage execution); and abnormal recovery (such as automatic rollback and replanning after execution failure).

[0133] The execution results will be fed back to the Agent, enabling adaptive evaluation of the execution effect and operational feasibility.

[0134] (6) Self-learning and optimization layer: By distilling and reorganizing knowledge from Workflow instance runtime logs, execution results, and human feedback, the system can automatically correct and optimize the private domain knowledge base, achieving continuous knowledge evolution. This self-learning mechanism supports RAG-enhanced semantic retrieval and Workflow regeneration, forming a closed-loop optimization.

[0135] The implementation process includes:

[0136] (1) Knowledge injection and Workflow generation: Through manual sorting and automatic extraction, the operation and maintenance experience documents are transformed into structured Workflow templates and injected into the private domain knowledge base.

[0137] (2) Alarm intent recognition and Workflow triggering: When the system receives the duty alarm information, it identifies the alarm intent through the BERT and RAG semantic parsing modules and matches the optimal Workflow template.

[0138] (3) Agent execution and automated decision-making: The Agent calls execution tools (such as inspection commands, configuration interfaces, recovery scripts, etc.) based on the Workflow instance to realize the process of "automated execution - status verification - closed-loop feedback".

[0139] (4) Execution feedback and self-learning: The execution results are automatically written back to the knowledge base by the Agent. The Workflow parameters and descriptions are corrected through LLM analysis to form a self-evolution mechanism and realize the three-layer closed loop of "knowledge accumulation - model reinforcement - decision optimization".

[0140] The method provided in the above embodiments enables the system to adapt to new failure modes by dynamically updating the private domain knowledge base. For example, traditional solutions require manual maintenance of the rule base, while this step, through difference feature comparison and knowledge distillation, enables the system to automatically optimize rule matching logic and improve the adaptability of the handling strategy.

[0141] In one embodiment, an API self-integration technology is proposed based on a large-scale model collaborative architecture. This technology aims to leverage the semantic generation capabilities of the large model and the structured processing capabilities of the small model to achieve automatic API corpus generation, dynamic API call chain construction, continuous model optimization and verification, thereby significantly improving the efficiency of alarm information parsing and O&M system integration. This technology constructs two core modules: a high-quality corpus generation mechanism and a large-scale model collaborative reasoning mechanism. These modules enable automatic identification, integration, and dynamic optimization of APIs from multiple systems, achieving a model call accuracy rate of over 90%, greatly improving the automation level and processing accuracy of O&M.

[0142] Among them, high-quality corpus generation technology is used to solve problems such as scarce corpus, uneven sample distribution, and inconsistent parameter descriptions in traditional API calls, and to build a continuously evolving API semantic dataset, providing a foundation for continuous model fine-tuning and generalization.

[0143] Specifically, the process of generating high-quality corpora includes:

[0144] (1) Corpus structured modeling: First, the structured elements such as parameter names, request bodies, and return fields are automatically extracted from multi-source API documents (REST, gRPC, CLI, etc.); the LLM performs semantic completion and parameter normalization to unify the API namespace and field standards.

[0145] (2) Multidimensional corpus enhancement mechanism: Based on the dual indicators of diversity and semantic coverage, LLM is used to perform prompt chain optimization and automatically expand the corpus types (example calls, abnormal inputs, parameter boundaries, etc.).

[0146] (3) Auto Few-shot semantic reuse mechanism: LLM automatically generates multi-scene extended samples on a small amount of existing high-quality corpus, and improves sample generalization and context consistency through the Auto Few-shot algorithm.

[0147] (4) LLM-assisted verification and label generation: The system uses a multi-model mutual evaluation (LLM and SLM cross-validation) mechanism to automatically generate corpus labels (such as API purpose, field dependency, and calling logic); and filters out unqualified corpus by controlling the accuracy score and perplexity threshold.

[0148] (5) Dynamic iteration and fine-tuning feedback of corpus: The corpus is periodically fed back to the training pool of small models. After the small models are fine-tuned in the domain, they provide feedback on the new distribution differences. Based on this, the large models generate new few-shot templates, forming a continuous evolution cycle.

[0149] The collaborative reasoning process between large and small models includes:

[0150] (1) Semantic task planning: The large model first performs self-questioning to clarify the alarm type, API target and processing logic; and generates a semantic call draft (including API name, parameter mapping and condition judgment).

[0151] (2) Task decomposition and small model execution: The large model decomposes the semantic task into multiple executable sub-tasks, which are then executed in parallel by the small model; the small model calls the API according to the rule template and verifies the consistency between the call return status and the output in real time.

[0152] (3) Collaborative arbitration and multi-round optimization: If the result deviates from the expectation, the large model will re-analyze the input context and make a second call by updating the prompt words or replacing the API path. After multiple rounds of collaborative iteration, the system automatically selects the optimal strategy and updates the knowledge cache.

[0153] (4) Dynamic generalization and self-learning: Each call process generates a semantic-call-result triplet, which is incorporated into the knowledge base for the next reasoning self-learning and domain generalization.

[0154] In one embodiment, the multi-source alarm processing method based on size model collaboration includes:

[0155] Step 1: Alarm Access and Feature Analysis

[0156] Processing objects: Raw alarm data from multi-source monitoring systems (such as switch logs, link status, and device performance indicators).

[0157] Processing procedure: The alarm text is processed by LLM using Natural Language Processing (NLP) to extract key features (such as alarm type, object, time, and scope of impact) and generate structured corpus. For example, when the alarm "Link jitter, packet loss rate exceeds 5%" is received, LLM parses "link jitter" as the alarm type, "packet loss rate" as the performance indicator, and "5%" as the threshold, and associates it with the device ID and timestamp.

[0158] Processing result: A structured alarm feature vector containing semantic tags and metadata is generated.

[0159] Step 2: Collaborative Judgment and Classification Decision Based on Large and Small Models

[0160] Processing object: The structured alarm feature vector generated in step 1.

[0161] Processing steps: The Large Model (LLM) generates alarm types and handling strategies based on a private knowledge base and historical experience, while the Small Model (SLM) quickly identifies high-frequency scenarios (such as bandwidth exceeding thresholds) through rule matching. For example, if the LLM identifies an alarm as "line interruption," it generates a strategy of "calling the link detection API → analyzing device status → generating repair instructions," while the SLM directly matches "bandwidth exceeding threshold" as a low-priority alarm and triggers the traffic collection interface.

[0162] Processing results: Output alarm classification results and preliminary handling strategies.

[0163] The above method achieves full automation of alarm handling through the collaborative mechanism of LLM and SLM:

[0164] LLM is responsible for semantic parsing and policy generation: extracting key features from the original alarm text and generating handling policies (such as calling APIs or generating work orders) based on the private knowledge base.

[0165] SLM is responsible for rule matching and API calls: for high-frequency, low-complexity alarms (such as bandwidth exceeding the threshold), it directly performs rule judgment and calls the corresponding API (such as the traffic collection interface).

[0166] Private domain knowledge self-learning closed loop: Knowledge fragments are extracted from historical handling records using RAG technology to update the knowledge base and optimize the LLM strategy generation logic. For example, when the success rate of handling a certain type of alarm increases, the system automatically adjusts the priority of related workflows.

[0167] Third-party API self-integration: LLM generates API call parameters and scripts, SLM verifies the execution results, and uses the feedback data for model fine-tuning, forming a closed loop of "parsing → execution → learning".

[0168] The above method significantly improves the intelligence level of data center alarm handling through the collaboration of large and small models and a knowledge self-learning mechanism. Specifically, this is manifested in:

[0169] Improved semantic parsing accuracy: LLM's deep understanding capabilities can accurately parse heterogeneous alarm texts from multiple vendors and systems, avoiding the misjudgment and omission problems of traditional rule systems.

[0170] Optimized processing efficiency: SLM enables rapid response to high-frequency alarms, while LLM generates strategies for complex scenarios, achieving parallel processing of alarm classification and execution, thus shortening MTTR.

[0171] Knowledge continuously evolves: The private knowledge base is dynamically updated through RAG technology. The system can automatically summarize historical handling experience and optimize Workflow templates, reducing manual maintenance costs.

[0172] Enhanced cross-system integration capabilities: Third-party API self-integration technology supports automatic parsing and invocation of multiple protocols such as RESTful, gRPC, and CLI, enabling seamless integration of multiple systems such as monitoring systems, device interfaces, and CMDB.

[0173] Self-decision-making capability formation: Through the Wensheng Workflow mechanism, the system can transform fault scenarios described in natural language into executable operation flows, realizing the transformation from "manual alarm-driven" to "intelligent agent-driven".

[0174] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0175] Based on the same inventive concept, this application also provides a multi-source alarm processing device. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations of one or more multi-source alarm processing device embodiments provided below can be found in the limitations of the multi-source alarm processing method above, and will not be repeated here.

[0176] In one embodiment, such as Figure 4As shown, the multi-source alarm processing device includes a data acquisition module 401, a first processing module 402, a second processing module 403, and an interface call and processing module 404, wherein:

[0177] Data acquisition module 401 is used to acquire multi-source alarm data from the multi-source monitoring system;

[0178] The first processing module 402 is used to perform semantic parsing on multi-source alarm data based on a large language model and generate a structured processing strategy.

[0179] The second processing module 403 is used to perform rule matching on the structured processing strategy based on the small model and determine the automated execution path.

[0180] The interface call and processing module 404 is used to call the target system interface according to the automated execution path to complete the alarm processing.

[0181] In one possible implementation, the first processing module 402 is specifically used for:

[0182] Key features are extracted from multi-source alarm data, including alarm text, timestamp, device identifier, and performance metrics.

[0183] Natural language processing is performed on the extracted alarm text based on a large language model to generate semantic tags;

[0184] Combining semantic tags with performance metrics, timestamps, and device identifiers forms a structured processing strategy.

[0185] In one possible implementation, the first processing module 402 is specifically used for:

[0186] Obtain device performance metrics and network topology diagrams from the monitoring system;

[0187] Based on a multimodal coding model, device performance indicators are mapped to a unified semantic space along with the network topology graph.

[0188] The data in the unified semantic space is jointly parsed with the alarm text to generate semantic tags.

[0189] In one possible implementation, the second processing module 403 is specifically used for:

[0190] Monitor system resource status, including CPU utilization, memory usage, and API response time;

[0191] Based on the system resource status, dynamically adjust the rule matching priority and prioritize the execution of low-complexity tasks;

[0192] Based on the adjusted rule matching priority, an automated execution path is generated.

[0193] In one possible implementation, the interface call and processing module 404 is specifically used for:

[0194] Call at least one of the following interfaces: the link detection interface, the device health detection interface, and the work order system interface;

[0195] The link detection interface is used to obtain the device interface status, the device health detection interface is used to analyze the device CPU, memory and power status, and the work order system interface is used to generate disposal work orders.

[0196] In one possible implementation, the apparatus further includes a generation module for:

[0197] The rule matching results are compared with historical processing records to generate difference features;

[0198] Knowledge distillation is performed on differential features based on a large language model to update the private domain knowledge base;

[0199] The updated private domain knowledge base will be used to generate subsequent structured processing strategies.

[0200] Each module in the aforementioned multi-source alarm processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0201] Figure 5 A schematic diagram of the structure of the computer device provided in this application. Figure 5 As shown, the computer device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0202] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0203] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0204] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0205] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0206] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

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

[0208] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0209] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0210] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0211] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

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

[0213] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0215] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0216] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A multi-source alarm processing method, characterized by, The method includes: Acquire multi-source alarm data from a multi-source monitoring system; Semantic parsing of the multi-source alarm data is performed based on a large language model to generate a structured processing strategy; Based on the small model, rule matching is performed on the structured processing strategy to determine the automated execution path; The target system interface is invoked according to the automated execution path to complete the alarm processing.

2. The method of claim 1, wherein, The semantic parsing of the multi-source alarm data based on a large language model to generate a structured processing strategy includes: Key features are extracted from the multi-source alarm data, including alarm text, timestamp, device identifier, and performance indicators. The extracted alarm text is processed using the large language model to generate semantic tags. The semantic tags are combined with the performance metrics, the timestamp, and the device identifier to form a structured processing strategy.

3. The method of claim 2, wherein, The step of performing natural language processing on the extracted alarm text based on the large language model to generate semantic tags includes: Obtain device performance metrics and network topology diagrams from the monitoring system; Based on a multimodal coding model, the device performance indicators and the network topology graph are mapped to a unified semantic space; The data in the unified semantic space is jointly parsed with the alarm text to generate the semantic tag.

4. The method of claim 1, wherein, The step of performing rule matching on the structured processing strategy based on a small model to determine the automated execution path includes: Monitor system resource status, including CPU utilization, memory usage, and API response time; Based on the system resource status, the rule matching priority is dynamically adjusted, prioritizing the execution of low-complexity tasks; Based on the adjusted rule matching priority, an automated execution path is generated.

5. The method of claim 1, wherein, The step of calling the target system interface according to the automated execution path includes: Call at least one of the following interfaces: the link detection interface, the device health detection interface, and the work order system interface; The link detection interface is used to obtain the device interface status, the device health detection interface is used to analyze the device CPU, memory and power status, and the work order system interface is used to generate a handling work order.

6. The method of claim 1, wherein, After performing rule matching on the structured processing strategy based on the small model to determine the automated execution path, the method further includes: The rule matching results are compared with historical processing records to generate difference features; Based on the large language model, knowledge distillation is performed on the differential features to update the private domain knowledge base; The updated private domain knowledge base will be used to generate subsequent structured processing strategies.

7. A multi-source alarm processing apparatus characterized by comprising: The device includes: The data acquisition module is used to acquire multi-source alarm data from the multi-source monitoring system. The first processing module is used to perform semantic parsing on the multi-source alarm data based on a large language model and generate a structured processing strategy. The second processing module is used to perform rule matching on the structured processing strategy based on the small model to determine the automated execution path; The interface call and processing module is used to call the target system interface according to the automated execution path to complete the alarm processing.

8. A computer device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 6.

Images