A method for monitoring fault analysis of a fusion multi-modal knowledge base

Abstract

The application relates to the technical field of fault analysis, and particularly provides a monitoring fault analysis method fusing a multi-modal knowledge base, which comprises the following steps: collecting original data of monitoring fault logs, preprocessing and storing the original data; performing data cleaning and feature extraction on the obtained original data of the monitoring fault logs; constructing a searchable knowledge base based on the cleaned data; when an alarm is triggered by the system, performing hybrid retrieval through a dynamic routing mechanism; aggregating various retrieval results to generate an executable repair scheme; iteratively optimizing a decision-making process through artificial feedback; continuously optimizing the knowledge base and a diagnosis model to form a closed-loop iterative mechanism. Through the above scheme, the accuracy and response efficiency of fault diagnosis are improved.

Description

Technical Field

[0001] This invention relates to the field of fault analysis technology, specifically providing a monitoring fault analysis method that integrates a multimodal knowledge base. Background Technology

[0002] With the large-scale application of domestically produced software and hardware systems in key areas, their complexity and security requirements have significantly increased. However, traditional monitoring fault analysis methods have many shortcomings. First, the problem of data silos is prominent. The logs and metrics generated by the monitoring system are fragmented with the topological relationships and configuration information of the CMDB and industry knowledge base, lacking a unified connection. Second, intelligent adaptability is insufficient. Existing large-scale model technologies lack targeted optimization for the non-standardized logs and special fault modes of domestically produced systems, resulting in low retrieval accuracy, error-prone generated results, and inability to meet the real-time requirements of critical scenarios.

[0003] Currently, there are some monitoring and alerting systems based on rules or Large Language Models (LLM) that support alert analysis to some extent, but the following problems still exist:

[0004] (1) There is a lack of standard knowledge bases. Data or knowledge is scattered in various places. Operation and maintenance experience and technology are scattered in the minds of operation and maintenance engineers and in work orders. It is impossible to form standard and effective knowledge to help less experienced people or large models to apply fault alarms.

[0005] (2) Poor adaptability of large models and inaccurate answers: Existing models are all general large models. When facing different software and hardware environments and professional fields, they are poorly adaptable and cannot accurately perform root cause analysis and diagnosis. They can only give relatively vague answers.

[0006] (3) There is a lack of feedback optimization links for the results generated by the RAG knowledge base. When the adaptation system finds that the results generated by the RAG retrieval are unsatisfactory during manual inspection, there is a lack of optimization and improvement mechanism, or it can only go around to add new knowledge from the knowledge collection layer of the knowledge base, which is cumbersome and has a slow update frequency.

[0007] (4) The ordinary RAG retrieval method is simple and does not cover long-tail problems. It is suitable for scenarios with low timeliness requirements and little data change, which leads to problems such as insufficient accuracy and poor flexibility of the naive RAG in complex scenarios.

[0008] To address the aforementioned issues, a monitoring and fault analysis method integrating a multimodal knowledge base and Retrieval Enhancement Generation (RAG) technology is urgently needed. This method constructs a multimodal knowledge base, unifying the structured data of the CMDB with multimodal industry knowledge (fault cases, product manuals, diagnostic libraries) into a single encoded vector. This enables semantic association across modal data, breaking down traditional data silos. Based on this, RAG technology is used for intelligent log analysis. For example, when a "database connection timeout" log is detected, the database version and associated middleware configuration in the CMDB can be automatically retrieved, and SQL optimization solutions from the knowledge base can be matched to generate a diagnostic report containing root cause analysis. Furthermore, through adaptive analysis capabilities, the retrieval strategy is continuously optimized based on work orders and human feedback, dynamically updating the knowledge base content and adjusting retrieval weights, thereby improving the accuracy and response efficiency of fault diagnosis. Summary of the Invention

[0009] To overcome the above-mentioned shortcomings, this invention provides a monitoring fault analysis method that integrates a multimodal knowledge base, comprising the following steps:

[0010] S1: Collect raw data from monitoring fault logs, preprocess it, and store it;

[0011] S2: Perform data cleaning and feature extraction on the raw data of the acquired monitoring fault logs;

[0012] S3: Build a searchable knowledge base based on the cleaned data;

[0013] S4: When the system triggers an alarm, a hybrid retrieval is performed on the knowledge base through a dynamic routing mechanism;

[0014] S5: Aggregate multiple search results from mixed search feedback to generate an executable repair solution;

[0015] S6: For the generated executable repair solutions, the decision-making process is iteratively optimized through human feedback;

[0016] S7: Optimize the decision-making process through iterative feedback from human input, continuously improve the knowledge base and diagnostic model, and form a closed-loop iterative mechanism.

[0017] Furthermore, the data cleaning includes deduplication, noise reduction, and format standardization.

[0018] The deduplication process involves using the SimHash algorithm to remove duplicates from the original data of the monitoring fault logs, while also introducing a time window parameter, device context encoding, and a dynamic similarity threshold. The time window parameter involves segmenting the original data of the monitoring fault logs according to a time window, with logs within the same window being compared first. The device context encoding involves adding hash bits for the device ID and fault type to the improved SimHash algorithm. The dynamic similarity threshold involves dynamically adjusting the similarity threshold based on the type of the monitoring fault log.

[0019] The noise reduction includes filtering invalid monitoring fault log data, including null values, garbled characters, incorrect formats, and values ​​exceeding the normal range;

[0020] The format standardization includes unifying timestamps to the Unix millisecond format, mapping error codes to a standard encoding table, and converting unstructured monitoring fault logs into a unified JSON format.

[0021] Furthermore, the feature extraction includes entity relation extraction, data labeling and classification, and keyword extraction.

[0022] The entity relationship extraction includes identifying hardware models, operating system versions, and dependencies in the original monitoring fault log data after data cleaning based on the BiLSTM-CRF model.

