System and method for query processing engine based on knowledge graph data structure

By introducing a knowledge graph-based query processing engine and GCN/LLM technology into the event management system, the problems of computing limitations and semantic analysis difficulties in the process of event diagnosis and resolution in the prior art are solved, and an efficient and automated event management process is achieved.

CN119808925APending Publication Date: 2025-04-11HSBC SOFTWARE DEV (GUANGDONG) LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411999831.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-31
Publication Date
2025-04-11

AI Technical Summary

Technical Problem

The prior art has limitations in the calculation process and difficulty in semantic analysis in the process of event diagnosis and resolution, making it difficult to effectively collect and organize relevant data, resulting in inefficient event management.

Method used

Using a knowledge graph-based query processing engine, combined with graph convolutional network (GCN) and large language model (LLM), an efficient event management system is built through natural language processing and graph search technology to achieve automation and acceleration of event diagnosis, resolution and post-review.

Benefits of technology

Improves the efficiency and accuracy of the event management process, reduces the time for manual intervention and data integration, can quickly generate solution suggestions, and improves service quality maintenance capabilities.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119808925A_ABST
    Figure CN119808925A_ABST
Patent Text Reader

Abstract

The present invention proposes an improved method based on computer learning that utilizes a combination of a graph convolutional network and natural language processing (NLP) to process a knowledge graph to effectively organize event and service data. The proposed method includes training learnable parameters of a graphical convolutional network (GCN), and deploying the GCN to update a knowledge graph for label estimation. A synthetic question and answer (QA) workflow pipeline process based on the generated knowledge graph may be used for downstream processes to generate suggestions that represent the most effective response to the event estimated by the machine learning model.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to a computer architecture based on machine learning / artificial intelligence for updating knowledge graphs, and in particular to a system and method for a query processing engine based on a proposed knowledge graph data structure. Background Art

[0002] Maintaining uninterrupted service and minimizing unexpected events that could affect service quality is critical to businesses, especially those that provide computer-implemented online services. Effective incident management practices can help resolve incidents with minimal disruption, making the business better prepared for future incidents. Summary of the invention

[0003] The present invention proposes an improved knowledge graph-based query processing engine and a corresponding system and method. The query processing engine can be integrated into a backend infrastructure management computer system configured to process an information technology (IT) service event management workflow that uses artificial intelligence (AI) and machine learning (ML) methods to computationally accelerate event diagnosis and resolution. The proposed method computationally enhances three steps in the event management process: event diagnosis, event resolution, and post-event review. The method can also be used in other similar scenarios, such as a system configured to process customer service inquiries, such as a customer service question-and-answer system that generates suggested responses for responding to inquiries.

[0004] The computational components in the query processing engine collaborate with each other to process the large amount of service and event data generated by multiple coupled IT infrastructure components. Improved knowledge graph data structure objects are instantiated and populated for implementing efficient computational search algorithms and machine learning methods to calculate insights for incoming events and generate resolution recommendations.

[0005] The present invention proposes a variant of a computer system for IT service incident management, including incident overview, incident root cause location and solution recommendations. The system includes a specially configured knowledge graph (KG), which serves as a basic element for data storage and provides a foundation for all upper-level functions. The KG query engine can support low-level and high-level APIs to achieve efficient or even zero-code graph queries. The KG query engine can be used in conjunction with a root cause location module based on a graph convolutional network (GCN) (which uses the abnormal severity of performance indicator data for troubleshooting) and a question-answering module based on a large language model (LLM). The question-answering module is configured to generate incident solutions using historical event data by utilizing retrieval-augmented generation (RAG) technology.

[0006] The present invention proposes a root cause analysis module based on specific tracking, which uses a metric-based GCN, trained with node classification, and is able to estimate the problem services in the service chain through calculation. The metric data is collected and obtained from the runtime monitoring platform, including the mean and standard deviation of each feature in the normal state of the service. After the event occurs, the method includes comparing the current metric value with the respective long-term value and evaluating the degree to which each feature deviates from its normal value.

[0007] The GCN proposed in the present invention can use different architectures. GCN can be provided as a stack of graph convolutional layers (>=1 layer). In a specific embodiment, GCN uses a single graph convolutional layer for training and reasoning. In a variant, GCN can have multiple layers.

[0008] For node classification tasks, especially anomaly service detection, a GCN model with one or more stacks can be used to control how many n-hop neighbors (e.g., upstream / downstream neighbor nodes) of a given service node are used in the update. GCN accepts a graph as input, loads features into nodes and edges, and progressively updates these states using each graph convolutional layer. The output of GCN is a graph with the final state of the classification result.

[0009] During the training process in some embodiments, a multi-layer stack may be used to iteratively update the knowledge graph node labels and output an updated knowledge graph after training. The training process may be used with a snapshot data object (e.g., a tuple) of the service knowledge graph during an event, which includes a service for monitoring metric information. The parameters of the output function may be modified using backpropagation and / or gradient descent. A specific update function may be used to define how each node "updates" its state - inputting the previous state of its neighbors and itself, and outputting the current state of the node.

[0010] The updated knowledge graph can be kept static and applied to generate estimated output labels for nodes based on the currently input problem data. During the reasoning process in some embodiments, the GCN parameters are fixed and provided with real metric data. The system generates node classification predictions indicating whether each service node has a problem. In some embodiments, during the reasoning process, the method uses only one hidden layer GCN model. This requires aggregating information only from one-hop neighbors (i.e., the direct upstream or downstream services of the service node).

