Troubleshooting method, system, device and computer program product

Abstract

The application discloses a troubleshooting method, system, device and computer program product. It relates to the field of system operation and maintenance, and the method comprises the following steps: obtaining a target troubleshooting template, and extracting a troubleshooting step sequence in the target troubleshooting template; converting the troubleshooting step sequence into a plurality of troubleshooting subtasks through a troubleshooting process arrangement engine; for each troubleshooting subtask, constructing a prompt word of the troubleshooting subtask; inputting the prompt word into a pre-trained language model to obtain a query statement of the troubleshooting subtask; triggering execution of the query statement, obtaining an execution result of the query statement, and determining the execution result of the query statement as a query result of the troubleshooting subtask; and determining a system troubleshooting result based on the query results of the plurality of troubleshooting subtasks. Through the application, the problem that the troubleshooting result of using a small model to troubleshoot a system is inaccurate due to the context window limitation and weak logical reasoning ability in the related art is solved.

Description

Technical Field

[0001] This application relates to the field of system operation and maintenance, and more specifically, to a troubleshooting method, system, device, and computer program product. Background Technology

[0002] With the widespread adoption of cloud computing and microservice architectures, the complexity of enterprise-level systems is increasing exponentially. Troubleshooting methods relying on manual switching of monitoring, logging, and tracing tools are inefficient and highly dependent on expert experience. AI-powered operations and maintenance assistants based on large language models directly use extremely large models, leading to high costs associated with private deployment, high inference latency, and risks of data privacy breaches. Therefore, adopting low-cost, low-parameter models for private deployment is becoming a trend.

[0003] However, small-parameter models suffer from a "lost in the middle" phenomenon due to context window limitations in complex troubleshooting: troubleshooting requires injecting massive amounts of metadata and log information, while small-parameter models have limited context windows. Injecting all information at once can lead to distraction or information truncation, causing the model to ignore core instructions and fail to generate accurate queries or maintain multi-turn dialogue goals. It also cannot perform cross-data source comparative analysis, making it difficult to establish a complete chain of evidence. Complex troubleshooting involves multi-step reasoning, including intent recognition, indicator analysis, and link localization. Small-parameter models have weaker logical capabilities, making them prone to accumulating errors and creating illusions during multi-step reasoning, resulting in inaccurate troubleshooting results.

[0004] There is currently no effective solution to the problem that the troubleshooting results of using small models to troubleshoot systems are inaccurate due to the limitations of context windows and weak logical reasoning capabilities in related technologies. Summary of the Invention

[0005] The main objective of this application is to provide a fault diagnosis method, system, device, and computer program product to solve the problem inaccurate fault diagnosis results when using small models to diagnose system faults due to context window limitations and weak logical reasoning capabilities in related technologies.

[0006] To achieve the above objectives, according to one aspect of this application, a fault diagnosis method is provided. The method includes: obtaining a target fault diagnosis template and extracting a sequence of troubleshooting steps from the target fault diagnosis template; converting the sequence of troubleshooting steps into multiple troubleshooting subtasks using a troubleshooting process orchestration engine; constructing prompt words for each troubleshooting subtask; inputting the prompt words into a pre-trained language model and processing them to obtain a query statement for the troubleshooting subtask, wherein the number of parameters in the pre-trained language model is smaller than that of a large language model; triggering the execution of the query statement, obtaining the execution result of the query statement, and determining the execution result of the query statement as the query result of the troubleshooting subtask; and determining the fault diagnosis result of the system based on the query results of multiple troubleshooting subtasks.

[0007] Optionally, obtaining the target fault diagnosis template includes: receiving input natural language text, extracting multiple entities from the natural language text, constructing a target semantic vector based on the multiple entities, wherein the natural language text is the text used for fault diagnosis of the system; extracting multiple fault diagnosis templates from a preset operation and maintenance program library, calculating the similarity between the target semantic vector and each fault diagnosis template; and determining the fault diagnosis template with the highest similarity as the target fault diagnosis template.

[0008] Optionally, the investigation process orchestration engine includes a state controller, a task dispatcher, and a memory manager. Converting the investigation step sequence into multiple investigation subtasks via the orchestration engine includes: splitting each investigation step in the sequence into at least one investigation subtask using the task dispatcher, resulting in multiple investigation subtasks; after converting the investigation step sequence into multiple investigation subtasks via the orchestration engine, the method further includes: determining the target execution order of the multiple investigation subtasks based on the investigation step sequence, and sending the investigation subtasks to the context manager one by one according to the target execution order via the state controller, wherein the context manager is used to construct prompts for the investigation subtasks; after obtaining the query results of the investigation subtasks, the method further includes: storing the query results via the memory manager.

[0009] Optionally, the prompts for constructing the investigation subtask include: obtaining the system's metadata dataset and extracting multiple data tables from the metadata dataset; retrieving the target data table associated with the investigation subtask from the multiple data tables and obtaining summary information of the other data tables besides the target data table from the multiple data tables; generating a task summary based on the historical query results of previous investigation subtasks; and constructing prompts for the investigation subtask based on the target data table, summary information, and task summary.

[0010] Optionally, triggering the execution of a query statement, obtaining the execution result of the query statement, and determining the execution result of the query statement as the query result of the investigation subtask include: obtaining multiple heterogeneous data sources of the system, mapping the target field in the query statement to query conditions matching each data source through virtual foreign key association; converting the query statement into a target query statement corresponding to each data source based on the query conditions, wherein the target query statement uses the query language of the corresponding data source; querying target data from the corresponding data source through the target query statement, and determining the query result based on the target data queried from multiple heterogeneous data sources.

[0011] Optionally, before triggering the execution of the query statement, the method further includes: performing syntax verification on the query statement through a syntax parser to obtain a verification result; issuing a first prompt message if the verification result indicates that the verification failed, wherein the first prompt message is used to indicate that the query statement has a syntax error; and triggering the execution of the query statement if the verification result indicates that the verification was successful.

[0012] Optionally, after triggering the execution of the query statement, obtaining the execution result of the query statement, and determining the execution result of the query statement as the query result of the investigation subtask, the method further includes: issuing a second prompt message when the query result of the investigation subtask is empty, wherein the second prompt message is used to indicate that the query has no results; adjusting the time range or keywords in the prompt words of the investigation subtask to obtain updated prompt words; performing the step of inputting the prompt words into the pre-trained language model based on the updated prompt words until the query result of the investigation subtask is not empty, or the number of re-executions is greater than or equal to the number of executions threshold; issuing a third prompt message when the number of re-executions is greater than or equal to the number of executions threshold, wherein the third prompt message is used to indicate that the investigation subtask query failed.

[0013] To achieve the above objectives, according to another aspect of this application, a fault diagnosis system is provided. The system includes: a fault diagnosis template matching module, used to receive input natural language text, determine a target fault diagnosis template matching the natural language text from a preset operation and maintenance program library, wherein the natural language text is text used for fault diagnosis of the system; a fault diagnosis process orchestration engine, used to extract the fault diagnosis step sequence from the target fault diagnosis template, convert the fault diagnosis step sequence into multiple fault diagnosis sub-tasks, and determine the fault diagnosis result of the system based on the query results of the multiple fault diagnosis sub-tasks; a context manager, used to construct prompt words for each fault diagnosis sub-task; a pre-trained language model, used to receive the prompt words for each fault diagnosis sub-task, process them to obtain the query statement of the fault diagnosis sub-task, wherein the number of parameters of the pre-trained language model is smaller than that of a large language model; and a heterogeneous data adaptation layer, used to convert the query statement into a query statement corresponding to each data source, obtain the execution result of the query statement, determine the execution result of the query statement as the query result of the fault diagnosis sub-task, and send the query result to the fault diagnosis process orchestration engine.

