Alarm automatic processing system and method based on locally deployed large model

Abstract

The application provides an alarm automatic processing system and method based on a locally deployed large model. The system includes an alarm access unit configured to generate standardized alarm data; an intelligent analysis engine configured to generate a search query element corresponding to an alarm event; a knowledge enhancement component configured to build an alarm handling knowledge base, retrieve candidate handling case information according to the search query element, and when a preset recall condition is not met, update the search query element and retrieve again to output handling evidence; a handling suggestion generation unit configured to generate a handling suggestion corresponding to the alarm event; and a closed-loop feedback unit configured to write the handling result feedback into the alarm handling knowledge base in association with the standardized alarm data, the alarm type and the handling suggestion, and trigger incremental training or parameter update of a large language model based on the written associated data. The application can improve alarm analysis and handling efficiency, improve low-frequency alarm processing accuracy, and reduce the cost of manual analysis and collaborative handling.

Description

Technical Field

[0001] This application relates to the technical field of information security, and in particular to an automatic alarm processing system and method based on a locally deployed large model. Background Technology

[0002] As enterprise IT infrastructure continues to grow, the number of business systems, infrastructure, and security devices is increasing, leading to a monitoring system characterized by multi-source heterogeneity, complex links, and high-frequency alarms. Alarm handling, a crucial aspect of operations and security response, typically requires merging, analyzing, and locating alarm content, and providing appropriate handling steps to ensure the continuity of critical business operations. Existing technologies commonly employ alarm handling methods such as threshold- and rule-based filtering and merging, centralized alarm platform-based work order processing and manual analysis, and cloud-based intelligent analysis of alarm data.

[0003] The existing technologies described above still have the following shortcomings in practical applications: On the one hand, massive alarm volumes lead to low analysis efficiency, high rule maintenance costs, and poor adaptability to new and low-frequency alarms, making it difficult to provide timely and reliable handling suggestions; on the other hand, manual judgment relies on experience, resulting in long handling chains, significant response delays, and scattered alarm contexts in cross-system collaborations, easily forming information silos; furthermore, in scenarios with strict data sovereignty and compliance requirements, such as finance and government, alarm logs and handling records often involve sensitive information, and relying on cloud processing can easily introduce the risk of data leakage, making it difficult to meet the deployment requirements of local controllability and auditability. Therefore, there is an urgent need for an automatic alarm processing technology solution that can achieve alarm semantic understanding, knowledge retrieval enhancement, and closed-loop accumulation of handling experience in a local environment. Summary of the Invention

[0004] In view of this, the embodiments of this application provide an automatic alarm processing system and method based on a locally deployed large model to solve the problems of existing technologies, such as alarm semantic analysis relying on manual intervention, insufficient knowledge of low-frequency alarm handling, and difficulty in closed-loop accumulation of handling experience.

[0005] The first aspect of this application provides an automatic alarm processing system based on a locally deployed large-scale model, comprising: an alarm access unit, used to receive raw alarm data output by at least one monitoring system, and perform field normalization and alarm event normalization processing on the raw alarm data to generate standardized alarm data; an intelligent analysis engine, including a locally deployed and supervised fine-tuned large language model, used to extract alarm elements and determine alarm types based on the standardized alarm data, generate retrieval query elements corresponding to alarm events, and select an alarm processing structure based on the alarm type; and a knowledge enhancement component, used to construct an alarm handling knowledge base, perform vectorization representation and similarity retrieval index construction on historical handling records or operation and maintenance knowledge items in the alarm handling knowledge base, and select an alarm handling structure based on the retrieval query elements. The system retrieves candidate handling case information. If the preset recall conditions are not met, the search query elements are updated and the search is repeated to output handling evidence associated with the alarm event. The handling suggestion generation unit is used to input standardized alarm data and handling evidence into the large language model to generate handling suggestions corresponding to the alarm event. The handling suggestions include a sequential sequence of handling steps and corresponding verification items and / or rollback items. The closed-loop feedback unit is used to obtain the handling results feedback from operation and maintenance personnel on the handling suggestions. When the handling results feedback meets the preset storage conditions, the handling results feedback is associated with standardized alarm data, alarm type and handling suggestions and written into the alarm handling knowledge base. Based on the written associated data, incremental training or parameter updates of the large language model are triggered.

[0006] The second aspect of this application provides an automatic alarm processing method based on a locally deployed large-scale model, using the system of the first aspect. The method includes: receiving raw alarm data output from at least one monitoring system; performing field normalization and alarm event normalization on the raw alarm data to generate standardized alarm data; inputting the standardized alarm data into a large-scale language model; extracting alarm elements associated with alarm events and determining alarm types; generating retrieval query elements corresponding to alarm events; and selecting an alarm processing structure based on the alarm type; constructing an alarm handling knowledge base; performing vectorization representation and similarity retrieval index construction on historical handling records or operation and maintenance knowledge items; and retrieving candidate alarms from the alarm handling knowledge base based on the retrieval query elements. Select case information for handling, and if the preset recall conditions are not met, update the search query elements and search again to output handling evidence associated with the alarm event; input standardized alarm data and handling evidence into the big language model to generate handling suggestions corresponding to the alarm event. The handling suggestions include a sequence of handling steps arranged in order and verification items and / or rollback items corresponding to the sequence of handling steps; obtain the handling results feedback from operation and maintenance personnel on the handling suggestions, and when the handling results feedback meets the preset storage conditions, write the handling results feedback, standardized alarm data, alarm type and handling suggestions into the alarm handling knowledge base, and trigger incremental training or parameter updates of the big language model based on the written associated data.

[0007] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: The alarm access unit receives raw alarm data from at least one monitoring system and performs field normalization and alarm event normalization on the raw alarm data to generate standardized alarm data. The intelligent analysis engine, including a locally deployed and supervised fine-tuned large language model, extracts alarm elements from the standardized alarm data, determines the alarm type, generates retrieval query elements corresponding to the alarm event, and selects the alarm handling structure based on the alarm type. The knowledge enhancement component builds an alarm handling knowledge base, performs vectorization representation and similarity retrieval index construction on historical handling records or operation and maintenance knowledge items in the knowledge base, and retrieves candidate handling case information based on the retrieval query elements. If the preset call value is not met... When the conditions are met, the search query elements are updated and the search is performed again to output the handling evidence associated with the alarm event. The handling suggestion generation unit inputs standardized alarm data and handling evidence into the large language model to generate handling suggestions corresponding to the alarm event. The handling suggestions include a sequentially arranged sequence of handling steps and corresponding verification items and / or rollback items. The closed-loop feedback unit obtains feedback from operations personnel on the handling suggestions and, when the feedback meets preset storage conditions, associates the feedback with standardized alarm data, alarm type, and handling suggestions, writing it into the alarm handling knowledge base. Based on the written associated data, incremental training or parameter updates to the large language model are triggered. This application can improve the efficiency of alarm analysis and handling, increase the accuracy of low-frequency alarm handling, and reduce the cost of manual analysis and collaborative handling. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a schematic diagram of the structure of the automatic alarm processing system based on a locally deployed large model provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the automatic alarm processing method based on a locally deployed large model provided in an embodiment of this application. Detailed Implementation

[0010] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0011] As enterprise IT infrastructure becomes increasingly complex, traditional alert handling models face a triple challenge: low analysis efficiency due to massive alert volumes, response delays caused by manual assessment, and information silos in cross-system collaboration. Especially in sectors with strict data sovereignty requirements, such as finance and government, cloud-based processing solutions pose compliance risks due to the potential for sensitive data leakage. In this context, locally deployed large-scale models, by bringing intelligent analysis capabilities to the user side, avoid the risk of data being off-shore and dynamically integrate historical handling experience through RAG (Retrieval Augmentation) technology to form a closed-loop knowledge base. For example, after adopting a local DeepSeek model, a bank reduced its false alarm rate by 40% and significantly improved the accuracy of threat merging by utilizing an industry terminology library in its private knowledge base. This technical approach not only solves the rigidity problem of traditional rule engines but also provides a controllable intelligent upgrade path for critical business scenarios with high real-time requirements.

[0012] In view of the problems existing in the prior art, this application provides an automatic alarm processing system and method based on a locally deployed large model. The core architecture of the automatic alarm processing system of this application can be divided into three key modules: an intelligent analysis engine, a knowledge enhancement component, and a closed-loop feedback mechanism.

[0013] Among them, the intelligent analysis engine, as the core processing unit, adopts a large model deployed locally. By fine-tuning and adapting to the alarm semantic understanding task, it utilizes its multi-turn dialogue and context modeling capabilities to achieve alarm root cause analysis.

[0014] The knowledge enhancement component uses RAG technology to build a dynamic knowledge base, which vectorizes and stores unstructured data such as historical alarm handling records and operation and maintenance manuals. When the model encounters a new type of alarm, it can retrieve the handling solutions of similar cases in real time, which significantly improves the handling accuracy of low-frequency alarms.

[0015] The closed-loop feedback mechanism automatically updates the knowledge base based on the handling results of operations and maintenance personnel, forming a virtuous cycle of handling experience, model optimization, and knowledge accumulation. This architecture design not only ensures the local security of data processing but also overcomes the shortcomings of large models in vertical domains through retrieval enhancement mechanisms, ultimately achieving a dual improvement in alarm analysis accuracy and handling efficiency.