[0011] After training the GCN, the LLM-based question-answering computation engine / computation module can use the output graph to generate string outputs corresponding to potential event resolution outputs.

[0012] The above has been quite extensively summarized the features and technical advantages of the present invention so that the following detailed description can be better understood. Other features and advantages will be described below. It will be appreciated by those skilled in the art that the disclosed concepts and specific embodiments can be easily used as a basis for modifying or designing other structures. It will also be appreciated by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the embodiments described herein. The specific description of the combination and method of operation of the present invention hereinafter can be better understood by combining the accompanying drawings. However, it should be clearly understood that each of the accompanying drawings is only used for illustration and description and does not define the limits of the embodiments herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more fully understand the methods and apparatus disclosed herein, reference will now be made to the accompanying drawings which illustrate embodiments in more detail, wherein:

[0014] Figure 1 A flow diagram is shown that illustrates an example incident management process in some embodiments.

[0015] Figure 2 A set of example components that may be used to provide the proposed AI-driven IT service incident management system in some embodiments is shown.

[0016] Figure 3 A graph schema of a knowledge graph data object schema in some embodiments is shown.

[0017] Figure 4 Depicted are example interconnected computing components of a knowledge graph query engine in some embodiments.

[0018] Figure 5A , Figure 5B and Figure 5C An example method for root cause analysis based on GCN in some embodiments is shown. Figure 5A An example of a service dependent network is shown; Figure 5B An example of different layers of a GCN is shown; Figure 5C An example of a GCN model for a checkout node is shown.

[0019] Figure 6 An example flow of a question and answer (QA) module in some embodiments is shown.

[0020] The drawings are not necessarily drawn to scale. The disclosed embodiments are sometimes shown in diagrammatic and partial views. In some cases, details that are not necessary for understanding the disclosed methods and apparatuses or details that make other details difficult to understand may be omitted. The disclosure herein is not limited to the specific embodiments shown herein. DETAILED DESCRIPTION

[0021] Incident management is a process used by IT operations and DevOps teams to respond to and resolve unexpected events that may affect service quality or service operations. Incident management aims to identify and correct problems while maintaining normal services and minimizing the impact on the business. Organizations establish incident management processes that outline a predefined sequence of actions for response teams. The main stages involve incident diagnosis and resolution. These steps require convening relevant IT teams and conducting multiple rounds of meetings, which are labor-intensive and time-consuming. IT operations teams rely on their expertise (stored in knowledge bases such as Confluence or even in their heads) to come up with potential causes and actionable insights.

[0022] Considering the multitude of DevOps platforms available, such as AppDynamics, Splunk, xMatters, and ServiceNow, an organization may have a large amount of data. This data preserves the history of previous incidents, including relevant logs and monitored metrics. This data is the knowledge required for incident diagnosis and resolution. While historical records have great value in enhancing incident management strategies, the process of effectively collecting and organizing relevant data can be challenging due to limitations in computing processes and problems with semantic parsing. For example, data may be scattered and stored on various platforms, making it difficult to track and integrate.

[0023] Therefore, this paper proposes an improved method that utilizes natural language processing (NLP) mechanisms (including knowledge graph data structures) combined with an improved computing system configured to effectively organize incident and service data. By utilizing techniques such as large language models (LLMs) for data processing, the system can be configured to establish a comprehensive question answering (QA) workflow process based on the generated knowledge graph data structure, which can be used in downstream processes to generate computationally estimated resolution suggestions that represent the most effective responses estimated by the machine learning model based on historical data, which helps to speed up incident resolution.

[0024] The GCN model is trained for node classification, so that problems in the service chain can be identified. GCN is used to iteratively generate updates for node classification. GCN is a stack of graph convolutional layers, which is updated based on the proposed update function. Once the graph network iteration is completed, the trained GCN is output, which can be used as a QA module for processing queries. GCN is used to predict which node has problems during reasoning. GCN can use different numbers of graph convolutional layers, and the number of layers can be an adjustable hyperparameter to adjust for different application scenarios. In some embodiments, the number of graph convolutional layers controls how many "jumps" the system uses for node classification. The number of layers can be various different numbers, such as 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 or more. However, as the number of layers increases, the computational complexity will also increase accordingly. The GCN proposed in the present invention can use different architectures. GCN can be provided as a stack of graph convolutional layers (>=1 layer). In a specific embodiment, GCN uses a single graph convolutional layer for training and reasoning. In a variant, GCN can have multiple layers.

[0025] The updated knowledge graph can be kept static and applied to generate estimated output labels for nodes based on the currently input problem data. During the reasoning process in some embodiments, the GCN parameters are fixed and provided with real metric data. The system generates node classification predictions indicating whether each service node has a problem. In some embodiments, during the reasoning process, the method uses only one hidden layer GCN model. This requires aggregating information only from one-hop neighbors (i.e., the direct upstream or downstream services of the service node).

[0026] While the example embodiments described herein describe exemplary practical use cases in software development and managing computing infrastructure, these embodiments are not limiting and contemplate applications in other fields. For example, the method can be used with graph convolutional networks to identify problems in automotive manufacturing or other heavy manufacturing, or for debugging activities and other processes that may require modeling of various dependencies.

[0027] For financial institutions, incident management is critical to ensure reliable banking services, and the proposed machine learning / AI incident management system can be used to speed up incident diagnosis and resolution based on the historical records of previous incidents. The first process step includes implementing a knowledge graph to effectively organize service and incident-related data from multiple platforms and data storage devices (such as DevOps platforms). To facilitate the construction of the knowledge graph data structure, a trained LLM is used for named entity recognition (NER) and relation extraction (RE). In addition, the system is configured to utilize LLM for natural language-based queries on the knowledge graph, and the queries use NL2Cypher technology.

