Implementation method of large model graph retrieval enhancement system for software and hardware monitoring and operation

Abstract

The present invention relates to the field of intelligent operation and maintenance technology, specifically to an execution method of a large-model graph retrieval enhancement system for software and hardware monitoring and operation and maintenance, comprising: step S1: inputting fault information into the graph retrieval enhancement system; step S2: the graph construction and update module receives and processes the fault information, generates triples, and writes them into the operation and maintenance / fault knowledge graph; step S3: inputting the fault information into the graph retrieval enhancement module for a two-stage filtering retrieval to filter out subgraph information; step S4: the prompt word construction module converts the fault information and the filtered subgraph information into structured natural language prompt fragments; step S5: the reasoning generation module performs natural language question and answer to generate fault analysis results. Based on the above scheme, the execution method enhances the adaptability of knowledge reasoning and fault location, and while ensuring accuracy, it gives full play to the generalized reasoning ability of the large language model, thereby enhancing its practical value.

Description

Technical Field

[0001] The present invention relates to the field of intelligent operation and maintenance technology, and in particular to an execution method of a large model graph retrieval enhancement system for software and hardware monitoring and operation and maintenance. Background Art

[0002] In modern IT systems, as business complexity and scale continue to expand, the adaptation and migration of next-generation information technology (NGIT) faces complex and ever-changing failure scenarios. During the adaptation process, it is necessary to monitor the operating status of various IT resources, such as servers, databases, and applications, so that when a failure occurs, the cause can be quickly and accurately located, solutions can be developed, and repair processes can be executed, thereby ensuring stable system operation during the migration of NGIT. With the rapid development of large language models (LLMs), researchers have combined domain knowledge bases with LLMs and knowledge bases accumulated in IT monitoring and operation and maintenance fields. Using Retrieval-Augmented Generation (RAG) technology, researchers have addressed issues encountered during the migration and adaptation of NGIT. However, traditional document-based RAG architectures suffer from knowledge redundancy and difficulty in reasoning due to the difficulty of structuring, making them difficult to meet the real-time and interpretability requirements of IT systems.

[0003] In recent years, knowledge graph technology has been widely used in many fields. Through structured knowledge representation and powerful reasoning capabilities, it provides new ideas for solving complex problems. In the fields of system adaptation, monitoring and operation and maintenance, the integration of knowledge graphs and large models has the following advantages:

[0004] 1) Improve interpretability: The explicit knowledge of the knowledge graph is combined with the implicit knowledge of the large model to improve the interpretability of knowledge applications.

[0005] 2) Achieve cross-validation: The output of the knowledge graph is combined with the output of the large model to provide a means of cross-validation / comparison for knowledge applications and improve the reliability of the service.

[0006] 3) Optimize knowledge storage: The combination of structured information storage of knowledge graphs and unstructured information processing of large models can optimize knowledge storage and retrieval efficiency.

[0007] 4) Improve decision-making capabilities: The combination of knowledge graph reasoning results and large model reasoning results can further enrich the knowledge background for auxiliary decision-making and provide more accurate decision-making recommendations.

[0008] In the migration to next-generation information technology, knowledge graphs can integrate knowledge about hardware and software, application assets, failure modes, and solutions to form a comprehensive knowledge system. However, how to efficiently retrieve relevant knowledge from knowledge graphs and apply it to intelligent question answering, fault localization, and automated process development and execution remains a pressing issue.

[0009] Graph-based Retrieval-Augmented-Generation (GraphRAG) enables the deep integration of large language models and knowledge graphs, enabling more efficient and accurate implementation of intelligent question answering, IT fault localization, and automated process formulation and execution. This framework enhances LLMs' reasoning capabilities by integrating relevant information from external knowledge graphs.

[0010] However, GraphRAG currently also faces problems such as high computing cost, knowledge base noise and redundancy, which seriously affect the efficiency and accuracy of the reasoning process.

[0011] In summary, the existing technology still has the following shortcomings:

[0012] 1) Low knowledge retrieval efficiency: Existing knowledge graph retrieval technology requires high computing power when facing large-scale knowledge graphs, and the retrieval efficiency is low, making it difficult to quickly locate relevant knowledge.

[0013] 2) Inaccurate retrieval results: Existing technologies lack a deep understanding of contextual information during the retrieval process, resulting in insufficient relevance of retrieval results.

[0014] 3) Lack of dynamic update mechanism: The knowledge graph is not updated in a timely manner, resulting in the inability to guarantee the timeliness and accuracy of the search results.

[0015] 4) Low automation level in troubleshooting process: The existing troubleshooting process relies on manual operations, has a low level of automation, is inefficient, and is prone to errors. Summary of the Invention

[0016] In order to solve the above technical problems, the present invention discloses an execution method of a large model graph retrieval enhancement system for software and hardware monitoring and operation and maintenance.

[0017] The present invention discloses an execution method of a large-scale graph retrieval enhancement system for software and hardware monitoring and operation maintenance, wherein the graph retrieval enhancement system includes a graph construction and update module, a graph retrieval enhancement module, a prompt word construction module, an inference generation module, a process parsing module, and a process execution module; the graph construction and update module is used to construct and update the operation and maintenance / fault knowledge graph; the graph retrieval enhancement system is used to execute and process the fault information of the fault event;

[0018] The execution method of the graph retrieval enhancement system includes the following steps:

[0019] Step S1: inputting fault information of a fault event into the graph retrieval enhancement system;

[0020] Step S2: The graph construction and update module receives and processes the fault information of the fault event, generates triples, writes the triples into the operation and maintenance / fault knowledge graph, and updates the operation and maintenance / fault knowledge graph;

[0021] Step S3: Input the fault information into the graph retrieval enhancement module; the graph retrieval enhancement module performs a two-stage filtering search based on the operation and maintenance / fault knowledge graph to filter out the subgraph information corresponding to the fault information;

[0022] Step S4: The prompt word construction module converts the fault information and the filtered sub-graph information into a structured natural language prompt segment;

[0023] Step S5: The reasoning generation module calls the large language model and combines it with the structured natural language prompt fragments to perform natural language question answering and generate fault analysis results.

[0024] A further improvement of the present invention is that the graph retrieval enhancement system further includes a process analysis module and a process execution module; the execution method further includes step S6 and step S7;

[0025] Step S6: The process parsing module parses the fault analysis results generated by the large language model into a structured task flow;

[0026] Step S7: The process execution module calls the corresponding scripts in sequence to schedule and execute the structured task flow, and records the execution results.

[0027] A further improvement of the present invention is that the graph construction and update module constructs an operation and maintenance / fault knowledge graph based on an ontology model; the ontology model is obtained by modeling the semantic relationships between software and hardware components, fault time, monitoring indicators, and operation and maintenance actions in the IT system; the ontology model can be divided into entities, relationships, and attributes;

[0028] The process of constructing an operation and maintenance / fault knowledge graph based on the ontology model is as follows: the original data in the unstructured knowledge base is subjected to field standardization processing, and then the original data after field standardization processing is input into the ontology model for entity recognition and semantic mapping to obtain the operation and maintenance / fault knowledge graph.

[0029] A further improvement of the present invention is that step S3 includes the following steps:

[0030] Step S31: The graph retrieval enhancement module constructs the fault information into a graph-structured query statement, and then uses the graph embedding model to convert the graph-structured query statement into a structured query vector;

[0031] Step S32: The graph retrieval enhancement module converts the predefined subgraph in the operation and maintenance / fault knowledge graph into a structured vector subgraph;

