Fault case intelligent matching method based on large language model and jaccard similarity

Abstract

The application provides a fault case intelligent matching method based on a large language model and Jaccard similarity, comprising: fault information extraction, extracting a service list, an alarm list and an association mapping from an original alarm event; service role abstraction, calling a large language model to infer a specific service name into a predefined service role; alarm type classification, calling a large language model to classify a specific alarm into a predefined alarm type; feature combination set construction, combining the service role and the alarm type into a "{service role.alarm type}" feature element to form a feature combination set; Jaccard similarity calculation, calculating the Jaccard similarity of the feature set of the current fault and the historical cases; result sorting and returning, returning the top N most similar cases after sorting according to the similarity; the application realizes semantic abstraction through LLM, utilizes Jaccard for efficient set operation, and introduces a cache reuse mechanism, so that the real-time performance, interpretability and low cost requirements are considered while the matching accuracy is ensured.

Description

Technical Field

[0001] This invention belongs to the field of intelligent operations and maintenance (AIOps) technology, specifically involving an intelligent fault case matching method based on the similarity between a large language model and Jaccard. Background Technology

[0002] With the continuous expansion of enterprise IT systems and the widespread adoption of microservice architectures, the frequency and complexity of system failures have increased significantly. In the process of fault handling, quickly retrieving and referencing solutions from similar historical failure cases is crucial for improving operational efficiency and shortening fault recovery time. However, existing fault case retrieval methods have the following drawbacks: 1. Inefficient manual retrieval: Currently, the retrieval of historical fault cases mainly relies on the personal experience of maintenance personnel and manual document searching. This method is not only inefficient, but also prone to missing key cases. Especially when team members change, valuable fault handling experience is difficult to pass on, often resulting in the dilemma of "the problem seems familiar, but the solution cannot be remembered".

[0003] 2. Direct matching based on service names is almost ineffective: Some automation solutions attempt to match based on service names; however, in large IT systems, which often contain hundreds of microservices, the probability of two failures involving completely identical services is extremely low. For example, a failure caused by the master MySQL database and a failure caused by the slave MySQL database will result in zero direct matching results due to the different service names (mysql-master vs. mysql-slave), even though the essence of the failure (database problem) is the same. This problem of "different literal meanings, same semantics" leads to extremely low recall rates for direct matching solutions.

[0004] 3. Traditional similarity algorithms lack semantic understanding capabilities: Although text similarity algorithms such as TF-IDF and BM25 and set similarity algorithms such as Jaccard are computationally efficient, they can only handle literal or symbolic matching and cannot understand the deep semantics and role relationships behind service names and alarm information. They are also unable to identify cases with the same fault mode but involving different services.

[0005] 4. Pure large language model solutions have performance and interpretability issues: Relying entirely on large language models for end-to-end case matching, while possessing semantic understanding capabilities, has significant shortcomings: First, high computational costs and large response latency make it difficult to meet the real-time requirements of fault handling; second, the matching process is like a "black box," with results lacking clear explanation, which is not conducive to the understanding and trust of operations and maintenance personnel; finally, each query requires calling the LLM, resulting in high API costs and making it difficult to deploy on a large scale in production environments. Summary of the Invention

[0006] To overcome the shortcomings of existing technologies, this invention provides an intelligent fault case matching method based on large language model and Jaccard similarity. This method combines the semantic understanding capability of LLM with the efficient calculation of Jaccard set similarity, ensuring matching accuracy while meeting the requirements of real-time performance, interpretability and low cost in actual operation and maintenance scenarios.

[0007] like Figure 1 As shown, the intelligent fault case matching method based on large language model and Jaccard similarity of the present invention mainly includes six steps: fault information extraction, service role abstraction, alarm type classification, feature combination set construction, Jaccard similarity calculation, result sorting and return.

[0008] Step 1: Fault information extraction. From the original, unstructured fault alarm events, the key structured information required for subsequent matching is parsed out.

[0009] Raw fault alarm events are usually in unstructured or semi-structured formats, such as JSON or text logs, which cannot be directly used for subsequent matching calculations. In order to standardize fault processing, it is necessary to first extract key elements with clear semantics and relationships from the raw events.

[0010] Enter a raw fault alarm event E, which includes fields for alarm trigger time, alarm name, alarm details, and a list of service instances involved.