[0016] The specific structure and functions of the automatic alarm processing system based on a locally deployed large model provided in this application will be described in detail below with reference to the accompanying drawings and specific embodiments. Figure 1 This is a schematic diagram of the structural composition of the automatic alarm processing system based on a locally deployed large model provided in an embodiment of this application, as shown below. Figure 1 As shown, the system may specifically include the following components: The alarm access unit 101 is used to receive raw alarm data output by at least one monitoring system, and to perform field normalization and alarm event normalization processing on the raw alarm data to generate standardized alarm data. The intelligent analysis engine 102 includes a locally deployed and supervised fine-tuned large language model, which is used to extract alarm elements and determine alarm types based on standardized alarm data, generate retrieval query elements corresponding to alarm events, and select alarm processing structures based on alarm types. The knowledge enhancement component 103 is used to build an alarm handling knowledge base. It performs vectorization representation and similarity retrieval index construction on historical handling records or operation and maintenance knowledge items in the alarm handling knowledge base, and retrieves candidate handling case information based on the retrieval query elements. If the preset recall conditions are not met, the retrieval query elements are updated and the retrieval is performed again to output handling evidence associated with the alarm event. The handling suggestion generation unit 104 is used to input standardized alarm data and handling evidence into the big language model to generate handling suggestions corresponding to the alarm event. The handling suggestions include a sequence of handling steps arranged in order and verification items and / or rollback items corresponding to the sequence of handling steps. The closed-loop feedback unit 105 is used to obtain the feedback of the operation and maintenance personnel on the handling suggestions, and when the handling result feedback meets the preset storage conditions, it writes the handling result feedback, standardized alarm data, alarm type and handling suggestions into the alarm handling knowledge base, and triggers incremental training or parameter update of the large language model based on the written associated data.

[0017] In some embodiments, field normalization and alarm event normalization are performed on the raw alarm data to generate standardized alarm data, including: Perform unified mapping and normalization on the field names, field value definitions, and alarm description text of the raw alarm data from different monitoring systems to obtain alarm event data with a unified field structure; Based on one or more of the alarm object identifier, alarm type information, alarm occurrence time, and severity level information in the alarm event data, alarm event normalization is performed, merging multiple original alarm data representing the same alarm event into one standardized alarm data, and generating an event identifier for the standardized alarm data for subsequent processing. Supplement the standardized alarm data with basic context fields that are associated with the alarm events, so that the standardized alarm data can be used by the intelligent analysis engine to extract alarm elements and generate search query elements.

[0018] Specifically, the raw alarm data comes from multiple monitoring systems, including one or more of host monitoring, database monitoring, middleware monitoring, or application performance monitoring. Different monitoring systems often use different field names and value definitions for the same type of anomaly. For example, the same fault phenomenon may be described as "connection pool full," "connection pool exhausted," or "pool exhausted," and the severity level may be represented by numerical or textual levels. The alarm object may be represented by hostname, instance identifier, container identifier, or service name. To avoid inconsistencies in the subsequent semantic understanding of alarms by the large language model, the alarm access unit first performs unified mapping and standardization processing on field names, field value definitions, and alarm description text.

[0019] In some examples, the alarm access unit pre-establishes field mapping rules to uniformly map field names output by different monitoring systems to a preset field set. This preset field set includes at least the alarm object identifier, alarm occurrence time, severity level, alarm description text, and alarm type information. Regarding field value definitions, the alarm access unit performs standardized formatting on the time field to eliminate time zone or format differences, performs level mapping on the severity level field to unify it into a preset level system, and performs identifier normalization on the alarm object field to unify it into a uniquely identifiable object identifier. For the alarm description text, the alarm access unit performs normalization processing on the text content, including unifying synonyms, removing irrelevant prefixes and suffixes, and retaining key entity fragments, ensuring that the alarm description text can stably represent abnormal symptoms. Through these processes, the alarm access unit obtains alarm event data with a unified field structure, providing a data foundation for subsequent alarm event normalization.

[0020] Furthermore, after obtaining the alarm event data, the alarm access unit performs alarm event normalization based on one or more of the alarm object identifier, alarm type information, alarm occurrence time, and severity level information in the alarm event data, so as to merge multiple original alarm data representing the same alarm event into a single standardized alarm data. In this embodiment, the alarm access unit aggregates and compares multiple alarm event data appearing within a preset time window for the same alarm object identifier. If the aggregation and comparison results show that their alarm type information is the same or their alarm description text has a consistent abnormal symptom description after normalization, then it is determined that they correspond to the same alarm event and merging processing is performed.

[0021] During merging, the alarm access unit can use the highest severity level among multiple alarm event data as the severity level of the standardized alarm data, the earliest alarm occurrence time as the event start time, and the latest alarm occurrence time as the event update time. Simultaneously, it writes information such as the source monitoring system identifier and original alarm identifier of each alarm event data as tracing fields into the standardized alarm data. Furthermore, the alarm access unit generates an event identifier for the merged standardized alarm data. The event identifier can be calculated from a combination of the alarm object identifier, alarm type information, and alarm occurrence time, ensuring that subsequent handling suggestions and closed-loop feedback are stably referenced when written to the knowledge base.

[0022] Furthermore, after standardizing alarm data, the alarm access unit continues to supplement the standardized alarm data with basic context fields associated with the alarm events, so that the standardized alarm data can be used by the intelligent analysis engine to extract alarm elements and generate retrieval query elements. For example, the basic context fields include at least one or more of the following: alarm object category, abnormal symptom description, and key indicator information. The alarm object category is used to characterize whether the alarm object belongs to a database instance, application service, host node, or middleware component, thereby providing a filtering basis for the subsequent knowledge enhancement component to retrieve similar cases in the alarm handling knowledge base.

[0023] The abnormal symptom description is used to further structure and extract information from the alarm description text. For example, "database connection pool full" is extracted as a symptom of connection resource exhaustion, and "CPU spike" is extracted as a symptom of high computing resource load. Key indicator information is used to retain numerical or status indicators that are strongly related to alarm handling, such as connection pool occupancy rate, thread pool queue length, CPU utilization, memory usage, or error count. This enables the intelligent analysis engine to determine the alarm type based on the indicator context and generate more accurate retrieval query elements.

[0024] To illustrate the feasibility of the above processing procedure, this embodiment uses a "database connection pool full" alarm as an example. In the raw alarm data output by monitoring system A, the alarm description text is recorded as "connection pool exhausted," the alarm object as "db-instance-01," and the severity level as "critical." In the raw alarm data output by monitoring system B, the alarm description text is recorded as "connection pool full," the alarm object as "database instance one," and the severity level as "P1."

[0025] The alarm access unit unifies the two into a preset field set through field name mapping and performs level mapping on the severity level to obtain a unified severity level; it maps "database instance one" to an alarm object identifier consistent with "db-instance-01" through alarm object identifier normalization; and it normalizes "connection pool exhausted" and "connection pool full" into a consistent abnormal symptom description through description text normalization.

[0026] Subsequently, the alarm access unit determines that the two alarm event data belong to the same alarm event within a preset time window and merges them to generate a standardized alarm data. It generates an event identifier for it and completes the alarm object category as a database instance, key indicator information as connection occupancy rate and waiting queue length, so that the standardized alarm data meets the input requirements of the subsequent intelligent analysis engine for alarm element extraction, alarm type determination and retrieval query element construction.

[0027] This embodiment unifies the structure and semantics of alarm data output by different monitoring systems by performing field regularization, alarm event normalization, and basic context completion on the original alarm data. It forms standardized alarm data that can be stably parsed by a large language model that can be deployed locally and fine-tuned under supervision. This supports the subsequent chain of outputting handling evidence and generating handling suggestions based on retrieval enhancement, thereby improving the data consistency and reusability of the alarm processing chain.

[0028] In some embodiments, alarm elements are extracted based on standardized alarm data and alarm types are determined to generate retrieval query elements corresponding to alarm events, including: Standardized alarm data is input into a large language model, which performs semantic parsing on the alarm description text and context fields associated with the alarm event in the standardized alarm data, and extracts alarm elements associated with the alarm event. The alarm elements include alarm object identifier, abnormal symptom description, key entity information and / or key indicator information. Based on alarm elements, the large language model outputs alarm types and generates type labels associated with alarm events for each alarm type; The search query elements are constructed based on alarm type and alarm elements. The search query elements include one or more of the following: alarm type, description of abnormal symptoms, and key entity information.

[0029] Specifically, standardized alarm data includes at least one or more of the following: event identifier, alarm object identifier, alarm occurrence time, severity level, alarm description text, and basic context fields. The basic context fields may include one or more of the following: alarm object category, abnormal symptom description, key indicator information, operating environment marker, or source monitoring system identifier.

[0030] When processing standardized alarm data, the intelligent analysis engine first organizes the standardized alarm data into a model input context according to a preset input template. The model input context includes at least: alarm description text that can stably represent the abnormal phenomenon, alarm object identifiers and alarm object categories used to locate objects and boundaries, and key indicator information used to support the judgment. Through this input organization method, the large language model can perform multi-dimensional joint reasoning on alarm text and indicator context in a local environment, rather than simply classifying isolated text.

[0031] In some examples, the intelligent analysis engine inputs standardized alarm data into a large language model, enabling the model to perform semantic parsing on the alarm description text and context fields associated with the alarm event to extract alarm elements related to the event. For example, alarm elements include at least one or more of the following: an alarm object identifier, used to uniquely identify the object generating the alarm; an anomaly symptom description, used to summarize the anomaly expressed in the alarm text; key entity information, used to extract entities such as system components, service names, resource types, or error identifiers associated with handling; and key indicator information, used to extract numerical or status indicators related to the anomaly. To ensure that alarm elements can be reused by subsequent modules, the intelligent analysis engine outputs alarm elements using a unified terminology during the parsing process and stores the alarm elements in association with the event identifier, ensuring consistency in subsequent retrieval, handling suggestion generation, and feedback into the database.

