LM-driven operation and maintenance system management agent optimization method
By optimizing the LM-driven operation and maintenance intelligence agent, a multi-dimensional intent recognition model, a multi-level fault diagnosis process, a full-process security mechanism, and cross-system integration are constructed. This solves the shortcomings of the operation and maintenance intelligence agent in intent recognition, fault diagnosis, automated operation, and knowledge accumulation, and achieves efficient and secure operation and maintenance management.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- FUJIAN DIGITAL FUJIAN CLOUD COMPUTING OPERATION CO LTD
- Filing Date
- 2025-12-12
- Publication Date
- 2026-05-05
AI Technical Summary
Existing LM-driven operation and maintenance intelligence agents lack sufficient understanding of intent recognition context, rely heavily on a single data source for fault diagnosis, lack security mechanisms for automated operations, have low efficiency in knowledge accumulation and updating, and poor cross-system integration adaptability, resulting in low operation and maintenance efficiency, high costs, and reliance on human experience.
By constructing a multi-dimensional intent recognition model, a multi-level fault diagnosis process, a full-process security mechanism, adaptive knowledge base updates, and cross-system integration optimization, combined with context-related weighting factors, multi-dimensional data fusion, dynamic permission adaptation, and a standardized API adaptation layer, we can achieve accurate parsing of fuzzy commands, precise fault location, safe automated operation, and efficient knowledge management.
It improves the accuracy of fuzzy command parsing to over 90%, the accuracy of fault location to ≥85% with early warning of over 1 hour, the error execution rate of high-risk operations to ≤0.1%, the response time of knowledge query to ≤1 second, and the accuracy of cross-system data interoperability to ≥99%, significantly improving operation and maintenance efficiency and reducing costs.
Smart Images