[0023] The data labeling and classification includes labeling the raw data of the monitoring fault logs after data cleaning, including fault type, fault level, triggering conditions, device type, processing result, and whether it is the root cause;

[0024] The keyword extraction includes using the TF-IDF algorithm to extract keywords with preset rankings from the raw data of the cleaned monitoring fault logs.

[0025] Furthermore, the knowledge base is constructed using methods including log BM25 indexing, vectorized indexing, and knowledge graph-based indexing.

[0026] The log BM25 index includes keywords extracted based on features, an inverted index built based on the BM25 algorithm, and storage sharded according to log type;

[0027] The vectorized index includes text segmentation, vectorization using the BGE-M3 improved model, partitioning according to device ID, and storing in the FAISS vector library.

[0028] The knowledge graph-based indexing includes dynamically dividing the graph into subgraphs based on scene tags and storing them in the Neo4j graph database in the form of triples.

[0029] Furthermore, the improved BGE-M3 model includes:

[0030] During training, negative sample pairs are sampled from the domestically produced transfer knowledge base;

[0031] Adjust the temperature parameter of the contrast loss based on text complexity. τ = α· Entropy D )+ β Among them, Entropy ( D ) represents the text information entropy, and α and β are configured according to requirements;

[0032] After segmenting long texts, hierarchical attention aggregation is used.

[0033] Furthermore, step S4 includes:

[0034] A fault classifier is pre-trained based on a lightweight TextCNN model, which is used to output the probability of fault types.

[0035] Obtain the monitoring fault target data at the time the alarm was triggered, including alarm information and device context;

[0036] The input is fed into a pre-trained fault classifier, which outputs the probability of the fault type.

[0037] Determine the probability of the fault type. If the highest probability is greater than 0.8, match the preset dynamic routing mechanism retrieval strategy; otherwise, start a hybrid retrieval.

[0038] Furthermore, the preset dynamic routing mechanism retrieval strategy includes:

[0039] For simple problems with clear error codes and standard solutions, consult the technical documentation directly.

[0040] For complex problems involving multiple device associations and reasoning, when the specific problem is a device topology problem, KG retrieval is used; when the specific problem is a historical case dependency, work order + log retrieval is used; and when the specific problem is a real-time diagnostic requirement, monitoring + log retrieval is used.

[0041] For unknown questions, HyDE is used to generate hypothetical queries, and a hybrid retrieval method is employed.

[0042] Furthermore, the hybrid retrieval includes:

[0043] a. Combining log timestamps with device topology optimization BM25 scores, candidate segments with preset rankings are retrieved from the log BM25 index. Log timestamps are used to reduce the weight of older logs through a time decay factor. =BM25(q,d)· ,in, =0.01, Δt is the difference between the current time and the log time, and the device topology means that if the log device has a dependency relationship with the currently faulty device, the score increases. = + β· TopoLinkScore, where... β =0.2, TopoLinkScore is the device topology correlation degree;

[0044] b. Use BGE-M3 to calculate the similarity between the query and candidate paragraphs, and retain the data with the preset ranking;

[0045] c. Load the fine-tuned MiniLM-L6-v2 model, perform weighted sorting based on BM25 score, vector similarity, and knowledge graph retrieval cross-encoder, and calculate the final score final_score=0.2. bm25 + 0.3 cos_sim + 0.5 `cross_score` outputs the data with the preset ranking.

[0046] Furthermore, step S5 includes:

[0047] The weights of keyword retrieval, knowledge graph, and vector retrieval are dynamically calculated based on the question type and context.

[0048] Dynamically load domain-adaptive templates, use the DeepSeek-32B model, and output structured results.

[0049] Furthermore, the dynamic calculation of the weights for keyword retrieval, knowledge graph, and vector retrieval based on question type and context includes:

[0050] Output the probability distribution of question types using a lightweight TextCNN model. P =[ p 1, p 2,..., pn ];

[0051] Calculate the weights of various search types, keyword search w BM25 = Knowledge graph w KG = Vector retrieval w Vector =1- w BM25- w KG, of which For the probability of a simple problem, The probability of a complex problem is given by k=2, which is an adjustment coefficient.

[0052] The working principle and beneficial effects of this invention:

[0053] In implementing the technical solution of this invention, historical alarm data is collected and utilized. The collected alarm data undergoes quality inspection, splitting, and cleaning to obtain high-quality alarm and processing data. This processed high-quality data serves as the knowledge base of RAG (Rapid Alarm Data). Based on this, the RAG model is used to achieve intelligent retrieval and processing of alarm information, and fine-tuning techniques are combined to improve the model's accuracy and adaptability in specific scenarios. Compared to traditional alarm processing methods, this invention can significantly reduce diagnostic time, improve the accuracy and efficiency of alarm processing, and also provide effective training and auxiliary tools for operations and maintenance personnel, thereby improving work efficiency. Attached Figure Description

[0054] The disclosure of this invention will become more readily understood with reference to the accompanying drawings. It will be readily understood by those skilled in the art that these drawings are for illustrative purposes only and are not intended to limit the scope of protection of this invention. Furthermore, similar numbers in the drawings are used to denote similar components, wherein:

[0055] Figure 1 This is a schematic diagram of the main steps of a monitoring fault analysis method integrating a multimodal knowledge base according to the present invention;

[0056] Figure 2 This is a flowchart of the RAG hybrid retrieval and rearrangement process in this invention;

[0057] Figure 3 This is a technical design diagram of a monitoring fault analysis system integrating a multimodal knowledge base, according to the present invention. Detailed Implementation

[0058] Some embodiments of the present invention will now be described with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0059] Example 1