[0032] Furthermore, after extracting alarm elements, the intelligent analysis engine outputs alarm types from the large language model based on these elements, and generates type labels associated with alarm events for each alarm type. These type labels map alarm events to a preset alarm type space, thereby supporting subsequent operations such as "selecting alarm processing structures based on alarm types" and "retrieving similar cases in the alarm handling knowledge base." In this embodiment, the supervised fine-tuning samples of the large language model come from the alarm log dataset and include label types with clear handling semantics, such as "database connection pool full," enabling the model to develop stable discrimination capabilities for common alarm types under local deployment conditions.

[0033] Meanwhile, to avoid semantic bias caused by relying on a single label, the intelligent analysis engine can perform consistency verification between alarm type labels and key entity information and key indicator information. For example, when the alarm type label points to a connection resource exhaustion alarm, the key indicator information should contain at least one indicator related to connection resources, such as connection occupancy rate, waiting queue length, or timeout count. Otherwise, the alarm event is marked as a low-confidence type judgment that needs to be enhanced by retrieval, so that evidence can be supplemented later through knowledge enhancement components.

[0034] Furthermore, after obtaining the alarm type and alarm elements, the intelligent analysis engine constructs retrieval query elements based on the alarm type and alarm elements. These retrieval query elements are used by the knowledge enhancement component to perform vector similarity retrieval in the alarm handling knowledge base, thereby recalling candidate handling case information. In this embodiment, the retrieval query elements include at least one or more of the following: alarm type, abnormal symptom description, and key entity information. They may also include alarm object category and operating environment tags when necessary to improve retrieval matching accuracy.

[0035] In some examples, to enhance the searchability of query elements, the intelligent analysis engine organizes abnormal symptom descriptions and key entity information into query text fragments that can be vectorized, and uses alarm type as a search filter or recall ranking factor, so that the search results are both semantically similar and type consistent, making it easier to recall historical cases that are similar to the current alarm event handling path.

[0036] The above process is illustrated below with a specific example. In the standardized alarm data output by the alarm access unit, the alarm description text is formatted as "database connection pool full," the alarm object identifier is db-instance-01, the alarm object category is a database instance, and key indicator information includes a connection occupancy rate consistently approaching 100% and a continuously increasing waiting queue length. The intelligent analysis engine combines these fields into a locally deployed large language model that serves as the model input context. The model performs joint semantic parsing on the alarm description text and key indicator information, extracting alarm elements: the alarm object identifier is db-instance-01, the abnormal symptom description is connection resource exhaustion, key entity information includes database instance and connection pool, and key indicator information includes connection occupancy rate and waiting queue length. Based on these alarm elements, the large language model outputs the alarm type and generates a type label as "database connection resource exhaustion alarm."

[0037] Subsequently, the intelligent analysis engine constructs search query elements, taking alarm type and abnormal symptom description as core search elements, and key entity information "database instance, connection pool" as search constraint elements. This enables the knowledge enhancement component to prioritize recalling historical work orders and operation and maintenance manual entries related to "connection pool full" handling from the alarm handling knowledge base. For example, case information involving key points of handling steps such as connection limit configuration, connection leak investigation, and thread pool blocking location, providing handling evidence support for the generation of subsequent handling suggestions.

[0038] This embodiment inputs standardized alarm data into a locally deployed and supervised fine-tuned large language model to complete alarm element extraction, alarm type determination, and retrieval query element construction. This enables alarm events to enter the knowledge-enhanced retrieval chain with consistent object identifiers, symptom descriptions, and key entity expressions, thereby improving the relevance and stability of similar case recall. It also provides more sufficient semantic basis and evidence support for the subsequent generation of handling suggestions that include a sequence of handling steps, verification items, and / or rollback items.

[0039] In some embodiments, selecting an alarm processing structure based on the alarm type includes: Based on alarm type and standardized alarm data, determine whether an alarm event belongs to a preset common alarm set. The preset common alarm set includes high-frequency alarm types obtained from historical handling records. When it is determined that the alarm event belongs to the preset common alarm set, an alarm processing structure that mainly generates handling suggestions is selected, and the search query elements are used as auxiliary inputs for generating handling suggestions; When it is determined that the alarm event does not belong to the preset common alarm set or the alarm element meets the preset uncertainty condition, an alarm processing structure that focuses on outputting handling evidence is selected, and the knowledge enhancement component is triggered based on the search query elements to perform similar case retrieval to obtain candidate handling case information.

[0040] Specifically, the preset common alarm set is maintained synchronously by the knowledge enhancement component when building the alarm handling knowledge base or when adding new knowledge entries in the closed-loop feedback unit. Specifically, the system statistically analyzes the alarm type tags associated with historical handling records, operation and maintenance manual entries, and work order records to obtain the frequency of occurrence, the number of effective handling samples, and the stability characteristics of the corresponding handling step sequences for each alarm type. Based on the statistical results, alarm types with a frequency reaching a preset threshold and a number of effective handling samples reaching a preset threshold are included in the preset common alarm set. To ensure that this set is consistent with the operation and maintenance habits of the local deployment environment, the system can also include operation and maintenance scoring information in the statistical conditions, only counting handling samples with scores not lower than a preset scoring threshold into the number of effective handling samples. This makes the preset common alarm set more reflective of "high-quality handling scenarios that can directly generate handling suggestions."

[0041] Furthermore, after the intelligent analysis engine completes the alarm type determination, it first determines whether the current alarm event belongs to a preset common alarm set based on the alarm type and standardized alarm data. For example, this determination process includes at least: performing a membership determination within the preset common alarm set based on the alarm event's type label; and performing a consistency check by combining the alarm object category, operating environment markers, and key indicator information in the standardized alarm data to avoid misjudging scenarios where the same type label corresponds to different handling paths in different object categories or environments, leading to scenarios where handling suggestions can be directly generated. If the membership determination is correct and the consistency check passes, the alarm event is considered to belong to the preset common alarm set; otherwise, it enters a processing structure primarily focused on enhanced retrieval.

[0042] In some examples, when an alarm event is determined to belong to a preset set of common alarms, the intelligent analysis engine selects an alarm processing structure that primarily generates handling suggestions, and uses retrieval query elements as auxiliary input for generating these suggestions. This handling suggestion generation structure does not exclude the retrieval capabilities of the knowledge enhancement component, but rather uses the retrieval query elements for lightweight evidence supplementation and handling path verification.

[0043] For example, for alarm types like "database connection pool full," if this alarm type appears frequently in historical handling records and there are many samples whose scores meet the inclusion criteria, it will be included in a preset set of common alarms. At this point, the intelligent analysis engine can directly drive the large language model to generate handling suggestions containing a sequence of handling steps based on standardized alarm data. Simultaneously, it provides retrieval query elements to the knowledge enhancement component to recall a small number of handling points that match the current alarm object category or operating environment. These points are used to supplement or verify the generated sequence of handling steps, thereby ensuring that the suggested content is consistent with the local operations and maintenance manual and existing work order handling practices.

[0044] When it is determined that an alarm event does not belong to a preset set of common alarms or that the alarm elements meet preset uncertainty conditions, the intelligent analysis engine selects an alarm processing structure that primarily outputs handling evidence. Based on the retrieval query elements, it triggers a knowledge enhancement component to perform a similar case retrieval to obtain candidate handling case information. In this embodiment, the preset uncertainty conditions can be triggered by the following factors: the alarm elements lack key entity information or key indicator information, resulting in unclear alarm semantic boundaries; the same standardized alarm data can be mapped by the model to multiple candidate alarm types with no significant difference in confidence; or the description of abnormal symptoms in the standardized alarm data does not match historical high-frequency handling paths. In this case, the intelligent analysis engine uses the retrieval query elements as input. The knowledge enhancement component first performs a similarity retrieval in the alarm handling knowledge base to recall candidate handling case information. If the preset recall conditions are not met, the engine iteratively updates the retrieval query elements to supplement key entity information, error identification information, or operating environment information until handling evidence sufficient to support the generation of subsequent handling suggestions is obtained.

[0045] To facilitate understanding of the above structure selection mechanism, this embodiment will provide a comparative explanation with examples. For connection resource exhaustion alarms occurring in the production environment, standardized alarm data includes a clear alarm object identifier db-instance-01, an abnormal symptom description of connection resource exhaustion, and key indicator information showing that the connection occupancy rate is consistently close to 100%. The intelligent analysis engine determines that the alarm type is a connection pool full alarm and matches this type in the preset common alarm set. Therefore, it selects an alarm handling structure that primarily generates handling suggestions, while providing retrieval query elements to the knowledge enhancement component to recall handling points that match the current database version or connection configuration to assist in the generation process.

[0046] Conversely, if the same alarm type label is determined by the model to be related to the connection pool, but key indicator information is missing or the alarm description text contains an incorrect label that is unrelated to the connection pool, causing the alarm element to meet the preset uncertainty condition, then the intelligent analysis engine selects an alarm processing structure that focuses on outputting disposal evidence. It first triggers the knowledge enhancement component to search for similar cases, and then fills in the semantic boundary of the disposal by recalling candidate disposal case information before entering the disposal suggestion generation link.

[0047] This embodiment forms a preset set of common alarms based on historical handling records. After determining the alarm type, different alarm handling structures are selected. This enables the system to quickly enter the handling suggestion generation link for high-frequency alarms and prioritize the evidence supplementation link for low-frequency, novel, or insufficiently informed alarms. This improves the response efficiency of the alarm handling link and the reliability of handling suggestions while ensuring controllable local deployment, and reduces the cost of repeated analysis caused by the uncertainty of alarm semantics.