[0014] To achieve the above objectives, according to another aspect of this application, a fault diagnosis device is provided. The device includes: an acquisition unit for acquiring a target fault diagnosis template and extracting a sequence of troubleshooting steps from the target fault diagnosis template; a conversion unit for converting the sequence of troubleshooting steps into multiple troubleshooting subtasks using a troubleshooting process orchestration engine, and for each troubleshooting subtask, constructing prompt words for the troubleshooting subtask; an input unit for inputting the prompt words into a pre-trained language model, processing them to obtain a query statement for the troubleshooting subtask, wherein the number of parameters in the pre-trained language model is smaller than that of a large language model; a triggering unit for triggering the execution of the query statement, acquiring the execution result of the query statement, and determining the execution result of the query statement as the query result of the troubleshooting subtask; and a first determination unit for determining the fault diagnosis result of the system based on the query results of the multiple troubleshooting subtasks.

[0015] To achieve the above objectives, according to another aspect of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the troubleshooting methods described in various embodiments of this application.

[0016] This application employs the following steps: obtaining a target fault diagnosis template and extracting the troubleshooting step sequence from it; transforming the troubleshooting step sequence into multiple troubleshooting subtasks using a troubleshooting process orchestration engine, and constructing prompt words for each subtask; inputting the prompt words into a pre-trained language model to obtain the query statement for the troubleshooting subtask, wherein the pre-trained language model has fewer parameters than a large language model; triggering the execution of the query statement, obtaining the execution result, and determining the execution result as the query result of the troubleshooting subtask; and determining the system's fault diagnosis result based on the query results of multiple troubleshooting subtasks. This solves the problem in related technologies where the troubleshooting results are inaccurate due to context window limitations and weak logical reasoning capabilities when using small models for system fault diagnosis. By utilizing a pre-trained language model with fewer parameters in conjunction with a troubleshooting process orchestration engine, the reliance on expensive large models is avoided, enabling low-cost, low-latency private deployment suitable for long-term operation and maintenance scenarios. Complex troubleshooting tasks are broken down into sub-tasks based on the target fault diagnosis template. For each sub-task, prompts are generated to overcome context window limitations, effectively preventing error accumulation and illusions in multi-step reasoning and ensuring the accuracy of generated queries. The query results from the sub-tasks are then aggregated to determine the final fault diagnosis result for the system, thereby improving the accuracy of fault diagnosis. Attached Figure Description

[0017] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1 This is a flowchart of a troubleshooting method provided according to an embodiment of this application;

[0019] Figure 2 This is a schematic diagram of a troubleshooting system provided according to an embodiment of this application;

[0020] Figure 3 This is a timing diagram of the troubleshooting process provided according to the embodiments of this application;

[0021] Figure 4 This is a schematic diagram of a fault diagnosis device provided according to an embodiment of this application;

[0022] Figure 5 This is a schematic diagram of an electronic device provided according to an embodiment of this application. Detailed Implementation

[0023] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] The present invention will now be described in conjunction with preferred implementation steps. Figure 1 This is a flowchart of a troubleshooting method provided according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0027] Step S101: Obtain the target fault troubleshooting template and extract the troubleshooting step sequence from the target fault troubleshooting template.

[0028] In step S101, the fault investigation scenario is determined by receiving natural language input from the user. Then, a target fault investigation template matching the scenario is obtained. The target fault investigation template is a predefined standard operating procedure for a specific fault type or business scenario, which encapsulates expert-level troubleshooting logic and dependencies. The troubleshooting step sequence is a series of troubleshooting actions, such as checking indicators and locating links, that are structured and parsed from the template and arranged in logical order. This transforms the unstructured natural language fault description into a standardized, executable logical path, providing a definite process framework for subsequent fine-grained task decomposition and ensuring that the troubleshooting process follows established best practices rather than random model divergence.

[0029] Step S102: The investigation process orchestration engine transforms the investigation step sequence into multiple investigation sub-tasks. For each investigation sub-task, prompt words for the investigation sub-task are constructed.

[0030] In step S102, the troubleshooting process orchestration engine is the control center within the fault troubleshooting system, implemented based on finite state machines and dynamic context pruning. It is responsible for decomposing the macro-level troubleshooting step sequence into atomic, context-independent execution units. Each troubleshooting subtask is the smallest execution unit after decomposition, such as generating a specific SQL (Structured Query Language) statement. The prompt words are dynamically assembled input instructions for each subtask, containing the current step's objective, necessary metadata, and contextual constraints. By externally constraining the reasoning range of the small-parameter language model with deterministic logic, complex, long-link tasks are decomposed into short, fast, single-step tasks, and irrelevant information is dynamically pruned to construct high signal-to-noise ratio inputs, thereby overcoming the limitations of small model context windows and insufficient logical reasoning capabilities.

[0031] Dynamic context pruning involves dynamically loading or unloading metadata, historical memory, and tool definitions during model interaction based on the semantic relevance of the current task step, in order to maintain a concise context window and a high signal-to-noise ratio.

[0032] Step S103: Input the prompt words into the pre-trained language model and process them to obtain the query statement for the investigation sub-task. The number of parameters in the pre-trained language model is smaller than that in the large language model.

[0033] In step S103, the pre-trained language model can be an SLM (Small Language Model), which is a pre-trained language model with 7 billion or fewer parameters. Compared to large models with hundreds of billions of parameters, SLMs offer faster inference speeds and lower deployment costs. The query statement is structured execution code generated by the pre-trained language model based on prompts, tailored to specific heterogeneous data sources. By leveraging the efficient generation capabilities of small models, grammatically correct query code is accurately output within a limited context window. Guided input, rather than autonomous model derivation, compensates for the limitations of small models in handling complex logic, achieving reliable code generation at low cost.

[0034] Step S104: Trigger the execution of the query statement, obtain the execution result of the query statement, and determine the execution result of the query statement as the query result of the investigation subtask.

[0035] In step S104, the heterogeneous data federation adaptation layer of the fault diagnosis system receives the query statement, converts it into the corresponding underlying database protocol, and sends a request to the corresponding data source; the query result is the raw data returned from the underlying heterogeneous data source, such as indicator values, log text, link number, etc.

[0036] Step S105: Determine the system's fault investigation results based on the query results of multiple investigation sub-tasks.

[0037] In step S105, under the control of the orchestration engine, the intermediate evidence chains accumulated by each subtask, such as abnormal indicators, log errors, and link breakpoints, are executed in sequence. Based on these evidence chains, the system's fault diagnosis results are obtained through logical summarization or final reasoning steps.

[0038] The fault diagnosis method provided in this application involves obtaining a target fault diagnosis template and extracting the sequence of diagnosis steps from it. A fault diagnosis process orchestration engine then transforms this sequence into multiple fault diagnosis subtasks. For each subtask, a prompt word is constructed. This prompt word is input into a pre-trained language model, which is then processed to obtain a query statement for the subtask. The pre-trained language model has fewer parameters than a large language model. The execution of the query statement is triggered, and its execution result is determined as the query result of the fault diagnosis subtask. Based on the query results of multiple subtasks, the system's fault diagnosis result is determined. This method solves the problem in related technologies where inaccurate fault diagnosis results are achieved using small models due to context window limitations and weak logical reasoning capabilities. By utilizing a small-parameter pre-trained language model in conjunction with a fault diagnosis process orchestration engine, the method avoids dependence on expensive large models, enabling low-cost, low-latency private deployment suitable for long-term operation and maintenance scenarios. Complex troubleshooting tasks are broken down into sub-tasks based on the target fault diagnosis template. For each sub-task, prompts are generated to overcome context window limitations, effectively preventing error accumulation and illusions in multi-step reasoning and ensuring the accuracy of generated queries. The query results from the sub-tasks are then aggregated to determine the final fault diagnosis result for the system, thereby improving the accuracy of fault diagnosis.