[0028] The second process step is based on root cause location using a specialized data model architecture built on service chains that describe the dependencies between services. By analyzing the traces that record the before and after relationships of each service call, the trained model combines the metrics data from the monitoring system to predict potential problem services.

[0029] The third process step utilizes the proposed question answering (QA) system, which operates using a knowledge graph data structure (e.g., a DevOps data structure). This system can leverage the Retrieval Augmented Generation (RAG) technique to enhance the generation capabilities of the LLM. The approach uses both semantic search based on event text descriptions and graph search based on event relationships to leverage the retrieval component of the RAG technique. The knowledge graph data structure used to organize the data naturally facilitates this graph-based search approach.

[0030] All three processes work closely together to expedite the incident management process.

[0031] Figure 1 is a flow chart illustrating an example event management process.

[0032] Flowchart 100 illustrates an example incident management process that covers several key phases: fault detection, mobilization, incident diagnosis, service restoration, incident resolution, and post-incident review.

[0033] The fault detection step is shown at 102. This initial phase involves detecting faults or events within the IT infrastructure or services. Various monitoring tools and systems are used to identify any anomalies or deviations from expected performance.

[0034] The mobilization step is shown at 104. Once a failure is detected, an incident response team is immediately mobilized. The team consists of personnel with the expertise and skills required to effectively resolve the incident.

[0035] The incident diagnosis and service recovery step is shown at 108. In this phase, the response team focuses on diagnosing the root cause of the incident. The response team collects relevant information, analyzes system logs, and employs various troubleshooting techniques to pinpoint the underlying problem.

[0036] After the root cause is determined, the service recovery step restores the affected service to a normal operating state. This may involve implementing temporary workarounds, deploying backups, or leveraging redundancy mechanisms to minimize the impact on service availability.

[0037] The incident resolution step is shown at 110. After service is restored, the incident resolution phase involves implementing a permanent fix or solution to prevent similar incidents from happening again in the future. This may include software patches, configuration changes, or infrastructure upgrades.

[0038] The post-incident review step is shown at 112. After the incident is resolved, a comprehensive review is conducted to evaluate the overall incident response process. This phase involves analyzing the incident management process, identifying any areas for improvement, and implementing corrective actions or best practices to enhance future incident handling.

[0039] Figure 2 A set of example components that may be used to provide the proposed AI-driven IT service incident management system in some embodiments is shown. An architectural diagram 200 of the AI-driven IT service incident management system shows a number of different layers: data sources 202 , core components 204 , and applications 206 .

[0040] 202 enables event management to provide a data source of valuable information. It is important to note that this framework is not limited to any specific software or platform. As long as the IT management software covers the following data, it can be seamlessly integrated into the system.

[0041] This data can include application performance monitoring data. This data captures real-time information about the operational status of the service. In the proposed example implementation, AppDynamics can be used to collect and analyze the data. Log data is used to extract service-related information from logging systems such as Splunk. This data helps understand the behavior and performance of the service. Workflow management data includes incident records and post-incident reviews (PIRs), which contain valuable root cause analysis. These records can be stored in the ServiceNow system. In addition, some teams may manage PIR records in Confluence pages, which can be integrated into the system. External knowledge bases can be used to import external knowledge (such as StackOverflow) into the system. This additional source of information can enrich the incident management process by providing a wider range of insights and solutions.

[0042] 204 constitutes the core component of the proposed system and may include components including a knowledge graph (KG). A knowledge graph (KG) is a key data object / component that acts as a centralized knowledge base containing all information extracted from underlying data sources. The knowledge graph acts as an operational cornerstone, supporting various applications at the upper layer. Included in the core component is a knowledge graph query engine to facilitate seamless data retrieval and exploration within the knowledge graph. The engine can efficiently and effectively query the graph structure data model of the knowledge graph. Also included in the core component is a GCN-based root cause location module that leverages the implicit topology information embedded in the metrics monitored in AppDynamics and the dependency graph to predict services that may have problems. Also included in the core component is a question-and-answer module that provides a core component for generating incident solutions, which is built on LLM using RAG workflows. The retrieval component contains multiple methods such as semantic search, keyword search, and graph search.

[0043] The application layer 206 mainly covers three underlying applications: the event dashboard uses knowledge graph data objects and an efficient query engine to present a comprehensive view of events; the cause location module predicts services that may fail for rapid troubleshooting; and the event resolution engine generates solutions based on historical event records and post-event review knowledge.

[0044] Figure 2 The proposed architecture combines data sources, knowledge graphs, search engines, root cause analysis modules, and QA systems to provide a comprehensive and efficient incident management solution.

[0045] Figure 3 A schema diagram 300 of example knowledge graph data objects is shown. Schema diagram 300 shows the relationship between different systems, and the system includes business logic 310. The value stream nodes are composed of business functions, which are implemented by APIs, and the APIs call other APIs to implement specific functions. Business logic 310 runtime monitoring includes IT services that expose APIs to support business functions. The operation monitoring service 320 relies on other services to implement applications, and the applications also rely on other applications to form the entire IT system that supports all business functions. The workflow management mechanism 330 tracks the occurrence of events, where events occur on various services and affect various services. After the event is resolved, the event node can be connected to the problem node to record event information. The logging system 340 utilizes indicators, logs, and alert nodes. Some alerts may be upgraded to events. Given the limitations of the graph database, the system can be configured to store only data related to the event, such as error logs. The schema of the knowledge graph database is configured to capture various components and relationships within the system, so as to enable a comprehensive understanding of the application infrastructure and promote effective event management.