[0048] In some embodiments, an alarm handling knowledge base is constructed, and vectorized representation and similarity retrieval index construction are performed on historical handling records or operation and maintenance knowledge entries in the alarm handling knowledge base, including: Acquire knowledge source data related to alarm handling, including historical alarm handling records, operation and maintenance manuals, and / or work order records; The knowledge source data is structured and segmented to generate multiple knowledge entries, and the metadata of each knowledge entry is associated with and stored in relation to alarm handling. The content of each knowledge item is generated into a vectorized representation, and the vectorized representation is associated with the corresponding item metadata and stored to form an alarm handling knowledge base; An index structure for similarity retrieval is constructed based on vectorized representation, enabling the knowledge enhancement component to perform similarity retrieval in the alarm handling knowledge base based on the retrieval query elements to obtain candidate handling case information.

[0049] Specifically, the knowledge enhancement component first acquires knowledge source data related to alarm handling. This knowledge source data includes historical alarm handling records, operation and maintenance manuals, and / or work order records. Historical alarm handling records may include the alarm type, alarm object, description of the anomaly, handling steps, verification methods, and handling conclusions of past alarm events. Operation and maintenance manuals may include troubleshooting procedures for common faults, configuration item descriptions, operational precautions, and rollback principles. Work order records may include the handling process, change records, scope of related impacts, and final conclusions of cross-team collaboration.

[0050] To ensure data sovereignty and compliance requirements in local deployment scenarios, knowledge source data is collected and stored locally in this embodiment. The collection process can be completed by the local interface of the operation and maintenance platform, work order system or knowledge base system, and sensitive fields are anonymized or marked with access control to support subsequent auditing and permission isolation.

[0051] Furthermore, after acquiring the knowledge source data, the knowledge enhancement component performs structured organization and content segmentation on the knowledge source data, generating multiple knowledge entries and associating and storing entry metadata related to alarm handling for each knowledge entry. Specifically, the knowledge enhancement component segments unstructured text according to a preset granularity, which can be divided by chapters, paragraphs, step sequences, or question-and-answer units, enabling each knowledge entry to express a relatively complete handling semantic. For historical handling records and work order records, the knowledge enhancement component can use one or more of the following as segmentation criteria: "phenomenon description, root cause description, key points of handling steps, key points of verification, key points of rollback, and handling conclusion," making the generated knowledge entries closer to the evidence units required for subsequent handling recommendations. For operation and maintenance manuals, the knowledge enhancement component can use one or more of the following as segmentation criteria: "fault type title, applicable conditions, troubleshooting steps, operational precautions, and rollback principles," to form handling entries that can be directly retrieved and recalled.

[0052] In some examples, entry metadata is used to support retrieval filtering, sorting, and result interpretation. In this embodiment, entry metadata includes at least one or more of the following: alarm type, alarm object category, abnormal symptom description, key entity information, operating environment marker, key points of handling steps, key points of verification, key points of rollback, handling conclusion information, and sample quality marker. Specifically, the alarm type and abnormal symptom description are used to ensure consistency with the alarm type and abnormal symptom description in the retrieval query elements; the alarm object category is used to distinguish differentiated handling paths for the same type of fault under different object categories; key entity information is used to mark component names, configuration item names, error identifiers, or resource types that are strongly related to the handling; the operating environment marker is used to distinguish between production and testing environments, as well as different version definitions; and the sample quality marker can be generated from the operation and maintenance scoring information of the closed-loop feedback unit to prioritize high-quality entries during retrieval and sorting.

[0053] Furthermore, after completing the itemization and organization, the knowledge enhancement component generates a vectorized representation of the content of each knowledge item and associates and stores the vectorized representation with the corresponding item metadata to form an alarm handling knowledge base. For example, the knowledge enhancement component performs vector embedding calculations on the knowledge item text to obtain a vector representation representing semantic features, and establishes an association between this vector representation and the knowledge item identifier, item metadata, and the original item content. To ensure consistency in subsequent cross-module references, each knowledge item in this embodiment generates a unique item identifier, which can be further associated with the event identifier of the alarm event, enabling new items generated by closed-loop feedback to form a traceable link with the original alarm event, handling suggestions, and handling result feedback.

[0054] Furthermore, after obtaining the vectorized representation, the knowledge enhancement component constructs an index structure for similarity retrieval based on the vectorized representation. This enables the knowledge enhancement component to perform similarity retrieval in the alarm handling knowledge base based on the search query elements to obtain candidate handling case information. The index structure is used to support low-latency vector similarity retrieval in a local environment. During index construction, the vectorized representation of the knowledge entry is written into the index, and the entry identifier is used as the association key of the index item, so that the corresponding entry metadata and entry content can be quickly read back after a retrieval hit. Furthermore, to improve retrieval relevance, the knowledge enhancement component can use alarm type, alarm object category, or operating environment markers in the entry metadata as retrieval filtering conditions or re-ranking factors, so that the retrieval results satisfy both type consistency and applicable condition matching on the basis of semantic similarity.

[0055] The following explanation uses the "Database connection pool full" alarm as an example. Historical alarm handling records and work order records contain multiple handling processes related to connection pool exhaustion, including connection limit configuration checks, connection leak investigations, thread blocking location, and rollback to a stable configuration version. The knowledge enhancement component divides these handling processes into multiple knowledge items according to "phenomenon—handling steps—verification points—rollback points," and annotates each item with metadata. For example, the alarm type is labeled as a connection resource exhaustion alarm, the alarm object category is labeled as a database instance, key entity information is labeled as the connection pool, maximum connection configuration item, and timeout error identifier, and the runtime environment is labeled as the production environment.

[0056] Subsequently, the knowledge enhancement component generates a vectorized representation for each knowledge entry and writes it into the index structure. When the intelligent analysis engine generates retrieval query elements containing alarm type and abnormal symptom description for db-instance-01, the knowledge enhancement component can retrieve candidate treatment case information in the index structure that is semantically similar to the connection pool and matches the applicable conditions, and output treatment evidence for subsequent treatment suggestion generation.

[0057] This embodiment organizes historical handling records, operation and maintenance manuals, and work order records in a local environment through itemization, metadata annotation, vectorization, and index construction. This enables alarm handling knowledge to be stored in the alarm handling knowledge base in a searchable and reusable manner. This allows the knowledge enhancement component to quickly recall similar case evidence when faced with low-frequency or new alarms, improves the response speed and recall relevance of the retrieval enhancement link, and provides more sufficient handling basis for the generation of subsequent handling suggestions.

[0058] In some embodiments, candidate handling case information is retrieved based on search query elements. If a preset recall condition is not met, the search query elements are updated and the search is performed again to output handling evidence associated with the alarm event, including: Based on the search query elements, a similarity search is performed in the alarm handling knowledge base to obtain candidate handling case information; The recall condition is determined for candidate handling case information. The preset recall condition includes one or more of the following: the similarity of candidate handling case information meets a preset similarity threshold, the number of candidates meets a preset number threshold, or the alarm object category of candidate handling case information is consistent with the alarm object category of alarm event. When the preset recall conditions are not met, supplementary search elements are determined based on candidate disposal case information and standardized alarm data, and the supplementary search elements are merged into the search query elements to form updated search query elements. Based on the updated search query elements, a similarity search is performed again, and when the preset recall conditions are met, the processing evidence associated with the alarm event is output.

[0059] Specifically, the knowledge enhancement component first performs a similarity search in the alarm handling knowledge base based on the retrieval query elements to obtain candidate handling case information. The retrieval query elements are constructed by the intelligent analysis engine based on alarm type and alarm elements, and include at least one or more of the following: alarm type, description of abnormal symptoms, and key entity information.

[0060] The knowledge enhancement component organizes the search query elements into query text fragments and vectorizes them. It then uses the constructed similarity retrieval index to perform vector similarity calculation and candidate item recall in the alarm handling knowledge base, and outputs a set of candidate handling case information.

[0061] Candidate disposal case information may include one or more of the following: similar case summary, key points of disposal steps, applicable conditions, key points of verification, key points of rollback, and disposal conclusion information. It should also be associated with the metadata of the corresponding knowledge entry so that it can be filtered and reordered when determining the recall conditions.

[0062] Furthermore, after obtaining candidate disposal case information, the knowledge enhancement component performs recall condition determination on the candidate disposal case information to evaluate whether the first round of retrieval results meet the quality threshold for generating disposal evidence. In this embodiment, the preset recall conditions include at least one or more of the following conditions: the similarity of the candidate disposal case information meets a preset similarity threshold; the number of candidates meets a preset number threshold; and the alarm object category of the candidate disposal case information is consistent with the alarm object category of the alarm event.

[0063] In some examples, a similarity threshold is used to ensure that recalled entries are semantically close to the current alarm event; a quantity threshold is used to ensure evidence coverage, avoiding recalling only single and unrepresentative entries; and object category consistency is used to ensure the applicability of the handling path, preventing the misapplication of handling steps for other object categories to the current alarm object. To further improve stability, the knowledge enhancement component can also combine runtime environment markers, version information, or sample quality markers in the entry metadata to perform auxiliary judgments, making the candidate handling case information that meets the recall conditions more closely match the real handling scenarios of local deployment.