[0039] Optionally, in the fault diagnosis method provided in this application embodiment, obtaining the target fault diagnosis template includes: receiving input natural language text, extracting multiple entities from the natural language text, constructing a target semantic vector based on the multiple entities, wherein the natural language text is the text used for fault diagnosis of the system; extracting multiple fault diagnosis templates from a preset operation and maintenance program library, calculating the similarity between the target semantic vector and each fault diagnosis template; and determining the fault diagnosis template corresponding to the maximum similarity as the target fault diagnosis template.

[0040] For example, a user might enter the following natural language question on the troubleshooting interface: "Why was the version number QMS_V1.2.3_DASHBOARD not successfully collected by the QMS (Quality Management System) for the ETE (Enterprise Technology Environment) system?" The essence of this type of question is not a single-table query, but rather requires step-by-step verification across multiple data sources. Possible reasons include: the version number was not entered into the source system, an incorrect item was entered, the naming does not conform to the rules, metadata from upstream software or modules is missing, or the data collection link is misconfigured. Therefore, this problem requires step-by-step verification and cross-referencing across multiple heterogeneous data sources, rather than relying solely on a single log or database query. First, the user input is structured and parsed to extract the following key entities: Business object: Version number QMS_V1.2.3_DASHBOARD; Belonging system: ETE; Target system: QMS; Problem type: Version collection failed / Version not synchronized / Metadata missing. Subsequently, a match was performed in the preset operation and maintenance program library, and the target fault diagnosis template most relevant to this type of problem was found: "SOP_Version_Collection_Failure".

[0041] This embodiment uses semantic vectorization matching technology to achieve accurate mapping between user natural language fault descriptions and fault troubleshooting templates, ensuring that the troubleshooting process for complex multi-source faults strictly follows standardized expert experience procedures, thereby improving the accuracy and interpretability of the troubleshooting results.

[0042] To avoid context window limitations, the troubleshooting step sequence is transformed into multiple troubleshooting subtasks. Optionally, in the fault troubleshooting method provided in this application embodiment, the troubleshooting process orchestration engine includes a state controller, a task dispatcher, and a memory manager. Transforming the troubleshooting step sequence into multiple troubleshooting subtasks through the troubleshooting process orchestration engine includes: splitting each troubleshooting step in the troubleshooting step sequence into at least one troubleshooting subtask through the task dispatcher, resulting in multiple troubleshooting subtasks; after transforming the troubleshooting step sequence into multiple troubleshooting subtasks through the troubleshooting process orchestration engine, the method further includes: determining the target execution order of the multiple troubleshooting subtasks based on the troubleshooting step sequence, and sending the troubleshooting subtasks to the context manager one by one according to the target execution order through the state controller, wherein the context manager is used to construct prompts for the troubleshooting subtasks; after obtaining the query results of the troubleshooting subtasks, the method further includes: storing the query results through the memory manager.

[0043] In some embodiments, the task dispatcher is the core component of the troubleshooting process orchestration engine responsible for logical decomposition. It refines macroscopic, abstract troubleshooting steps, such as verifying the existence of a version number in the source registration system, into specific, atomic-level instructions executable by a small language model, such as generating a query to the jira_projectversion table to determine whether the version number QMS_V1.2.3_DASHBOARD exists. Troubleshooting subtasks are the smallest execution units after decomposition, possessing context independence, and aiming to eliminate error accumulation in multi-step reasoning. The target execution order refers to the predefined or dynamically generated sequence of troubleshooting subtasks based on the logical dependencies of fault investigation, such as the requirement to confirm the existence of a version before verifying its naming conventions. The state controller is the decision-making center in the troubleshooting process orchestration engine, maintaining the current troubleshooting progress based on a finite state machine, and is responsible for controlling the flow rhythm of troubleshooting subtasks to ensure that subtasks are executed sequentially according to a predetermined logical order. The context manager is the module responsible for constructing prompt words, receiving subtask instructions sent by the state controller, and dynamically loading the metadata most relevant to the step, such as specific table structures and historical summaries, to generate concise and high signal-to-noise ratio prompt words. The memory manager is an information persistence component in the investigation process orchestration engine. It is responsible for maintaining a global blackboard structure to store key conclusions, evidence fragments, or abnormal states generated by each investigation action, such as evidence E1: no version number was found in jira_projectversion.

[0044] For example, the target fault troubleshooting template predefines a standard troubleshooting sequence for issues where the version number has not been collected, breaking it down into troubleshooting subtasks, including:

[0045] 1. Verify that the version number exists in the source registration system;

[0046] 2. Verify that the version number belongs to the correct project;

[0047] 3. Verify that the version number meets the data collection naming rules;

[0048] 4. Verify that the software name and module name of the version exist in the intermediate metadata database;

[0049] 5. Verify whether the QMS data acquisition link or synchronization configuration is abnormal;

[0050] 6. Summarize the evidence and generate root cause conclusions.

[0051] The troubleshooting process orchestration engine initializes the finite state machine accordingly and writes the initial context into the blackboard.

[0052] This embodiment achieves atomic decoupling of complex tasks through a troubleshooting process orchestration engine that includes a state controller, a task dispatcher, and a memory manager. It avoids the context window limitation of small models and improves the stability, accuracy, and interpretability of small models in complex, multi-step fault troubleshooting scenarios.

[0053] After obtaining the decomposed troubleshooting subtasks, prompt words for the troubleshooting subtasks are constructed. Optionally, in the fault troubleshooting method provided in this application embodiment, constructing prompt words for the troubleshooting subtasks includes: obtaining the system's metadata dataset and extracting multiple data tables from the metadata dataset; retrieving the target data table associated with the troubleshooting subtask from the multiple data tables and obtaining summary information of other data tables besides the target data table from the multiple data tables; generating a task summary based on the historical query results of previous troubleshooting subtasks; and constructing prompt words for the troubleshooting subtask based on the target data table, summary information, and task summary.

[0054] In some embodiments, the system's metadata dataset is a structured collection storing the structure, field definitions, data types, and inter-table relationships of all database tables in the system; it serves as a knowledge base for the model to understand data structures. A data table refers to each specific logical or physical table recorded in the metadata dataset. A target data table is a key data table that is directly related to the current investigation subtask (e.g., checking for the existence of a version number), selected through semantic matching or tag retrieval, and requires loading its complete structure. Summary information is concise information, such as table names, main fields, or brief descriptions, for other related tables that are not directly dependent on by the current task, rather than complete metadata. Historical investigation subtasks are preceding steps that have been executed before the current subtask in the target execution order. Historical query results are raw data or intermediate conclusions obtained from the underlying data source after the preceding steps executed queries. A task summary is a one-sentence or multi-sentence conclusion generated after automatically compressing and refining a large number of historical query results; for example, a preceding step found that the version number was not found in a certain source table.

[0055] For example, the first step of the investigation subtask is to verify whether the version number exists in the source registration system. The source registration information for the version number is stored in the Jira (a software version management platform) database. Since the goal of this step is to confirm whether the version has been registered in the source system, the dynamic context manager only loads the minimum context relevant to this step, including: current step description: check whether the version number has been entered into Jira; accessible logical table: jira_projectversion; available field summary: project_id, version_name, description, created_time; known entity to be retrieved: QMS_V1.2.3_DASHBOARD. Other contexts unrelated to this step, such as the QMS collection log table, the SPD (Software Platform Data) module table, historical investigation results, etc., are not injected into the model for the time being, thereby reducing the attention burden on the small model. The atomic task issued by the system to the small model is: "Based on the current table structure, please generate a query condition to determine whether the version number QMS_V1.2.3_DASHBOARD exists in the Jira version table." After the small model outputs the structured query intent, the heterogeneous data federated adaptation layer converts this intermediate representation into actual SQL and executes it. The execution result is empty. The verification module judges the successful execution but empty result and generates partial evidence: Evidence E1: The version number QMS_V1.2.3_DASHBOARD was not found in jira_projectversion. At this time, the system does not directly output a conclusion, but proceeds to the next step of troubleshooting according to the target fault investigation template: because the absence of a version could mean that the version does not exist, or that the version exists in another project, the project field is incorrect, or there is a naming error.