[0046] The knowledge graph database is a core component of the computing system. The knowledge graph consists of three main components: nodes, edges, and attributes. Any object, place, or person can be a node, and edges define the relationship between nodes. In the operational example knowledge graph data object, each node represents a DevOps entity of ten node types, and edges represent various relationships between these nodes.

[0047] like Figure 3 As shown, the following 10 types of nodes can be used in the embodiment of the present invention:

[0048] A service node is an atomic / basic IT operation unit in a workflow, used to generate knowledge graphs, and is a basic IT operation unit in a DevOps management workflow.

[0049] Application nodes can be configured to represent any deployed program, module, or group of programs designed to provide a specific function on the computing infrastructure.

[0050] Log data nodes are digital records of events that occur within the system. Due to storage limitations, the system can be configured to only extract logs related to event records.

[0051] Alert nodes are similar to log data nodes in that the system can be configured to store alerts associated with events.

[0052] Metric nodes represent important indicators of how devices and applications are performing and how they are coping with workloads, and the system can be configured to keep records of metric data relevant to alerts.

[0053] Application Programming Interface (API) nodes can be used to implement business functions, serving as a bridge between business logic and IT interaction functions.

[0054] A business function node includes a specific business function or process within a value stream.

[0055] Value stream nodes represent the software and infrastructure environments that deliver business capabilities.

[0056] An incident node represents an incident record in ServiceNow and has several properties such as incident description, severity, responsible group, resolution instructions, etc.

[0057] The problem node can represent a post-incident review that contains information such as an incident summary, incident handling details, root cause analysis, and preventive measures.

[0058] The relationship between nodes grouped by different systems can be represented by the following:

[0059] Business logic: Value stream nodes are composed of business functions, which are implemented through APIs. APIs call other APIs to implement specific functions.

[0060] Business logic to operational monitoring: IT services expose APIs to support business functions, and applications are IT representatives of the value stream.

[0061] Operation monitoring: Service nodes rely on other services to implement applications, and applications also rely on other applications, thus forming the entire IT system that supports all businesses.

[0062] Workflow management: An incident occurs and affects the service. Once resolved, the incident is connected to the post-incident record, which is the problem node.

[0063] Logging system: Service nodes have some performance requirements, such as metrics, logs, and alerts, and some alerts may be escalated to events. Considering the limitations of graph databases, the system is configured to store only event-related data, such as error logs.

[0064] The schema diagram 300 of DevOps knowledge graph data objects captures the various components and relationships within the system, enabling a comprehensive understanding of the application infrastructure and facilitating effective incident management.

[0065] Figure 4 Interconnected computing components of an example knowledge graph query engine are shown. Diagram 400 shows a knowledge graph query engine that serves as a central computing component responsible for processing requests from front-end users and other system components.

[0066] Knowledge graphs are essential for knowledge management and data analysis. However, querying a KG or graph database is not as simple as querying a relational database and is therefore a complex computational problem. To simplify and enhance the accessibility of KG capabilities, the proposed approach designs a query engine to provide both high-level and low-level APIs.

[0067] The low-level API is designed for users familiar with graph databases, and the query engine allows the direct use of graph query languages ​​to efficiently query data in the knowledge graph. The system can be configured to support widely adopted graph query languages ​​such as Cypher, Gremlin, and SPARQL. If some graph databases do not support these languages, LLM can be used for query conversion to ensure compatibility.

[0068] The high-level API supports users who are not familiar with graph query languages ​​and can include two methods for querying data. These methods can include function calls that implement a set of predefined queries on the graph, including the following queries: node queries, edge queries, path queries, community queries, and centrality queries. These predefined functions not only facilitate efficient searches on the graph, but also serve as building blocks for other modules within the system. The second method includes natural language queries, which is an extension that enables users to interact with the graph database using natural language, leveraging LLM to generate graph queries. This approach allows users to express queries in everyday language, thereby improving the usability of the system. By providing both high-level and low-level APIs, the query engine enables users to efficiently retrieve information from the knowledge graph, regardless of whether they are familiar with graph query languages.

[0069] In some embodiments, the system can be implemented as a dedicated server computer or server computing device that is configured to maintain the GCN for a long time, training the trainable parameters of the update function based on the recorded data obtained from the message bus. The GCN is trained periodically and can be used for reasoning. When a user queries the system, the trained GCN update function parameters can remain fixed, and the input KG data object provided can then generate GCN-generated labels, for example, in the form of a metadata file with labels corresponding to each node, enhancing / transforming the KG data object. The labeled KG data object can then be provided to an onboard or coupled LLM / question-answering system to generate or rank potential solution suggestions so that a string output can be generated, ultimately providing a recommended remedy. When the system ranks or re-ranks the solution suggestions based on the KG data, the output data structure may include an updated ranking. In some embodiments, the GCN may also have one or more settable hyperparameters, such as the number of GCN convolutional layers to be used.

[0070] Figure 5A , Figure 5B and Figure 5C An example method for root cause analysis based on GCN is shown. In some embodiments, Figure 5A An example of a service dependent network is shown; Figure 5B An example of different layers of a GCN is shown; Figure 5C Illustration of the GCN model showing a checkout node.