[0060] Figure 1 This is a schematic diagram illustrating the main steps of a monitoring fault analysis method integrating a multimodal knowledge base, as described in this invention. Figure 1 As shown, a monitoring fault analysis method integrating a multimodal knowledge base in an embodiment of the present invention mainly includes the following steps S1-S7.

[0061] Step S1: Collect raw data from monitoring fault logs from multimodal heterogeneous data types such as technical documents (PPT, Word, PDF, Excel, etc.), CMDB configuration, web pages, monitoring data, operation and maintenance logs, and work records. Perform different types of preprocessing on different data formats and store them.

[0062] Step S2: Perform data cleaning and feature extraction on the raw data of the acquired monitoring fault logs.

[0063] In one implementation, data cleaning includes deduplication, noise reduction, and format standardization. Specifically:

[0064] ① The raw data of the monitoring fault log is deduplicated using the SimHash algorithm (80 bits), while introducing time window parameters, device context encoding and dynamic similarity threshold.

[0065] Introduce a time window parameter: Divide the raw data of the monitoring fault log into segments according to time windows (e.g., 5 minutes), and compare logs within the same window first;

[0066] Device context encoding: The improved SimHash algorithm adds hash bits for metadata such as device ID and fault type (the original 64 bits are extended to 80 bits, the first 64 bits are text hash, and the last 16 bits are device context encoding).

[0067] Dynamic similarity threshold: The similarity threshold is dynamically adjusted according to the type of monitored fault logs (e.g., error log threshold = 0.85, warning log threshold = 0.7).

[0068] The calculation formula using the improved SimHash algorithm is D = SimHash( D text)⊕Hash( D device D type), where ⊕ represents bit concatenation. D text is a log type. D device is the device ID. D "type" refers to the fault type.

[0069] ② Filter invalid monitoring fault log data, such as empty values, garbled characters, incorrect format, and values ​​exceeding the normal range.

[0070] ③ Format standardization: Timestamps are standardized to Unix millisecond format, and error codes are mapped to a standard encoding table (e.g., "E1001" represents "driver compatibility error"). Unstructured monitoring fault logs are converted to a unified JSON format.

[0071] In one implementation, feature extraction includes entity relation extraction, data labeling and classification, and keyword extraction, specifically:

[0072] ① Entity Relationship Extraction: Based on the BiLSTM-CRF model, identify the hardware model (e.g., "Kunpeng 920"), operating system version (e.g., "Kylin V10"), and dependencies in the original data of the monitoring fault log after data cleaning;

[0073] ② Data labeling and classification: Label the raw data of the monitoring fault logs after data cleaning, including fault type, fault level, triggering conditions, equipment type, processing result, whether it is the root cause, etc.

[0074] ③ Keyword extraction: The TF-IDF algorithm is used to extract the top 10 keywords from the raw data of the monitoring fault logs after data cleaning.

[0075] Step S3: Construct a searchable knowledge base based on the cleaned data.

[0076] In one implementation, the knowledge base construction includes a log BM25 index, a vectorized index, and a knowledge graph-based KG index, specifically:

[0077] ①Log BM25 Index

[0078] Based on the keywords extracted from the features, an inverted index (BM25 algorithm, parameters k1=1.2, b=0.75) is constructed and stored in shards according to log type (error, warning, message).

[0079] ② Vectorized index

[0080] After text segmentation, the BGE-M3 improved model is used for vectorization, partitioned according to device ID, and stored in the FAISS vector library.

[0081] In one implementation, the improved BGE-M3 model addresses the semantic ambiguity problem of non-standardized logs in domestic monitoring scenarios by introducing a domain-adaptive contrastive learning mechanism. Specific improvements include:

[0082] a. During training, negative examples are sampled from the domestically produced transfer knowledge base (such as "driver incompatibility" and "network interruption" as negative sample pairs).

[0083] b. Adjust the temperature parameter of the contrast loss based on the text complexity: τ = α· Entropy D )+ β Among them, Entropy ( D ) represents the text information entropy. α =0.1, β =0.05, α and β Configurable.

[0084] C. After segmenting long texts, hierarchical attention aggregation is used.

[0085] ③ Based on knowledge graph index

[0086] The graph is dynamically divided based on scene tags (such as "ARM migration" and "driver installation") and stored in the Neo4j graph database (such as "Kylin V10 - Dependency - GCC 9.3") in the form of triples (head entity, relation, tail entity).

[0087] Step S4: When the system triggers an alarm (such as "Kylin V10 failed to install NVIDIA driver, error code E1001"), perform a hybrid search through a dynamic routing mechanism.

[0088] In one implementation, a fault classifier is pre-trained based on a lightweight TextCNN model (parameters: kernel_sizes=[3,4,5], filters=128). The fault classifier is used to output the probability of fault type (10 categories such as hardware compatibility, missing driver, API conflict, etc.).

[0089] The system acquires monitoring fault target data at the time the alarm is triggered, including alarm information (error code, log fragment) and device context (model, operating system version), and inputs this data into a pre-trained fault classifier, outputting the fault type probability. It determines the fault type probability; if the highest probability is > 0.8, it directly matches the preset dynamic routing mechanism retrieval strategy; otherwise, it initiates a hybrid retrieval to reduce the risk of misjudgment. The hybrid retrieval includes KG retrieval (implemented based on knowledge graph storage) + keyword retrieval (implemented based on log BM25 index) + vector retrieval (implemented based on vectorized index).

[0090] In one implementation, the preset dynamic routing mechanism retrieval strategy includes:

[0091] ① For simple problems with clear error codes and standard solutions (such as "insufficient disk space"), directly consult technical documents (such as "Disk Cleanup Operation Guidelines").