[0056] The second step is to check the subtask: verifying whether the version number has been entered into the correct project. The target troubleshooting template stipulates that when the version existence check is empty, it is necessary to further confirm whether an incorrect version has been entered into the correct project. At this time, the context manager continues to maintain the relationship between the project mapping and the version table, but only loads the target project information QMS_Proj and its associated field descriptions. The system issues a second atomic task to the small model: "Please generate a query to determine whether the version number QMS_V1.2.3_DASHBOARD is registered in the project QMS_Proj. If no results are found, return empty." The query returned an empty result. This leads to the second piece of evidence: Evidence E2: The version number was not found in the target project QMS_Proj. This step eliminates the possibility that the version exists but only the project attribution is correct, and also initially supports the judgment that the version was not correctly entered into the source system.

[0057] The third step, troubleshooting the subtask, involves verifying whether the version naming conforms to the data collection rules. The target troubleshooting template stipulates that after no results are found in the source system, it's necessary to further determine if the version number might not have been recognized due to non-standard naming. At this point, the context manager unloads the project association details from the previous stage and instead loads: naming rule instructions; version number regular expression template; example version format; and the current version string to be verified. The small model no longer generates SQL but instead executes a restricted rule matching task. "Based on the current naming rules, determine whether QMS_V1.2.3_DASHBOARD meets the version number naming conventions, and explain the reason." The model outputs the conclusion that the version number conforms to the preset naming pattern. Based on this, the system generates a third piece of evidence, Evidence E3: the version naming format conforms to the collection rules, and the hypothesis that it was not collected due to non-standard naming is not supported. Therefore, the reason for not being collected due to non-standard naming is ruled out.

[0058] The fourth step, a subtask of investigation, involves cross-source verification of the existence of software names and module metadata. To further rule out the possibility of non-existent upstream business objects, the system switches to the business metadata source, loads the logical tables related to software, modules, and their mapping relationships, and extracts: Software name: QMS; Module name: DASHBOARD (dashboard / workbench); Accessible logical tables: spd_modular, etc.; and necessary field summaries. After the model generates a query, the system executes it and finds that: the software name QMS exists in the metadata table; the upstream business definition of the module DASHBOARD exists. This forms the fourth piece of evidence: Evidence E4: the upstream software and module metadata exist, which does not support the assumption that data collection is impossible due to the non-existence of software / modules. After the above steps are completed, the investigation process orchestration engine summarizes the multiple pieces of evidence on the blackboard and generates a final diagnostic conclusion. The system summarizes the following:

[0059] 1. QMS_V1.2.3_DASHBOARD was not found in the Jira version table;

[0060] 2. This version number was also not found in the target project's QMS_Proj file;

[0061] 3. The version naming format conforms to the data collection rules;

[0062] 4. The upstream metadata for the software name QMS and the module DASHBOARD exists.

[0063] Therefore, the system outputs the final conclusion:

[0064] The main reason why the version number QMS_V1.2.3_DASHBOARD was not collected by the QMS system is not due to non-standard naming or missing software or module metadata, but because this version number was not entered into the target project of the source registration system Jira. Therefore, QMS could not obtain the corresponding version record during the collection phase. The system also provides suggested actions: check if any version entries were missed in Jira; check if any non-target items were entered; if they have been entered but not yet collected, check the synchronization interface configuration, permissions, and field mapping rules between QMS and Jira. This completes an automated troubleshooting process based on multi-source heterogeneous data comparison.

[0065] This embodiment effectively resolves the contradiction between the limited context window of a small language model and the massive heterogeneous data required for troubleshooting by constructing a dynamic prompting word mechanism that includes accurate loading of the target data table, preservation of non-core table summaries, and historical information summarization. This dynamic context pruning and guidance strategy reduces the model's input consumption and inference latency, and suppresses model illusions by improving the context signal-to-noise ratio, ensuring that the small model can generate high-quality, executable query instructions at key steps.

[0066] After obtaining the query statement, the query statement is executed. Optionally, in the fault diagnosis method provided in this application embodiment, triggering the execution of the query statement, obtaining the execution result of the query statement, and determining the execution result of the query statement as the query result of the troubleshooting subtask includes: obtaining multiple heterogeneous data sources of the system, mapping the target field in the query statement to query conditions matching each data source through virtual foreign key association; converting the query statement into a target query statement corresponding to each data source based on the query conditions, wherein the target query statement uses the query language of the corresponding data source; querying target data from the corresponding data source through the target query statement, and determining the query result based on the target data queried from multiple heterogeneous data sources.

[0067] In some embodiments, a single logical task may require simultaneous access to and association of data from multiple heterogeneous storage engines. For example, simultaneously querying MySQL (relational database), Prometheus / VictoriaMetrics (time-series database), Elasticsearch / Loki (log search engine), and Jaeger / SkyWalking (distributed tracing system). Virtual foreign key associations are a logical mapping mechanism used to establish correspondences between the same logical entities in different data sources, enabling the identification of the same logical object in different monitoring systems. For example, associating "instance='192.168.1.1:8080'" in Prometheus with "host.name='web-01'" in Elasticsearch and "Service='OrderService'" in CMDB (Configuration Management Database).

[0068] Based on the query conditions, the query statement is converted into a target query statement corresponding to each data source. The target query statement is a special query code that fully conforms to the syntax specification of the specific data source after being transformed by the adaptation layer. For example, general SQL is converted into PromQL (for time series data query) or LogQL (for log query). The query results are formed by integrating the retrieved data from multiple different data sources.

[0069] This embodiment introduces virtual foreign key associations and a heterogeneous data federation adaptation layer to achieve automatic conversion and execution of general query commands generated by a small language model to dedicated query languages ​​for various heterogeneous data sources. This ensures the accuracy and compatibility of query execution and improves the integrity of the evidence chain and the accuracy of root cause location in complex fault diagnosis.

[0070] To ensure the accuracy of the query statement, it is necessary to verify the query statement. Optionally, in the fault diagnosis method provided in this application embodiment, before triggering the execution of the query statement, the method further includes: performing syntax verification on the query statement through a syntax parser to obtain a verification result; issuing a first prompt message if the verification result indicates that the verification failed, wherein the first prompt message is used to indicate that the query statement has a syntax error; and triggering the execution of the query statement if the verification result indicates that the verification was successful.

[0071] In some embodiments, the parser is a predefined code analysis tool or a static check barrier established before the query statement is actually sent to the underlying data source. This barrier identifies and intercepts syntax errors caused by small model illusions or insufficient generation capabilities, preventing invalid queries from polluting the data source or causing unexpected side effects. When the parser detects a syntax violation in the query statement that prevents it from being parsed or executed, the system provides initial feedback to the user or workflow orchestration engine, clearly informing them of the syntax problem in the generated query statement. Error details can be included for model correction. If the parser confirms that the query statement fully conforms to the syntax specifications of the target data source, is structurally complete, and has no logical conflicts, the validated and valid query statement is formally sent to the heterogeneous data federation adaptation layer, where it is converted into a specific database query command and sent to the corresponding data source for actual retrieval.

[0072] This embodiment introduces a pre-verification mechanism based on a syntax parser, building an effective security interception and error correction defense before query execution. This effectively overcomes the technical defects of small language models, which are prone to syntax errors and illusions when generating complex query statements. It reduces the load impact and security risks caused by invalid queries on the underlying heterogeneous data sources. By feeding back syntax error information, it promotes the self-correction of the model, thereby ensuring the high availability and execution success rate of query commands during the troubleshooting process.