[0071] Figure 5AAn example of a service dependency network 500A is shown, which can be processed according to a trace-based root cause analysis module. The core of its root cause analysis module is the metric-based GCN. The GCN model is trained to classify nodes, enabling the identification of problematic services in a service chain. The features used in this analysis come from the operations monitoring platform, which include basic metrics such as CPU usage, error rate, network receive / send throughput, latency, and HTTP status.

[0072] GCN accepts the topological structure in the knowledge graph and the metric data in the monitoring system as input, transforms the input features in an iterative manner (described in the update function section), and is configured to generate the final output (such as node classification results). The core part of GCN is the stacked graph convolution layer, each of which is described by an update function that defines how to transform the input features. The parameters of the update function are trainable parameters that will be determined during the training process.

[0073] The operation of GCN can be divided into two phases: training phase and inference phase. In the training phase, the system is configured to use the collected historical metric data and basic facts to adjust the parameters of the update function; in the inference phase, the parameters are fixed, and the system is configured to input the real metric data and generate node classification predictions, indicating whether each node has problems.

[0074] As described below, a GCN-specific architecture using a single-layer GCN is proposed. In the embodiment of this example, a single graph convolutional layer is used in both training and reasoning. In another variant, there can be multiple layers.

[0075] A technical advantage of this approach is that it is configured to predict a node's label by leveraging the states of its neighbors (upstream / downstream services), which provides more detailed contextual information and therefore has stronger expressive power, as evidenced by the update function equation. This is particularly beneficial in dealing with knowledge graph computations with specific characteristics. This approach can be used for anomaly detection in any knowledge graph that describes operation trajectories through nodes and edges.

[0076] The training of GCN produces a trained GCN model. This model can be deployed for node classification tasks and in this application, also known as root cause localization, the GCN is operated in inference mode.

[0077] During inference, the trained GCN is used as a QA module. This module is suitable for receiving new queries for execution, where the query can be a low-level query or a high-level query that has been converted to a low-level query. The GCN model and the QA module are two independent modules. The task of GCN is root cause localization, that is, finding (predicting) problematic services (nodes). The QA module and the query engine are different computing engines.

[0078] Metrics data is collected over time to determine the mean and standard deviation of each characteristic for the service's normal state, which is determined from historical records and confirmed by expert review.

[0079] When an event occurs, the current indicator values ​​can be compared with their respective long-term values ​​to assess the extent to which each feature deviates from the normal value, as shown below:

[0080]

[0081] where v f is the current value of the feature, μ f is the average of long-term observations, σ f is the standard deviation and α measures the deviation of the feature from its normal value. This deviation is then used as the input to the GCN model.

[0082] For node classification tasks, especially abnormal service detection, a simplified example approach uses a GCN model with only one hidden layer. This requires aggregating information only from one-hop neighbors (e.g., the immediate upstream or downstream nodes of a service node).

[0083] Figure 5B In , GCN can be seen as a stack of graph convolutional layers, which contains 0-3 layers, but there may be more or fewer layers. GCN accepts a graph as input, loads features (initial states) into its nodes and edges, and progressively updates these states using each graph convolutional layer, and then outputs a graph with a final state (e.g., classification result).

[0084] The number of update iterations is equal to the number of graph convolution layers, and the hyperparameters can be selected according to the application scenario. If more layers are used, the model will make more use of the "global" information of each node; when fewer layers are used, the model will be more localized.

[0085] For example, consider a node A, during one round of updates (one graph convolutional layer), node A will use the states of its directly connected (one-hop) neighbors to update its own state, and after 3 layers of updates, A's state contains information from all of its 3-hop neighbors. The more layers there are, the more neighbor states are included in the update, and the model becomes more global.

[0086] Figure 5C Example nodes in some embodiments are shown, specifically the GCN model of the checkout node. The proposed method uses an update function to illustrate how each node updates its state. The input is the previous state of its neighbors and itself, and the output is the current state of the node.

[0087] For any node, the update process of one layer is as follows:

[0088]

[0089] h indicates the node status, the subscript indicates the node number, and the superscript indicates the layer number.

[0090] l can have different values. In the example of a single-layer GCN, l can have two values: l = 0, which is the input value (0th layer node state) and l = 1, which is the output value (1st layer node state), for example is the output value of node i;

[0091] Neighbors of node i, Indicates the state of node j in layer l, and node j is the neighbor of node i;

[0092] c ij It is the product of the square roots of the node degrees of node i and node j. If the direction of the edge is from i to j, it takes a positive value, that is, node i is located upstream, otherwise it takes a negative value;

[0093] σ is an activation function;

[0094] b and W are trainable parameters of the GCN model.

[0095] In the activation function, the system is configured to collect state features (such as CPU usage) and use different symbols to represent upstream and downstream nodes. This enables the system to capture changes in metrics along the call chain.

[0096] That is, if all upstream nodes are functioning properly, but the node in question and its downstream nodes are exhibiting unusual behavior, there is likely a problem.

[0097] Training a neural network requires repeatedly passing a set of input data into the network, comparing the network’s output with the expected output, and adjusting weights and biases to reduce the error. In the proposed application, the input training dataset is a set of snapshots of the service knowledge graph during the incident, including service monitoring metric information, and the corresponding ground truth indicating the services that are truly problematic.

[0098] The training process can be divided into three steps, and these steps are performed in an iterative manner:

[0099] Complete a prequel;

[0100] Compute loss using the training node; and

[0101] Calculate gradients and update parameters

[0102] In a simplified example, we can consider only one node (named Node A):

[0103] Initial state / input features: All nodes have their initial state, which is collected from the monitoring platform and adjusted by the above method.