[0092] ② For complex problems involving multiple devices and requiring reasoning (such as "Service A crash caused Service B to time out"), when the specific issue is a device topology problem, use KG retrieval (such as "database node status that Service A depends on"); when the specific issue is a historical case dependency, use work order + log retrieval (such as "solutions to similar faults"); when the specific issue is a real-time diagnostic requirement, use monitoring + log retrieval (such as "current CPU / network anomaly mode").

[0093] ③ For unknown problems, use HyDE to generate hypothetical queries (such as "service crash may be caused by memory leak") and adopt hybrid retrieval.

[0094] In this embodiment, HyDE hypothesis generation involves inputting the log text of the current monitored fault issue and real-time monitoring charts (CPU / memory, etc. metric curves) into the T5-3B model to generate hypothetical answers (e.g., "Error code E1001 is usually caused by CUDA version mismatch"). Contrastive learning is used to filter the generated hypothetical answers, retaining the top 3 hypotheses with the highest consistency with the knowledge base. Dynamic temperature adjustment is applied: temperature = 0.5 + 0.2·Uncertainty(q), where Uncertainty(q) is the entropy value output by the problem classification model. The hypothetical answers are then used as new monitored fault issues, and vector retrieval (BGE-M3) is performed to supplement the context.

[0095] In one implementation, KG retrieval includes: extracting a 3-hop subgraph (containing dependencies and historical repair paths) from the Neo4j knowledge graph based on the Cypher query language, which is associated with the current device model (e.g., "Kunpeng 920") and error code (e.g., "E1001"); sorting the nodes in the subgraph according to their semantic similarity to the query (cosine value of the vector from the BGE-M3 improved algorithm), and retaining the top 5 associated nodes. (Extracting the 3-hop associated subgraph using Cypher, and retaining the top 5 nodes based on semantic similarity)

[0096] In one implementation, Figure 2 This is a flowchart of the RAG hybrid retrieval and rearrangement process in this invention, as shown below. Figure 2 As shown, after a user inputs a question or fault alarm information, the implementation of hybrid retrieval includes the following steps:

[0097] a. Keyword Search – This invention improves the BM25 algorithm by combining log timestamps with device topology optimization BM25 scores to retrieve the Top 50 candidate paragraphs (score > 6.0) from the log BM25 index, i.e., blocks containing keywords. SQL is used to construct SQL query statements from the database using these keywords in order to retrieve relevant text or paragraphs (blocks containing keywords) from the relational database.

[0098] Log timestamps are used to reduce the weight of older logs by applying a time decay factor. =BM25(q,d)· Where q is the user's query input text or search keywords, and d is data or logs in the knowledge base. =0.01, where Δt is the difference (in hours) between the current time and the log time. Device topology: If the log device has a dependency on the currently faulty device, the score increases. = + β·TopoLinkScore, where... β =0.2, TopoLinkScore is the device topology correlation degree.

[0099] b. Vector Similarity Search: BGE-M3 is used to calculate the similarity between the query and candidate paragraph vectors, retaining the Top 20 (threshold > 0.7), i.e., blocks of similar content. FAISS, as a vector similarity search library, is used to efficiently retrieve document blocks most similar to the user's query vector, thereby quickly locating relevant operational knowledge and fault information.

[0100] c. Knowledge Graph Search (Keyword and Semantic Search of Graph and Subgraph Entity Names, Attributes, or Relationship Descriptions). Neo4j, as a graph database, is used to perform GraphRag searches, searching the graph for entity names, attributes, or relationship descriptions using keywords and semantics to return and query entity attributes and relationships closely related to the input.

[0101] By loading a finely tuned MiniLM-L6-v2 model, a weighted ranking was performed using a cross-encoder that integrates BM25 score, vector similarity, and knowledge graph retrieval (weight ratio: 0.2:0.3:0.5), and the final score was calculated as final_score = 0.2. bm25 + 0.3 cos_sim + 0.5 `cross_score` is defined as follows: `bm25` represents the value of the keyword search result; `cos_sim` represents the parameter used in vector similarity search to calculate the similarity between the query and candidate paragraph vectors using BGE-M3; and `cross_score` represents the values ​​of closely related entity attributes and relationships in knowledge graph search. The top 10 results are output, excluding those with a `final_score` < 0.6. The results are then sorted in descending order of `final_score`, and the top 10 are passed to the large model generation stage (less than 10 results are allowed, but the accuracy of the retrieved content must be guaranteed). These are the related knowledge graphs and subgraphs.

[0102] Step S5: Aggregate multiple search results using BM25 scores to generate an executable repair solution.

[0103] ① A dynamic hybrid retrieval weight allocation algorithm dynamically calculates the weights of keyword retrieval, knowledge graph, and vector retrieval based on the question type and context. Specific steps include:

[0104] a. Use a lightweight TextCNN model to output the probability distribution of question types. P =[ p 1, p 2,..., pn ];

[0105] b. Calculate the weights of various search types, including keyword search. w BM25 = Knowledge graph w KG = Vector retrieval w Vector =1- w BM25- w KG ,in, For the probability of a simple problem, For the probability of a complex problem, k=2 is an adjustment coefficient. Corresponding to... Figure 2 In step S4, all retrieved blocks are reranked as weighted blocks.

[0106] ②Generative Diagnosis

[0107] Prompt template: Dynamically load domain-specific templates (e.g., "You are a domestic OS migration expert, and you need to output the following information: 1. Root cause analysis; 2. Step-by-step repair instructions; 3. Risk warnings").

[0108] Generation Control: The top 15 blocks are selected and fed into the large model, along with user questions / fault alarm information. Using the DeepSeek-32b model (top_p=0.85, temperature=0.7, repetition_penalty=1.2, max_length=512), structured results are output, transforming alarm data or code logs into user-understandable text for explanation, fault location analysis, and handling suggestions. For example:

[0109] {

[0110] Root cause: CUDA version ≥ 11.4, current version is 11.2.

[0111] Repair Steps: ["1. Download CUDA 11.4", "2. Update the PATH environment variable"],

[0112] Risk: A system restart is required for the changes to take effect, which may cause service interruption.

[0113] }

[0114] Step S6: Iteratively optimize the decision-making process through human feedback.

[0115] ① The operations and maintenance personnel mark the correctness of the generated results (correct / partially correct / incorrect) and supplement the correction plan (such as "actually needs to be downgraded to CUDA 11.3"), and store the triple <original problem, routing strategy, generated result, manual correction> to MongoDB (index fields: error_code, route_type).

[0116] ② Calculate the total reward value L = α·user rating + β·repair success rate - γ·risk coefficient + δ· - • Operations and maintenance personnel experience level, where the experience level ranges from 0 to 1. α =0.4, β=0.3, γ=0.1, δ=0.15, =0.05, the parameter can be adjusted and configured by operation and maintenance personnel.

[0117] In this embodiment, user interaction information includes user ratings (1-5 points, reflecting the effectiveness of the repair solution); manual correction records (such as correcting root cause labels or repair scripts); execution results (success / failure status and log details); and contextual metadata (device type, system status at the time of alarm triggering: CPU, operating system, network, memory, storage). Users rate the generated results (1-5 points, reflecting the effectiveness of the generated results), with 5 points for complete compliance and 0 points for complete non-compliance; the default is complete compliance. If a result is non-compliant, the rating can be modified, and the result can be manually corrected, with the error reason and correct information filled in.

[0118] ③ Train the routing decision model using a PPO-like algorithm, and add a complexity regularization term to the loss function: L CLIP=E t [min( rt · At ,clip( rt ,1- ,1+ )· At )]+ η· ComplexityPenalty, where η=0.01, and ComplexityPenalty=∑StepCount, represents the number of repair steps. The model parameters are updated using the improved algorithm through PPO, prioritizing high-reward recommendations (e.g., recommending low-risk, high-scoring solutions). The routing decision model is used to generate the dynamic routing mechanism retrieval strategy in step S4.

[0119] Step S7: Based on the human feedback data collected in Step S7, the system continuously optimizes the knowledge base and diagnostic model, forming a closed-loop iterative mechanism.

[0120] ① Incremental update of knowledge base: Associate the correction scheme marked in step S6 with the original knowledge base in step S3, and dynamically update the following components:

[0121] BM25 Index: Merging manually corrected technical documents (Source of step S1)

[0122] Vector library: Triggers incremental training of the BGE-M3 model (batch_size=32, epochs=2), enhancing semantic understanding of non-standardized logs (continuing the domain adaptation optimization from step S3).

[0123] Knowledge Graph: Based on triplet correction records (data stored in MongoDB in step S6), missing dependencies are supplemented (e.g., adding the edge "Kylin V10—Incompatible—CUDA 11.2").

[0124] Version control: Git is used to manage knowledge graph snapshots, and rollback by fault timestamp is supported (forming a fault-tolerant linkage with the KG subgraph retrieval in step S04).

[0125] ② Model fine-tuning

[0126] Feedback-driven lightweight updates:

[0127] Based on the manually modified and labeled data in step S5, the LoRA technique (rank=16, alpha=32) was used to efficiently adjust the attention projection layers (q_proj / k_proj / v_proj) of the DeepSeek-32B model, specifically optimizing the following scenarios:

[0128] Fix the redundancy issue in the steps (related to the ComplexityPenalty item in step S5).

[0129] Root cause analysis bias (related to the cross encoder fine-tuning results in step S4)

[0130] Adversarial training enhancement: Using the erroneous cases labeled in step S6, construct adversarial examples (such as replacing "E1001" with the synonym "E1002"), and improve the model's robustness to semantic interference by using KL divergence loss (L_KL=0.1).

[0131] Training efficiency optimization:

[0132] By employing mixed precision (bf16) and gradient accumulation (steps=8), we ensure that a single A100 card can complete fine-tuning of hundreds of billions of models (matching the real-time generation requirements of step S05).

[0133] It should be noted that although the steps in the above embodiments are described in a specific order, those skilled in the art will understand that in order to achieve the effects of the present invention, different steps do not necessarily have to be executed in such an order. They can be executed simultaneously (in parallel) or in other orders, and these variations are all within the scope of protection of the present invention.

[0134] Based on steps S1-S7 above, this embodiment can efficiently collect and utilize historical alarm data. Through data governance, the collected alarm data undergoes quality inspection, splitting, and cleaning to obtain high-quality alarm and processing data. This processed high-quality data serves as the knowledge base for RAG (Radar Algorithm). Based on this, the RAG model is used to achieve intelligent retrieval and processing of alarm information, and fine-tuning techniques are combined to improve the model's accuracy and adaptability in specific scenarios. Compared to traditional alarm processing methods, this invention can significantly reduce diagnostic time, improve the accuracy and efficiency of alarm processing, and reduce the average fault repair time from 40 minutes to 15 minutes. Simultaneously, this embodiment can also provide effective training and auxiliary tools for maintenance personnel, improving work efficiency.

[0135] The improvements and advantages of this embodiment include:

[0136] ① Improve and optimize existing algorithms based on domestically produced monitoring data and processes, making the algorithm parameters and variables more applicable to the field of operation and maintenance monitoring. Improved algorithms include SimHash algorithm for log deduplication, vectorized BGE-M3 model, BM25 algorithm for keyword retrieval, HyDE hypothesis generation improvement, dynamic weight calculation for hybrid retrieval, result reward calculation formula improvement, PPO algorithm training decision model improvement, and large model fine-tuning algorithm improvement. See the specific embodiments of this invention for details.