[0073] If the query for the troubleshooting subtask fails, the prompt words are updated promptly. Optionally, in the troubleshooting method provided in this application embodiment, after triggering the execution of the query statement, obtaining the execution result of the query statement, and determining the execution result of the query statement as the query result of the troubleshooting subtask, the method further includes: issuing a second prompt message when the query result of the troubleshooting subtask is empty, wherein the second prompt message is used to indicate that the query has no results; adjusting the time range or keywords in the prompt words of the troubleshooting subtask to obtain updated prompt words; performing the step of inputting the prompt words into a pre-trained language model based on the updated prompt words until the query result of the troubleshooting subtask is not empty, or the number of re-executions is greater than or equal to the number of executions threshold; issuing a third prompt message when the number of re-executions is greater than or equal to the number of executions threshold, wherein the third prompt message is used to indicate that the query for the troubleshooting subtask has failed.

[0074] In some embodiments, after the query statement generated based on the current prompt word is executed, if the underlying data source returns zero records or an empty set, it indicates that no fault evidence was matched under the currently set time range, entity, or keyword conditions; the second prompt message informs the process orchestration engine or model that the current step failed to obtain valid data, and the adjustment may involve expanding the time window to cover potential delay faults; it may also involve fuzzy matching, synonym replacement, or relaxation of constraints on the original prompt word;

[0075] To obtain non-empty query results, the system repeatedly adjusts the suggestion words and re-calls the model for the query; it sets an execution count threshold to prevent the system from getting stuck in an infinite loop or excessively consuming computing power. When the maximum number of retries is reached and no valid data is obtained, the system issues a third prompt message, indicating that the current investigation subtask has exhausted its search capabilities under the current strategy.

[0076] This embodiment effectively compensates for the biases and limitations that small language models are prone to when generating accurate query conditions by constructing a dynamic prompt word adjustment and retry mechanism based on empty result feedback. This adaptive adjustment strategy improves the success rate of obtaining effective fault evidence in complex heterogeneous data environments and avoids the interruption of troubleshooting due to a single query failure.

[0077] According to another embodiment of this application, a fault diagnosis system is also provided. Figure 2 This is a schematic diagram of a troubleshooting system provided according to an embodiment of this application. For example... Figure 2 As shown, the system includes:

[0078] The troubleshooting template matching module is used to receive input natural language text and determine the target fault troubleshooting template that matches the natural language text from the preset operation and maintenance program library. The natural language text is the text used to troubleshoot system faults.

[0079] Specifically, this module receives natural language input from operations and maintenance personnel, such as "Why was the payment service lagging yesterday afternoon?", and transforms it into a structured troubleshooting task chain. Its functions include: Entity recognition: extracting key entities from the query, including service name, time range, and symptom description. In its implementation, intent parsing is not only based on keyword matching but also combines a domain dictionary and a lightweight semantic classification model to standardize user input. For example, expressions such as "slow down," "lag," and "timeout" are uniformly mapped to intents like "delay anomaly." Simultaneously, time expressions such as "this morning" and "last hour" are normalized and parsed, and key slots such as service name, metric type, and anomaly are extracted to form a structured representation. This structured result will serve as input for subsequent fault diagnosis template matching and process initialization.

[0080] Based on vector similarity, the system matches the most suitable troubleshooting template from a predefined operations and maintenance (O&M) program library. For example, if it matches 'SOP_Latency_Diagnosis', this troubleshooting template defines standard troubleshooting steps: 'Check_Metrics->Find_Abnormal_Trace->Locate_Slow_Component->Check_Component_Logs'. During the matching process, the system does not simply perform keyword searches, but rather matches based on the semantic similarity between structured intent and the troubleshooting template. Each troubleshooting template includes applicable scenarios, key steps, and constraints. The system prioritizes the template with the highest consistency with the current fault type, service object, and time range. When multiple candidate troubleshooting templates exist, they can be sorted by combining historical troubleshooting records or rule weights to select the optimal path. When the matching confidence is insufficient, the process is recorded, providing O&M personnel with information to summarize new troubleshooting methods and accumulate knowledge.

[0081] The troubleshooting process orchestration engine is used to extract the troubleshooting step sequence from the target fault troubleshooting template, transform the troubleshooting step sequence into multiple troubleshooting subtasks, and determine the system's fault troubleshooting results based on the query results of multiple troubleshooting subtasks.

[0082] Specifically, it is implemented based on a finite state machine. It maintains the current investigation progress and determines the next action. Its functions include:

[0083] 1. State transition: The state controller determines the transition to the next state based on the execution result (Success / Empty / Error) of the previous step and the target fault troubleshooting template definition.

[0084] 2. Task Distribution: The task distributor breaks down the macro-level steps in the target fault diagnosis template into atomic instructions for smaller models.

[0085] 3. Memory Management: Maintain a Blackboard to store key conclusions found at each step, such as "anomaly detected at time T=10:05", for reference in subsequent steps.

[0086] The context manager is used to construct prompts for each investigation subtask;

[0087] Specifically, this module is key to overcoming the limitations of small model windows. It dynamically constructs prompt words based on the attributes of the current task. The core algorithm is context pruning, which selects the most relevant subset of information for the current investigation step as needed, rather than loading the entire context at once, thereby reducing the interference of irrelevant information on model inference. Specifically, this includes: Metadata filtering: If the current step is to query the order table, the system uses Embedding retrieval or metadata tags to load only the structure of the "orders" table and its related table "users", filtering out irrelevant "inventory" or "shopping" tables. That is, during the filtering process, the system combines the entities involved in the current task (such as service name, table name, indicator type) to judge the relevance of candidate metadata, retaining only the directly related table structure and key field information; for non-key fields or weakly related tables, only summary information is retained or they are directly removed, thereby reducing context redundancy. Historical compression: Instead of including previous original query results such as 1000 log entries in the prompt words, the system automatically summarizes and generates a one-sentence conclusion, "The log shows that the main error is SQLTimeout," and includes it in the historical part of the prompt words. For the numerous intermediate results generated from historical steps, the system does not retain all the original content. Instead, it extracts key conclusions and presents them in a summary, such as retaining information on whether anomalies exist, the main error types, and the scope of impact. This significantly reduces the length of the context while ensuring information integrity. As the investigation process progresses, the context content is dynamically updated: new key conclusions are added to the context, while irrelevant information is gradually removed, ensuring that the model always processes the most relevant information within a limited context window.

[0088] A pre-trained language model is used to receive prompts for each investigation subtask and process them to obtain the query statement for the investigation subtask. The number of parameters in the pre-trained language model is smaller than that in the large language model.

[0089] The heterogeneous data adaptation layer is used to convert query statements into query statements corresponding to each data source, obtain the execution results of the query statements, determine the execution results of the query statements as the query results of the investigation subtasks, and send the query results to the investigation process orchestration engine.

[0090] Specifically, heterogeneous data federation maps underlying data sources with different structures to logical tables or graphs through a unified middleware interface, freeing upper-layer applications from concern themselves with the details of the underlying storage. This module is responsible for shielding the differences in underlying data sources and achieving cross-source alignment. Its functions include:

[0091] 1. Unified query interface: The model only needs to output the intent in an intermediate format, and the adaptation layer converts it into a query statement corresponding to the specific data source through the query translator.

[0092] 2. Virtual foreign key association:

[0093] Establish the Time-Series <-> Log association: Map the time windows of abnormal metrics to the time range of log queries. Establish the Trace <-> DB association: Extract the SQL statement fingerprints from the Trace and associate them with the Slow QueryLog table in the database.

[0094] 3. Data normalization: Convert all returned data into a unified DataFrame structure (Timestamp, Entity, Value, Metadata) to facilitate comparison by the model.

[0095] The troubleshooting system also includes an interactive verification and self-healing module, introducing a closed-loop verification mechanism to address the issue of small models easily generating illusions or error codes. Its functions include:

[0096] 1. Syntax Pre-validation: Before executing the SQL / PromQL generated by the model, it is checked by the syntax parser. 2. Empty Result Reflection: If the query succeeds but returns an empty result, the system does not terminate directly, but triggers a "reflection mechanism," prompting the model: "No results found. Please check if you need to broaden the time range or use fuzzy matching keywords," guiding the model to retry.