[0104] Perform a single forward pass: Node A transforms its state through the above update function. Since there is only one graph convolutional layer, there is only one transformation iteration.

[0105] The system then applies a softmax function to convert the updated state of node A into a probability [0,1] representing whether A is classified as a problematic node. The system compares this probability with the ground truth and calculates the difference (loss).

[0106] Back-propagation and gradient descent algorithms are used to modify the parameters of the update function so that the predictions are closer to the ground truth.

[0107] Figure 6 An example flow of a QA module in some embodiments is shown. The module takes a current event and generates a solution suggestion based on historical events. The module includes three main parts.

[0108] Multi-head retrieval: This initial step involves retrieving relevant information from the knowledge graph and other data sources, using various retrieval methods to collect historical event records similar to the query event. These methods can include vector-based retrieval. Vector retrieval is a method for storing and searching unstructured data by embedding and storing the generated embedding vectors. During querying, the unstructured query is also embedded, and the embedding vector closest to the query is retrieved.

[0109] The system can leverage the OpenAI Ada embedding model for text embedding and supports other embedding models such as CodeBERT for specific use cases. The FAISS library is used for vector storage and k-nearest neighbor (KNN) search. Keyword-based retrieval can focus on matching keywords rather than understanding the context or intent behind the search. This approach has proven effective in documents containing repeated technical vocabulary. The BM25 ranking function based on keyword matching is used in information retrieval systems to estimate the relevance of a document to a search query. In implementation, the method can adopt the Rank-BM25 Python package to implement a keyword-based retrieval algorithm.

[0110] For graph-based retrieval, knowledge graphs are good at describing the relationships between entities. Graph-based retrieval methods can return richer and more relevant information about the query entity, thereby capturing similar candidate entities that are close to the graph, which traditional vector-based methods usually fail to retrieve. The proposed method integrates graph-based retrieval by leveraging the contextual information contained in the matching subgraph.

[0111] Consider the following scenario: (1) if three events A (current event), B, and C (historical event) are caused by the same problem (e.g., database connection problem); (2) A and B are triggered by similar alerts and share similar log information (they belong to the same service and the same team); (3) B and C have similar descriptions; (4) a detailed post-incident review has been conducted on C and a root cause analysis has been completed.

[0112] For traditional vector-based methods, event C may be missed during the retrieval process of event A because they come from different services and teams, and the alert\log information may be different. However, since A is "related" to B (similar alerts\logs), and B is "related" to C (similar descriptions because they are both caused by the same problem), C is a 2-hop neighbor of A on the event knowledge graph and will therefore be retrieved and processed.

[0113] After the initial retrieval process, the system is configured to employ a re-ranking phase to improve the quality of the retrieval results.

[0114] The system adopts the Reciprocal Ranking Fusion (RRF) method / algorithm for this purpose, which is a technique in information retrieval and recommender systems. The main goal of RRF is to integrate the results from multiple ranking models and thus improve the overall ranking performance. RRF achieves this by considering the reciprocal rankings of items in various ranking lists. It assigns higher priority to items that consistently receive excellent reciprocal rankings in multiple ranking models.

[0115] The last step is to generate the final answer to the question using LLM. LLM leverages the retrieved and re-ranked information as well as external information collected from some external knowledge base to provide a comprehensive and contextual response.

[0116] By combining the above three components, the QA module can utilize retrieval, re-ranking and language generation techniques to ensure the generation of efficient and accurate incident solution suggestions.

[0117] Those skilled in the art understand that information and signals may be represented using a variety of different technologies and methods. For example, the data, instructions, commands, information, signals, bits, symbols, and chips that may be cited in the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or particles, light fields, or any combination thereof.

[0118] The functional blocks and modules described herein may include processors, electronic devices, hardware devices, electronic components, logic circuits, memories, software codes, firmware codes, etc., or any combination thereof. In addition, the features discussed herein may be implemented by dedicated processor circuits, executable instructions, and / or a combination thereof.

[0119] The various terms used herein are only used to describe specific embodiments and are not intended to limit the embodiments. For example, as used herein, ordinal numbers (such as "first", "second", "third", etc.) used to modify elements (such as structures, components, operations, etc.) do not necessarily represent any priority or order of the element relative to another element, but only distinguish the element from another element with the same name (but using ordinal numbers). The term "coupled" is defined as connected, although not necessarily directly connected, nor mechanically connected; two "coupled" objects can be each one. Unless the present disclosure clearly requires, the terms "one" and "an" can be defined as one or more. The term "approximately" can be replaced by "within 10% of the specified content". The phrase "and / or" means and or or. For illustration, A, B and / or C include: a single A, a single B, a single C, a combination of A and B, a combination of A and C, a combination of B and C, or a combination of A, B and C. In addition, the phrase "A, B, C or a combination thereof" or "A, B, C or any combination thereof" includes: A alone, B alone, C alone, a combination of A and B, a combination of A and C, a combination of B and C, or a combination of A, B and C.

[0120] The terms "comprising" and any form thereof, such as "includes" and "including", "having" and any form thereof, such as "having" and "having", are open conjunctions. Thus, a device that "comprising", "having" or "includes" one or more elements possesses the one or more elements, but is not limited to possessing only those elements. Similarly, a method that "comprising", "having" or "includes" one or more steps possesses the one or more steps, but is not limited to possessing only the one or more steps.