[0064] In some examples, when the recall condition determination result indicates that the preset recall condition is not met, the knowledge enhancement component determines supplementary search elements based on candidate disposal case information and standardized alarm data, and merges the supplementary search elements into the search query elements to form updated search query elements. Supplementary search elements are used to compensate for insufficient or ambiguous information in the first round of search expression. In this embodiment, supplementary search elements include at least one or more of the following: key entity information, key indicator information, operating environment information, or error identification information.

[0065] Specifically, if the alarm object categories in the first round of candidate handling case information are scattered, it indicates that the retrieval query elements do not adequately constrain the object boundaries. In this case, alarm object categories or operating environment markers are extracted from the standardized alarm data as supplementary retrieval elements. If the first round of candidate handling case information is similar but the key points of the handling steps differ significantly, it indicates that the description of abnormal symptoms is too broad. In this case, more precise key indicator information or error identification information is extracted from the standardized alarm data as supplementary retrieval elements. If the overall similarity of the first round of candidate handling case information is low, it indicates that key entity information is insufficient. In this case, frequently occurring component names, configuration item names, or fault keywords are extracted from the candidate handling case information and merged with the key entity information in the standardized alarm data to form more distinctive updated retrieval query elements.

[0066] Furthermore, after forming the updated retrieval query elements, the knowledge enhancement component performs a similarity search again in the alarm handling knowledge base based on the updated retrieval query elements, and repeatedly performs the recall condition determination; when the preset recall conditions are met, it outputs handling evidence associated with the alarm event. Handling evidence is the evidence-based organization of candidate handling case information that meets the conditions. In this embodiment, handling evidence includes at least one or more of the following: handling steps, applicable conditions, and verification points, and may further carry rollback points to support the subsequent handling suggestion generation unit in outputting "verification items and / or rollback items". The handling evidence is associated with the event identifier of the alarm event, enabling the subsequent handling suggestion generation and closed-loop feedback to reuse the same evidence set and maintain consistent referencing.

[0067] The following explanation uses the "Database connection pool full" alarm as an example. The intelligent analysis engine extracts alarm elements from standardized alarm data and generates search query elements. The alarm type is a connection resource exhaustion alarm, the abnormal symptom is described as a full connection pool, and key entity information includes the database instance and the connection pool. The knowledge enhancement component performs an initial similarity search based on this. If some candidate entries in the recall results are related to "resource exhaustion" but their object categories include both database instances and application services, and the similarity does not reach the preset threshold, then the preset recall conditions are not met.

[0068] At this point, the knowledge enhancement component supplements the standardized alarm data by extracting alarm object categories as database instances and key indicator information as connection occupancy ratio and waiting queue length, and merges them into the search query elements to form updated search query elements, and performs a similarity search again. After the second search, the candidate items in the recall results have consistent object categories and the similarity meets the threshold, and the number of candidates also reaches the threshold. Based on this, the knowledge enhancement component outputs handling evidence, such as "check the maximum connection number configuration item and key points of connection leak investigation steps", "use the decline in connection waiting queue and error count as verification points", and "if necessary, roll back to a stable connection configuration version as a rollback point", providing directly usable evidence to support the generation of subsequent handling suggestions.

[0069] This embodiment introduces an iterative similarity retrieval mechanism into the alarm handling knowledge base and automatically generates supplementary retrieval elements to update the retrieval query elements when the recall quality is insufficient. This enables the knowledge enhancement component to stably obtain candidate handling case information that is semantically consistent with the alarm event and matches the applicable conditions, and output handling evidence. This improves the relevance and usability of the retrieval and recall, and supports the subsequent handling suggestion generation chain output of a more executable handling step sequence and corresponding verification items and / or rollback items.

[0070] In some embodiments, standardized alarm data and handling evidence are input into a large language model to generate handling suggestions corresponding to the alarm event, including: The evidence was organized in a structured manner to obtain a set of evidence related to the alarm event; Standardized alarm data and evidence sets are combined into the model input context, and the model input context is input into the large language model so that the large language model outputs handling suggestions under the constraints of the evidence set. A sequence of sequentially arranged disposal steps is generated from a large language model, and corresponding verification items and / or rollback items are generated for each step in the sequence. The verification items are used to check the execution results of the disposal steps, and the rollback items are used to reverse the execution of the disposal steps or restore the state when the verification fails.

[0071] Specifically, the disposal evidence is retrieved by the knowledge enhancement component through similarity and output after meeting preset recall conditions. The disposal evidence includes at least one or more of the following: key points of the disposal steps, applicable conditions, verification points, and rollback points. The disposal suggestion generation unit first structures and organizes the disposal evidence to obtain a set of evidence associated with the alarm event. In some examples, the disposal suggestion generation unit merges and deduplicates information from different candidate disposal cases according to a preset evidence structure. The preset evidence structure includes at least: a summary of similar cases, a set of key points of the disposal steps, a set of verification points, and a set of rollback points.

[0072] The similar case summary outlines the applicable scenarios and anomalies of candidate disposal cases. The disposal step key point set summarizes the key operational steps that repeatedly occur in candidate cases. The verification key point set summarizes the indicators or status items that should be checked after disposal. The rollback key point set summarizes the reverse operation or status recovery path when disposal fails or verification fails. To facilitate subsequent traceability, the evidence set in this embodiment can also carry the item identifier and item metadata summary corresponding to the candidate disposal cases, enabling the disposal suggestions to be associated with the evidence source when output.

[0073] Furthermore, after completing the construction of the evidence set, the handling suggestion generation unit combines the standardized alarm data with the evidence set to form the model input context, and then inputs the model input context into the large language model. The model input context includes at least one or more of the following: event identifier associated with the alarm event, alarm object identifier, alarm type label, abnormal symptom description, key entity information, and key indicator information; and one or more of the following: handling step key point set, verification key point set, and rollback key point set from the evidence set.

[0074] By inputting standardized alarm data and an evidence set, the large language model ensures that it satisfies two types of constraints when generating handling suggestions: one is the actual semantic and boundary constraints of the alarm event, and the other is the evidence constraints formed by the accumulation of historical handling experience. To avoid the model's generation deviating from the evidence set, the handling suggestion generation unit in this embodiment can explicitly require the model to prioritize the reference to key points of the handling steps in the evidence set in the model input context. When the evidence set is insufficient to cover the specific environmental differences of the current alarm event, the handling steps are adapted and supplemented as necessary based on the operating environment markers or key indicator information in the standardized alarm data.

[0075] Furthermore, during the model generation phase, the large language model generates a sequence of sequentially arranged handling steps, and generates corresponding verification items and / or rollback items for each step in the sequence. For example, the sequence of handling steps includes at least several handling steps arranged in execution order, each step consisting of a clearly defined operation object and operation action, such as a step-by-step expression of actions like configuration item adjustment, service status check, resource threshold verification, or connection status cleanup.

[0076] Verification items are used to check the execution results of the handling steps. Verification items may include at least one or more of the following: monitoring metric checks, business link connectivity checks, and resource consumption threshold checks. Rollback items are used to reverse the executed handling steps or restore their state when verification fails. Rollback items may include at least one or more of the following: reversing configuration changes, restoring service status, or restoring to a historical stable version configuration. To maintain a logical closed loop between steps, the handling suggestion generation unit ensures that the output or state change of each handling step can be checked in the corresponding verification items when organizing the output. When verification fails, the rollback item provides a clear recovery path, thus forming a controllable handling link of "execution—verification—rollback".

[0077] The following uses the "database connection pool full" alarm as an example. The handling evidence output by the knowledge enhancement component includes key handling steps related to connection pool exhaustion, such as checking the connection limit configuration, investigating connection leaks, and locating blockages. It also includes verification points, such as a decrease in connection occupancy, a decrease in the waiting queue length, and a reduction in the error count. Furthermore, it includes rollback points, such as reversing connection configuration changes or restoring to a stable connection configuration version. The handling suggestion generation unit combines the alarm object identifier db-instance-01, the alarm type label connection resource exhaustion alarm, the key entity information connection pool, and the key indicator information (connection occupancy approaching 100% and waiting queue length continuously increasing) from the standardized alarm data with the aforementioned evidence set to form the model input context for the locally deployed large language model.

[0078] The large language model generates a sequence of handling steps based on this, such as first performing connection configuration verification and connection leak investigation, and then performing blockage location and handling operations; and generates corresponding verification items for each step, such as checking whether the connection occupancy ratio and waiting queue length change in the preset direction; when a verification item fails, a rollback item is generated, such as undoing the executed configuration adjustments and restoring to a historical stable configuration, or performing a service state recovery operation to return to a controllable operating state. In this way, the handling suggestions are consistent with the actual indicator context of the current alarm event, and can also draw on historical handling experience to form an executable step-by-step output.

[0079] This embodiment structures the retrieved disposal evidence into an evidence set and inputs it together with standardized alarm data into a locally deployed and supervised fine-tuned large language model. This enables the disposal suggestions generated by the model to form a sequence of disposal steps and their corresponding verification items and / or rollback items with the support of evidence. This improves the operability and verifiability of the disposal suggestions, reduces the reliance on human experience in the disposal process, and provides a traceable disposal sample basis for subsequent closed-loop feedback and incremental model updates.

[0080] In some embodiments, the verification items include one or more of the following: monitoring metric checks for verifying alarm recovery status, connectivity checks for verifying service link status, or threshold checks for verifying resource occupancy status; the rollback items include one or more of the following: reverse configuration operation for reversing configuration changes or service restart operation for restoring service status.

[0081] Specifically, the verification items include at least one or more of the following: monitoring metric checks for verifying alarm recovery status, connectivity checks for verifying service link status, or threshold checks for verifying resource occupancy status.