Figure CN121979708A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of operation and maintenance system management technology, and in particular to an LM-driven operation and maintenance system management intelligent agent optimization method. Background Technology
[0002] As enterprise IT architectures become increasingly complex, traditional operation and maintenance (O&M) models face problems such as low efficiency, high costs, and reliance on human experience. While existing LM-driven O&M agents have achieved some automation, they still have many shortcomings: 1. Intent recognition is poorly adaptable to ambiguous commands and lacks sufficient contextual understanding; 2. Fault diagnosis often relies on a single data source, resulting in limited location accuracy and predictive capabilities; 3. Automated operations lack robust security mechanisms, easily leading to operational risks; 4. Knowledge accumulation is mostly passive storage, resulting in low update efficiency and inconvenient retrieval; 5. Poor cross-system integration adaptability makes it difficult to collaborate with existing enterprise O&M tools. In light of the above, this application proposes an optimization method for LM-driven O&M system management agents. Summary of the Invention
[0003] Based on the technical problems existing in the background technology, this invention proposes an LM-driven optimization method for operation and maintenance system management intelligent agents.
[0004] This invention proposes an LM-driven optimization method for operation and maintenance system management agents, comprising the following steps:
[0005] S1: Basic optimization of intent recognition: The LM language model is trained and fine-tuned based on the corpus of operation and maintenance scenarios. The context association weight factor is introduced to build a multi-dimensional intent recognition model to achieve accurate parsing of fuzzy operation and maintenance commands.
[0006] S2: Fault Diagnosis Framework Construction: Based on the optimized intent recognition capability, a multi-level diagnostic process of "log preprocessing - abnormal feature extraction - multi-dimensional data fusion - root cause reasoning" is established. Combined with transfer learning from the historical fault case library, the accuracy of fault location and the timeliness of prediction are improved.
[0007] S3: Optimized Automated Operations: Based on intent parsing and fault diagnosis results, a full-process mechanism of "script generation - security verification - permission classification - secondary confirmation - log auditing" is designed, and a dynamic permission adaptation module is introduced to realize secure automated execution in different operation and maintenance scenarios;
[0008] S4: Knowledge Accumulation Optimization: Based on fault handling data and automated operation experience, a closed-loop system of "task processing - experience extraction - structured storage - intelligent update" is constructed. A semantic similarity matching algorithm is adopted to achieve efficient retrieval and adaptive updating of the knowledge base.
[0009] S5: Cross-system integration optimization: Design a standardized API adaptation layer and data conversion module to support seamless integration with various operation and maintenance tools such as monitoring systems, CMDB, and work order systems, and achieve cross-platform data interoperability and process collaboration.
[0010] Preferably, the specific logical steps of S1 are as follows:
[0011] S101: Construction of Operation and Maintenance Scenario Corpus: Collect historical operation and maintenance conversations, operation manuals and public corpora of enterprises, filter effective data containing "instruction description-intent type-scenario tag", and after "human + machine" cross-annotation, divide it into training set, validation set and test set in 7:2:1 to form a structured corpus;
[0012] S102: Basic LM Language Model Selection and Pre-adaptation: Select the LM language model according to the enterprise size. Small and medium-sized enterprises should choose GPT-4Mini / Llama3, and large enterprises should choose GPT-4. Lightweight pre-train the selected LM language model using Linux and K8s operation and maintenance documents to adapt to the understanding of operation and maintenance terminology.
[0013] S103: Fine-tuning training of the LM language model: Train the pre-adapted LM language model selected in S102 using the training set and validation set, set the cosine annealing learning rate and BatchSize = 8-16, use dropout regularization to suppress overfitting, stop training when the validation set intention recognition accuracy does not improve for 3 consecutive rounds, and ensure that the validation set accuracy is ≥85%.
[0014] S104: Design of Contextual Association Weighting Factors: Constructing a Model for Calculating the Total Weight of Contextual Association
[0015] Total weight = Conversation round weight × 0.5 + Keyword frequency weight × 0.3 +
[0016] Scenario complexity weight × 0.2;
[0017] The session round weight is 0.8. (n-1) The calculation is performed, where n is the current conversation round, and the keyword frequency weight is calculated in "min": Keyword frequency weight = number of times the keyword appears × 0.2. When the number of times is greater than 3, the weight is capped at 0.6. The scene complexity weight is set according to the scene difficulty as 0.8 basic, 1.0 medium, and 1.2 complex. The total weight is integrated into the model's attention mechanism to improve the understanding ability of multi-round conversations.
[0018] S105: Design of a fuzzy instruction clarification mechanism: Set "the confidence of the top-1 of the top-3 intent candidates in the model output is <0.8" as the criterion for judging fuzzy instructions, and generate "closed + guiding" clarification text for fuzzy instructions to ensure accurate instruction parsing;
[0019] S106: Model Validation: Validate the model performance using a test set. The model must meet the following requirements: intent recognition accuracy ≥ 90%, ambiguity command clarification success rate ≥ 95%, and finally output the optimized intent recognition model.
[0020] Preferably, the specific logical steps of S2 are as follows:
[0021] S201: Log preprocessing: Connect to system logs and application logs, segment by Jieba word segmentation library, deduplicate by log ID, mark "ERROR" and "Timeout" exception fields, remove redundant data, and retain valid log entries;
[0022] S202: Anomaly Feature Extraction: Using the Random Forest algorithm, error codes and core features of anomaly keywords are extracted from the preprocessed logs to construct a fault anomaly feature vector library;
[0023] S203: Multi-dimensional data fusion: Integrates monitoring indicators and system configuration data to form a multi-dimensional data source of "logs + monitoring + configuration", breaking the limitations of single data;
[0024] S204: Root Cause Reasoning and Fault Prediction: Based on existing causal relationship graph models, combined with transfer learning from historical fault case databases, the root causes of faults are located; and existing fault risk assessment models are trained using historical fault data, according to the formula:
[0025] Risk value = α × historical failure frequency + β × deviation of real-time monitoring indicators +
[0026] γ× Impact of configuration changes;
[0027] Calculate the fault risk value, where α+β+γ=1 and β>α>γ, with priority given to real-time indicators;
[0028] Furthermore, the deviation of the real-time monitoring indicators is calculated using the formula:
[0029] Calculations enable early warning of potential faults;
[0030] S205: Model Validation: Validate the fault risk assessment model. The fault risk assessment model must meet the following requirements: fault location accuracy ≥ 85%, fault prediction lead time ≥ 1 hour, and output an optimized fault diagnosis framework.
[0031] Preferably, the specific logical steps of S3 are as follows:
[0032] S301: Operation and maintenance script generation: Based on the user's natural language operation and maintenance instructions, call the S1 optimized LM language model to generate Shell / Python / Ansible scripts, and output script logic descriptions at the same time for operation and maintenance personnel to check;
[0033] S302: Security Verification: First, perform script syntax verification using the ShellCheck tool, then perform logic verification in the "dry-run" mode within the simulation environment, and finally, apply the formula:
[0034] Risk score = Impact range weight × A + Operational reversibility weight × B, to assess the risk level of the task;
[0035] Where A is the impact range score: 1 point for a single machine, 3 points for a cluster, and 5 points for the entire system; B is the operation reversibility score: 1 point for recoverable, 3 points for semi-recoverable, and 5 points for unrecoverable; the impact range weight = 0.6, and the operation reversibility weight = 0.4.
[0036] Risk is categorized into 1-5 levels based on risk scores: 1-2 points for low risk, 3-4 points for medium risk, 5-8 points for high risk, and 9-10 points for extremely high risk.
[0037] S303: Hierarchical Permissions and Secondary Confirmation: Connect to the enterprise LDAP user system and set up a three-level permission system: Ordinary maintenance personnel: Level 1-2 tasks, Senior maintenance personnel: Level 3-4 tasks, Administrator: Level 5 tasks; Level 4-5 high-risk tasks require manual confirmation from the administrator + SMS verification code verification, and can only be executed after secondary confirmation is completed.
[0038] S304: Operation Log Audit: Records a full log of "Operator - Operation Time - Instruction Content - Script Content - Execution Result - Risk Level" and stores it in an immutable PostgreSQL database, supporting retrieval and traceability by dimension;
[0039] S305: Dynamic permission adaptation: Adjust permission rules according to the enterprise's organizational structure to ensure flexible permission control;
[0040] S306: Verification: Execute 200 automated tasks, and the operation success rate must be ≥98% and the high-risk operation error execution rate ≤0.1%.
[0041] Preferably, the specific logical steps of S4 are as follows:
[0042] S401: Knowledge Data Acquisition: Automatically captures fault diagnosis reports output by the fault diagnosis framework in S2 and automated operation records in S3. It also supports maintenance personnel to manually enter special scenario experience. The fault diagnosis report includes fault phenomena, root causes and solutions. Special scenario experience includes, but is not limited to, rare fault handling methods.
[0043] S402: Knowledge structuring processing: The BERT model named entity recognition algorithm is used to extract the core information of "problem description - fault cause - operation steps - verification method" from the data collected in S401, and it is stored in a unified Markdown template and labeled with scene tags. At the same time, a knowledge index is built based on Elasticsearch to support keyword and semantic search.
[0044] S403: Knowledge Base Adaptive Update: When adding new knowledge entries, word vectors for the entries are generated using the BERT model and calculated according to the cosine similarity formula.
[0045] Calculate the semantic similarity with existing knowledge base entries;
[0046] Where A and B are the word vectors of the new entry and the existing entry, respectively. If Sim(A,B)≥0.7, the existing entry is updated and a new solution is added. If Sim(A,B)<0.7, a new entry is added. Redundant entries are automatically detected every month. If Sim(A,B)≥0.9, the latest complete entry is retained.
[0047] S404: Knowledge Reuse Function Development: Add a "Knowledge Query" entry to the intelligent agent interaction interface to ensure that the query response time meets the requirements; response time = index matching time + data return time ≤ 1 second, and support "one-click solution call";
[0048] S405: Verification: Randomly initiate 100 knowledge queries, which must meet the following requirements: response time ≤ 1 second, knowledge matching accuracy ≥ 90%, and new knowledge update delay ≤ 2 hours.
[0049] Preferably, the specific logical steps of S5 are as follows:
[0050] S501: Standardized API Adaptation Layer Development: Develop an API gateway that supports RESTful, SOAP, and gRPC protocols, and encapsulate the native APIs of monitoring systems, CMDB, work order systems, and CI / CD platform tools into a unified "intelligent agent interface" to reduce the complexity of calls;
[0051] S502: Data Conversion Module Development: Convert heterogeneous data from various systems into a common JSON format for intelligent agents, define unified data fields; perform missing value filling and outlier filtering on the converted data to ensure data accuracy;
[0052] S503: Integrated Process Configuration: Develop a visual configuration interface that supports drag-and-drop configuration of cross-system processes, with the triggering mechanism set to "timed trigger + event trigger";
[0053] S504: Fault Tolerance and Performance Optimization: Design an API call retry mechanism to send an alarm to operations personnel upon failure; according to the formula:
[0054]
[0055] Optimize call efficiency in high-concurrency scenarios to ensure API call success rate ≥99.5% and data transmission latency ≤1 second;
[0056] S505: Verification: Complete the integration of 3-5 types of core enterprise operation and maintenance systems, according to the formula:
[0057] Verification requires meeting the following criteria: data interoperability accuracy ≥ 99%, new system integration cycle ≤ 3 days, and process execution success rate ≥ 98%.
[0058] Preferably, in S104, the keywords are core related words of operation and maintenance intent, including "restart", "log", "fault", "performance", "deployment" and "configuration", which are automatically statistically extracted and regularly updated by the operation and maintenance scenario corpus.
[0059] Preferably, in step S402, the scenario tags adopt a hierarchical labeling method of "first-level tag - second-level tag". The first-level tags include "server management", "application deployment", "fault handling", "performance monitoring" and "configuration adjustment". The second-level tags are subdivided based on specific operation and maintenance scenarios, including but not limited to "server management - Linux restart" and "fault handling - database connection timeout". The tag system supports custom expansion according to enterprise operation and maintenance needs.
[0060] Preferably, in S503, the time interval for timed triggering can be set to be adjustable from 1 to 30 minutes through a visual configuration interface. Event triggering supports custom triggering conditions, including but not limited to "triggering work order creation when the fault risk value is ≥0.8" and "triggering knowledge base update after successful execution of automated operation". All integrated process configurations support export backup and one-click import recovery.
[0061] Compared with existing technologies, the beneficial effects of this invention are:
[0062] 1. By optimizing the basic intent recognition, a multi-dimensional recognition model with contextual association weight factors is constructed. Combined with the mechanism of "triggering clarification when Top-1 confidence is <0.8", the accuracy of parsing fuzzy operation and maintenance instructions is improved to over 90%, the ability to understand the context of multi-turn conversations is significantly enhanced, and operation and maintenance deviations caused by instruction misunderstandings are completely avoided.
[0063] 2. By building a fault diagnosis framework, we break through the limitations of single data and integrate multi-dimensional data such as "logs + monitoring indicators + system configuration". Based on causal relationship graphs and historical fault case transfer learning, we locate the root cause. At the same time, through predictive models, we achieve a fault location accuracy of ≥85% and a prediction lead time of ≥1 hour, which effectively reduces fault investigation time and reduces the impact of faults on business.
[0064] 3. By optimizing the design of the entire security mechanism of "script generation - security verification - permission classification - secondary confirmation - log auditing" through automated operation, the risk level is divided by "risk score = impact scope weight × A + operation reversibility weight × B", and combined with a three-level permission system and secondary verification of high-risk operations, the success rate of automated operation is ≥98% and the error execution rate of high-risk operation is ≤0.1%. At the same time, the full audit log supports traceability, completely avoiding operational security risks.
[0065] 4. By optimizing and constructing a closed loop of "data collection - structured processing - intelligent update - efficient reuse" through knowledge accumulation, core knowledge is extracted through BERT named entity recognition, adaptive updates are achieved by combining cosine similarity algorithm, and Elasticsearch semantic index is combined to make knowledge query response time ≤1 second, matching accuracy ≥90%, and new knowledge update delay ≤2 hours, avoiding passive accumulation of knowledge and inefficient retrieval, and realizing efficient reuse and continuous iteration of operation and maintenance experience;
[0066] 5. Through a standardized API adaptation layer and data conversion module, seamless integration with tools such as monitoring systems, CMDB, work order systems, and CI / CD platforms is achieved, with data interoperability accuracy ≥99% and new system integration cycle ≤3 days. At the same time, it supports drag-and-drop configuration of cross-system processes, breaking down data silos in operation and maintenance and forming a collaborative operation and maintenance system across the entire process.
[0067] This invention addresses the problems of existing operation and maintenance intelligence agents, such as poor parsing of fuzzy commands, single-dimensional fault diagnosis, high security risks in automated operations, inefficient knowledge accumulation, and difficulty in cross-system collaboration, through five-stage optimization: intent recognition, fault diagnosis, automated operation, knowledge accumulation, and cross-system integration. It achieves a fuzzy command parsing accuracy of ≥90%, a fault location accuracy of ≥85% with early warning of more than 1 hour, a high-risk operation error execution rate of ≤0.1%, a knowledge query response time of ≤1 second, and a cross-system data interoperability accuracy of ≥99%. This significantly improves operation and maintenance efficiency, reduces operation and maintenance costs, decreases reliance on manual labor and operational risks, and promotes the upgrade of the operation and maintenance system from passive response to proactive prevention and intelligent collaboration. Attached Figure Description
[0068] Figure 1 This is a flowchart of an LM-driven operation and maintenance system management intelligent agent optimization method proposed in this invention. Detailed Implementation
[0069] The present invention will be further explained below with reference to specific embodiments.
[0070] Example
[0071] Reference Figure 1This embodiment proposes an LM-driven optimization method for operation and maintenance system management agents, including the following steps:
[0072] S1: Basic optimization of intent recognition: The LM language model is trained and fine-tuned based on the corpus of operation and maintenance scenarios. The context association weight factor is introduced to build a multi-dimensional intent recognition model to achieve accurate parsing of fuzzy operation and maintenance commands.
[0073] The specific logical steps are as follows:
[0074] S101: Construction of Operation and Maintenance Scenario Corpus: Collect historical operation and maintenance conversations, operation manuals and public corpora of enterprises, filter effective data containing "instruction description-intent type-scenario tag", and after "human + machine" cross-annotation, divide it into training set, validation set and test set in 7:2:1 to form a structured corpus;
[0075] S102: Basic LM Language Model Selection and Pre-adaptation: Select the LM language model according to the enterprise size. Small and medium-sized enterprises should choose GPT-4Mini / Llama3, and large enterprises should choose GPT-4. Lightweight pre-train the selected LM language model using Linux and K8s operation and maintenance documents to adapt to the understanding of operation and maintenance terminology.
[0076] S103: Fine-tuning training of the LM language model: Train the pre-adapted LM language model selected in S102 using the training set and validation set, set the cosine annealing learning rate and BatchSize = 8-16, use dropout regularization to suppress overfitting, stop training when the validation set intention recognition accuracy does not improve for 3 consecutive rounds, and ensure that the validation set accuracy is ≥85%.
[0077] S104: Design of Contextual Association Weighting Factors: Constructing a Model for Calculating the Total Weight of Contextual Association
[0078] Total weight = Conversation round weight × 0.5 + Keyword frequency weight × 0.3 +
[0079] Scenario complexity weight × 0.2;
[0080] The session round weight is 0.8. (n-1) The calculation is performed, where n is the current conversation round, and the keyword frequency weight is calculated in "min": Keyword frequency weight = number of times the keyword appears × 0.2. When the number of times is greater than 3, the weight is capped at 0.6. The scene complexity weight is set according to the scene difficulty as 0.8 basic, 1.0 medium, and 1.2 complex. The total weight is integrated into the model's attention mechanism to improve the understanding ability of multi-round conversations.
[0081] The keywords are core related terms of operation and maintenance intent, including "restart", "log", "fault", "performance", "deployment" and "configuration", which are automatically collected, extracted and updated regularly by the operation and maintenance scenario corpus;
[0082] S105: Design of a fuzzy instruction clarification mechanism: Set "the confidence of the top-1 of the top-3 intent candidates in the model output is <0.8" as the criterion for judging fuzzy instructions, and generate "closed + guiding" clarification text for fuzzy instructions to ensure accurate instruction parsing;
[0083] S106: Model Validation: Validate the model performance using a test set. The model must meet the following requirements: intent recognition accuracy ≥ 90%, ambiguity command clarification success rate ≥ 95%, and finally output the optimized intent recognition model.
[0084] S2: Fault Diagnosis Framework Construction: Based on the optimized intent recognition capability, a multi-level diagnostic process of "log preprocessing - abnormal feature extraction - multi-dimensional data fusion - root cause reasoning" is established. Combined with transfer learning from the historical fault case library, the accuracy of fault location and the timeliness of prediction are improved.
[0085] The specific logical steps are as follows:
[0086] S201: Log preprocessing: Connect to system logs and application logs, segment by Jieba word segmentation library, deduplicate by log ID, mark "ERROR" and "Timeout" exception fields, remove redundant data, and retain valid log entries;
[0087] S202: Anomaly Feature Extraction: Using the Random Forest algorithm, error codes and core features of anomaly keywords are extracted from the preprocessed logs to construct a fault anomaly feature vector library;
[0088] S203: Multi-dimensional data fusion: Integrates monitoring indicators and system configuration data to form a multi-dimensional data source of "logs + monitoring + configuration", breaking the limitations of single data;
[0089] S204: Root Cause Reasoning and Fault Prediction: Based on existing causal relationship graph models, combined with transfer learning from historical fault case databases, the root causes of faults are located; and existing fault risk assessment models are trained using historical fault data, according to the formula:
[0090] Risk value = α × historical failure frequency + β × deviation of real-time monitoring indicators +
[0091] γ× Impact of configuration changes;
[0092] Calculate the fault risk value, where α+β+γ=1 and β>α>γ, with priority given to real-time indicators;
[0093] Furthermore, the deviation of the real-time monitoring indicators is calculated using the formula:
[0094] Calculations enable early warning of potential faults;
[0095] S205: Model Validation: Validate the fault risk assessment model. The fault risk assessment model must meet the following requirements: fault location accuracy ≥ 85%, fault prediction lead time ≥ 1 hour, and output an optimized fault diagnosis framework.
[0096] S3: Optimized Automated Operations: Based on intent parsing and fault diagnosis results, a full-process mechanism of "script generation - security verification - permission classification - secondary confirmation - log auditing" is designed, and a dynamic permission adaptation module is introduced to realize secure automated execution in different operation and maintenance scenarios;
[0097] The specific logical steps are as follows:
[0098] S301: Operation and maintenance script generation: Based on the user's natural language operation and maintenance instructions, call the S1 optimized LM language model to generate Shell / Python / Ansible scripts, and output script logic descriptions at the same time for operation and maintenance personnel to check;
[0099] S302: Security Verification: First, perform script syntax verification using the ShellCheck tool, then perform logic verification in the "dry-run" mode within the simulation environment, and finally, apply the formula:
[0100] Risk score = Impact range weight × A + Operational reversibility weight × B, to assess the risk level of the task;
[0101] Where A is the impact range score: 1 point for a single machine, 3 points for a cluster, and 5 points for the entire system; B is the operation reversibility score: 1 point for recoverable, 3 points for semi-recoverable, and 5 points for unrecoverable; the impact range weight = 0.6, and the operation reversibility weight = 0.4.
[0102] Risk is categorized into 1-5 levels based on risk scores: 1-2 points for low risk, 3-4 points for medium risk, 5-8 points for high risk, and 9-10 points for extremely high risk.
[0103] S303: Hierarchical Permissions and Secondary Confirmation: Connect to the enterprise LDAP user system and set up a three-level permission system: Ordinary maintenance personnel: Level 1-2 tasks, Senior maintenance personnel: Level 3-4 tasks, Administrator: Level 5 tasks; Level 4-5 high-risk tasks require manual confirmation from the administrator + SMS verification code verification, and can only be executed after secondary confirmation is completed.
[0104] S304: Operation Log Audit: Records a full log of "Operator - Operation Time - Instruction Content - Script Content - Execution Result - Risk Level" and stores it in an immutable PostgreSQL database, supporting retrieval and traceability by dimension;
[0105] S305: Dynamic permission adaptation: Adjust permission rules according to the enterprise's organizational structure to ensure flexible permission control;
[0106] S306: Verification: Execute 200 automated tasks, and the operation success rate must be ≥98%, and the high-risk operation error execution rate must be ≤0.1%;
[0107] S4: Knowledge Accumulation Optimization: Based on fault handling data and automated operation experience, a closed-loop system of "task processing - experience extraction - structured storage - intelligent update" is constructed. A semantic similarity matching algorithm is adopted to achieve efficient retrieval and adaptive updating of the knowledge base.
[0108] The specific logical steps are as follows:
[0109] S401: Knowledge Data Acquisition: Automatically captures fault diagnosis reports output by the fault diagnosis framework in S2 and automated operation records in S3. It also supports maintenance personnel to manually enter special scenario experience. The fault diagnosis report includes fault phenomena, root causes and solutions. Special scenario experience includes, but is not limited to, rare fault handling methods.
[0110] S402: Knowledge structuring processing: The BERT model named entity recognition algorithm is used to extract the core information of "problem description - fault cause - operation steps - verification method" from the data collected in S401, and it is stored in a unified Markdown template and labeled with scene tags. At the same time, a knowledge index is built based on Elasticsearch to support keyword and semantic search.
[0111] Its scenario tags adopt a hierarchical labeling method of "first-level tag - second-level tag". The first-level tags include "server management", "application deployment", "fault handling", "performance monitoring" and "configuration adjustment". The second-level tags are subdivided based on specific operation and maintenance scenarios, including but not limited to "server management - Linux restart" and "fault handling - database connection timeout". The tag system supports custom expansion according to enterprise operation and maintenance needs.
[0112] S403: Knowledge Base Adaptive Update: When adding new knowledge entries, word vectors for the entries are generated using the BERT model and calculated according to the cosine similarity formula.
[0113] Calculate the semantic similarity with existing knowledge base entries;
[0114] Where A and B are the word vectors of the new entry and the existing entry, respectively. If Sim(A,B)≥0.7, the existing entry is updated and a new solution is added. If Sim(A,B)<0.7, a new entry is added. Redundant entries are automatically detected every month. If Sim(A,B)≥0.9, the latest complete entry is retained.
[0115] S404: Knowledge Reuse Function Development: Add a "Knowledge Query" entry to the intelligent agent interaction interface to ensure that the query response time meets the requirements; response time = index matching time + data return time ≤ 1 second, and support "one-click solution call";
[0116] S405: Verification: Randomly initiate 100 knowledge queries, and the response time must be ≤1 second, the knowledge matching accuracy rate must be ≥90%, and the delay in updating new knowledge must be ≤2 hours.
[0117] S5: Cross-system integration optimization: Design a standardized API adaptation layer and data conversion module to support seamless integration with various operation and maintenance tools such as monitoring systems, CMDB, and work order systems, and achieve cross-platform data interoperability and process collaboration;
[0118] The specific logical steps are as follows:
[0119] S501: Standardized API Adaptation Layer Development: Develop an API gateway that supports RESTful, SOAP, and gRPC protocols, and encapsulate the native APIs of monitoring systems, CMDB, work order systems, and CI / CD platform tools into a unified "intelligent agent interface" to reduce the complexity of calls;
[0120] S502: Data Conversion Module Development: Convert heterogeneous data from various systems into a common JSON format for intelligent agents, define unified data fields; perform missing value filling and outlier filtering on the converted data to ensure data accuracy;
[0121] S503: Integrated Process Configuration: Develop a visual configuration interface that supports drag-and-drop configuration of cross-system processes, with the triggering mechanism set to "timed trigger + event trigger";
[0122] The time interval for its scheduled triggers can be set to be adjustable from 1 to 30 minutes through a visual configuration interface. Event triggering supports custom trigger conditions, including but not limited to "triggering work order creation when the fault risk value is ≥0.8" and "triggering knowledge base update after successful execution of automated operation". All integrated process configurations support export backup and one-click import recovery.
[0123] S504: Fault Tolerance and Performance Optimization: Design an API call retry mechanism to send an alarm to operations personnel upon failure; according to the formula:
[0124]
[0125] Optimize call efficiency in high-concurrency scenarios to ensure API call success rate ≥99.5% and data transmission latency ≤1 second;
[0126] S505: Verification: Complete the integration of 3-5 types of core enterprise operation and maintenance systems, according to the formula:
[0127] Verification requires meeting the following criteria: data interoperability accuracy ≥ 99%, new system integration cycle ≤ 3 days, and process execution success rate ≥ 98%.
[0128] This embodiment optimizes operations through five stages: intent recognition, fault diagnosis, automated operation, knowledge accumulation, and cross-system integration. It specifically addresses the problems of existing operation and maintenance intelligence agents, such as poor parsing of fuzzy commands, single-dimensional fault diagnosis, high security risks in automated operation, inefficient knowledge accumulation, and difficulty in cross-system collaboration. It achieves a fuzzy command parsing accuracy rate of ≥90%, a fault location accuracy rate of ≥85% with early warning of more than 1 hour, a high-risk operation error execution rate of ≤0.1%, a knowledge query response time of ≤1 second, and a cross-system data interoperability accuracy rate of ≥99%. This significantly improves operation and maintenance efficiency, reduces operation and maintenance costs, reduces reliance on manual labor and operational risks, and promotes the upgrade of the operation and maintenance system from passive response to proactive prevention and intelligent collaboration.
[0129] 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 equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.
Claims
1. A method for optimizing an operation and maintenance system management intelligent agent driven by LM, characterized in that, Includes the following steps: S1: Basic optimization of intent recognition: The LM language model is trained and fine-tuned based on the corpus of operation and maintenance scenarios. The context association weight factor is introduced to build a multi-dimensional intent recognition model to achieve accurate parsing of fuzzy operation and maintenance commands. S2: Fault Diagnosis Framework Construction: Based on the optimized intent recognition capability, a multi-level diagnostic process of "log preprocessing - abnormal feature extraction - multi-dimensional data fusion - root cause reasoning" is established. Combined with transfer learning from the historical fault case library, the accuracy of fault location and the timeliness of prediction are improved. S3: Optimized Automated Operations: Based on intent parsing and fault diagnosis results, a full-process mechanism of "script generation - security verification - permission classification - secondary confirmation - log auditing" is designed, and a dynamic permission adaptation module is introduced to realize secure automated execution in different operation and maintenance scenarios; S4: Knowledge Accumulation Optimization: Based on fault handling data and automated operation experience, a closed-loop system of "task processing - experience extraction - structured storage - intelligent update" is constructed. A semantic similarity matching algorithm is adopted to achieve efficient retrieval and adaptive updating of the knowledge base. S5: Cross-system integration optimization: Design a standardized API adaptation layer and data conversion module to support seamless integration with various operation and maintenance tools such as monitoring systems, CMDB, and work order systems, and achieve cross-platform data interoperability and process collaboration.
2. The LM-driven operation and maintenance system management intelligent agent optimization method according to claim 1, characterized in that, The specific logical steps of S1 are as follows: S101: Construction of Operation and Maintenance Scenario Corpus: Collect historical operation and maintenance conversations, operation manuals and public corpora of enterprises, filter effective data containing "instruction description-intent type-scenario tag", and after "human + machine" cross-annotation, divide it into training set, validation set and test set in 7:2:1 to form a structured corpus; S102: Basic LM Language Model Selection and Pre-adaptation: Select the LM language model according to the enterprise size. Small and medium-sized enterprises should choose GPT-4Mini / Llama3, and large enterprises should choose GPT-4. Lightweight pre-train the selected LM language model using Linux and K8s operation and maintenance documents to adapt to the understanding of operation and maintenance terminology. S103: Fine-tuning training of the LM language model: Train the pre-adapted LM language model selected in S102 using the training set and validation set, set the cosine annealing learning rate and BatchSize = 8-16, use dropout regularization to suppress overfitting, stop training when the validation set intention recognition accuracy does not improve for 3 consecutive rounds, and ensure that the validation set accuracy is ≥85%. S104: Design of Contextual Association Weighting Factors: Constructing a Model for Calculating the Total Weight of Contextual Association Total weight = Conversation round weight × 0.5 + Keyword frequency weight × 0.3 + Scenario complexity weight × 0.2; The session round weight is 0.
8. (n-1) The calculation is performed, where n is the current conversation round, and the keyword frequency weight is calculated in "min": Keyword frequency weight = number of times the keyword appears × 0.
2. When the number of times is greater than 3, the weight is capped at 0.
6. The scene complexity weight is set according to the scene difficulty as 0.8 basic, 1.0 medium, and 1.2 complex. The total weight is integrated into the model's attention mechanism to improve the understanding ability of multi-turn conversations. S105: Design of a fuzzy instruction clarification mechanism: Set "the confidence of the top-1 of the top-3 intent candidates in the model output is <0.8" as the criterion for judging fuzzy instructions, and generate "closed + guiding" clarification statements for fuzzy instructions to ensure accurate instruction parsing; S106: Model Validation: Validate the model performance using a test set. The model must meet the following requirements: intent recognition accuracy ≥ 90%, ambiguity command clarification success rate ≥ 95%, and finally output the optimized intent recognition model.
3. The LM-driven operation and maintenance system management intelligent agent optimization method according to claim 1, characterized in that, The specific logical steps of S2 are as follows: S201: Log preprocessing: Connect to system logs and application logs, segment by Jieba word segmentation library, deduplicate by log ID, mark "ERROR" and "Timeout" exception fields, remove redundant data, and retain valid log entries; S202: Anomaly Feature Extraction: Using the Random Forest algorithm, error codes and core features of anomaly keywords are extracted from the preprocessed logs to construct a fault anomaly feature vector library; S203: Multi-dimensional data fusion: Integrates monitoring indicators and system configuration data to form a multi-dimensional data source of "logs + monitoring + configuration", breaking the limitations of single data; S204: Root Cause Reasoning and Fault Prediction: Based on existing causal relationship graph models, combined with transfer learning from historical fault case databases, the root causes of faults are located; and existing fault risk assessment models are trained using historical fault data, according to the formula: Risk value = α × historical failure frequency + β × deviation of real-time monitoring indicators + γ× Impact of configuration changes; Calculate the fault risk value, where α+β+γ=1 and β>α>γ, with priority given to real-time indicators; Furthermore, the deviation of the real-time monitoring indicators is calculated using the formula: Calculations enable early warning of potential faults; S205: Model Validation: Validate the fault risk assessment model. The fault risk assessment model must meet the following requirements: fault location accuracy ≥ 85%, fault prediction lead time ≥ 1 hour, and output an optimized fault diagnosis framework.
4. The LM-driven operation and maintenance system management intelligent agent optimization method according to claim 1, characterized in that, The specific logical steps of S3 are as follows: S301: Operation and maintenance script generation: Based on the user's natural language operation and maintenance instructions, call the S1 optimized LM language model to generate Shell / Python / Ansible scripts, and output script logic descriptions at the same time for operation and maintenance personnel to check; S302: Security Verification: First, perform script syntax verification using the ShellCheck tool, then perform logic verification in the "dry-run" mode within the simulation environment, and finally, apply the formula: Risk score = Impact range weight × A + Operational reversibility weight × B, to assess the risk level of the task; Where A is the impact range score: 1 point for a single machine, 3 points for a cluster, and 5 points for the entire system; B is the operation reversibility score: 1 point for recoverable, 3 points for semi-recoverable, and 5 points for unrecoverable; the impact range weight = 0.6, and the operation reversibility weight = 0.
4. Risk is categorized into 1-5 levels based on risk scores: 1-2 points for low risk, 3-4 points for medium risk, 5-8 points for high risk, and 9-10 points for extremely high risk. S303: Hierarchical Permissions and Secondary Confirmation: Connect to the enterprise LDAP user system and set up a three-level permission system: Ordinary maintenance personnel: Level 1-2 tasks, Senior maintenance personnel: Level 3-4 tasks, Administrator: Level 5 tasks; Level 4-5 high-risk tasks require manual confirmation from the administrator + SMS verification code verification, and can only be executed after secondary confirmation is completed. S304: Operation Log Audit: Records a full log of "Operator - Operation Time - Instruction Content - Script Content - Execution Result - Risk Level" and stores it in an immutable PostgreSQL database, supporting retrieval and traceability by dimension; S305: Dynamic permission adaptation: Adjust permission rules according to the enterprise's organizational structure to ensure flexible permission control; S306: Verification: Execute 200 automated tasks, and the operation success rate must be ≥98% and the high-risk operation error execution rate ≤0.1%.
5. The LM-driven operation and maintenance system management intelligent agent optimization method according to claim 1, characterized in that, The specific logical steps of S4 are as follows: S401: Knowledge Data Acquisition: Automatically captures fault diagnosis reports output by the fault diagnosis framework in S2 and automated operation records in S3. It also supports maintenance personnel to manually enter special scenario experience. The fault diagnosis report includes fault phenomena, root causes and solutions. Special scenario experience includes, but is not limited to, rare fault handling methods. S402: Knowledge structuring processing: The BERT model named entity recognition algorithm is used to extract the core information of "problem description - fault cause - operation steps - verification method" from the data collected in S401, and it is stored in a unified Markdown template and labeled with scene tags. At the same time, a knowledge index is built based on Elasticsearch to support keyword and semantic search. S403: Knowledge Base Adaptive Update: When adding new knowledge entries, word vectors for the entries are generated using the BERT model and calculated according to the cosine similarity formula. Calculate the semantic similarity with existing knowledge base entries; Where A and B are the word vectors of the new entry and the existing entry, respectively. If Sim(A,B)≥0.7, the existing entry is updated and a new solution is added. If Sim(A,B)<0.7, a new entry is added. Redundant entries are automatically detected every month. If Sim(A,B)≥0.9, the latest complete entry is retained. S404: Knowledge Reuse Function Development: Add a "Knowledge Query" entry to the intelligent agent interaction interface to ensure that the query response time meets the requirements; response time = index matching time + data return time ≤ 1 second, and support "one-click solution call"; S405: Verification: Randomly initiate 100 knowledge queries, which must meet the following requirements: response time ≤ 1 second, knowledge matching accuracy ≥ 90%, and new knowledge update delay ≤ 2 hours.
6. The LM-driven operation and maintenance system management intelligent agent optimization method according to claim 1, characterized in that, The specific logical steps of S5 are as follows: S501: Standardized API Adaptation Layer Development: Develop an API gateway that supports RESTful, SOAP, and gRPC protocols, and encapsulate the native APIs of monitoring systems, CMDB, work order systems, and CI / CD platform tools into a unified "intelligent agent interface" to reduce the complexity of calls; S502: Data Conversion Module Development: Convert heterogeneous data from various systems into a common JSON format for intelligent agents, define unified data fields; perform missing value filling and outlier filtering on the converted data to ensure data accuracy; S503: Integrated Process Configuration: Develop a visual configuration interface that supports drag-and-drop configuration of cross-system processes, with the triggering mechanism set to "timed trigger + event trigger"; S504: Fault Tolerance and Performance Optimization: Design an API call retry mechanism to send an alarm to operations personnel upon failure; according to the formula: Optimize call efficiency in high-concurrency scenarios to ensure API call success rate ≥99.5% and data transmission latency ≤1 second; S505: Verification: Complete the integration of 3-5 types of core enterprise operation and maintenance systems, according to the formula: Verification requires meeting the following criteria: data interoperability accuracy ≥ 99%, new system integration cycle ≤ 3 days, and process execution success rate ≥ 98%.
7. The LM-driven operation and maintenance system management intelligent agent optimization method according to claim 2, characterized in that, In S104, the keywords are core related words of operation and maintenance intent, including "restart", "log", "fault", "performance", "deployment" and "configuration", which are automatically statistically extracted and regularly updated by the operation and maintenance scenario corpus.
8. The LM-driven operation and maintenance system management intelligent agent optimization method according to claim 5, characterized in that, In S402, the scenario tags adopt a hierarchical labeling method of "first-level tag - second-level tag". The first-level tags include "server management", "application deployment", "fault handling", "performance monitoring" and "configuration adjustment". The second-level tags are subdivided based on specific operation and maintenance scenarios, including but not limited to "server management - Linux restart" and "fault handling - database connection timeout". The tag system supports custom expansion according to the enterprise's operation and maintenance needs.
9. The LM-driven operation and maintenance system management intelligent agent optimization method according to claim 6, characterized in that, In the S503, the time interval for timed triggering can be set to 1-30 minutes through a visual configuration interface. Event triggering supports custom triggering conditions, including but not limited to "triggering work order creation when the fault risk value is ≥0.8" and "triggering knowledge base update after successful execution of automated operation". All integrated process configurations support export backup and one-click import recovery.