[0032] Step S33: The graph retrieval enhancement module calculates the semantic similarity between the structured query vector and the structured vector subgraph based on the semantic similarity formula, and preliminarily screens the structured vector subgraph based on the first threshold to obtain candidate subgraphs, and stores the candidate subgraphs in a candidate subgraph set;

[0033] Step S34: extracting structural patterns from the candidate subgraphs in the candidate subgraph set to obtain the structure of each candidate subgraph;

[0034] Step S35: Structural matching scores are performed on the structures of each candidate subgraph and the predefined template structure based on the structural matching formula, and fine screening is performed based on the second threshold to obtain a final subgraph set; the final subgraph set is the subgraph information corresponding to the fault information.

[0035] A further improvement of the present invention is that in step S4, the structured language prompt segment includes a first prompt segment and a second prompt segment, the first prompt segment is generated by the prompt word construction module based on the fault information, and the second prompt segment is generated by the prompt word construction module based on the fault information and the subgraph information;

[0036] Step S5 includes the following steps:

[0037] Step S51: The inference generation module inputs the first prompt segment into the large language model to obtain a first output;

[0038] Step S52: the inference generation module inputs the second prompt segment into the large language model to obtain a second output;

[0039] Step S53: The inference generation module performs weighted fusion on the first output and the second output to obtain a fused output;

[0040] Step S54: The inference generation module generates text based on the fusion output and uses Softmax to obtain the probability distribution to obtain the final response text; the final response text is the fault analysis result.

[0041] A further improvement of the present invention is that, in step S53, the inference generation module performs weighted fusion on the first output and the second output based on a weighted fusion formula to obtain a fusion output;

[0042] The weighted fusion formula is: Logits final=α·Logits KG + (1-α) Logits LLM ;

[0043] Among them, Logits final is the fusion output, α is the weight coefficient, Logits KG For the second output, Logits LLM is the first output.

[0044] A further improvement of the present invention is that the value of α is set based on a static method or a dynamic method; the value of α is between [0, 1].

[0045] A further improvement of the present invention is that the static method refers to presetting the value of α;

[0046] The dynamic method refers to calculating the value of α based on the dynamic formula;

[0047] The dynamic formula is:

[0048] α=Sigmoid(β·Sim(Q,G best )-γ);

[0049] Among them, Sim (Q, G best ) is the query vector Q and the most relevant vector subgraph G best The cosine similarity of ; β and γ are training parameters; Sigmoid is used to constrain the value of α to be between [0,1].

[0050] A further improvement of the present invention is that step S6 includes the following steps:

[0051] Step S61: The process analysis module inputs the fault analysis results into the natural language task parser to extract task information;

[0052] Step S62: The process analysis module constructs a directed acyclic graph based on the extracted task information;

[0053] Step S63: The process parsing module converts the directed acyclic graph into a structured task flow.

[0054] Beneficial effects of the present invention:

[0055] The present invention has high-precision structured knowledge expression. Based on structured semantic mapping and ontology models, the present invention accurately constructs the deployment, dependency and fault semantic relationships between domestic operating systems, databases, middleware and chip platforms. It can cover the complex equipment structure and abnormal propagation paths in the domestic ecosystem, significantly improving the expression accuracy and coverage of graph knowledge, and enhancing the adaptability of knowledge reasoning and fault location.

[0056] The present invention has a precise two-stage structured graph retrieval mechanism and introduces a two-stage knowledge filtering mechanism: first, irrelevant subgraphs are quickly screened out based on semantic similarity, and then fine-grained structural filtering is performed strictly according to the "component-indicator-fault-repair" structural template, effectively avoiding the interference of invalid knowledge on the reasoning of large language models, and significantly improving the context fit of the generated results and the accuracy and stability of reasoning.

[0057] This paper, based on the Logits fusion strategy, explicitly balances external knowledge with the LLM's inherent reasoning capabilities. This approach effectively improves the quality of generated results through a dynamic weight α (adaptively adjusted based on semantic relevance). While ensuring accuracy, this implementation method leverages the generalized reasoning capabilities of the large language model, significantly enhancing the practical value of the results. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Figure 1 This is the technical architecture of the large-scale graph retrieval enhancement system for software and hardware monitoring and operation and maintenance of the present invention. DETAILED DESCRIPTION

[0059] The following is a clear and complete description of the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings in the embodiments of the present invention. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can also be implemented in other ways different from those described herein, and those skilled in the art can make similar generalizations without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0060] The present invention discloses an execution method of a large model graph retrieval enhancement system for software and hardware monitoring and operation maintenance.

[0061] This invention addresses the needs of a new generation of information technology application innovation environments. It builds an ontology-based structure and knowledge graph integration mechanism based on domestic hardware and software platforms (such as the Kylin operating system, the DAMO database, and Feiteng / Haiguang chips). This supports fault signature modeling and similar event matching across diverse hardware and software combinations. Through ontology definitions, structural constraints between nodes (servers, applications, middleware, databases, etc.) and attributes are clearly defined, ensuring data consistency and the reasonability of the knowledge graph.

[0062] On this basis, the present invention proposes a graph retrieval enhancement (GraphRAG) system that fully utilizes the structured representation and efficient association capabilities of knowledge graphs to achieve low-cost, highly explainable intelligent operation and maintenance assistance, and improve the knowledge retrieval efficiency and question-answering accuracy in the retrieval enhancement generation process.

[0063] This paper proposes a low-computing, high-efficiency Graph Retrieval Enhancement (GraphRAG) system for software and hardware monitoring and operation and maintenance scenarios, particularly for domestically produced software and hardware. This system innovatively combines the advantages of large language models and knowledge graphs. Leveraging ontological constraints, it constructs a high-quality knowledge graph for the operation and maintenance / fault management of domestically produced software and hardware. This supports structured retrieval and semantically enhanced prompt construction, enabling highly interpretable question-answering and process generation in low-resource environments.

[0064] The current artificial intelligence (AI) technology architecture can be divided into the following four layers:

[0065] 1) Infrastructure: The solid foundation of AI technology, encompassing hardware, software, and data resources. Hardware includes GPU-based computing acceleration chips and intelligent chips, such as those for intelligent voice and image recognition. Software includes intelligent cloud platforms (such as Alibaba Cloud, Tencent Cloud, and Amazon Cloud) that manage hardware resources and big data platforms that manage general and industry-specific data resources.

[0066] 2) Model Layer: The AI ​​model layer is the "brain" of the AI ​​technology architecture, primarily comprising algorithms and models. The choice of model directly determines the effectiveness of the technology layer. Algorithms should be tailored to business needs.

[0067] 3) Capability Layer: A versatile toolbox for intelligent applications. This layer encompasses the large model's understanding, memory, logic, and generation capabilities, providing direct technical support for applications. Core capabilities include text processing, image generation, and code generation, and key technologies include RAG, Agent, large model fine-tuning, prompt word engineering, and thought chaining. In this document, the large model refers to the large language model.

[0068] 4) Application Layer: The application layer is where the AI ​​architecture ultimately lands and directly reflects the value of AI technology. Application layer developers deeply integrate technology with specific business scenarios to solve practical problems and create business value.

[0069] The positioning of this invention is to improve the technology of the capability layer, by improving the high-order search enhancement generation framework GraphRAG in the RAG technology system, improving the efficiency and accuracy of knowledge base and knowledge graph retrieval, and at the same time using technologies such as prompt word engineering, applied to the scenarios of information innovation adaptation, monitoring and operation and maintenance, to find the optimal solution for IT fault diagnosis and problem handling during the information innovation adaptation migration process, such as Figure 1 shown.