[0082] The monitoring metric check items are used to read key metrics associated with alarm events from the monitoring system or alarm platform, and determine whether the alarm has been cleared or the anomaly has been mitigated based on preset recovery criteria. The key metrics can be consistent with the key metric information in the standardized alarm data to ensure that the verification items are consistent with the semantic boundaries of the alarm events.

[0083] Connectivity checks are used to perform connectivity or availability verification on the business links associated with the alarm object. The business links can be determined by the alarm object category and key entity information. For example, links for database instances may include application-to-database connection availability checks or query connectivity checks, while links for application services may include service port availability checks or API call availability checks.

[0084] The threshold check item is used to determine the threshold of resource usage status. The resource usage status may include one or more of the following: connection usage ratio, thread queue length, processor usage rate, or memory usage rate. It is compared with a preset threshold range to determine whether the handling steps have brought the resource usage back to an acceptable range.

[0085] In some examples, the generation of verification items maintains a one-to-one correspondence with the sequence of handling steps, meaning that each handling step corresponds to at least one verification item, enabling immediate result verification after the handling step is executed. Specifically, when organizing the model's input context, the handling suggestion generation unit uses the verification points output by the knowledge enhancement component and key indicator information from standardized alarm data as the basis for generating verification items. This allows the large language model to output verification items associated with each handling step simultaneously. For example, when a handling step involves configuration item adjustment or connection cleanup, the verification items can prioritize monitoring indicator checks and threshold checks to verify whether the connection occupancy rate, waiting queue length, or error count changes in a preset direction. When a handling step involves service status restoration or fault isolation, the verification items can simultaneously select connectivity checks to verify whether the business link has been restored to availability.

[0086] In some examples, rollback items include one or more of the following: reverse configuration operation items for undoing configuration changes or service restart operation items for restoring service state. Reverse configuration operation items are used to undo executed configuration adjustments when verification fails, reverting the system state to its pre-processing or historically stable configuration state. To ensure the executability of the rollback operation, this embodiment establishes a correspondence between reverse configuration operation items and configuration change items in the processing steps. Specifically, the adjusted configuration object and change direction are recorded in the processing step sequence, and the target configuration value or rollback basis is given in the rollback item.

[0087] The service restart operation item is used to restore the service to its running state when verification fails or an abnormal state occurs during the handling process. The service restart object can be determined by the alarm object identifier, alarm object category, and key entity information. For example, it can be used to restart the connection service or middleware component associated with the database instance, or to restart the application service instance to restore its availability. To reduce the risks introduced by rollback operations, the handling suggestion generation unit can also provide the corresponding verification items in the rollback item, so that the rolledback state can also be verified by monitoring indicator checks, connectivity checks, or threshold checks.

[0088] The following example illustrates the "database connection pool full" alarm. The recommended handling steps may include connection configuration verification and connection cleanup. For connection cleanup, verification items may include monitoring metric checks and threshold checks, such as checking if the connection occupancy rate has decreased from nearly 100% to within a preset threshold range, if the wait queue length has decreased and remained stable, and if the related error count has decreased. For the business link status of database access recovery, connectivity checks can be configured, such as verifying the availability of applications connecting to the database or the availability of critical queries.

[0089] If the above verification items fail after adjusting the connection configuration, the rollback item may include a reverse configuration operation item, used to undo the adjusted connection limit or timeout configuration and restore the historical stable configuration. If an abnormal service status or connection service unavailability occurs during the handling process, the rollback item may include a service restart operation item, used to restart the service instance associated with the alarm object to restore the service status. In this way, the handling recommendation can provide verifiable checks after each step of the handling and provide an executable rollback path when verification fails, making the handling chain a controllable closed loop.

[0090] This embodiment defines verification items and rollback items in a typological manner, establishes a correspondence between verification items and the sequence of handling steps, and establishes a correspondence between rollback items and configuration changes or service status operations in the handling steps. This enables handling suggestions to have verifiable and rollback capabilities, allowing operation and maintenance personnel to quickly determine whether the handling is effective based on the verification results and to perform rollback when necessary. This reduces the trial and error costs and secondary failure risks in the handling process, and provides a structured basis for the closed-loop feedback unit to collect high-quality handling result feedback and for subsequent knowledge base updates.

[0091] In some embodiments, the closed-loop feedback unit is specifically used for: Obtain feedback from operations and maintenance personnel regarding the handling suggestions. The handling result feedback includes one or more of the following: operations and maintenance score information and handling conclusion information. The entry conditions are determined based on the feedback of the disposal results. The preset entry conditions include that the operation and maintenance score is not lower than the preset score threshold, and / or the disposal conclusion is marked as a valid disposal conclusion. When the preset data entry conditions are met, the feedback of the handling results is associated with the event identifier, alarm type and handling steps sequence of the standardized alarm data to generate associated sample data, and the associated sample data is written into the alarm handling knowledge base to form new knowledge entries. The addition of new knowledge entries triggers incremental training or parameter updates for the large language model, enabling the large language model to call upon the corresponding handling evidence when generating handling suggestions for the same or similar alarm events.

[0092] Specifically, the closed-loop feedback unit obtains feedback from operations and maintenance personnel regarding the handling results of the suggested actions. This feedback includes one or more of the following: operations and maintenance score information and handling conclusion information. The operations and maintenance score information can be represented using a preset scoring scale, such as a 1-5 point system. A high score indicates that the handling suggestion is highly executable and effective, while a low score indicates that the handling suggestion is inapplicable or has omissions. The handling conclusion information characterizes the status of the alarm handling result and may include conclusion markers such as alarm cleared, alarm not cleared, handling failed, requiring escalation, or rollback already performed.

[0093] To ensure that the feedback content can be stably associated with alarm events and handling suggestions, the closed-loop feedback unit simultaneously acquires the event identifier, alarm type and handling suggestion identifier when collecting feedback. It can also record the actual execution steps selected by the operation and maintenance personnel, the actual execution order and the results of key verification items during execution, so that the feedback data not only includes the results, but also includes traceable handling path information.

[0094] Furthermore, after receiving feedback on the handling results, the closed-loop feedback unit performs an entry condition determination based on the handling results feedback. Preset entry conditions include an operation and maintenance score not lower than a preset score threshold, and / or the handling conclusion being marked as a valid handling conclusion. For example, the closed-loop feedback unit compares the operation and maintenance score with the preset score threshold, which can be set to 4 points or other thresholds that meet the local operation and maintenance quality threshold. Simultaneously, it determines the validity of the handling conclusion information. For example, if the handling conclusion is marked as alarm cleared and no rollback was triggered, or marked as a rollback performed but the system recovered and was confirmed by operation and maintenance after the rollback, it can be considered a valid handling conclusion. Through this determination mechanism, the closed-loop feedback unit only includes high-quality and reusable handling experience in the knowledge accumulation scope, avoiding the pollution of the alarm handling knowledge base by low-quality suggestions or inapplicable handling paths.

[0095] When the preset data entry conditions are met, the closed-loop feedback unit associates the handling result feedback with the event identifier, alarm type, and handling step sequence of the standardized alarm data, generating associated sample data. This associated sample data is then written into the alarm handling knowledge base to form new knowledge entries. The associated sample data includes at least: an event identifier, used to establish a unique association with the standardized alarm data; an alarm type, used to ensure consistency with the type label output by the intelligent analysis engine; a handling step sequence, used to record the confirmed and valid step-based handling path; and verification items and / or rollback items corresponding to the handling step sequence, used to characterize the verification and rollback information of the handling steps.

[0096] Furthermore, the associated sample data may also include one or more of the following: key entity information, key indicator information, and operating environment tags, enabling newly added knowledge entries to match search query elements in subsequent searches. The closed-loop feedback unit uses the aforementioned associated sample data as the content source for new knowledge entries, generates an entry identifier for each new knowledge entry, and writes entry metadata, such as recording operation and maintenance scores, disposal conclusion tags, and summaries of applicable conditions, thereby giving the new knowledge entries the attributes of being searchable, sortable, and interpretable.

[0097] After a new knowledge entry is written into the alarm handling knowledge base, the closed-loop feedback unit triggers incremental training or parameter updates for the large language model based on the new knowledge entry. For example, the closed-loop feedback unit can convert the associated sample data corresponding to the new knowledge entry into supervised training samples or incremental adaptation samples. The input side includes at least standardized alarm data associated with the event identifier and a summary of handling evidence associated with the alarm type. The output side includes at least a confirmed valid sequence of handling steps and its verification and / or rollback items.

[0098] In this way, incremental training of the model can enhance the consistency of the generated handling paths and terminology in local scenarios. At the same time, the newly added knowledge entries are incorporated into the alarm handling knowledge base and participate in vectorization representation and index updates. This enables the knowledge enhancement component to recall the newly added knowledge entries as candidate handling case information in subsequent searches, and then output the corresponding handling evidence, providing direct evidence support for the generation of handling suggestions for the next similar alarm event.

[0099] The following example illustrates the "database connection pool full" alarm. After implementing the suggested handling measures, the operations and maintenance personnel assign an operational score of 4 or 5 points and mark the alarm as resolved. Based on this, the closed-loop feedback unit determines that the preset data entry conditions are met, and associates the handling result with the event identifier, alarm type label (connection resource exhaustion alarm), and handling step sequence of the alarm event to form associated sample data. This data is then written into the alarm handling knowledge base to generate a new knowledge entry.

[0100] The newly added knowledge entries record the key points of the handling steps related to connection pools for database instance categories, the corresponding verification items (such as monitoring indicators such as connection usage ratio decline and waiting queue length decrease), and rollback items when necessary (such as reverse configuration operation items to undo configuration changes or service restart operation items to restore service status).