[0137] ② High update frequency: Historical alarm data and real-time monitoring data are collected through the alarm data collection module; secondly, the data governance module is used to perform quality inspection, splitting, and cleaning on the collected alarm data to obtain high-quality alarm and processing data. This processed high-quality data serves as an external knowledge base for RAG, and the retrieval and generation modules of the RAG model are used to realize intelligent retrieval and processing of alarm information, thereby improving the update frequency.

[0138] ③ Modular RAG Knowledge Base Construction: Through multimodal heterogeneous data collection, SimHash-like (80-bit) deduplication and rule engine cleaning, a modular knowledge base (such as "ARM migration", "database migration" and "operating system migration") adapted to domestic monitoring scenarios is constructed. Combined with knowledge graphs and hybrid indexes (BM25 + vector index BGE-M3), efficient retrieval and enhanced generation are achieved.

[0139] ④ Dynamic routing strategy: Dynamically route to KG subgraph retrieval, hybrid retrieval, or HyDE hypothesis generation (T5-3B virtual answer guidance), and output Top 15 results through weighted fusion to improve recall and recall precision;

[0140] ⑤ Continuous optimization of the manual annotation feedback loop: Combining the improved reinforcement learning optimization strategy with PPO (reward value based on manual scoring), and using an improved fine-tuning algorithm to lightweight fine-tune the DeepSeek-32B model, achieving high domain adaptability and efficient resource utilization.

[0141] ⑥ The large model exhibits high monitoring adaptability in the field of domestic adaptation, and its accuracy and adaptability in specific scenarios are improved through fine-tuning techniques. Furthermore, by introducing reinforcement learning mechanisms to fine-tune domain-specific monitoring data and continuously reinforcing the learning of new knowledge, the model's performance is further optimized.

[0142] ⑦ Driven by continuous document updates and the accumulation of operational knowledge, lightweight fine-tuning and automated knowledge injection have enabled the co-evolution of models and knowledge bases, significantly improving operational efficiency and accuracy in domestic migration scenarios.

[0143] Example 2

[0144] This embodiment primarily utilizes an operations and maintenance knowledge base and a RAG model to retrieve, supplement, and analyze fault alarms generated by the monitoring and adaptation of domestically produced software. The overall architecture comprises six modules: data source, knowledge base construction, index construction, knowledge base application and fault analysis, and feedback optimization. This enables the construction and application of the knowledge base, transforming manual operations and maintenance experience into knowledge for a large-scale model. This enhances professional experience and fault analysis capabilities within the large-scale model in the monitoring field. Furthermore, the combination of dynamic routing strategies improves retrieval accuracy, significantly enhancing the accuracy of fault location analysis.

[0145] Figure 3 This is a technical design diagram of a monitoring and fault analysis system integrating a multimodal knowledge base, as described in this invention. Figure 3 As shown, a monitoring and fault analysis system integrating a multimodal knowledge base in this embodiment mainly includes:

[0146] 1. Data source module

[0147] Collect data including fault alarms, CMDB configurations, technical documents, web page data, monitoring data, operation and maintenance logs, and work order records. Preprocess the collected data, including parsing and extracting multimodal file content, standardizing formats, removing invalid data, and deduplicating, to ensure data quality and consistency.

[0148] The above data source module is used for execution. Figure 1Step S1 is shown in a monitoring fault analysis method that integrates a multimodal knowledge base.

[0149] 2. Knowledge Base Construction Module

[0150] Data from various data sources is processed and formatted into a unified format to build a knowledge base. The knowledge base contains the root cause of alarms, corresponding handling methods, alarm cases in different scenarios, and operating parameter information of devices or systems.

[0151] Data cleaning: Using data cleaning techniques to perform quality checks, remove erroneous or incomplete data, and standardize data formats.

[0152] Feature extraction: Extracting key features, such as entities, relationships, and keywords, from the cleaned data to provide a foundation for subsequent indexing and retrieval.

[0153] Keyword Indexing: The BM25 algorithm is used for keyword extraction and inverted indexing to improve the efficiency of keyword retrieval.

[0154] Text vectorization: The BGEM3 improved algorithm is used to segment and vectorize the text, build a vector index, and support semantic similarity retrieval.

[0155] Knowledge graph construction: Construct knowledge graphs, store entity relationship triples, and support queries on complex graph structures with clear relationships.

[0156] The aforementioned knowledge base building modules are used for execution. Figure 1 Steps S2-S3 of a monitoring fault analysis method that integrates a multimodal knowledge base are shown.

[0157] 3. Hybrid Index Module

[0158] This module enables efficient multi-dimensional retrieval by constructing a keyword index, a vector index, and a knowledge graph storage. (See appendix for details.) Figure 2 The hybrid index module works through the following steps:

[0159] Keyword Index Library: Constructs an improved BM25 log index to support efficient keyword retrieval.

[0160] Vector Index Library: Construct a vector library of monitoring data to support semantic similarity retrieval.

[0161] Knowledge Graph Storage: Build a KG storage for work orders, supporting knowledge graph queries.

[0162] The above hybrid index module is used for execution Figure 1 Step S4 in a monitoring fault analysis method that integrates a multimodal knowledge base is shown.

[0163] 4. Fault Analysis and Repair Module

[0164] This module is responsible for analyzing and diagnosing newly generated faults or user-submitted issues. For operational problems, it returns operational steps and guidance to the user. For faults or log-related issues, it dynamically routes and selects appropriate retrieval strategies to more accurately find corresponding fault analysis content and solutions. Then, it feeds the retrieved TOP-K knowledge and questions into the large model to generate the final answer. It converts alarm data or code logs into user-understandable text, providing explanations, fault location analysis, and handling suggestions. It works through the following steps:

[0165] Fault Triggering: Fault analysis is triggered by alarm information or logs to respond to maintenance needs in real time.