[0070] The graph retrieval enhancement system disclosed in the present invention includes a graph construction and update module, a graph retrieval enhancement module, a prompt word construction module, an inference generation module, a process analysis module and a process execution module. Figure 1 shown.

[0071] (1) Graph construction and update module (corresponding to Figure 1 "Graph Construction and Update" in

[0072] The graph construction and update module is used to build and update the operation and maintenance / fault knowledge graph when necessary. Based on the raw data in the unstructured knowledge base, the graph construction and update module constructs the nodes, attributes, relationships, and semantic paths of entities that conform to the ontology structure of domestic software and hardware fields, forming a unified semantic, reasonable, and scalable operation and maintenance / fault knowledge graph, and supports dynamic incremental updates, version control, and graph state backtracking.

[0073] 1) The ontology model is the fundamental semantic framework for constructing and reasoning about the O&M / fault knowledge graph. It determines the concept granularity and entity organization within the O&M / fault knowledge graph, as well as the interpretability of subsequent retrieval and generation. This paper designs an ontology model for intelligent O&M, targeting innovative software and hardware environments within next-generation information technology. This ontology model targets domestic software and hardware platforms and supports intelligent and interpretable fault handling and O&M processes. The ontology model is derived by modeling the semantic relationships between software and hardware components, fault events, monitoring indicators, and O&M actions within IT systems. It forms the foundation for subsequent O&M / fault knowledge graph construction, graph retrieval, and reasoning. Table 1 lists the core entity classes (Classes), relationships (Object Properties), and properties (Data Properties) of the ontology model. This model covers mainstream domestic software and hardware platforms (such as Kylin OS, DAMO Database, Feiteng / Loongson / Zhaoxin / Kunpeng), and represents information such as component hierarchy, fault type, indicator information, configuration dependencies, and operational processes. The entity class contains multiple entities.

[0074] Table 1: Operation and maintenance ontology entity classes in the new generation of information technology environment

[0075]

[0076] The relationships between entities are as follows:

[0077] a. Deployed On: This field describes the operating system or physical device on which application services, middleware, and other software are deployed, reflecting the system's topological dependencies. For example, the DM database is deployed On Kylin V10.

[0078] b. belongsTo: Indicates that a component belongs to a specific platform or architecture. This is used for platform-level analysis and locating issues with Chinese-made adaptations. Feiteng CPUs belongTo Chinese-made platforms, and Feiteng xx CPUs belongTo the ARM architecture.

[0079] c. Causes: This indicates that an abnormal monitoring indicator or underlying component status may cause a certain type of failure. It is the core edge of the reasoning chain. For example, network delay causes database connection failure.

[0080] d. dependsOn: This field indicates configuration or communication dependencies between services, helping to identify cascading failures and their propagation paths. For example, a web service dependsOnRedis.

[0081] e. Solved by (solvedBy): Indicates that a certain fault type can be resolved by a specific operation and maintenance action. This is used to generate repair process suggestions. If a database connection timeout occurs, the solvedBy command restarts the connection pool service.

[0082] f. Metric is (hasMetric): This indicates that a component or fault is bound to a specific monitoring metric, used for conditional triggering and matching similar cases (events). The service exception hasMetric connection_count = 0.

[0083] Attributes are designed for entities. As shown in Table 2 below, attributes can be embedded in entity nodes as first-order attributes of the operation and maintenance / fault knowledge graph, providing background information for subsequent large language model prompt construction and rule matching.

[0084] Table 2

[0085]

[0086] 2) The graph construction and update module normalizes the raw data in the unstructured knowledge base through field standardization (cleaning, word segmentation, and format conversion). It then performs entity recognition and semantic mapping based on the constructed domestic software and hardware ontology model, generating triples based on the raw data. Raw data refers to data collected by the current operations and maintenance system, including operation logs and metrics from various monitoring nodes (hosts, servers, databases, middleware, application software, etc.), as well as documents accumulated through review and organization of fault events.

[0087] 3) The ontology model constructs a highly consistent and reasonable operation / fault knowledge graph from triples based on the raw data, based on the rules of the ontology structure. Specifically, the triples are organized into nodes and edges in a graph database according to the ontology structure, establishing deployment dependencies between components, causal relationships between metrics and faults, and resolution relationships between faults and operations. Ultimately, an operation / fault knowledge graph is constructed that supports multi-hop reasoning and subgraph queries. All node and edge types in the operation / fault knowledge graph are inherited from the ontology model to prevent semantic conflicts or redundancy, thereby partitioning subgraph namespaces for different hosts / platforms / subsystems and improving query efficiency. For example, a Service node cannot connect to an illegal edge outside of a metric. The constructed operation / fault knowledge graph contains multiple subgraphs. When a new fault event is encountered, its fault information is entered into the operation / fault knowledge graph for retrieval of related subgraphs.

[0088] (4) Event chain diagram

[0089] Traditional knowledge graph construction methods typically use a static triple (entity-relationship-attribute) extraction model to process operation and maintenance data. This approach is inadequate when dealing with continuous events and dynamically associated information, easily resulting in isolated knowledge points lacking context. In addition to using traditional triples to construct the operation and maintenance / fault knowledge graph, this invention also designs an "instance-driven event chain modeling" mechanism. By instantiating and modeling continuous fault events generated during the actual operation and maintenance process, this method more effectively captures the causal relationships and dynamic evolution relationships between fault events, constructing a dynamic knowledge graph with greater semantic expression and fault tracking capabilities.

[0090] The process of constructing an event chain subgraph based on the instance-driven event chain modeling mechanism is as follows:

[0091] a. Fault event instantiation:

[0092] Continuous failure events are instantiated and extracted to generate event chain nodes (such as "server CPU utilization is too high", "database response delay", etc.).

[0093] b. Identification and modeling of event chain relationships:

[0094] Based on the associated attributes of consecutive fault events (same alarm indicator / same component ID / same alarm time / same host IP), the following method is used to automatically establish a logical relationship (event chain relationship) between fault events:

[0095] Time correlation analysis: Identify failure events that occur continuously within a time window (10-minute window) and have the same or similar component identifiers, and automatically merge them into a higher-level event chain (for example, "high server CPU utilization" → "slow database response" → "service unavailable"; these three failure events are connected by causality or inference logic).

[0096] Correlation analysis between indicators and components: Based on component types and operation and maintenance indicators (CPU utilization, disk IO, network latency, etc.), it dynamically identifies possible associated failure events and automatically builds causal paths or indicator correlation chains.

[0097] c. Dynamic graph modeling method based on time series

[0098] First, we construct an event chain subgraph based on dynamic time series relationships. We add explicit timestamp attributes to the relationships between event chain nodes and dynamically sort the relationships by timestamps, allowing us to reverse trace the historical fault event chain. We store the event chain as a special subgraph (event chain subgraph) in the operation and maintenance / fault knowledge graph.

[0099] In addition, the present invention implements a dynamic incremental update mechanism: introducing the "incremental update + historical version control" method, each time a new event instance chain is added, an incremental merging algorithm is used to update the operation and maintenance / fault knowledge graph, and at the same time, a snapshot of the historical operation and maintenance / fault knowledge graph version and the event chain subgraph is recorded to facilitate subsequent backtracking or evolution trend analysis.

[0100] d. Graph storage and index optimization strategy

[0101] Event chain storage structure optimization: At the operation and maintenance / fault knowledge graph storage level, path compression and subgraph indexing (such as the subgraph indexing in Neo4j) are used with event chains as units to improve the efficiency of subsequent fast queries.