[0097] Figure 3 This is a timing diagram of the troubleshooting process provided according to the embodiments of this application. For example... Figure 3 As shown, the state machine requests the context manager to construct a prompt (hint word). For example, the task is to query the slow log of the `orders` table. The context manager retrieves the table structure related to "orders" from the knowledge base / metadata. The knowledge base / metadata filters out irrelevant tables and returns the schema (metadata) of the `orders` and `orders_items` tables. The context manager obtains the conclusion of the previous step from the state machine (CPU spike from 10:00 to 10:05). The context manager assembles the prompt words: System: You are a DB expert…; Context: 10:00 CPU high; Schema: tableorders(id, time, duration); Task: Write SQL to query the slow log for this period. The prompt is sent to the small model, which returns the SQL statement to the state machine. The SQL is executed in the data source, and the data source returns the result set. The state machine passes the result set to the context manager. The context manager extracts a data summary (extracts the Top 1 SQL fingerprint), sends the summary to the small model, requests analysis of the cause, and the small model sends the conclusion (e.g., missing index caused a full table scan) to the state machine.

[0098] For example, taking typical interface response timeouts and cascading failures in a microservice architecture as an example, the target fault troubleshooting template, dynamic context pruning, heterogeneous data federated query and verification error correction mechanism, across multiple heterogeneous data sources such as time series indicators, link tracing, logs and relational databases, complete a complete automated root cause investigation.

[0099] A typical failure scenario involves a monitoring dashboard issuing a critical alert. Operations personnel input the following question into the troubleshooting interface: "Starting at 10:00 AM today, the TicketOrderService's order creation interface has been reporting a large number of 504 timeout errors. Please investigate the cause." Such failures usually involve a combination of anomalies in the upstream gateway, current service computing resources, downstream dependent services, or the underlying database. Traditional troubleshooting requires operations personnel to switch between Prometheus, SkyWalking, Elasticsearch, and MySQL clients and manually concatenate timestamps and TraceIDs. This system will automate this cross-source deduction process using a small model and a state machine.

[0100] The system first performs structured parsing of user input, extracting key entities: Abnormal service: TicketOrderService; Abnormal interface: CreateOrder; Time window: from 10:00 AM today to present; Symptom description: 504 timeout, sudden increase in latency. Semantic matching is performed in the operations database, matching the highest-confidence troubleshooting template: SOP_API_Timeout_Diagnosis. This target fault troubleshooting template defines a standard troubleshooting state machine chain: Check_Metrics (metric delimitation) -> Locate_Slow_Trace (chain location) -> Extract_Error_Logs (log analysis) -> Inspect_DB_Status (database drill-down) -> Summarize (summary report). The troubleshooting process orchestration engine initializes the state machine accordingly and writes the initial entities and time window into the global blackboard.

[0101] Step 1: Based on anomaly delimitation using time-series metrics, the state machine enters the Check_Metrics state. To prevent the small model from being overwhelmed by massive heterogeneous data table structures, the dynamic context manager performs its first pruning: only loading the basic schema related to the Prometheus time-series database (such as request_latency_seconds, cpu_usage_total), and unloading all irrelevant log or business table structures. The small model's Prompt command is injected: "Please generate PromQL to query the CPU utilization and network I / O trends of TicketOrderService before and after 10:00."

[0102] Heterogeneous Execution and Feedback: The small model outputs its intent, which is then translated into native PromQL and executed by the heterogeneous data federated adaptation layer. The returned time series array is "normalized" by the adaptation layer, and key features are extracted (e.g., "From 10:01, the CPU showed no significant fluctuation, but the number of Goroutines surged").

[0103] Memory Update: The system extracts the summary and records evidence E1 on the blackboard: No bottleneck was found in the service computing resources; the request backlog is suspected to be caused by downstream blockage. The state machine then proceeds to the next step.

[0104] Step 2: Based on bottleneck location and cross-source alignment using traces, the state machine enters the Locate_Slow_Trace state. At this point, the "virtual foreign key" of the heterogeneous data federation layer comes into play: the system automatically uses the abnormal time window (10:01-10:05) in the blackboard as a filtering condition. The dynamic context manager performs a second pruning: unloading the PromQL-related context and loading the query syntax and Span structure definition of the trace system (such as Jaeger / SkyWalking). The Prompt instruction is injected into the small model: "Query the CreateOrder interface call chains that take more than 5 seconds within this time period and find the downstream component with the longest time consumption percentage." Cross-source alignment and feedback: The small model generates TraceQL. The system retrieves 50 slow call chains. Since the small model cannot process 50 complex JSON trees at once, the system performs historical memory compression, extracting only the topological features of the Top 1 slow call and feeding them back to the model. Memory update: Model analysis concluded that additional evidence E2 on the blackboard showed that 95% of the time was blocked on the downstream update_stock call to InventoryDB, and the corresponding TraceID was extracted.

[0105] Step 3: Semantic extraction based on unstructured logs; the state machine enters the Extract_Error_Logs state. The system uses TraceID as a virtual foreign key to bridge the semantic gap between Trace and Log. The dynamic context manager performs a third pruning: loading the query syntax rules of Elasticsearch / Loki and application log index metadata. A Prompt instruction is injected into the small model: "Based on the current TraceID, query the application error logs in Elasticsearch and extract the core exception stack information." Interactive verification and self-healing: The initial query generated by the small model results in an empty result due to a mismatched time format. The self-healing module intervenes, not directly terminating the error, but instead feeding back to the model: "Query successful but no results; please check if the timestamp format needs to be converted to ISO8601 and relaxed by ±1 minute." The model corrects the DSL statement and retrys successfully. Memory update: Evidence E3 is added to the blackboard: the log shows that the underlying layer throws a java.sql.SQLException: Lock waittimeoutexceeded; try restarting transaction exception.

[0106] Step 4: Based on root cause analysis of the business database, the state machine enters the Inspect_DB_Status state. Based on evidence E3 (database lock wait timeout), the target is narrowed down to MySQL. The dynamic context manager performs a final pruning: precisely loads the InventoryDB table structure (keeping only the inventory_stock table and its associated information_schema.innodb_trx transaction view). A Prompt instruction is injected into the small model: "A lock wait timeout has occurred. Please use the provided table structure to write an SQL query for transactions that have not been committed for an extended period between 10:00 and 10:05 and their corresponding SQL statements." Execution and Feedback: The model generates a relational query SQL to identify the source of the blockage. Memory Update: Evidence E4 is added to the blackboard: a batch deduction task (Batch_Deduct_Job) that has been executing for more than 10 minutes has triggered row-level lock contention, blocking single-row update operations for online orders.

[0107] After evidence is collected and root cause analysis is performed, the troubleshooting process orchestration engine determines that the SOP link has been completed, submits E1 to E4 collected in the blackboard to the small model, and executes the final Summarize instruction.

[0108] The system's final investigation report concluded that the root cause of the TicketOrderService 504 timeout was not a bottleneck in the service's own resources, but rather a severe row lock contention in the underlying InventoryDB database. Complete chain of evidence:

[0109] 1. Abnormal metrics: The number of Goroutines in the service has surged while the CPU usage remains stable, indicating that the system is in an I / O blocking and waiting state.

[0110] 2. Link bottleneck: The slow link takes more than 5000ms to locate the update_stock link.

[0111] 3. Log correlation: The log of this link explicitly throws a Lock wait timeout exceeded exception.

[0112] 4. Database locking cause: The background scheduled task (Batch_Deduct_Job) held row locks for an extended period without committing, causing online transaction requests to be blocked.

[0113] Recommended repair actions:

[0114] 1. Immediately kill the MySQL thread (ID: 10452) that is causing the deadlock / long transaction.

[0115] 2. It is recommended that the development team physically isolate the background batch processing tasks from the online real-time transactions, or reschedule the batch processing tasks to be executed during off-peak hours. Thus, through the guidance of an external state machine and the on-demand loading of dynamic contexts, the system successfully navigated four heterogeneous data sources with a small parameter model, completing a highly complex root cause analysis of a fault.