[0011] 1. Service list extraction: Parse the "Services Involved" field of alarm event E to extract all relevant service instance names and form a service set. , where m is the number of services involved in this failure.

[0012] 2. Alarm List Extraction: Parse all triggered alarm entries from the "Alarm Details" field of alarm event E to form an alarm set. Where n is the number of alarms triggered by this fault.

[0013] 3. Alarm-Service Association Construction: Based on the correspondence between alarms and services provided in the alarm events (for example, each alarm entry may explicitly indicate the service instance that generated the alarm), establish an association mapping. Alarm By service trigger If the original fault alarm event clearly indicates the correspondence between the alarm and the service, then a mapping is established directly; if the alarm entry does not provide an explicit association with a specific service instance, then the service corresponding to the alarm is marked as an unknown service, and a mapping is established. (Unknown), in subsequent steps, this alarm only participates in feature combination construction and similarity matching based on its alarm type.

[0014] This step outputs a structured fault information triplet. .

[0015] Step two, service role abstraction, unifies the semantically diverse but functionally similar specific service names into standardized service roles, eliminating matching barriers caused by differences in service names.

[0016] Traditional methods directly use service names for matching, but a service name is just an identifier and cannot reflect its functional role; for example, order-mysql-master and user-db-slave are different names, but they are both database services; without abstraction, it is impossible to match faults that are essentially the same.

[0017] This step involves inputting the service set. Service Role Definition Set Each role includes a name, description, and typical representative; service role cache library. Storing key-value pairs .

[0018] For each service Perform the following sub-steps: 1. Cache query: Key query service role cache library If the hit is successful, the service will be obtained directly. Corresponding role .

[0019] 2. If a cache miss occurs, the large language model inference is triggered: ① System build structured prompts (Prompt) Its contents include: Task Description: The task explicitly requires LLMs to determine their role type based on the provided service information. Service Information: The system queries the CMDB and service registry in real time via API to obtain the latest status information of the service, including but not limited to: service name, service description, recent alarm records, listening port, dependencies, etc., and formats this information into text. Role Definition: Input the set of service role definitions The name, description, and typical representatives of each role in the model are formatted as text and used as the basis for classifying LLMs; Output format: The LLM should be returned in JSON format, including the fields role (role name), confidence (confidence level, a floating-point number between 0 and 1), and reason (judgment basis).

[0020] ② Result parsing and caching: Receive the JSON string returned by the LLM and parse out the roles. Confidence level and reasons; Store in service role cache library And record the timestamp.

[0021] ③ Output mapping: Obtaining services Corresponding role .

[0022] This step outputs the service role mapping table. .

[0023] Furthermore, the predefined service role types mentioned in step two are role classification systems based on the functional layers of the IT system architecture, including but not limited to: traffic entry points (such as Gateway), business applications (such as Application), data storage (such as Database), caching services (such as Cache), message queues (such as MessageQueue), middleware (such as Middleware), storage services (such as Storage), and infrastructure (such as Infra). The service role types can be expanded or adjusted according to actual business scenarios.

[0024] Step 3: Alarm type classification. This involves unifying the specific and diverse alarm information into standardized alarm types, focusing on the essential categories of alarms.

[0025] Alarm messages can take many different forms. For example, "CPU utilization > 90%" and "memory utilization > 95%" may have different metrics, but they are essentially both resource-related alarms. If you directly match the original alarm text, you will not be able to identify faults with similar symptoms.

[0026] This step involves entering the alarm set. Alarm type definition set Each type includes a name, description, and a typical alarm example; alarm type cache library. Storing key-value pairs .

[0027] For each alarm Perform the following sub-steps: 1. Cache query: Query alarm type cache library by key If it hits, an alert will be generated immediately. Corresponding type .

[0028] 2. If a cache miss occurs, the large language model classification will be triggered: ① System construction structure prompts The content includes: Task Description: The task requires the LLM to determine the alarm type based on the provided alarm information. Alarm information includes alarm name, alarm details, threshold information, etc. Type definition: The set of alarm type definitions to be entered. The name, description, and typical alarm examples for each type in the LLM are formatted as text and used as the basis for LLM classification; Output format: The LLM should be returned in JSON format, including the fields type (alarm type), confidence (confidence level), and reason (judgment basis).

[0029] ② Result parsing and caching: Receive the JSON returned by the LLM and parse out the type. Confidence level and reasons; Store in alarm type cache library .