[0102] Versioning and state chain maintenance: Record incremental update operation logs for each event chain, maintain historical version information of event chain nodes and relationships, and ensure historical data query and traceability capabilities.

[0103] An event chain is a storable and searchable knowledge graph. It consists of the aforementioned event instance nodes (nodes) and causal relationship chains (edges), forming a temporally ordered, causally explicit subgraph structure (event chain subgraph). It represents the evolutionary path of an actual fault. In this invention, the event chain is stored as a subgraph (event chain subgraph) in the operation and maintenance / fault knowledge graph.

[0104] The following are some examples of operations and maintenance / fault knowledge graphs. An enterprise uses domestic hardware and software platforms, including Feiteng servers, Kylin operating system, DAMO database, Eastcom middleware, and enterprise financial system applications. In daily operations and maintenance, it is necessary to monitor the operating status of these components to quickly locate and resolve faults.

[0105] The nodes of the operation and maintenance / fault knowledge graph represent entities, such as Feiteng D2000 server, Kylin V10 operating system, DAMO database, Oriental Telecom middleware, enterprise financial system applications, etc.; the edges represent the relationships between entities, such as deployedOn, causes, dependsOn, solvedBy, hasMetric, etc.

[0106] Description of some graph structures of the operation and maintenance / fault knowledge graph:

[0107] Server and operating system: There is a deployedOn edge between the Feiteng D2000 server node and the Kylin V10 operating system node; there is also a deployedOn edge between the Hygon server node and the Kylin V10 operating system node.

[0108] Operating system and database / middleware: There is a deployedOn edge between the Kylin V10 (Feitian D2000 server) node and the DAMO database node; there is a deployedOn edge between the Kylin V10 (Haiguang server) node and the Renmin University of China Jincang database node; there is a deployedOn edge between the Kylin V10 (Feitian D2000 server) node and the Oriental Telecom middleware node.

[0109] Middleware and application services: There is a deployedOn edge between the Oriental Telecom middleware node and the enterprise financial system application node.

[0110] Monitoring indicators and fault types: There is a causes edge between the CPU usage node and the database connection failure node; there is a causes edge between the memory usage node and the middleware communication timeout node; there is a causes edge between the network latency node and the application service response delay node.

[0111] Application service and database / middleware: There is a dependsOn edge between the enterprise financial system application node and the DAMO database node; there is a dependsOn edge between the enterprise financial system application node and the Oriental Communications middleware node.

[0112] Fault type and solution: There is a solvedBy edge between the Database Connection Failure node and the Restart Database Connection Pool Service node; there is a solvedBy edge between the Middleware Communication Timeout node and the Increase Middleware Memory Allocation node; there is a solvedBy edge between the Application Service Response Delay node and the Optimize Network Configuration node.

[0113] Components and monitoring indicators: There is a hasMetric edge between the DAMO database node and the CPU usage node; there is a hasMetric edge between the Oriental Telecom middleware node and the memory usage node; there is a hasMetric edge between the enterprise financial system application node and the network delay node.

[0114] The Operations / Fault Knowledge Graph showcases the relationships between components in domestic software and hardware operations scenarios, as well as the associations between fault types, monitoring indicators, and solutions. This graph provides a clearer understanding of system architecture and fault handling processes, supporting intelligent operations.

[0115] (5) Update of operation and maintenance / fault knowledge graph

[0116] This paper designs an operation and maintenance / fault knowledge graph update mechanism that balances real-time, evolutionary, consistent, and traceable performance. It is particularly suitable for handling complex operation and maintenance scenarios with high-frequency alarms and fluctuating indicators. This update mechanism includes three key functions: dynamic incremental updates, version control, and graph state backtracking. The specific technical implementation path is as follows:

[0117] a. Event chain dynamic update strategy

[0118] An event chain is a clear causal path or sequential path consisting of a series of logically or temporally related fault events. This mechanism uses the following methods to dynamically update the event chain:

[0119] Identifying and linking new fault events: When a new fault event enters the system, the system matches event chain nodes based on node identifiers (such as host IP, service name, and device ID). If an event chain node already exists, but the event type differs from the node type recorded in the operation and maintenance / fault knowledge graph (for example, from "memory overload" to "network timeout"), the system identifies it as a new event chain node, creates a new event chain node, and adds a causal relationship (as an edge) to the event chain node, forming a clear "event chain" structure.

[0120] Event chain node independence: Event chain nodes are stored according to the instantiation principle. Each event chain node represents a specific alarm or fault event. Existing nodes are not overwritten or updated. Instead, new event chain nodes are added and linked to the event path to clearly record the time of occurrence. Only attributes of existing event chain nodes (such as historical attribute values ​​and duration) are updated. However, the fault type represented by the event chain node cannot be modified to ensure that the historical event chain structure is not destroyed.

[0121] Incremental update and expiration mechanism for link relationships: When a new event chain node forms a new relationship with an existing event chain node, a new edge (relationship) is explicitly created and the start timestamp is recorded. If the old causal path (old edge) is no longer valid due to the evolution of the event chain, only the expiration time of the old edge is marked without deleting the old edge (relationship), maintaining the traceability of the historical evolution path.

[0122] b. Association update mechanism between event chain and global knowledge graph

[0123] Clearly distinguish the "event chain subgraph" from the overall "operation and maintenance / fault knowledge graph" to avoid misoperation of the original node. The specific mechanism is as follows:

[0124] Independent storage of event chain subgraphs: Each event chain is stored as a separate subgraph (event chain subgraph) in the operation and maintenance / fault knowledge graph, clearly distinguished from ordinary node entities by a clear identifier. Nodes within the event chain subgraph are distinguished by event instance naming (e.g., "CPU Alarm @ 2024-05-07 14:05") to prevent node overlap.

[0125] Cross-chain and cross-event relationship maintenance: For complex relationships across multiple event chains or multiple devices, the system creates edges with clearly labeled relationship types, maintaining global causal or association relationships without destroying the independence of individual event chains.

[0126] c. Incremental update implementation process

[0127] Receive new fault data: Collect and parse new fault events (such as CPU overload and network timeout) and their associated attributes (host, timestamp, component ID).

[0128] Node instantiation and link determination: Determine whether an event chain node already exists based on the host IP, component ID, and event type. If it is a new event type, create a new event chain node with the timestamp and event type as attributes.

[0129] Event chain update logic: Explicitly add new event chain nodes to the end of an existing event chain or at an appropriate location. If a new event is clearly determined to have a logical or causal relationship with the previous event, automatically generate a new edge, clearly recording the relationship type (e.g., "leads to," "occurs immediately after") and the start time.

[0130] Attribute history maintenance of event chain nodes: When the attributes of an event chain node change (such as an increase in duration), only the attribute history is updated without modifying the event type to maintain the consistency of the event chain.

[0131] d. Version control and event chain history status management

[0132] When each event chain changes (such as adding a new node or relationship), a subgraph snapshot is automatically generated or an incremental change log is recorded, recording a clear timestamp for each change for subsequent backtracking.

[0133] Separate the operation / fault knowledge graph from the event chain snapshot: The operation / fault knowledge graph and the event chain subgraph each have independent snapshots and incremental logging. A clear snapshot management service is responsible for recording the version time and identification number of each snapshot.

[0134] e. Historical event chain backtracking method

[0135] Based on the operation and maintenance / fault knowledge graph version management function, the event chain status backtracking at a specified time can be achieved: by specifying the time point, the most recent event chain snapshot can be retrieved.

[0136] Apply the incremental change log after the snapshot in chronological order to reconstruct the accurate historical state of the event chain.