[0116] The fault diagnosis system in this embodiment does not rely on the model's own autonomous planning capabilities. Instead, it constructs a deterministic process orchestration engine as the brain, using smaller models as executors. The system maintains a global fault diagnosis state machine, breaking down complex fault diagnosis tasks into a series of atomic, context-independent subtasks. When executing each subtask, the system utilizes metadata indexing, entity mapping relationships, and dynamic pruning algorithms to inject only the minimum metadata and data fragments required for the current step into the model, thereby improving the stability and accuracy of the smaller models under constrained tasks. Simultaneously, through a heterogeneous data adaptation layer, data from different sources is uniformly abstracted into an intermediate representation, assisting the model in cross-source comparison.

[0117] By leveraging external state machine guidance and dynamic context pruning, an expert-level troubleshooting system can be run on a fraction of ordinary graphics cards. Compared to deploying models with hundreds of billions of parameters, this reduces hardware costs while increasing inference speed, significantly lowering the barrier to entry for enterprises to implement intelligent operations and maintenance (O&M). Context pruning (viewing only relevant data) and state machine constraints (performing only necessary actions) suppress model illusions and improve task success rates. Virtual foreign keys and multi-dimensional entity alignment technology enable cross-source entity and evidence correlation analysis. The troubleshooting process, based on a target fault troubleshooting template, is highly interpretable. O&M personnel can view the system's state at any time and the data used to make judgments. Simultaneously, the system records the step sequence, query templates, and evidence chains during successful troubleshooting, allowing O&M personnel to subsequently compile them into new templates and achieve knowledge accumulation.

[0118] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0119] This application also provides a fault diagnosis device. It should be noted that the fault diagnosis device of this application can be used to execute the fault diagnosis method provided in this application. The fault diagnosis device provided in this application is described below.

[0120] Figure 4 This is a schematic diagram of a troubleshooting device provided according to an embodiment of this application. Figure 4 As shown, the device includes:

[0121] The acquisition unit 401 is used to acquire the target fault troubleshooting template and extract the troubleshooting step sequence from the target fault troubleshooting template;

[0122] The transformation unit 402 is used to transform the sequence of investigation steps into multiple investigation sub-tasks through the investigation process orchestration engine. For each investigation sub-task, prompt words for the investigation sub-task are constructed.

[0123] Input unit 403 is used to input prompt words into a pre-trained language model and process them to obtain the query statement of the investigation sub-task. The number of parameters of the pre-trained language model is smaller than that of the large language model.

[0124] Triggering unit 404 is used to trigger the execution of the query statement, obtain the execution result of the query statement, and determine the execution result of the query statement as the query result of the investigation subtask;

[0125] The first determining unit 405 is used to determine the system's fault investigation results based on the query results of multiple investigation sub-tasks.

[0126] The fault diagnosis device provided in this application embodiment acquires a target fault diagnosis template through an acquisition unit 401 and extracts a sequence of diagnosis steps from the template; a conversion unit 402 converts the sequence of diagnosis steps into multiple diagnosis subtasks through a diagnosis process orchestration engine, and constructs prompt words for each subtask; an input unit 403 inputs the prompt words into a pre-trained language model to obtain a query statement for the diagnosis subtask, wherein the number of parameters in the pre-trained language model is smaller than that of a large language model; and a trigger unit 404 triggers the execution of the query statement. The system obtains the execution results of the query statement and determines them as the query results of the troubleshooting subtasks. The first determining unit 405 determines the system's fault diagnosis results based on the query results of multiple troubleshooting subtasks. This solves the problem in related technologies where the troubleshooting results are inaccurate when using small models for system fault diagnosis due to context window limitations and weak logical reasoning capabilities. By utilizing a pre-trained language model with small parameters in conjunction with a troubleshooting process orchestration engine, it avoids dependence on expensive large models, achieving low-cost, low-latency private deployment suitable for long-term operation and maintenance scenarios. Complex troubleshooting tasks are broken down into troubleshooting subtasks according to the target fault diagnosis template, and prompt words are constructed for each subtask. This overcomes context window limitations, effectively preventing error accumulation and illusions in multi-step reasoning, and ensuring the accuracy of the generated query statement. The query results of the troubleshooting subtasks are summarized to finally determine the system's fault diagnosis results, thereby improving the accuracy of fault diagnosis.

[0127] Optionally, in the fault diagnosis device provided in this application embodiment, the acquisition unit 401 includes: a receiving module, used to receive input natural language text, extract multiple entities from the natural language text, and construct a target semantic vector based on the multiple entities, wherein the natural language text is the text used for fault diagnosis of the system; a first extraction module, used to extract multiple fault diagnosis templates from a preset operation and maintenance program library, and calculate the similarity between the target semantic vector and each fault diagnosis template; and a first determination module, used to determine the fault diagnosis template corresponding to the maximum similarity as the target fault diagnosis template.

[0128] Optionally, in the fault diagnosis device provided in this application embodiment, the conversion unit 402 includes: a splitting module, used to split each diagnosis step in the diagnosis step sequence into at least one diagnosis subtask through a task dispatcher, resulting in multiple diagnosis subtasks; a second determining module, used to determine the target execution order of the multiple diagnosis subtasks based on the diagnosis step sequence, and send the diagnosis subtasks to the context manager one by one according to the target execution order through a status controller, wherein the context manager is used to construct prompt words for the diagnosis subtasks; and a storage module, used to store the query results through a memory manager.

[0129] Optionally, in the fault diagnosis device provided in this application embodiment, the conversion unit 402 includes: a second extraction module, used to acquire the system's metadata dataset and extract multiple data tables from the metadata dataset; a retrieval module, used to retrieve the target data table associated with the troubleshooting subtask from the multiple data tables and acquire summary information of other data tables besides the target data table from the multiple data tables; a generation module, used to generate a task summary based on the historical query results of previous troubleshooting subtasks; and a construction module, used to construct prompt words for the troubleshooting subtask based on the target data table, summary information, and task summary.

[0130] Optionally, in the fault diagnosis device provided in this application embodiment, the triggering unit 404 includes: a mapping module, used to obtain multiple heterogeneous data sources of the system, and map the target field in the query statement to query conditions matching each data source through virtual foreign key association; a conversion module, used to convert the query statement into a target query statement corresponding to each data source based on the query conditions, wherein the target query statement uses the query language of the corresponding data source; and a query module, used to query target data from the corresponding data source through the target query statement, and determine the query result based on the target data queried from multiple heterogeneous data sources.

[0131] Optionally, in the fault diagnosis device provided in this application embodiment, the device further includes: a verification unit, used to perform syntax verification on the query statement through a syntax parser to obtain a verification result; a first prompt unit, used to issue a first prompt message when the verification result indicates that the verification failed, wherein the first prompt message is used to indicate that the query statement has a syntax error; and a statement triggering unit, used to trigger the execution of the query statement when the verification result indicates that the verification was successful.

[0132] Optionally, in the fault diagnosis device provided in this application embodiment, the device further includes: a second prompting unit, used to issue a second prompting message when the query result of the diagnosis subtask is empty, wherein the second prompting message is used to indicate that the query has no results; an adjustment unit, used to adjust the time range or keywords in the prompting words of the diagnosis subtask to obtain updated prompting words; an execution unit, used to execute the step of inputting the prompting words into a pre-trained language model based on the updated prompting words until the query result of the diagnosis subtask is not empty, or the number of re-executions is greater than or equal to the number of executions threshold; and a third prompting unit, used to issue a third prompting message when the number of re-executions is greater than or equal to the number of executions threshold, wherein the third prompting message is used to indicate that the diagnosis subtask query has failed.

[0133] The fault diagnosis device includes a processor and a memory. The aforementioned acquisition unit 401, conversion unit 402, input unit 403, trigger unit 404, and first determination unit 405 are all stored in the memory as program units. The processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0134] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and adjusting kernel parameters can improve the accuracy of troubleshooting.