[0030] ③ Output mapping: Receive alarms Corresponding type .

[0031] This step outputs an alarm type mapping table. .

[0032] Furthermore, the predefined alarm types mentioned in step three are alarm classification systems based on the manifestations of IT system failures, including but not limited to: resource alarms (such as Resource, covering alarms related to resource exhaustion such as CPU, memory, and connection pools), latency alarms (such as Latency, covering alarms related to timeouts, slow queries, and response delays), error alarms (such as Error, covering alarms related to abnormal status codes and increased failure rates), availability alarms (such as Availability, covering alarms related to downtime and unreachability), and capacity alarms (such as Capacity, covering alarms related to queue backlog and excessive traffic). These alarm types can be expanded or adjusted according to actual operation and maintenance scenarios.

[0033] Step four involves constructing a feature combination set, which integrates the two dimensions of service role and alarm type to form standardized fault mode feature elements. These fault cases are then represented as a set, laying the foundation for similarity calculation.

[0034] Knowing only the service role or alarm type is not enough, because a failure is composed of "a certain alarm generated by a certain role of a service"; for example, "database delay" and "application delay" are two completely different failure modes; therefore, service roles and alarm types must be combined to form fine-grained failure characteristics.

[0035] This step requires the following input: Service Role Mapping Table Alarm type mapping table Alarm-Service Association Mapping .

[0036] 1. Initialize an empty set of feature combinations. .

[0037] 2. Traverse each pair in the associative mapping M. : ①According to Get Alerts Corresponding type ; ②According to Get services Corresponding role ; ③ Construct feature elements (The dots here indicate combination; they are actually stored as strings, such as "Database.Latency"). ④ Add to set F, that is ;symbol The union operation represents sets.

[0038] 3. Because sets are distinct, duplicate elements are automatically removed.

[0039] This step outputs the feature combination set of the current fault case. .

[0040] Step 5: Jaccard similarity calculation, based on a standardized feature set, quickly quantifies the similarity between the current fault and historical cases.

[0041] After obtaining a standardized feature set, an efficient and intuitive metric is needed to quantify the similarity between two faults. Jaccard similarity is chosen because it directly compares the degree of overlap between two sets, which is a natural fit for the fault matching problem.

[0042] This step involves inputting the set of feature combinations for the current fault. Historical Case Library Each historical case Its feature combination set has been pre-computed and stored. .

[0043] 1. Initialize an empty list to store the similarity results.

[0044] 2. For each historical case Obtain its feature set .

[0045] 3. Calculate the Jaccard similarity coefficient between the two sets: ; in It represents the intersection of two sets, that is, the characteristic elements they share; It represents the union of two sets, that is, all unique characteristic elements; The cardinality (number of elements) of a set.

[0046] 4. Calculate the similarity score Case Identifier Forming tuples Add it to list L.

[0047] 5. After traversing all historical cases, a similarity list is obtained: .

[0048] This step outputs a similarity list L.

[0049] Step six involves sorting and returning the results, providing users with the most relevant and valuable Top-N historical cases.

[0050] Similarity calculations may yield a large number of historical cases, but users only care about the few most relevant and valuable cases; at the same time, cases with extremely low similarity may interfere with the judgment and need to be filtered.

[0051] This step involves entering a similarity list. Preset similarity threshold (For example (This can be adjusted according to actual needs), and the maximum number of cases N to be returned (e.g., N=5).

[0052] 1. Sorting: Score the list L according to its similarity. Sort the list in descending order from largest to smallest to obtain the sorted list. .

[0053] 2. Filtering: From Remove those with scores below the threshold The case received ,Right now: .

[0054] 3. Extracting Top-N: From The first N cases are selected as the final result. ;if If the length is less than N, return all.

[0055] 4. Return: will The output includes detailed information about each historical case (such as case ID, fault description, solution, handling steps, etc.) and its similarity score. .

[0056] This step outputs a list of the Top-N most similar historical fault cases. .

[0057] Compared with the prior art, the present invention has the following significant advantages: (1) The semantic abstraction of service roles and alarm types is realized by LLM, and then the Jaccard similarity is used for efficient set operation, which not only ensures the accuracy of matching, but also meets the real-time requirements.

[0058] (2) Introduce a cache reuse mechanism to persistently store the inference results of service roles and alarm types, avoid repeated calls to LLM, significantly reduce API costs, and make the solution feasible for production environments.

[0059] (3) The matching results are based on an intuitive set of feature combinations, which can be clearly explained as "which fault modes the two faults share", making it easy for maintenance personnel to understand and trust.

[0060] (4) Transform expert experience into a standardized knowledge base to help maintenance personnel quickly locate similar historical cases and refer to the handling plan, significantly shorten the fault recovery time and lower the maintenance threshold.

[0061] Other features and advantages of the invention will be set forth in the following description or may be learned by practicing the invention. Attached Figure Description

[0062] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0063] Figure 1 This is an overall flowchart of the intelligent fault case matching method based on the similarity between a large language model and Jaccard in this invention.