[0137] Event chain path difference analysis: Supports path difference analysis of event chains between two versions, provides a clear comparison of event chain nodes and relationship differences, and highlights changes in key nodes in fault evolution.

[0138] (2) Graph Retrieval Enhancement Module

[0139] Graph retrieval enhancement module (corresponding to Figure 1 "Graph Retrieval Enhancement") receives fault events (corresponding to Figure 1 In the "alarm / fault information"), a two-stage search is performed in the operation and maintenance / fault knowledge graph to extract the "subgraph segments" and "historical similar case subgraphs" most relevant to the fault event (query question) and construct a knowledge embedding context. On this basis, the reasoning generation module uses the language understanding and generation capabilities of LLMs to output natural language question answers (corresponding to Figure 1 Output Intelligent Dialogue in the Figure 1 Output "Recommended Troubleshooting Task Flow").

[0140] The graph retrieval enhancement module receives fault information from a fault event as input. This information can be triggered by the operation and maintenance system or manually entered by the user. Based on the graph structure, it retrieves subgraphs similar to the fault information and the most relevant subgraphs from the operation and maintenance / fault knowledge graph. Specifically, the retrieval process is divided into semantic consistency-oriented retrieval and structural consistency-oriented filtering.

[0141] For fault information, the graph retrieval enhancement module first performs query enhancement. Query enhancement refers to identifying entities from fault information, extracting relationships between entities, and aligning them with entities and relationships in the ontology model. It also extracts entity attributes from the fault context corresponding to the fault information to enrich the semantics of the entity, thereby ensuring consistency, accuracy, and comprehensiveness in subsequent retrieval in the operation and maintenance / fault knowledge graph. Figure 1 After "query enhancement" in [1], the fault information is constructed as a graph-structured query statement.

[0142] Specifically, the fault information q is constructed as a graph-structured query statement Q g , and transform it into a structured query vector Q using a pre-trained graph embedding model:

[0143] ;

[0144] Subgraph (subgraph of fault events) predefined in the operation and maintenance / fault knowledge graph i Transformed into a structured vector subgraph G i : ; Where i is the subgraph number;

[0145] in, Represents a graph embedding model.

[0146] To prevent excessive retrieval from introducing noise, the present invention uses enhanced graph query to perform graph retrieval based on double-layer knowledge filtering in the operation and maintenance / fault knowledge graph, which can improve retrieval accuracy. At the same time, based on structural template matching, it ensures the logic and causality of fault diagnosis, making it easier to process subsequent automated tasks. This mechanism is particularly suitable for highly complex operation and maintenance diagnosis scenarios, and can effectively reduce redundant subgraph retrieval, improve system response efficiency and user experience. The retrieval of the graph retrieval enhancement module is divided into two stages:

[0147] Phase 1: Semantic consistency retrieval. Calculate the query vector Q and the vector subgraph G based on the semantic similarity formula. i The semantic similarity between them is filtered out, and the vector subgraph G whose semantic similarity is lower than the set first threshold is removed. i After this stage, the vector subgraph G that does not match the semantics of the query vector Q can be preliminarily excluded. i , reducing the burden of subsequent processing.

[0148] Semantic similarity formula:

[0149]

[0150] Each subgraph G is represented as a vector subgraph G after passing through the semantic graph embedding encoder TransE (TransE model). i , input the query vector Q, calculate the cosine similarity, and filter the vector subgraph G whose similarity exceeds the first threshold θ by setting the first threshold θ i The vector subgraphs that are screened out are called candidate subgraphs, which are stored in a candidate subgraph set. The candidate subgraphs in the candidate subgraph set are then subjected to the second stage of fine screening.

[0151] Phase 2: Structural consistency filtering. To further improve filtering accuracy, this phase uses a predefined template structure of "component-indicator-fault-repair" to perform refined structural matching on the candidate subgraphs in the candidate subgraph set.

[0152] (1) Predefined template structure

[0153] Define the standard template structure M standard , which is expressed as follows:

[0154] [Monitoring object]---has_metric--->[Indicator]---causes--->[Fault event]--do--->[Repair action]

[0155] Its formal representation is as follows:

[0156] Node combination: V M = {C, I, F, R}

[0157] Among them, C (Component) is the monitored component, I (Indicator) is the monitoring indicator, F (Fault) is the fault event, and R (Repair) is the repair operation.

[0158] Edge relationship set E M ={(C,I),(I,F),(F,R)}.

[0159] (2) Structural pattern extraction of candidate subgraphs

[0160] For the candidate subgraphs in the candidate subgraph set in the first stage, the subgraph structure is extracted by node and edge type classification. The structure of the candidate subgraph is represented as:

[0161] V Subgraph = {C, I, F, R}

[0162] E Subgraph={(C,I),(I,F),(F,R)}

[0163] (3) Matching score

[0164] The structure matching formula between the candidate subgraph structure and the predefined template structure is:

[0165]

[0166] A successful match is recorded as 1, otherwise 0; both relationship integrity and node integrity are considered, where: is the number of identical relations between the candidate subgraph structure and the predefined template structure, is the number of identical node types in the candidate subgraph structure and the template structure, is the total number of all nodes and edges in the predefined template structure (in this embodiment, 4 nodes + 3 edges = 7).

[0167] The structural matching score of each candidate subgraph is obtained based on the structural matching formula, and then the structural matching score is compared with the second threshold θ struct To compare:

[0168]

[0169] The final sub-graph set is thus obtained through fine screening. The final sub-graph set is the sub-graph information corresponding to the fault information.

[0170] This method effectively reduces false positives and significantly improves the accuracy of maintenance / fault knowledge graph retrieval through a combination of semantic initial screening (Phase 1) and structural refinement (Phase 2). Furthermore, based on template structure matching, it clearly defines the structure of the event chain, ensuring the logic and causality of fault diagnosis and laying the foundation for subsequent automated troubleshooting. This mechanism is particularly suitable for highly complex maintenance and diagnostic scenarios, effectively reducing redundant subgraph retrieval and improving system response efficiency and user experience.