[0121] Any implementation of any device, system, and method may consist of or consist essentially of (rather than include / comprise / have) any of the described steps, elements, and / or features. Thus, in any claim, the term "consisting of" or "consisting essentially of" may replace any of the above open conjunctions in order to alter the scope of the claim from that when the open conjunctions are used.

[0122] Furthermore, a device or system configured in a certain way is configured in at least that way, but may also be configured in other ways than those specifically described. Aspects of one example may apply to other examples, even if not described or illustrated, unless expressly prohibited by the disclosure or the nature of the specific example.

[0123] It will also be appreciated by those skilled in the art that various illustrative logic blocks, modules, circuits, and algorithms related to the disclosure herein can be implemented as electronic hardware, computer software, or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, the functions of various illustrative components, blocks, modules, circuits, and steps have been generally described above. Whether these functions are specifically implemented as hardware or software depends on the specific application and the design constraints imposed on the entire system. The technician can implement the functions in different ways for each specific application, but such implementation decisions should not be interpreted as causing deviations from the scope of the disclosure. The technician will also recognize that the order or combination of components, methods, or interactions described herein are merely examples, and the components, methods, or interactions of various aspects of the disclosure can be combined or performed in a manner other than that shown and described herein.

[0124] The various illustrative logical blocks, modules, and circuits related to the disclosure herein may be implemented or performed with a processor, a digital signal processor (DSP), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or a combination designed to perform the functions described herein. The processor may be a microprocessor, but in an alternative, the processor may be another form of processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, a combination of one or more microprocessors and a DSP core, or any other such configuration.

[0125] The steps of the method or algorithm related to the disclosure herein can be directly embodied in hardware, in a software module executed by a processor, or in a combination of the two. The software module can reside in a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. In an alternative, the storage medium can be an integral part of the processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In an alternative, the processor and the storage medium can reside in a user terminal as discrete components.

[0126] In one or more exemplary designs, the functions can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions can be stored on a computer-readable medium or transmitted via a computer-readable medium as one or more instructions or codes. Computer-readable media include computer storage media and communication media, including any medium that facilitates the transfer of a computer program from one place to another. Computer-readable storage media can be any available medium that can be accessed by a computer. As an example and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage device, or any other device that can be used to carry or store the required program code in the form of an instruction or data structure. These devices are accessed by a computer or processor. In addition, the physical connection mode of information can be appropriately referred to as a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, or digital subscriber line (DSL), the coaxial cable, fiber optic cable, twisted pair, or DSL are all included in the definition of the medium. Disk and disc as used herein include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), hard disk, solid state disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs use lasers to reproduce data optically. Combinations of the above should also be included within the scope of computer-readable media.

[0127] The above description and examples provide a complete description of the structure and use of the illustrative embodiments. Although some of the above examples have been described with a certain degree of particularity or with reference to one or more separate examples, those skilled in the art may modify the disclosed embodiments without departing from the scope of the invention. Therefore, the various illustrative embodiments of the method and system are not intended to be limited to the specific form disclosed. Instead, they include all modifications and substitutions that fall within the scope of the claims, and examples other than the illustrated embodiments may include some or all of the features of the depicted embodiments. For example, elements may be omitted or combined as a single structure, and / or connections may be replaced. In addition, where appropriate, any of the above embodiments may be combined with any of the other embodiments described to form further embodiments having comparable or different characteristics and / or functions and solving the same or different problems. Similarly, the advantages described herein may relate to one embodiment or may relate to several embodiments.

[0128] The following claims are not intended to include, nor should they be interpreted as including means or step-plus-function limitations, unless such limitations are explicitly recited in the claims using the phrases "means" or "step", respectively.

[0129] Although the various aspects of the present invention and its advantages have been described in detail, various changes, substitutions and modifications may be made without departing from the subject matter of the present invention as defined in the appended claims. In addition, the scope of the present application is not limited to the specific implementations of the processes, machines, manufactures, material compositions, devices, methods and steps described in the specification. It will be understood by those skilled in the art from this document that the present disclosure may utilize existing or later developed processes, machines, manufactures, material compositions, devices, methods or steps to perform substantially the same functions or achieve substantially the same results as the corresponding embodiments described herein. Therefore, the appended claims are intended to include such processes, machines, manufactures, material compositions, devices, methods or steps within their scope.

Claims

1. A computer-implemented method for query processing for executing a query on an input knowledge graph, the computer-implemented method for query processing comprising: Instantiating in a non-transitory computer-readable data storage medium a graph convolutional network (GCN) suitable for computer service node classification, the GCN comprising a hidden layer GCN model data architecture having a stack of one or more convolutional layers for aggregating data from nearby node neighbors, the GCN configured to receive as input an input knowledge graph, wherein initial state features are loaded into nodes and edges and are incrementally updated based on a number of update iterations equal to the number of the one or more convolutional layers, each of the node updates being performed based on an update function; Use tuples of historical metric data and ground truth to train the trainable parameters of GCN; as well as During the reasoning process, the labels of one or more problem nodes are estimated for the input knowledge graph based on the current state information, and a labeled knowledge graph data object is output.

2. The method according to claim 1, characterized in that During the inference process, the trainable parameters are kept fixed and the GCN uses only a single-layer GCN which uses only the one-hop neighbors of a node's immediate upstream or downstream computer services.