[0166] Dynamic routing: Dynamically selects the analysis path based on the fault type, improving analysis efficiency.

[0167] KG retrieval: Performs knowledge graph retrieval and subgraph retrieval to extract relevant knowledge.

[0168] Hybrid retrieval: Combining keywords and vector retrieval maps to improve the accuracy and efficiency of retrieval.

[0169] HyDE Hypothesis Generation: Generates fault hypotheses, providing multiple possibilities for subsequent diagnosis.

[0170] Large model generation: The retrieved TOP-K knowledge is fed into the large model to generate fault location, repair suggestions and operation guidance.

[0171] Results output: The diagnostic results are output in a user-friendly manner, providing clear fault location and repair suggestions.

[0172] The above fault analysis and diagnosis module is used to perform Figure 1 Step S5 is shown in a monitoring fault analysis method that integrates a multimodal knowledge base.

[0173] 5. Evaluation and Optimization Module:

[0174] This module is responsible for evaluating and manually annotating the generated results, especially annotating and modifying answers that fail the manual evaluation, refeeding the results, and updating the knowledge base and the overall model. It also allows for configuring and optimizing routing strategies and adjusting index paths. It works through the following steps:

[0175] Results evaluation: Evaluate the generated results to determine their correctness and ensure the reliability of the diagnostic results.

[0176] When the judgment result is correct (corresponding to) Figure 3 The middle arrow "Y" points to the logic (the point is now closed);

[0177] When the judgment result is incorrect (corresponding to) Figure 3 If the middle arrow "N" points to a logic value, then the following adjustments will be made:

[0178] Manual annotation: Incorrect results are manually annotated and answers are corrected to accumulate more training data. Then, incremental learning is introduced to quickly update the knowledge base, supplementing it with location analysis and processing methods for alarm logs in new operational environments, monitoring equipment, and specific scenarios.

[0179] Optimization strategy: Configure optimization routing strategies and adjust analysis and indexing paths according to actual conditions.

[0180] Based on feedback from the evaluation and optimization module, the indexing strategy is iteratively optimized. By adjusting the weight allocation of keyword indexes, vector indexes, and knowledge graph indexes, as well as the indexing method matching strategy for different types of fault query inputs, the synergistic effect of the indexes is optimized, and retrieval efficiency and accuracy are continuously improved.

[0181] Reinforcement learning, calculating reward values: Using the PPO improved algorithm to adjust the model reward parameters, optimize the recommendation priority of large models, and achieve the self-evolution of the model.

[0182] Continuous improvement: Optimize the knowledge base and models through user feedback to form a closed-loop optimization mechanism.

[0183] User interaction and feedback: Through the user interface, users can easily query the knowledge base, submit new knowledge, or provide feedback on reasoning results. User feedback is used to continuously optimize the knowledge base's content and routing strategies.

[0184] The above evaluation and optimization modules are used for execution. Figure 1 Steps S6-S7 of a monitoring fault analysis method that integrates a multimodal knowledge base are shown.

[0185] The improvements and advantages of this embodiment include:

[0186] (1) The modular RAG architecture improves the efficiency and quality of information retrieval and generation.

[0187] By decomposing the system into multiple functionally independent modules, this architecture supports independent dynamic adjustment and optimization of each module, providing great flexibility and adaptability to different tasks and data types. Its advantage lies in its ability to flexibly handle complex and ever-changing query scenarios while maintaining continuous system evolution and performance optimization, providing users with a powerful and efficient retrieval enhancement and generation framework.

[0188] (2) Multi-level indexing and hierarchical retrieval improve recall and precision.

[0189] Construct a multi-layered index for phased recall. Reduce the search scope and improve efficiency for small datasets. The first layer, coarse screening (BM25), filters irrelevant documents using document summaries or category labels, prioritizing relevant categories. The second layer, fine screening (vectors), uses the BGE-M3 model to calculate semantic similarity and ranks the top-10 results by vector or keyword retrieval. The extended layer (knowledge graph) retrieves related subgraphs (e.g., "firmware version → compatibility → upgrade steps").

[0190] (3) Dynamic routing decision-making: automatically select the optimal retrieval path based on the fault type (hardware / software / network) to improve the accuracy of retrieval.

[0191] (4) Bidirectional evolution of knowledge base and model

[0192] By combining incremental learning (data updates) with reinforcement learning (policy optimization), a closed-loop iterative process of "data-model-policy" is achieved. The knowledge base enables rapid and timely updates of new data, and new knowledge is retrieved promptly and accurately through rag-and-drop optimization techniques. The model is continuously adjusted based on user feedback, reducing the frequency of low-quality diagnostic recommendations. In subsequent diagnoses, the model tends to recommend low-risk, high-success-rate solutions. A memory replay method combined with LoRA is used to fine-tune the large model, establishing an adjustable-capacity experience replay buffer. New data is fed in, while a portion of old data is introduced, and weights are assigned to both new and old data to achieve incremental training.

[0193] (5) Enhanced interpretability of fault log code error reporting assists in localization and repair, providing text and image explanations to enable maintenance personnel to find and analyze the cause of the problem more quickly. By using rag to associate fault alarms with the knowledge base, historical experience can be retrieved and matched to quickly and accurately locate the root cause of the fault and provide repair references, thus shortening the mean time to repair (MTTR).

[0194] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after such changes or substitutions will all fall within the scope of protection of the present invention.

Claims