[0135] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0136] This invention provides a computer-readable storage medium storing a program thereon, which, when executed by a processor, implements a fault diagnosis method.

[0137] This invention provides a processor for running a program, wherein the program executes a fault diagnosis method during runtime.

[0138] Figure 5 This is a schematic diagram of an electronic device provided according to an embodiment of this application. For example... Figure 5 As shown, electronic device 501 includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs the following steps: obtaining a target fault diagnosis template and extracting the sequence of diagnosis steps from the template; converting the sequence of diagnosis steps into multiple diagnosis subtasks using a diagnosis process orchestration engine; constructing prompts for each subtask; inputting the prompts into a pre-trained language model to obtain a query statement for the diagnosis subtask, wherein the pre-trained language model has fewer parameters than a large language model; triggering the execution of the query statement, obtaining the execution result, and determining the result as the query result of the diagnosis subtask; and determining the system's fault diagnosis result based on the query results of multiple diagnosis subtasks. The device in this paper can be a server, PC, PAD, mobile phone, etc.

[0139] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program with the following method steps: obtaining a target fault diagnosis template and extracting a sequence of troubleshooting steps from the target fault diagnosis template; converting the sequence of troubleshooting steps into multiple troubleshooting subtasks through a troubleshooting process orchestration engine, and for each troubleshooting subtask, constructing prompt words for the troubleshooting subtask; inputting the prompt words into a pre-trained language model and processing them to obtain a query statement for the troubleshooting subtask, wherein the number of parameters in the pre-trained language model is smaller than that of a large language model; triggering the execution of the query statement, obtaining the execution result of the query statement, and determining the execution result of the query statement as the query result of the troubleshooting subtask; and determining the fault diagnosis result of the system based on the query results of multiple troubleshooting subtasks.

[0140] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0141] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0142] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0143] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0144] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0145] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0146] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0147] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0148] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0149] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A troubleshooting method, characterized in that, include: Obtain the target fault troubleshooting template and extract the troubleshooting step sequence from the target fault troubleshooting template; The investigation process orchestration engine transforms the sequence of investigation steps into multiple investigation sub-tasks, and for each investigation sub-task, it constructs prompt words for the investigation sub-task. The prompt words are input into a pre-trained language model and processed to obtain the query statement for the investigation subtask, wherein the number of parameters of the pre-trained language model is smaller than that of a large language model. Trigger the execution of the query statement, obtain the execution result of the query statement, and determine the execution result of the query statement as the query result of the investigation subtask; The system's fault diagnosis results are determined based on the query results of the multiple troubleshooting subtasks.

2. The method according to claim 1, characterized in that, Obtaining the target fault diagnosis template includes: The system receives input natural language text, extracts multiple entities from the natural language text, and constructs a target semantic vector based on the multiple entities. The natural language text is the text used for troubleshooting the system. Multiple fault diagnosis templates are extracted from a pre-set operation and maintenance program library, and the similarity between the target semantic vector and each fault diagnosis template is calculated. The fault diagnosis template corresponding to the highest similarity is determined as the target fault diagnosis template.

3. The method according to claim 1, characterized in that, The investigation process orchestration engine includes a state controller, a task dispatcher, and a memory manager. The investigation process orchestration engine transforms the investigation step sequence into multiple investigation subtasks, including: The task dispatcher breaks down each investigation step in the investigation step sequence into at least one investigation sub-task, thus obtaining the plurality of investigation sub-tasks; After converting the sequence of investigation steps into multiple investigation subtasks using an investigation process orchestration engine, the method further includes: Based on the sequence of investigation steps, the target execution order of the multiple investigation sub-tasks is determined. The state controller sends the investigation sub-tasks to the context manager one by one according to the target execution order. The context manager is used to construct the prompt words for the investigation sub-tasks. After obtaining the query results of the investigation subtask, the method further includes: The query results are stored through the memory manager.

4. The method according to claim 1, characterized in that, The prompts for constructing the investigation subtask include: Obtain the metadata dataset of the system, and extract multiple data tables from the metadata dataset; Retrieve the target data table associated with the investigation subtask from the plurality of data tables, and obtain summary information of the other data tables in the plurality of data tables besides the target data table; A task summary is generated based on the historical query results of previous investigation sub-tasks. The prompt words for the investigation sub-task are constructed based on the target data table, the summary information, and the task summary.

5. The method according to claim 1, characterized in that, Triggering the execution of the query statement, obtaining the execution result of the query statement, and determining the execution result of the query statement as the query result of the investigation subtask include: Obtain multiple heterogeneous data sources from the system, and map the target fields in the query statement to query conditions that match each data source through virtual foreign key associations; Based on the query conditions, the query statement is converted into a target query statement corresponding to each data source, wherein the target query statement uses the query language of the corresponding data source; The target data is retrieved from the corresponding data source using the target query statement, and the query result is determined based on the target data retrieved from the multiple heterogeneous data sources.

6. The method according to claim 1, characterized in that, Before triggering the execution of the query statement, the method further includes: The query statement is syntax-checked using a syntax parser to obtain the check result; If the verification result indicates that the verification has failed, a first prompt message is issued, wherein the first prompt message is used to indicate that the query statement has a syntax error; If the verification result indicates that the verification was successful, the execution of the query statement is triggered.

7. The method according to claim 1, characterized in that, After triggering the execution of the query statement, obtaining the execution result of the query statement, and determining the execution result of the query statement as the query result of the investigation subtask, the method further includes: If the query result of the investigation subtask is empty, a second prompt message is issued, wherein the second prompt message is used to indicate that the query has no results; Adjust the time range or keywords in the prompts of the investigation sub-tasks to obtain updated prompts; Based on the updated prompt words, the step of inputting the prompt words into the pre-trained language model is performed until the query result of the investigation subtask is not empty, or the number of re-executions is greater than or equal to the execution count threshold. If the number of re-executions is greater than or equal to the execution count threshold, a third prompt message is issued, wherein the third prompt message is used to indicate that the investigation subtask query failed.

8. A fault diagnosis system, characterized in that, include: The troubleshooting template matching module is used to receive input natural language text and determine the target fault troubleshooting template that matches the natural language text from a preset operation and maintenance program library. The natural language text is the text used to troubleshoot system faults. The troubleshooting process orchestration engine is used to extract the troubleshooting step sequence from the target fault troubleshooting template, transform the troubleshooting step sequence into multiple troubleshooting sub-tasks, and determine the fault troubleshooting result of the system based on the query results of the multiple troubleshooting sub-tasks. A context manager is used to construct prompts for each of the aforementioned investigation subtasks; A pre-trained language model is used to receive prompt words for each of the investigation sub-tasks and process them to obtain the query statement of the investigation sub-task, wherein the number of parameters of the pre-trained language model is smaller than that of a large language model. The heterogeneous data adaptation layer is used to convert the query statement into a query statement corresponding to each data source, obtain the execution result of the query statement, determine the execution result of the query statement as the query result of the investigation subtask, and send the query result to the investigation process orchestration engine.

9. A fault diagnosis device, characterized in that, include: The acquisition unit is used to acquire the target fault troubleshooting template and extract the troubleshooting step sequence from the target fault troubleshooting template; The conversion unit is used to convert the sequence of investigation steps into multiple investigation sub-tasks through the investigation process orchestration engine, and to construct prompt words for each investigation sub-task for each investigation sub-task. An input unit is used to input the prompt words into a pre-trained language model and process them to obtain the query statement of the investigation subtask, wherein the number of parameters of the pre-trained language model is smaller than that of a large language model. A triggering unit is used to trigger the execution of the query statement, obtain the execution result of the query statement, and determine the execution result of the query statement as the query result of the investigation subtask. The first determining unit is used to determine the system's fault investigation results based on the query results of the multiple investigation sub-tasks.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the troubleshooting method according to any one of claims 1 to 7.

Images