3. The method according to claim 1, characterized in that The GCN model data architecture is updated using an update function with the following relationship: Among them, h represents the node state, the subscript represents the node number, and the superscript represents the layer number; Where l = 0 represents the input value (node ​​state at layer 0), and l = 1 represents the output value (node ​​state at layer 1), for example is the output value of node i; in is the neighbor of node i, Indicates the state of node j in layer l, and node j is a neighbor of node i; where c ij It is the product of the square roots of the node degrees of node i and node j. If the direction of the edge is from i to j, it takes a positive value, indicating that node i is upstream. If the direction of the edge is from j to i, it takes a positive value, indicating that node i is downstream. where σ is the activation function; and Where b and W are trainable parameters of the GCN model data architecture.

4. The method according to claim 3, characterized in that The activation function of the GCN is configured to represent one or more state features and utilizes different symbols to represent upstream and downstream nodes to capture metric changes along the call chain.

5. The method according to claim 1, characterized in that Further including: Receive query request string data message; as well as Using the trained GCN to process the query request string data message, query the knowledge graph data structure, and generate a query language string for execution; Executing the query language string against the knowledge graph data object or graph database; as well as Receive one or more query execution results as intermediate output.

6. The method according to claim 5, characterized in that Further comprising converting the one or more query execution results into one or more natural language outputs by processing the one or more query execution results using a trained large language model.

7. The method according to claim 5, characterized in that The query request string data message is converted from a natural language query input string, and the conversion is performed using a trained large language model.

8. The method according to claim 5, characterized in that The knowledge graph data structure includes a plurality of interconnected computing nodes, each of which represents a computing service on a computing environment.

9. The method according to claim 8, characterized in that The one or more query execution results include a list of identifiers of computational nodes estimated by the trained GCN to be problematic.

10. A computer program product storing computer-readable instructions, which, when executed by a processor, causes the processor to perform a computer-implemented method for query processing for an input knowledge graph, the computer-implemented method for query processing comprising: Instantiating in a non-transitory computer-readable data storage medium a graph convolutional network (GCN) suitable for computer service node classification, the GCN comprising a hidden layer GCN model data architecture having a stack of one or more convolutional layers for aggregating data from nearby node neighbors, the GCN configured to receive the input knowledge graph as input, wherein initial state features are loaded into nodes and edges to be incrementally updated based on a number of update iterations equal to the number of the one or more convolutional layers, each node update being performed based on an update function; Train the trainable parameters of the GCN using tuples of historical metric data and ground truth; as well as During the reasoning process, the labels of one or more problem nodes are estimated for the input knowledge graph based on the current state information, and a labeled knowledge graph data object is output.

11. A query processing computer system for executing queries against a knowledge graph data structure, the query processing computer system comprising a computer processor coupled to a computer memory and a non-transitory computer-readable data storage medium, the computer processor being configured to: Instantiating in a non-transitory computer-readable data storage medium a graph convolutional network (GCN) suitable for computer service node classification, the GCN comprising a hidden layer GCN model data architecture having a stack of one or more convolutional layers for aggregating data from nearby node neighbors, the GCN configured to receive as input an input knowledge graph, wherein initial state features are loaded into nodes and edges and are incrementally updated based on a number of update iterations equal to the number of the one or more convolutional layers, each of the node updates being performed based on an update function; Using tuples of historical metric data and ground truth to train the trainable parameters of the GCN; and During the reasoning process, the labels of one or more problem nodes are estimated for the input knowledge graph based on the current state information, and a labeled knowledge graph data object is output.

12. The system according to claim 11, characterized in that During the inference process, the trainable parameters are kept fixed and the GCN uses only a single-layer GCN which uses only the one-hop neighbors of a node's immediate upstream or downstream computer services.

13. The system according to claim 11, characterized in that The GCN model data architecture is updated using an update function with the following relationship: Among them, h represents the node state, the subscript represents the node number, and the superscript represents the layer number; Where l = 0 represents the input value (node ​​state at layer 0), and l = 1 represents the output value (node ​​state at layer 1), for example is the output value of node i; in is the neighbor of node i, Indicates the state of node j in layer l, and node j is a neighbor of node i; where c ij It is the product of the square roots of the node degrees of node i and node j. If the direction of the edge is from i to j, it takes a positive value, indicating that node i is upstream. If the direction of the edge is from j to i, it takes a positive value, indicating that node i is downstream. where σ is the activation function; and Where b and W are trainable parameters of the GCN model data architecture.

14. The system of claim 13, wherein: The activation function of the GCN is configured to represent one or more state features and utilizes different symbols to represent upstream and downstream nodes to capture metric changes along the call chain.

15. The system of claim 11, wherein: Further including: Receive query request string data message; as well as Using the trained GCN to process the query request string data message, query the knowledge graph data structure, and generate a query language string for execution; Executing the query language string against the knowledge graph data object or graph database; as well as Receive one or more query execution results as intermediate output.

16. The system of claim 15, wherein: Further comprising converting the one or more query execution results into one or more natural language outputs by processing the one or more query execution results using a trained large language model.

17. The system of claim 15, wherein: The query request string data message is converted from a natural language query input string, and the conversion is performed using a trained large language model.

18. The system of claim 15, wherein: The knowledge graph data structure includes a plurality of interconnected computing nodes, each of which represents a computing service on a computing environment.

19. The system of claim 18, wherein: The one or more query execution results include a list of identifiers of computational nodes estimated by the trained GCN to be problematic.

20. The system of claim 18, wherein: The query processing computer system operates as a dedicated machine in a data center configured for machine learning-based troubleshooting of a computing environment, wherein a list of identifiers of computing nodes estimated by the trained GCN to be problematic is transmitted to a service ticket computation function, which automatically generates one or more service ticket data objects for coordinating troubleshooting activities for each of the computing nodes.