1. A monitoring fault analysis method integrating a multimodal knowledge base, characterized in that, Includes the following steps: S1: Collect raw data from monitoring fault logs, preprocess it, and store it; S2: Perform data cleaning and feature extraction on the raw data of the acquired monitoring fault logs; S3: Build a searchable knowledge base based on the cleaned data; S4: When the system triggers an alarm, a hybrid retrieval is performed on the knowledge base through a dynamic routing mechanism; S5: Aggregate multiple search results from mixed search feedback to generate an executable repair solution; S6: For the generated executable repair solutions, the decision-making process is iteratively optimized through human feedback; S7: Optimize the decision-making process through iterative optimization of human feedback, continuously improve the knowledge base and diagnostic model, and form a closed-loop iterative mechanism; Step S4 includes: A fault classifier is pre-trained based on a lightweight TextCNN model, which is used to output the probability of fault types. Obtain the monitoring fault target data at the time the alarm was triggered, including alarm information and device context; The monitored fault target data is input into a pre-trained fault classifier, which outputs the probability of the fault type. Determine the probability of the fault type. If the highest probability is greater than 0.8, match the preset dynamic routing mechanism retrieval strategy; otherwise, start the hybrid retrieval. The preset dynamic routing mechanism retrieval strategy includes: For simple problems with clear error codes and standard solutions, consult the technical documentation directly. For complex problems involving multiple device associations and reasoning, when the specific problem is a device topology problem, KG retrieval is used; when the specific problem is a historical case dependency, work order + log retrieval is used; and when the specific problem is a real-time diagnostic requirement, monitoring + log retrieval is used. For unknown questions, HyDE is used to generate hypothetical queries, employing a hybrid retrieval approach; The hybrid retrieval includes: a. Combining log timestamps with device topology optimization BM25 scores, candidate segments with preset rankings are retrieved from the log BM25 index. Log timestamps are used to reduce the weight of older logs through a time decay factor. =BM25(q,d)· ,in, =0.01, Δt is the difference between the current time and the log time, and the device topology means that if the log device has a dependency relationship with the currently faulty device, the score increases. = + β· TopoLinkScore, where... β =0.2, TopoLinkScore is the device topology correlation degree; b. Use BGE-M3 to calculate the similarity between the query and candidate paragraphs, and retain the data with the preset ranking; c. Load the fine-tuned MiniLM-L6-v2 model, perform weighted sorting based on BM25 score, vector similarity, and knowledge graph retrieval cross-encoder, and calculate the final score final_score=0.

2. bm25 + 0.3 cos_sim + 0.5 cross_score outputs the data with the preset ranking.

2. The monitoring fault analysis method integrating a multimodal knowledge base according to claim 1, characterized in that, The data cleaning includes deduplication, noise reduction, and format standardization. The deduplication process involves using the SimHash algorithm to remove duplicates from the original data of the monitoring fault logs, while also introducing a time window parameter, device context encoding, and a dynamic similarity threshold. The time window parameter involves segmenting the original data of the monitoring fault logs according to a time window, with logs within the same window being compared first. The device context encoding involves adding hash bits for the device ID and fault type to the improved SimHash algorithm. The dynamic similarity threshold involves dynamically adjusting the similarity threshold based on the type of the monitoring fault log. The noise reduction includes filtering invalid monitoring fault log data, including null values, garbled characters, incorrect formats, and values ​​exceeding the normal range; The format standardization includes unifying timestamps to the Unix millisecond format, mapping error codes to a standard encoding table, and converting unstructured monitoring fault logs into a unified JSON format.

3. The monitoring fault analysis method integrating a multimodal knowledge base according to claim 1, characterized in that, The feature extraction includes entity relation extraction, data labeling and classification, and keyword extraction. The entity relationship extraction includes identifying hardware models, operating system versions, and dependencies in the original monitoring fault log data after data cleaning based on the BiLSTM-CRF model. The data labeling and classification includes labeling the raw data of the monitoring fault logs after data cleaning, including fault type, fault level, triggering conditions, device type, processing result, and whether it is the root cause; The keyword extraction includes using the TF-IDF algorithm to extract keywords with preset rankings from the raw data of the cleaned monitoring fault logs.

4. The monitoring fault analysis method integrating a multimodal knowledge base according to claim 1, characterized in that, The knowledge base can be constructed using various methods, including log BM25 indexing, vectorized indexing, and knowledge graph-based indexing. The log BM25 index includes keywords extracted based on features, an inverted index built based on the BM25 algorithm, and storage sharded according to log type; The vectorized index includes text segmentation, vectorization using the BGE-M3 improved model, partitioning according to device ID, and storing in the FAISS vector library. The knowledge graph-based indexing includes dynamically dividing the graph into subgraphs based on scene tags and storing them in the Neo4j graph database in the form of triples.

5. The monitoring fault analysis method integrating a multimodal knowledge base according to claim 4, characterized in that, The improved BGE-M3 model includes: During training, negative sample pairs are sampled from the transfer knowledge base; Adjust the temperature parameter of the contrast loss based on text complexity. τ = α· Entropy D )+ β Among them, Entropy ( D ) represents the text information entropy, and α and β are configured according to requirements; After segmenting long texts, hierarchical attention aggregation is used.

6. The monitoring fault analysis method integrating a multimodal knowledge base according to claim 1, characterized in that, Step S5 includes: The weights of keyword retrieval, knowledge graph, and vector retrieval are dynamically calculated based on the question type and context. Dynamically load domain-adaptive templates, use the DeepSeek-32B model, and output structured results.

7. The monitoring fault analysis method integrating a multimodal knowledge base according to claim 6, characterized in that, The dynamic calculation of weights for keyword retrieval, knowledge graph, and vector retrieval based on question type and context includes: Output the probability distribution of question types using a lightweight TextCNN model. P =[ p 1, p 2,..., pn ]; Calculate the weights of various search types, keyword search w BM25 = Knowledge graph w KG = Vector retrieval w Vector =1- w BM25 - w KG ,in, For the probability of a simple problem, The probability of a complex problem is given by k=2, which is an adjustment coefficient.

Images