[0171] (III) Prompt word construction module and reasoning generation module (corresponding to Figure 1 "Cue Word Construction and Inference Generation" in

[0172] The reasoning generation module reorganizes the final subgraph set based on semantic fusion. During the Large Language Model (LLM) training process, a portion of the training data already relates to operations and maintenance. This phase ensures the use of external knowledge while avoiding over-reliance on search results, retaining the LLM's own parameterized operations and maintenance knowledge, and leveraging its reasoning advantages.

[0173] The reorganization is based on a Logits-Based Integration strategy. To balance external knowledge with the reasoning capabilities of the large language model (LLM), a Logits-Based Integration strategy is adopted. Specifically, the output Logits of the LLM (in this case, the distilled DistilQwen2.5-7b, i.e., the LLM with 2.5, 7 parameters) are obtained separately without external knowledge and in combination with the retrieved subgraph information. The final response text is generated through a weighted fusion of these two Logits.

[0174] The prompt word construction module provides the reasoning generation module with a structured natural language prompt segment obtained by processing the fault information. In this application, the structured natural language prompt segment includes a first prompt segment and a second prompt segment.

[0175] (1) Input the fault information into the prompt word (Prompt) construction module to obtain the first prompt segment Prompt query , the first prompt fragment Prompt query Input into the large language model to get the first output Logits LLM The first output Logits LLM No additional external knowledge is included, only LLM itself is inferred: Logits LLM =LLM DistilQwen (Prompt query ).

[0176] (2) Input the fault information and subgraph information (such as event chain path) retrieved from the operation and maintenance / fault knowledge graph into the prompt word construction module to obtain the second prompt fragment Prompt combined . Second prompt fragment Prompt combined Input into the large language model to get the second output Logits KG Therefore, the second output Logits KG Prompt reasoning is obtained by combining the subgraph information retrieved from the two-stage operation and maintenance / fault knowledge graph: combined =Prompt query +Prompt Retrieved_Subgraph

[0177] Logits KG =LLM DistilQwen (Prompt combined ).

[0178] (3) Logits weighted fusion strategy: Based on the weighted fusion formula, the first output Logits LLM and the second output Logits KGPerform weighted fusion to obtain the fusion output.

[0179] Weighted Fusion Formula: Logits final =α·Logits KG + (1-α) Logits LLM

[0180] Among them, Logits final is the fusion output, and α is the weight coefficient.

[0181] The weight coefficient α determines the degree of influence of external knowledge. The closer α is to 1, the stronger the influence of external knowledge. The closer α is to 0, the more dominant the LLM's own reasoning is. Among them, the present invention supports two ways to set α: dynamic method and static method. The static method is to manually set it to a value between [0,1]. The dynamic method adaptively sets α according to the semantic relevance between the query question and the subgraph. That is, the higher the relevance of the retrieved content, the more valuable the retrieved subgraph is. Then the second output Logits KG The higher the weight,

[0182] The dynamic formula of the dynamic method is: α=Sigmoid(β·Sim(Q,G best )-γ)

[0183] Among them, Sim (Q, G best ) is the query vector Q and the most relevant vector subgraph G retrieved best The cosine similarity of ; Sim is the cosine function; β and γ are training parameters; Sigmoid is used to constrain α to [0,1].

[0184]

[0185] (4) Text generation based on fusion output

[0186] Using fusion output Logits final Perform text generation and use Softmax to obtain probability distribution to obtain the final response text.

[0187]

[0188] in, is the output probability of the kth word (token) in the generated response.

[0189]

[0190] Then generate the final response text based on the maximum output probability path of each word (token) , final response text This is the fault analysis result.

[0191] The proposed fusion output is highly controllable, enabling precise control of the influence of external knowledge and the LLM's own reasoning through a weight parameter α. This weight parameter α is adaptively adjusted based on semantic relevance, effectively improving generation quality while also achieving a better balance between accuracy and generalization: external knowledge enhances accuracy, while leveraging the LLM's inherent reasoning capabilities ensures generalization, achieving a fusion strategy that balances both.

[0192] (IV) Process parsing module and process execution module (corresponding to Figure 1 "Process Parsing and Process Execution")

[0193] The process parsing module aims to automatically and accurately convert the final response text (fault analysis results) generated by the Large Language Model (LLM) based on operation / fault knowledge graph retrieval (including event chain construction and dynamic update mechanisms), two-stage graph search and filtering, and Logits fusion strategies into an executable structured task flow. The task flow, through the process execution module, calls underlying operation and maintenance interfaces (such as automated scripting platforms and remote command systems) to achieve closed-loop fault handling. The process parsing module receives the fault analysis results (including fault diagnosis, remediation suggestions, and operation steps) from the reasoning generation module, automatically parses them, and then outputs them in structured natural language. It constructs a directed acyclic graph (DAG) for task execution and automatically maps it to predefined operation and maintenance templates to improve automation, generalization, and task execution efficiency. The process parsing module supports manual confirmation of key tasks to ensure system security and feeds processing results back to the operation / fault knowledge graph, enabling the accumulation and traceability of operation and maintenance knowledge.

[0194] The basic principles of the process parsing module can be divided into the following three stages:

[0195] a. Conversion from natural language to task graph (DAG)

[0196] In this stage, a dedicated natural language task parser is designed to automatically parse the fault analysis results (including diagnosis, repair suggestions, and operation steps) generated by LLM into clearly structured task nodes and DAG graphs.

[0197] (1) Text structured parsing (based on lightweight parser)

[0198] Leverage templates and lightweight natural language task parsers (e.g., regular expressions, pattern matching, or lightweight RNN parsers) to extract explicit task information from the fault analysis results generated by LLM, including:

[0199] Task node: specifies the task type, such as alarm confirmation, service restart, configuration update, and script call.

[0200] Input parameters: including host name, IP address, component name, service name, operation instructions, parameter values, etc.

[0201] Dependencies: Identify clear sequential dependencies between tasks (for example, "restart the database first, then restore service").

[0202] (2) Constructing a task graph

[0203] Based on the extracted task nodes and dependencies, a complete directed acyclic graph (DAG) is constructed to clearly represent the execution order and logical relationship between tasks.

[0204] b. Automatic mapping and execution scheduling of task flows

[0205] This phase automatically maps task nodes to predefined operation and maintenance templates to transform the DAG into an executable structured task flow:

[0206] (1) Predefined Operation Template

[0207] The system pre-defined operation and maintenance templates clearly define the underlying execution method for each task type: for example:

[0208] Service restart: → systemctl restart {service name}

[0209] Configuration modification: → Call API to modify configuration items

[0210] Alarm confirmation: → Alarm management platform API confirmation

[0211] Execute the repair script: → Call Bash / Python script

[0212] Template example:

[0213] templates:

[0214] - task_type: service_restart

[0215] cmmmand: “systemctl restart {service_name}”

[0216] - task_type: config_update

[0217] api_call: "POST / api / config / update"

[0218] - task_type: alert_confirm

[0219] api_call: "POST / api / alert / confirm"

[0220] - task_type: run_script

[0221] cmmmand: " / scripts / {script_name}.sh{params}"

[0222] (2) Automatic mapping of task nodes and instruction generation

[0223] Based on the automatic mapping of task node information and operation and maintenance operation templates, the underlying executable instructions or API calls are dynamically generated to form a complete task execution instruction sequence (i.e., a structured task flow).

[0224] (3) Process execution module execution feedback and knowledge graph write-back mechanism

[0225] The process execution module (execution engine) calls relevant scripts to implement automated closed-loop knowledge accumulation for fault handling. After execution, the alarm status and fault closed-loop information are automatically updated. After confirmation by the operation and maintenance engineer, the operation path is recorded in the operation and maintenance / fault knowledge graph to form an event chain for rapid location and recommendation of similar faults next time.

[0226] (1) Automatically update status and closed-loop information: After successful execution, the relevant status is automatically updated to "resolved". After the engineer confirms, it is updated to "confirmed". Clearly record the execution path, operation details and results of this task.

[0227] (2) Operation and maintenance / fault knowledge graph writing back: After confirmation by the operation and maintenance engineer, the executed task nodes and execution paths are written back to the operation and maintenance / fault knowledge graph, and added as a closed-loop event chain subgraph.

[0228] The task parsing and orchestration method proposed in this paper boasts a high degree of automation. Through a parser and automatic task mapping mechanism, it efficiently executes fault handling tasks without manual intervention. The method also boasts strong generalization capabilities and, through O&M operation templates and automatic mapping logic, is widely applicable to diverse fault types and O&M scenarios. This method also establishes a closed-loop knowledge accumulation loop, allowing execution results to be written back into the O&M / fault knowledge graph, forming a closed-loop knowledge base and continuously improving O&M efficiency.

[0229] The graph retrieval enhancement module of the present invention structures the fault information input by the current system (such as "component = DAMO database, event = connection failure, indicator = connection_count = 0"), retrieves relevant subgraphs in the operation and maintenance / fault knowledge graph, and uses a two-stage knowledge filtering mechanism (semantic retrieval + structural filtering) to remove irrelevant and redundant subgraphs, retaining only content with high contextual relevance. The retrieval results are then converted into structured prompt templates and input into the locally deployed large language model to generate natural language questions and answers or process suggestions. The key mechanisms for graph retrieval and generation include: using GraphSAGE+TransE as a graph embedding model to calculate the semantic distance between the query statement and the subgraph; introducing a two-stage filtering mechanism in the graph retrieval process to perform screening based on cosine similarity and graph structure matching; using structured templates to construct prompt input with semantic paths; using the Logits fusion mechanism to balance the model's native reasoning ability and the effect of external knowledge injection; and the model generation process is implemented using the locally deployed DistilQwen2.5-7B.

[0230] The process parsing module of this invention parses the natural language output generated by the large language model into a structured task flow, which is then automatically executed through an execution engine (such as Ansible or a custom command scheduler). For sensitive operations involving core components, the system supports approval processes and manual confirmation mechanisms to ensure operational controllability and security. After execution is complete, the system writes the entire process path, including fault information, operation procedures, and recovery results, back to the operation and maintenance / fault knowledge graph, forming a high-value subgraph for subsequent matching and recommendation.

[0231] The present invention further clarifies the knowledge write-back mechanism after the system executes the task, forming a closed-loop knowledge precipitation and reuse of "fault-operation-result", highlighting that this is different from the one-way processing method of existing solutions.

[0232] In the embodiments of the present invention, the overall solution has the following technical advantages in terms of technical implementation:

[0233] High Customizability:

[0234] A semantic ontology is built around the domestic software and hardware ecosystem, supporting the modeling of components on multiple platforms such as Feiteng, Loongson, Kylin, and DAMO, and capable of cross-platform fault semantic integration. Combining the domestic software and hardware deployment structure, service topology, and operation and maintenance semantic characteristics, a multi-level, highly consistent operation and maintenance / fault knowledge graph is customized to ensure that the graph structure is reasonable and scalable, and meets the actual needs of the domestic operation and maintenance environment.

[0235] Strong semantic relevance and high retrieval accuracy:

[0236] The present invention adopts a two-stage knowledge filtering mechanism, first calculating semantic similarity, and then filtering noisy subgraphs based on structural path matching; finally, only graph structures with high contextual relevance are retained to construct Prompt, greatly improving the pertinence, accuracy and interpretability of the output content of large language models.

[0237] High inference efficiency and low computing power requirements:

[0238] This paper selects a combination of lightweight graph embedding models (TransE for relationship modeling, GraphSAGE supports neighbor aggregation), and adopts the domestically produced large language model DistilQwen2.5-7b as the inference engine. After optimization based on INT4 quantization deployment, the graphics memory requirement does not exceed 8GB. It can run stably under the Feiteng / Kunpeng / ARM architecture, meeting the needs of edge computing and private deployment scenarios.

[0239] Strong process automation and closed-loop execution capabilities:

[0240] The output of the large language model is converted into a structured task flow through semantic analysis. Combined with standardized operation and maintenance operation templates, it automatically triggers a complete processing flow including network diagnosis, service restart, indicator inspection, etc. The system supports manual confirmation mechanism and task execution feedback written back to the operation and maintenance / fault knowledge graph, building a "fault-operation-result" knowledge closed loop, improving the intelligent operation and maintenance and knowledge reuse capabilities.

[0241] Modules are pluggable and the system is evolvable:

[0242] The system architecture adopts a modular design, and the construction of operation and maintenance / fault knowledge graphs, graph retrieval and large language model calls are decoupled from each other, which can be flexibly adapted to existing operation and maintenance platforms (such as log alarm systems and task scheduling systems); the graph content supports continuous learning and dynamic updates, and the model prompts can be iteratively evolved to achieve continuous enhancement of fault identification and processing capabilities.

[0243] The execution method of the graph retrieval enhancement system includes the following steps:

[0244] Step S1: Input the fault information of the fault event into the graph retrieval enhancement system; the fault information includes host IP, component type, fault phenomenon, related indicators, etc.

[0245] Step S2: The graph construction and update module standardizes the fields of fault information, performs entity recognition and semantic mapping based on the ontology model, and generates triples. The triples are then written into the operation and maintenance / fault knowledge graph, and the operation and maintenance / fault knowledge graph update strategy is executed to maintain historical versions and event chains.

[0246] Step S3: Input the fault information into the graph retrieval enhancement module for filtering and retrieval. The graph retrieval enhancement module performs a two-stage filtering and retrieval based on the operation and maintenance / fault knowledge graph to screen out the subgraph information corresponding to the fault information. Specifically, step S3 includes the following steps:

[0247] Step S31: The graph retrieval enhancement module constructs the fault information into a graph-structured query statement, and then uses the graph embedding model to convert the graph-structured query statement into a structured query vector;

[0248] Step S32: The graph retrieval enhancement module uses the graph embedding model to convert the predefined subgraphs in the operation and maintenance / fault knowledge graph into structured vector subgraphs;

[0249] Step S33: The graph retrieval enhancement module calculates the semantic similarity between the structured query vector and the structured vector subgraph based on the semantic similarity formula, and performs preliminary screening of the structured vector subgraph based on a first threshold to obtain candidate subgraphs, which are stored in a candidate subgraph set.

[0250] Step S34: extracting structural patterns from the candidate subgraphs in the candidate subgraph set to obtain the structure of each candidate subgraph;

[0251] Step S35: Structural matching scores are performed on the structures of each candidate subgraph and the predefined template structure based on the structural matching formula, and the candidate subgraphs in the candidate subgraph set are finely screened based on the second threshold to obtain the final subgraph set; the final subgraph set is the subgraph information corresponding to the fault information.

[0252] Step S4: The prompt word construction module converts the fault information and the filtered subgraph information into a structured natural language prompt segment (for example, "The number of connections to the DAMO database on host A is 0, and the historical processing path is restarting the connection pool"). The structured language prompt segment includes a first prompt segment and a second prompt segment. The first prompt segment is generated by the prompt word construction module based on the fault information, and the second prompt segment is generated by the prompt word construction module based on the fault information and subgraph information.

[0253] Step S5: The reasoning generation module uses a large language model (DistilQwen 2.5-7b) to perform natural language question answering based on structured natural language prompts, generating fault analysis results. These results include fault analysis, possible causes, task flow recommendations, and links to source text retrieved from the O&M / fault knowledge graph. The specific implementation steps for this step are as follows:

[0254] Step S51: The inference generation module inputs the first prompt segment into the large language model to obtain the first output; Step S52: The inference generation module inputs the second prompt segment into the large language model to obtain the second output; Step S53: The inference generation module performs weighted fusion on the first output and the second output to obtain a fused output; Step S54: The inference generation module generates text from the fused output and uses Softmax to obtain the probability distribution to obtain the final response text; the final response text is the fault analysis result.

[0255] Step S6: The process analysis module parses the fault analysis results generated by the large language model into a structured task flow (including operation instructions, execution order, dependencies, and other information), identifies high-risk operations in the structured task flow, and determines whether high-risk operations require user confirmation.

[0256] Step S6 includes the following steps:

[0257] Step S61: The process analysis module inputs the fault analysis results into the natural language task parser to extract task information;

[0258] Step S62: The process analysis module constructs a directed acyclic graph based on the extracted task information;

[0259] Step S63: The process analysis module converts the directed acyclic graph into a structured task flow, identifies high-risk operations in the structured task flow, and determines whether the high-risk operations require user confirmation.

[0260] Step S7: The process execution module (execution engine) calls the corresponding scripts (such as ping, restarting services, and checking indicators) in sequence to schedule and execute the structured task flow, thereby completing the actual operation and maintenance processing; during this period, the execution status, error code, and result information are recorded in real time.

[0261] Step S8: After the process execution module is completed, the graph retrieval enhancement system writes back the entire process of "fault input - reasoning analysis - operation execution - recovery result" to the operation and maintenance / fault knowledge graph as a reusable knowledge path for matching similar fault events next time.

[0262] Step S9: If the image retrieval enhancement system receives new fault information, it returns to step S1 and restarts the processing flow; if there is no input, it enters the standby state.

[0263] The present invention has the ability of automated closed-loop task execution and generalization. Through a specially designed natural language task parser, the present invention automatically parses the text results generated by the large language model into clear task nodes and task graphs, and automatically maps them to predefined operation and maintenance templates to achieve automatic scheduling and execution. It has dynamic response capabilities and multi-step operation and maintenance operation generalization capabilities that are significantly higher than traditional static template recommendation methods.

[0264] The present invention has a sustainable self-evolving knowledge closed-loop mechanism. The system automatically writes the task execution process and results back to the operation and maintenance / fault knowledge graph after manual confirmation, forming a closed-loop knowledge chain with a "fault-operation-result" structure, realizing the sedimentation and continuous reuse of operation and maintenance experience, and ensuring that the operation and maintenance / fault knowledge graph and the level of operation and maintenance intelligence can continue to improve over time.

[0265] This invention has the advantages of deployment and adaptation on low-computing power domestic platforms, realizes INT4 quantization deployment of lightweight large language models (DistilQwen2.5-7B), controls video memory overhead within 4GB, and ensures stable and efficient operation on domestic CPU platforms such as Feiteng, Kunpeng, and Haiguang and edge computing environments. It has strong environmental adaptability, engineering practicality and scalability, significantly reduces deployment costs, and meets the actual deployment needs of domestic software and hardware environments.

[0266] Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

Claims

1. The execution method of the large model graph retrieval enhancement system for software and hardware monitoring and operation maintenance is characterized by: The graph retrieval enhancement system includes a graph construction and update module, a graph retrieval enhancement module, a prompt word construction module, an inference generation module, a process parsing module, and a process execution module. The graph construction and update module is used to construct and update the operation and maintenance / fault knowledge graph. The graph retrieval enhancement system is used to execute and process the fault information of the fault event; The execution method of the graph retrieval enhancement system includes the following steps: Step S1: inputting fault information of a fault event into the graph retrieval enhancement system; Step S2: The graph construction and update module receives and processes the fault information of the fault event, generates triples, writes the triples into the operation and maintenance / fault knowledge graph, and updates the operation and maintenance / fault knowledge graph; Step S3: Input the fault information into the graph retrieval enhancement module; the graph retrieval enhancement module performs a two-stage filtering search based on the operation and maintenance / fault knowledge graph to filter out the subgraph information corresponding to the fault information; Step S4: The prompt word construction module converts the fault information and the filtered sub-graph information into a structured natural language prompt segment; Step S5: The inference generation module calls the large language model and combines the structured natural language prompt fragments to perform natural language question answering and generate fault analysis results; Step S3 includes the following steps: Step S31: The graph retrieval enhancement module constructs the fault information into a graph-structured query statement, and then uses the graph embedding model to convert the graph-structured query statement into a structured query vector; Step S32: The graph retrieval enhancement module converts the predefined subgraph in the operation and maintenance / fault knowledge graph into a structured vector subgraph; Step S33: The graph retrieval enhancement module calculates the semantic similarity between the structured query vector and the structured vector subgraph based on the semantic similarity formula, and preliminarily screens the structured vector subgraph based on the first threshold to obtain candidate subgraphs, and stores the candidate subgraphs in a candidate subgraph set; Step S34: extracting structural patterns from the candidate subgraphs in the candidate subgraph set to obtain the structure of each candidate subgraph; Step S35: Structural matching scores are performed on the structures of each candidate subgraph and the predefined template structure based on the structural matching formula, and fine screening is performed based on the second threshold to obtain a final subgraph set; the final subgraph set is the subgraph information corresponding to the fault information.

2. The execution method of the large model graph retrieval enhancement system for software and hardware monitoring and operation according to claim 1 is characterized in that: The graph retrieval enhancement system further includes a process analysis module and a process execution module; the execution method further includes steps S6 and S7; Step S6: The process parsing module parses the fault analysis results generated by the large language model into a structured task flow; Step S7: The process execution module calls the corresponding scripts in sequence to schedule and execute the structured task flow, and records the execution results.

3. The execution method of the large model graph retrieval enhancement system for software and hardware monitoring and operation according to claim 2 is characterized in that: The graph construction and update module builds an operation and maintenance / fault knowledge graph based on the ontology model. The ontology model is based on the semantic relationship modeling between software and hardware components, fault time, monitoring indicators, and operation and maintenance actions in the IT system. The ontology model can be divided into entities, relationships, and attributes. The process of constructing an operation and maintenance / fault knowledge graph based on the ontology model is as follows: the original data in the unstructured knowledge base is subjected to field standardization processing, and then the original data after field standardization processing is input into the ontology model for entity recognition and semantic mapping to obtain the operation and maintenance / fault knowledge graph.

4. The execution method of the large-scale graph retrieval enhancement system for software and hardware monitoring and operation according to claim 1 is characterized in that: In step S4, the structured language prompt segment includes a first prompt segment and a second prompt segment, the first prompt segment is generated by the prompt word construction module based on the fault information, and the second prompt segment is generated by the prompt word construction module based on the fault information and the sub-graph information; Step S5 includes the following steps: Step S51: The inference generation module inputs the first prompt segment into the large language model to obtain a first output; Step S52: the inference generation module inputs the second prompt segment into the large language model to obtain a second output; Step S53: The inference generation module performs weighted fusion on the first output and the second output to obtain a fused output; Step S54: The inference generation module generates text based on the fusion output and uses Softmax to obtain the probability distribution to obtain the final response text; the final response text is the fault analysis result.

5. The execution method of the large-scale graph retrieval enhancement system for software and hardware monitoring and operation according to claim 4 is characterized in that: In step S53, the inference generation module performs weighted fusion on the first output and the second output based on the weighted fusion formula to obtain a fusion output; The weighted fusion formula is: Logits final =α·Logits KG + (1-α) Logits LLM ; Among them, Logits final is the fusion output, α is the weight coefficient, Logits KG For the second output, Logits LLM is the first output.

6. The execution method of the large model graph retrieval enhancement system for software and hardware monitoring and operation according to claim 5 is characterized in that: The value of α is set based on the static method or the dynamic method; the value of α is between [0,1].

7. The execution method of the large model graph retrieval enhancement system for software and hardware monitoring and operation according to claim 6 is characterized in that: The static method refers to presetting the value of α; The dynamic method refers to calculating the value of α based on the dynamic formula; The dynamic formula is: α=Sigmoid(β·Sim(Q,G best )-c); Among them, Sim (Q, G best ) is the query vector Q and the most relevant vector subgraph G best The cosine similarity of ; β and γ are training parameters; Sigmoid is used to constrain the value of α to be between [0,1].

8. The execution method of the large-scale graph retrieval enhancement system for software and hardware monitoring and operation according to claim 2 is characterized in that: Step S6 includes the following steps: Step S61: The process analysis module inputs the fault analysis results into the natural language task parser to extract task information; Step S62: The process analysis module constructs a directed acyclic graph based on the extracted task information; Step S63: The process parsing module converts the directed acyclic graph into a structured task flow.

Images