[0064] Figure 2 This is a schematic diagram of the service role abstraction process in an embodiment.

[0065] Figure 3 This is a schematic diagram of the alarm type classification process in an embodiment.

[0066] Figure 4 This is a schematic diagram illustrating the process of constructing a feature combination set and calculating similarity in an embodiment. Detailed Implementation

[0067] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that the following embodiments are only used to explain the present invention and are not intended to limit the scope of the present invention.

[0068] Example: Matching of E-commerce Platform Order System Failure Cases This embodiment uses a real malfunction of an e-commerce platform as an example to fully illustrate the specific implementation process of the method of the present invention.

[0069] I. Fault Scenario Description: An e-commerce platform's monitoring system triggered an alarm on a certain day: the order system was responding slowly. The original fault alarm event E contained the following information: Alarm Name: Order Service Response Timeout Alarm details: response_time > 3s (response time > 3 seconds); slow_query > 1s (slow query > 1 second); connection_timeout (connection timeout); Services involved: order-service; order-mysql-master (order database); payment gateway.

[0070] II. Step-by-step implementation: Step 1, Fault Information Extraction: Extract structured information from the original alarm event E: Service Collection: The number of services is m=3.

[0071] Alarm Collection: The number of alarms is n=3.

[0072] Alarm - Service Association Mapping M (based on explicit annotations in the alarm event): .

[0073] This step outputs a structured fault information triplet. .

[0074] Step 2, Service Role Abstraction, such as Figure 2 As shown, LLM successfully inferred the service role based on the service information.

[0075] Service Role Definition Set It includes 8 characters, as shown in the table below (for reference). Figure 2 (Service role definition).

[0076] Service Role Caching Library Initially empty.

[0077] Process each service sequentially: (1) Service order-service: Cache miss, invoke LLM inference. Construct hint words. as follows: Please determine the service's role type based on the following information.

[0078]

Service Information

[0079] [Optional Roles and Definitions] ①Gateway - the traffic entry point, responsible for request routing and load balancing (typical: nginx, kong, api-gateway). ②Application - Business application service, which handles business logic (typical: various business microservices); ③ Database - Database service, responsible for data persistence (typical: MySQL, MongoDB, PostgreSQL); ④ Cache - a caching service that provides high-speed data access (typical examples: Redis, Memcached). ⑤MessageQueue - Message queue, responsible for asynchronous message passing (typical: Kafka, RabbitMQ); ⑥Middleware services (typical examples: Elasticsearch, ZooKeeper, Nacos); ⑦Storage - Storage services (typically: MinIO, HDFS, NFS); ⑧Infra-Infrastructure components (typical: Prometheus, ELK, Grafana).

[0080] Output Requirements Please output in JSON format, including the following fields: role: Role name (must be one of the above 8 types); confidence: confidence level (a value between 0.0 and 1.0); Reason: Basis for judgment (briefly explain the reason for the inference).

[0081] LLM returns JSON: { "role": "Application", "confidence": 0.95, "reason": "The service name contains '-service', it listens on business port 8080, and it is for core order processing." } Cache records (order-service, Application).

[0082] (2) Service order-mysql-master: Cache miss, LLM called. Returns: {"role": "Database", "confidence": 0.98, "reason": "The service name contains 'mysql' and it is the primary database"}; Cache records (order-mysql-master, Database).

[0083] (3) Service payment gateway: Cache miss, LLM called. Returns: {"role": "Gateway", "confidence": 0.96, "reason": "Service name containing 'gateway', responsible for payment gateway"}; Cache records (payment-gateway, Gateway).

[0084] This step outputs the service role mapping table: .

[0085] Step 3, classify alarm types, such as Figure 3 As shown, LLM successfully categorized alarm types based on alarm information.