[0101] Subsequently, the closed-loop feedback unit triggers incremental training or parameter updates of the model, enabling the large language model to more stably generate step-by-step handling suggestions consistent with the newly added knowledge entry when encountering the same or similar connection pool exhaustion alarms in the future, and making it easier for the knowledge enhancement component to recall the handling evidence corresponding to the newly added knowledge entry during the retrieval phase.

[0102] This embodiment introduces an entry condition judgment mechanism driven by operation and maintenance scoring and handling conclusions. It associates high-quality handling results feedback with event identifiers, alarm types and handling step sequences to form new knowledge entries. At the same time, it triggers incremental training or parameter updates of the large language model, so that handling experience can be continuously accumulated and fed back into the subsequent alarm handling chain, thereby improving the knowledge base coverage and the consistency of suggestion generation, reducing the cost of repeated judgment, and forming a sustainable optimization closed loop suitable for local deployment scenarios.

[0103] The above embodiments have described in detail the specific modules and functions of the alarm automatic processing system based on a locally deployed large model of this application. The implementation process of the alarm automatic processing method based on a locally deployed large model of this application will be described in detail below with reference to specific embodiments. Figure 2 This is a flowchart illustrating the automatic alarm processing method based on a locally deployed large model provided in an embodiment of this application, as shown below. Figure 2 As shown, the method may specifically include the following steps: S201: Receive raw alarm data output from at least one monitoring system, perform field normalization and alarm event normalization processing on the raw alarm data, and generate standardized alarm data; S202: Input standardized alarm data into the large language model, extract alarm elements associated with alarm events and determine alarm types, generate retrieval query elements corresponding to alarm events, and select alarm processing structures based on alarm types; S203, construct an alarm handling knowledge base, perform vectorization representation and similarity retrieval index construction on historical handling records or operation and maintenance knowledge items; retrieve candidate handling case information in the alarm handling knowledge base based on the retrieval query elements, and if the preset recall conditions are not met, update the retrieval query elements and retrieve again to output handling evidence related to the alarm event; S204. Input standardized alarm data and handling evidence into the big language model to generate handling suggestions corresponding to the alarm event. The handling suggestions include a sequence of handling steps arranged in order and verification items and / or rollback items corresponding to the sequence of handling steps. S205: Obtain feedback from operations and maintenance personnel on the handling results of the handling suggestions, and when the handling results feedback meets the preset storage conditions, associate the handling results feedback with standardized alarm data, alarm type and handling suggestions and write it into the alarm handling knowledge base, and trigger incremental training or parameter update of the large language model based on the written associated data.

[0104] Specifically, in S201, the alarm access side first faces heterogeneous alarms output from multiple monitoring systems: different systems differ in field names, field value definitions, time formats, severity level expressions, and alarm description text wording. To ensure that the subsequent large language model can stably parse and output reusable alarm elements, this application performs field normalization processing on the raw alarm data, uniformly mapping the field names of different monitoring systems to a preset field set, and standardizing the severity level, time field, alarm object identifier, etc., to form alarm event data with a unified field structure. Subsequently, based on one or more of the alarm object identifier, alarm type information, alarm occurrence time, and severity level information, alarm event normalization is performed, merging multiple raw alarm data representing the same alarm event into a single standardized alarm data, and generating an event identifier for it.

[0105] Furthermore, standardized alarm data is supplemented with basic context fields associated with alarm events, such as alarm object category, abnormal symptom description, and key indicator information. This ensures that standardized alarm data is not only "structurally consistent" but also possesses "contextual consistency" to support semantic judgment and enhanced retrieval. For example, for a "database connection pool full" alarm, standardized alarm data can include alarm object identifier, alarm object category as database instance, abnormal symptom description as connection resource exhaustion, connection occupancy ratio, waiting queue length, and other key indicator information. This provides an input foundation for subsequent alarm element extraction and retrieval query element construction.

[0106] In S202, the intelligent analysis engine organizes standardized alarm data into a model input context according to a preset input template and inputs it into a locally deployed and supervised fine-tuned large language model. The large language model performs semantic parsing on the alarm description text and context fields, extracting alarm elements associated with the alarm event. Alarm elements include at least the alarm object identifier, anomaly symptom description, key entity information, and / or key indicator information. Among them, key entity information is used to clarify the boundaries of the object or component to be handled, and key indicator information is used to characterize the quantitative performance of the anomaly; both together support the accuracy of alarm type determination.

[0107] Subsequently, the large language model outputs alarm types and generates type labels based on alarm elements, enabling alarm events to be mapped to a preset alarm type space. Based on alarm types and alarm elements, the intelligent analysis engine constructs retrieval query elements. The retrieval query elements include at least one or more of the following: alarm type, description of abnormal symptoms, and key entity information. These elements are used by the subsequent knowledge enhancement component to perform similarity retrieval in the alarm handling knowledge base.

[0108] Meanwhile, the intelligent analysis engine selects the alarm processing structure based on the alarm type: when the alarm type belongs to a preset set of common alarms obtained from historical handling records, it selects an alarm processing structure that primarily generates handling suggestions, and uses the search query elements as auxiliary inputs for generating handling suggestions; when the alarm type does not belong to the preset set of common alarms or the alarm elements meet preset uncertainty conditions, it selects an alarm processing structure that primarily outputs handling evidence, and prioritizes triggering search enhancement to fill in the evidence boundaries. Taking "database connection pool full" as an example, if the alarm is a high-frequency type and the handling path is stable, it can directly enter the main link of handling suggestion generation; if the alarm elements lack key indicators or there are multiple types of candidate ambiguities, it prioritizes entering the evidence-gathering search link.

[0109] In S203, the knowledge enhancement component locally collects and organizes knowledge source data related to alarm handling. This knowledge source data includes historical alarm handling records, operation and maintenance manuals, and / or work order records. The knowledge enhancement component performs structured organization and content segmentation on the knowledge source data, generating multiple knowledge entries and associating and storing metadata for each knowledge entry, such as alarm type, alarm object category, description of abnormal symptoms, key entity information, key points of handling steps, key points of verification, key points of rollback, operating environment markers, and sample quality markers.

[0110] Subsequently, a vectorized representation is generated for the knowledge entry content, and a similarity retrieval index structure is constructed based on this representation, enabling rapid semantic similarity retrieval in a local environment. After the intelligent analysis engine outputs the search query elements, the knowledge enhancement component performs a similarity retrieval in the knowledge base based on these elements to obtain candidate handling case information, and then performs recall condition determination on the candidate handling case information. The preset recall conditions include at least one or more of the following: similarity reaching a threshold, the number of candidates reaching a threshold, and the alarm object category of the candidate entry matching the alarm event object category.

[0111] If the recall criteria are not met, supplementary search elements are determined based on candidate handling case information and standardized alarm data. These elements may include key entity information, key indicator information, operating environment information, or error identification information. These are then merged to form updated search query elements, and a similarity search is performed again until the recall criteria are met, at which point handling evidence is output. Handling evidence is the evidence-based organization of key handling steps, applicable conditions, verification points, and / or rollback points in candidate cases. For example, in a "database connection pool full" scenario, the first round of search may recall entries related to resource exhaustion but with inconsistent object categories. After supplementing elements such as "database instance, connection pool, connection usage ratio," a second search can recall more matching connection pool handling entries. Reusable key handling steps, verification points, and rollback points are extracted from these entries to form handling evidence.

[0112] In S204, the handling suggestion generation unit first organizes the handling evidence in a structured manner to form an evidence set associated with the alarm event. The evidence set includes at least one or more of the following: a summary of similar cases, a set of key points of handling steps, a set of key points of verification, and a set of key points of rollback.

[0113] Subsequently, standardized alarm data and evidence sets are combined into the model input context and fed into a locally deployed large language model. This allows the model to output handling suggestions based on the evidence set, avoiding handling path drift caused by relying solely on free generation. The large language model then generates a sequential sequence of handling steps and generates corresponding verification items and / or rollback items for each step.

[0114] Verification items are used to check the result status after the execution of the handling steps, and may include one or more of the following: monitoring indicator checks, business link connectivity checks, and resource usage threshold checks. Rollback items are used to perform reverse operations or restore the state when verification fails, and may include one or more of the following: reverse configuration operations or service restart operations. Taking "database connection pool full" as an example, the sequence of handling steps can be organized around connection configuration verification, connection leak investigation, and blockage location. Verification items can check whether the connection usage ratio and waiting queue length have decreased, and whether key queries have been restored to connectivity. Rollback items can undo connection parameter changes or restart relevant service instances to restore a stable state, thus forming a controllable closed-loop output of "steps - verification - rollback".

[0115] In S205, the closed-loop feedback unit collects feedback on the handling results after the handling suggestion is executed. The handling result feedback includes one or more of the following: operation and maintenance score information and handling conclusion information. The operation and maintenance score can use a scale of 1-5 points, and the handling conclusion can be marked as alarm cleared, not cleared, handling failed, rolled back, or requiring escalation. The closed-loop feedback unit performs an entry condition determination based on the handling result feedback. The preset entry conditions include at least the operation and maintenance score not being lower than a preset score threshold and / or the handling conclusion being marked as a valid handling conclusion.

[0116] When the conditions for inclusion in the database are met, the feedback of the handling results is associated with the event identifier, alarm type, and handling step sequence of the handling suggestions in the standardized alarm data to generate associated sample data, which is written into the alarm handling knowledge base to form a new knowledge entry. At the same time, the similarity retrieval index is updated so that the new entry can be retrieved in subsequent searches.