[0086] Alarm type definition set It includes 5 types, as shown in the table below (refer to...) Figure 3 Alarm type definition).

[0087] Alarm type caching library Initially empty.

[0088] Process each alarm sequentially: (1) Alarm response_time > 3s: Cache miss, calling LLM categorization. Construct warning words. This includes alarm information and type definitions. LLM returns: {"type": "Latency", "confidence": 0.97, "reason": "Response timeout is a delay-related alarm"}; Cache record (response_time(response_time>3s,Latency).

[0089] (2) Alert slow_query > 1s: Cache miss, call LLM. Construct structured hint words. as follows: Please determine the type of alarm based on the following information.

[0090] [Alarm Information] Alarm Name: Slow Query Alarm; Alarm details: slow_query > 1s; Threshold information: Query execution time exceeds 1 second.

[0091]

Optional Types and Definitions

[0092] Output Requirements Please output in JSON format, including the following fields: type: Alarm type (must be one of the above 5 types); confidence: confidence level (a value between 0.0 and 1.0); Reason: Basis for judgment (briefly explain the reason for the inference).

[0093] LLM returns JSON: { "type": "Latency", "confidence": 0.96, "reason": "Slow queries cause database response delays, which falls under the category of delay-related alerts." } Cache records (slow_query>1s, Latency).

[0094] (3) Alarm connection_timeout: Cache miss, LLM called. Returns: {"type": "Error", "confidence": 0.94, "reason": "Connection timeout is a connection error"}; Cache record (connection_timeout, Error).

[0095] This step outputs an alarm type mapping table: .

[0096] Step 4, construct the feature combination set, such as Figure 4 As shown, the feature combination set has been constructed.

[0097] enter , M; Initialize an empty set ; Traverse each pair in M : (1) For (response_time > 3s, order-service): according to We get t = Latency; according to Get r = Application; Construct the feature element f = Application.Latency; .

[0098] (2) For (slow_query>1s, order-mysql-master): t = Latency; r = Database; f = Database.Latency; .

[0099] (3) For (connection_timeout, payment-gateway): t = Error; r = Gateway; f = Gateway.Error; .

[0100] The final set of feature combinations is obtained as follows: ; This step outputs .

[0101] Step 5, Jaccard similarity calculation, such as Figure 4 As shown, the Jaccard similarity calculation results are clear.

[0102] The historical case library H pre-stores feature sets for two historical cases: Historical Cases (Slow PostgreSQL query caused payment timeout): ; Historical Cases (Redis cache penetration caused high pressure on the database): ; Current fault set feature combination set : (1) Case Study Similarity calculation: , ; , ; .

[0103] (2) with case studies Similarity calculation: , ; ; ; This step outputs a similarity list: Case 1.0 Case 0.2 .

[0104] Step 6, sorting and returning results: Take a similarity threshold The maximum number of returns is N = 5.

[0105] 1. Sorting (already sorted in descending order of score): Case 1.0 Case 0.2 ; 2. Filtering: Remove cases with scores below 0.3. ,get Case 1.0 ; 3. Extract Top-N: Take the first 5 (actually only 1), and get... Case 1.0 .

[0106] The final output is a list of Top-N similar cases, including cases Detailed information (such as case ID, fault description, solution, handling steps, etc.) and its similarity score of 1.0.

[0107] III. Results Analysis: This embodiment successfully matched the current fault with historical case A, with a similarity score of 1.0, indicating that both have the exact same fault mode—"database performance issues causing application layer latency and errors." Operations personnel can directly refer to the handling plan in case A for rapid recovery, verifying the effectiveness and practicality of the method of this invention.

[0108] IV. Cache reuse benefit analysis: In this embodiment, service role abstraction and alarm type classification trigger a total of 6 LLM calls (3 services + 3 alarms). In a real production environment, assume that an enterprise IT system contains 300 services and 50 common alarm types: Initial full annotation: Requires calling LLM 350 times to build a complete service role cache library and alarm type cache library.

[0109] Subsequent fault matching: More than 90% of the services and alarms involved in new faults are already in the cache, and the number of LLM calls has been reduced to an average of 0-2 per fault.

[0110] Cost-effectiveness: Taking 100 failures per month as an example, the non-caching solution requires 600 LLM calls per month; the caching solution requires only about 50 incremental calls per month after the first 350 calls (new services / new alarms), reducing the cost of LLM calls by more than 90%, while the failure matching response time is reduced from seconds to milliseconds.

[0111] This cache reuse mechanism makes the solution of this invention feasible for large-scale production environment deployment.

[0112] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A fault case intelligent matching method based on the similarity between a large language model and Jaccard, characterized in that, Includes the following steps: Step 1, Fault Information Extraction: Extract the set of services involved in the fault from the original fault alarm events. Alarm Collection And the mapping between alarms and services. Alarm By service trigger ; Step 2, Service Role Abstraction: For each service in the service list S Infer its service role by calling a large language model. Get the service role mapping table The service role is a predefined role type. Step 3, Alarm Type Classification: For each alarm in alarm list A... The large language model is used to classify the alarm types. Obtain the alarm type mapping table The alarm type is a predefined type. Step 4, Feature Combination Set Construction: Based on the service role mapping table Alarm type mapping table And the association mapping M, construct the feature combination set ; (1) Initialize an empty feature combination set ; (2) Traverse each pair in the associative mapping M : ①According to Get Alerts Corresponding type ; ②According to Get services Corresponding role ; ③ Construct feature elements ; ④ Add to set F, that is ; (3) Since the sets are distinct, duplicate feature elements are automatically removed, and the feature combination set of the current fault case is output. ; Step 5, Jaccard similarity calculation: For each historical case in the historical case library... Calculate the set of feature combinations of the current fault. Historical Cases Feature combination set Jaccard similarity: ； Similarity score Case Identifier Forming tuples Add it to list L; After iterating through all historical cases, a similarity list is obtained: ； Step 6, Result Sorting and Return: Sort the similarity list L in descending order of score, and return the Top-N most similar historical cases as the matching results.

2. The intelligent fault case matching method based on large language model and Jaccard similarity as described in claim 1, characterized in that, The service role abstraction described in step 2 further includes: for each service First, query the service role cache library. If the role exists, return the cached service role directly. If it does not exist, the large language model is called to perform inference, and the inference result is stored in the cache.

3. The intelligent fault case matching method based on large language model and Jaccard similarity as described in claim 1, characterized in that, The alarm type classification described in step 3 further includes: for each alarm First, query the alarm type cache library. If it exists, directly return the cached alarm type. If it does not exist, the large language model is called for classification, and the classification result is stored in the cache.

4. The intelligent fault case matching method based on the similarity between a large language model and Jaccard as described in claim 1, characterized in that, The predefined service role types mentioned in step 2 are role classification systems based on the functional layers of the IT system architecture, including but not limited to: traffic entry type, business application type, data storage type, caching service type, message queue type, middleware type, storage service type, and infrastructure type; the service role types can be expanded or adjusted according to actual business scenarios.

5. The intelligent fault case matching method based on large language model and Jaccard similarity as described in claim 1, characterized in that, The predefined alarm types mentioned in step 3 are alarm classification systems based on the manifestation of IT system failures, including but not limited to: resource alarms, delay alarms, error alarms, availability alarms, and capacity alarms; the alarm types can be expanded or adjusted according to actual operation and maintenance scenarios.

6. The intelligent fault case matching method based on the similarity between a large language model and Jaccard as described in claim 1, characterized in that, When inferring service roles by calling the large language model in step 2, the input service information includes at least one of the following: service name, service description, recent alarm record, listening port, and dependencies.

7. The intelligent fault case matching method based on the similarity between a large language model and Jaccard as described in claim 1, characterized in that, When calling the large language model to classify alarm types in step 3, the input alarm information includes at least one of the following: alarm name, alarm details, and threshold information.

8. The intelligent fault case matching method based on the similarity between a large language model and Jaccard as described in claim 1, characterized in that, The number N of the Top-N most similar historical cases returned in step 6 is a preset value, and the returned results include similarity scores and case details.

9. The intelligent fault case matching method based on the similarity between a large language model and Jaccard as described in claim 1, characterized in that, The alarm-service association mapping M described in step 1 is constructed as follows: if the original fault alarm event clearly indicates the correspondence between the alarm and the service, then the mapping is established directly; if the alarm entry does not provide an explicit association with a specific service instance, then the service corresponding to the alarm is marked as an unknown service, and the mapping is established. (Unknown), in subsequent steps, this alarm only participates in feature combination construction and similarity matching based on its alarm type.

Images