[0117] Furthermore, by triggering incremental training or parameter updates of the large language model based on newly added knowledge entries, high-quality handling samples are incorporated into the model's continuous adaptation data source, enabling the model to generate handling suggestions consistent with local experience more stably when facing the same or similar alarm events in the future, and forming a synergy with the retrieval enhancement link.

[0118] Through the processes described in S201 to S205 above, this application, under localized deployment conditions, uses standardized alarm data as a unified input base, semantic parsing of a large language model as the core of alarm understanding, vectorized retrieval of the alarm handling knowledge base as a means of evidence supplementation, and step-by-step handling suggestions and their verification items and / or rollback items as executable outputs. Furthermore, it forms a closed-loop feedback mechanism driven by operation and maintenance scoring and handling conclusions for database entry and incremental updates. This enables the automatic alarm handling method to complete the entire chain from data organization, type determination, evidence retrieval to suggestion generation and continuous optimization in different alarm scenarios.

[0119] It should be understood that the sequence number of each step in the above method embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0120] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although the technical solutions of this application have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. An automatic alarm processing system based on a locally deployed large model, characterized in that, include: An alarm access unit is used to receive raw alarm data output by at least one monitoring system, and to perform field normalization and alarm event normalization processing on the raw alarm data to generate standardized alarm data. The intelligent analysis engine includes a locally deployed and supervised fine-tuned large language model, which is used to extract alarm elements and determine alarm types based on the standardized alarm data, generate retrieval query elements corresponding to alarm events, and select alarm processing structures based on alarm types. The knowledge enhancement component is used to build an alarm handling knowledge base. It performs vectorization representation and similarity retrieval index construction on the historical handling records or operation and maintenance knowledge entries in the alarm handling knowledge base, and retrieves candidate handling case information based on the retrieval query elements. If the preset recall conditions are not met, the retrieval query elements are updated and the retrieval is performed again to output handling evidence associated with the alarm event. The handling suggestion generation unit is used to input standardized alarm data and handling evidence into the big language model to generate handling suggestions corresponding to the alarm event. The handling suggestions include a sequential sequence of handling steps and verification items and / or rollback items corresponding to the sequence of handling steps. The closed-loop feedback unit is used to obtain the feedback of the operation and maintenance personnel on the handling results of the handling suggestions, and when the handling result feedback meets the preset storage conditions, it associates the handling result feedback with standardized alarm data, alarm type and handling suggestions and writes it into the alarm handling knowledge base, and triggers incremental training or parameter update of the large language model based on the written associated data.

2. The system according to claim 1, characterized in that, The step of performing field normalization and alarm event normalization on the original alarm data to generate standardized alarm data includes: Perform unified mapping and normalization on the field names, field value definitions, and alarm description text of the raw alarm data from different monitoring systems to obtain alarm event data with a unified field structure; Based on one or more of the alarm object identifier, alarm type information, alarm occurrence time, and severity level information in the alarm event data, alarm event normalization is performed, merging multiple original alarm data representing the same alarm event into one standardized alarm data, and generating an event identifier for the standardized alarm data for subsequent processing. The standardized alarm data is supplemented with basic context fields associated with alarm events so that the intelligent analysis engine can use the standardized alarm data to extract alarm elements and generate retrieval query elements.

3. The system according to claim 1, characterized in that, The step of extracting alarm elements and determining alarm types based on the standardized alarm data, and generating retrieval query elements corresponding to the alarm events, includes: The standardized alarm data is input into the large language model, which performs semantic parsing on the alarm description text and context fields associated with the alarm event in the standardized alarm data, and extracts alarm elements associated with the alarm event. The alarm elements include alarm object identifier, abnormal symptom description, key entity information and / or key indicator information. Based on the alarm elements, the large language model outputs the alarm type and generates a type label associated with the alarm event for the alarm type; Based on the alarm type and the alarm elements, a retrieval query element is constructed, wherein the retrieval query element includes one or more of the alarm type, the description of the abnormal symptoms, and the key entity information.

4. The system according to claim 3, characterized in that, The alarm processing structure based on alarm type selection includes: Based on the alarm type and the standardized alarm data, it is determined whether the alarm event belongs to a preset common alarm set, which includes high-frequency alarm types obtained by statistical analysis of historical handling records; When it is determined that the alarm event belongs to the preset common alarm set, an alarm processing structure that primarily generates the handling suggestions is selected, and the search query elements are used as auxiliary inputs for generating the handling suggestions; When it is determined that the alarm event does not belong to the preset common alarm set or the alarm element meets the preset uncertainty condition, an alarm processing structure that mainly outputs the disposal evidence is selected, and the knowledge enhancement component is triggered to perform similar case retrieval based on the retrieval query element to obtain the candidate disposal case information.

5. The system according to claim 1, characterized in that, The construction of the alarm handling knowledge base involves performing vectorized representation and similarity retrieval index construction on historical handling records or operation and maintenance knowledge entries in the alarm handling knowledge base, including: Acquire knowledge source data related to alarm handling, including historical alarm handling records, operation and maintenance manuals and / or work order records; The knowledge source data is structured and segmented to generate multiple knowledge entries, and the metadata of each knowledge entry is associated with and stored in relation to alarm handling. A vectorized representation is generated for the content of each knowledge item, and the vectorized representation is associated with and stored with the corresponding item metadata to form the alarm handling knowledge base; Based on the vectorized representation, an index structure for similarity retrieval is constructed, enabling the knowledge enhancement component to perform similarity retrieval in the alarm handling knowledge base based on the retrieval query elements to obtain candidate handling case information.

6. The system according to claim 5, characterized in that, The process of retrieving candidate handling case information based on search query elements, and then retrieving again after updating the search query elements if the preset recall conditions are not met, to output handling evidence associated with the alarm event, includes: Based on the search query elements, a similarity search is performed in the alarm handling knowledge base to obtain candidate handling case information; The candidate handling case information is subjected to a recall condition determination, wherein the preset recall condition includes one or more of the following: the similarity of the candidate handling case information meets a preset similarity threshold, the number of candidates meets a preset number threshold, or the alarm object category of the candidate handling case information is consistent with the alarm object category of the alarm event. If the preset recall conditions are not met, supplementary search elements are determined based on the candidate disposal case information and the standardized alarm data, and the supplementary search elements are merged into the search query elements to form updated search query elements. Based on the updated search query elements, the similarity search is performed again, and when the preset recall conditions are met, the processing evidence associated with the alarm event is output.

7. The system according to claim 1, characterized in that, The step of inputting standardized alarm data and handling evidence into the big language model to generate handling suggestions corresponding to the alarm event includes: The evidence of the handling is structured and organized to obtain a set of evidence associated with the alarm event; The standardized alarm data and the evidence set are combined into a model input context, and the model input context is input into the large language model so that the large language model outputs a handling suggestion under the constraint of the evidence set. The large language model generates a sequence of sequentially arranged disposal steps, and generates verification items and / or rollback items corresponding to the steps in the sequence. The verification items are used to check the execution result of the disposal steps, and the rollback items are used to reverse the execution of the disposal steps or restore the state when the verification fails.

8. The system according to claim 7, characterized in that, The verification items include one or more of the following: monitoring indicator checks for verifying alarm recovery status, connectivity checks for verifying service link status, or threshold checks for verifying resource occupancy status; the rollback items include one or more of the following: reverse configuration operation items for revoking configuration changes or service restart operation items for restoring service status.

9. The system according to claim 1, characterized in that, The closed-loop feedback unit is specifically used for: Obtain feedback from operations and maintenance personnel regarding the proposed handling results. The feedback results may include one or more of the following: operations and maintenance scoring information and handling conclusion information. Based on the feedback of the disposal results, the storage conditions are determined. The preset storage conditions include that the operation and maintenance score is not lower than the preset score threshold, and / or the disposal conclusion is marked as a valid disposal conclusion. When the preset storage conditions are met, the processing result feedback is associated with the event identifier, alarm type and processing step sequence of the standardized alarm data to generate associated sample data, and the associated sample data is written into the alarm processing knowledge base to form a new knowledge entry. Based on the newly added knowledge entry, incremental training or parameter updates of the large language model are triggered, enabling the large language model to call the handling evidence corresponding to the newly added knowledge entry when generating handling suggestions for the same or similar alarm events in the future.

10. An automatic alarm processing method based on a locally deployed large model according to any one of claims 1 to 9, characterized in that, include: Receive raw alarm data output from at least one monitoring system, perform field normalization and alarm event normalization processing on the raw alarm data, and generate standardized alarm data; The standardized alarm data is input into a large language model to extract alarm elements associated with alarm events and determine alarm types. Search query elements corresponding to the alarm events are generated, and alarm processing structures are selected based on the alarm types. Build an alarm handling knowledge base, and perform vectorization representation and similarity retrieval index construction on historical handling records or operation and maintenance knowledge items; Based on the search query elements, candidate handling case information is retrieved in the alarm handling knowledge base. If the preset recall conditions are not met, the search query elements are updated and the search is performed again to output handling evidence associated with the alarm event. The standardized alarm data and the handling evidence are input into the big language model to generate handling suggestions corresponding to the alarm event. The handling suggestions include a sequence of handling steps arranged in order and verification items and / or rollback items corresponding to the sequence of handling steps. Obtain feedback from operations and maintenance personnel regarding the proposed handling results. When the feedback results meet preset storage conditions, associate the feedback results with the standardized alarm data, the alarm type, and the proposed handling results and write them into the alarm handling knowledge base. Based on the written associated data, trigger incremental training or parameter updates for the large language model.

Images