Graph database fault query simplification method and device based on large language model

Abstract

The application discloses a large language model-based graph database fault query simplification method and device, and belongs to the technical field of computer software, comprising: obtaining an original query statement triggering a graph database crash and associated crash information, and constructing an iteration control architecture for managing query simplification, execution and verification processes; inputting the original query statement and the crash information into a large language model so that the large language model generates a simplified query statement according to a preset simplification rule set; executing the simplified query statement and detecting whether the graph database crashes again; based on the execution and detection results, performing state updating and iteration loop control through the iteration control architecture; and when a preset termination condition is met, outputting a minimized query statement triggering the graph database crash. The application significantly reduces the need for manual intervention, has high automation, improves simplification efficiency, is compatible with various LLM models and graph database systems, and has good scalability and adaptability.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and in particular to a simplified method and apparatus for fault querying of graph databases based on large language models. Background Technology

[0002] In the field of graph databases, as data scales continue to expand and query complexity increases, query statements often involve multi-level path matching, expression calculation, and conditional filtering. Such complex queries are prone to causing database server anomalies, such as memory overflows, type mismatches, or optimizer errors, leading to system crashes. To identify potential stability defects in databases, the industry commonly uses fuzzing to automatically generate a large number of complex queries to test database services. While fuzzing can generate test queries that trigger service failures, analyzing such crashes still relies on manual intervention during actual development and maintenance. This includes checking crash queries, backtracking stack traces, and analyzing system logs. Furthermore, it requires multiple trial-and-error processes to gradually simplify the queries and construct query cases that can reproduce the minimum crash scenario. This process is time-consuming, labor-intensive, inefficient, and heavily reliant on the experience of domain experts.

[0003] Existing query analysis tools and debuggers are mostly limited to static checks and cannot automatically verify whether simplified queries can still effectively trigger the original crash issue. In addition, traditional methods lack intelligent reasoning capabilities for query structures and are difficult to systematically apply rules such as removing unused variables, simplifying path patterns, or optimizing expression structures, thus failing to achieve efficient and reliable query minimization.

[0004] Therefore, a simplified fault query method that combines automation and intelligence is needed to improve the accuracy and efficiency of fault diagnosis in graph databases. Summary of the Invention

[0005] The purpose of this invention is to provide a simplified method and apparatus for graph database fault query based on a large language model, so as to solve the problems of long time consumption and low efficiency caused by the heavy reliance on domain expert experience in existing graph database fault query simplification methods, the inability to automatically verify whether the simplified query can effectively trigger the original crash, and the lack of intelligent reasoning ability on the query structure.

[0006] To achieve the above objectives, this application adopts the following technical solution:

[0007] This application presents a simplified method for fault querying in graph databases based on large language models, comprising the following steps:

[0008] Obtain the original query statement that triggered the graph database crash and its associated crash information, and build an iterative control architecture for managing the query simplification, execution and verification process;

[0009] The original query statement and crash information are input into a large language model so that the large language model can generate a simplified query statement according to a preset set of simplified rules.

[0010] Execute the simplified query statement and check if the graph database crashes again;

[0011] Based on the execution and detection results, state updates and iterative loop control are performed through the iterative control architecture.

[0012] When the preset termination condition is met, output the minimized query statement that triggers the graph database crash.

[0013] Preferably, the iterative control architecture is a directed workflow state graph, including query simplification nodes, query execution nodes, state update nodes, and iterative control nodes.

[0014] Preferably, the large language model is domain-adaptive fine-tuned to analyze the cause of the crash based on the crash information and generate simplified query statements that retain the original crash semantics.

[0015] Preferably, the simplified rule set includes constraint rules and multiple simplified rules arranged in descending order of priority;

[0016] The simplification rules include: removing unused variables, simplifying path patterns, removing redundant expression elements or complete statements, and simplifying label or attribute filtering conditions.

[0017] The constraints include: each simplification operation applies only to one statement element in the query, optimizer hints and instance selection statements are preserved, and original variable names, label names, attribute names, and expression operators are not changed.

[0018] Preferably, the state update and iterative loop control includes:

[0019] If the simplified query statement does not cause a crash after execution, the simplified query statement of the previous round is output as the minimized query statement.

[0020] If the simplified query statement causes a crash after execution, then determine whether the length of the current simplified query statement is greater than a set threshold.

[0021] If the value exceeds the set threshold, the current simplified query statement will be used as the input for a new round of iterations to continue simplification.

[0022] If the value is not greater than the set threshold, the termination condition is determined to be met and the minimized query statement is output.

[0023] Preferably, the termination condition includes at least one of the following: the length of the simplified query statement is less than a set threshold, the number of iterations reaches the upper limit, and the simplified query statement no longer triggers the graph database to crash.

[0024] Preferably, the simplified query statement is executed by calling an external tool through the model context protocol, and the session history is compressed after execution.

[0025] Preferably, the iterative control architecture supports branch selection and cyclic execution based on execution results, and dynamically determines the subsequent iteration path based on the crash detection results.

[0026] A simplified fault query device for graph databases based on large language models includes:

[0027] The information processing module is used to obtain the original query statement that triggered the graph database crash and its associated crash information, and to build an iterative control architecture for managing the query simplification, execution and verification process;

[0028] The query simplification module is used to input the original query statement and crash information into a large language model, so that the large language model can generate a simplified query statement according to a preset simplification rule set.

[0029] The execution detection module is used to execute the simplified query statement and detect whether the graph database has crashed again;

[0030] The iterative control module is used to perform state updates and iterative loop control based on the execution and detection results through the iterative control architecture.

[0031] The result output module is used to output a minimized query statement that triggers the graph database crash when a preset termination condition is met.

[0032] An electronic device includes a memory and a processor, the memory being used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement a simplified method for fault querying of a graph database based on a large language model as described in any one of the preceding descriptions.

[0033] A computer-readable storage medium storing a computer program that, when executed by a computer, implements a simplified method for fault querying of a graph database based on a large language model, as described in any one of the preceding descriptions.

[0034] The present invention has the following beneficial effects:

[0035] This application leverages the reasoning capabilities of the LLM model to automatically generate simplified query statements and integrates external tools via the MCP protocol to achieve real-time query execution and crash detection. The system can iteratively optimize queries until a minimal query statement that can trigger a failure is obtained. This method significantly reduces the need for manual intervention, has a high degree of automation, and improves simplification efficiency. It is also compatible with various LLM models and graph database systems, exhibiting good scalability and adaptability. Attached Figure Description

[0036] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0037] Figure 1 This is a flowchart of a simplified method for fault querying in a graph database based on a large language model, provided in an embodiment of this application.

[0038] Figure 2 This is a schematic diagram of the overall architecture of an embodiment of this application;

[0039] Figure 3 This is a schematic diagram of the workflow state diagram in the embodiments of this application;

[0040] Figure 4 This is a schematic diagram of the structure of a simplified fault query device for graph databases based on a large language model, provided in an embodiment of this application.

[0041] Figure 5 This is a schematic diagram of an electronic device that implements a simplified method for fault querying of graph databases based on a large language model, as provided in an embodiment of this application. Detailed Implementation

[0042] To make the technical solution of this application clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The terms "first," "second," etc., in the claims and specification 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 terms can be used interchangeably where appropriate. This is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of units is not necessarily limited to those units, but may include other units not explicitly listed or inherent to these processes, methods, products, or apparatuses.

[0043] Definitions:

[0044] Query statement: A query language statement used in graph databases, such as a query based on ISO GQL (GraphQuery Language), used to match, traverse, and manipulate graph data.

[0045] Crash: This refers to the abnormal termination of a graph database server (such as the graphd process) while executing a query, usually accompanied by a core dump and error logs.

[0046] Large Language Models (LLMs): A type of natural language processing model based on deep learning that can perform reasoning, generate code, and analyze text, such as models like Azure OpenAI and DeepSeek.

[0047] Model Context Protocol (MCP): A protocol that extends the operational capabilities of LLM for interaction between LLM and external tools (such as database clients), supporting tool invocation and response processing.

[0048] LangGraph: A workflow engine for building and managing state-based graph execution flows, supporting nodes, edges, and conditional branches.

[0049] Simplified Query: Gradually removes redundant elements (such as unused variables, path patterns, expressions, etc.) from the original crash query, but retains the query version with the core semantics that caused the crash.

[0050] Crash Stack: The call stack information generated when a crash occurs, used to analyze the location of the exception.

[0051] Crash Log: Error messages and diagnostic information recorded when a crash occurs.

[0052] like Figure 1 and Figure 2 As shown, this disclosure provides a simplified method for fault querying of graph databases based on large language models, including the following steps S110-S150.

[0053] S110. Obtain the original query statement that triggered the graph database crash and its associated crash information, and build an iterative control architecture for managing the query simplification, execution and verification process.

[0054] In the initial phase, the system receives the original query statement that caused the graph database to crash, along with related crash information, including critical data such as crash stacks and crash logs. This crash information provides crucial contextual information for the Large Language Model (LLM), assisting the LLM model in automatically inferring the potential causes of the graph database crash. For example, by analyzing the crash stack, the LLM model can clearly identify that the crash occurred at a specific filter node and infer that it was triggered by a specific WHERE condition. This allows for targeted retention or simplification of relevant filter conditions during subsequent query simplification, thereby improving simplification efficiency.

[0055] Based on the original query statements and crash information, the system also utilizes the LangGraph workflow engine to build an iterative control architecture to coordinate the entire process of query simplification, execution, and verification. This architecture defines the state transition rules for a series of operations from input reception and LLM invocation to MCP tool collaboration, ensuring that each component works collaboratively along a predetermined path to achieve gradual simplification of crash queries and root cause localization.

[0056] Furthermore, the iterative control architecture is a directed workflow state graph, including query simplification nodes, query execution nodes, state update nodes, and iterative control nodes.

[0057] In this embodiment of the disclosure, the iterative control architecture is presented in the form of a directed workflow state diagram, the structure of which is as follows: Figure 3 As shown in the diagram, this state diagram contains the following core nodes: start, assistant, tools, post-processing hook, try_again, and end. The assistant, also known as the query simplification node, sends the received raw query and crash information to the domain-adaptive fine-tuned LLM model for query simplification. The tools, also known as the query execution node, executes the simplified query using external tools via the MCP protocol. The post_tools_hook, also known as the state update node, updates the system state based on the execution results returned by the external tools. The try_again, also known as the iteration control node, determines whether the length of the current simplified query exceeds a set threshold; if so, it returns the query to the assistant node for further simplification.

[0058] S120. Input the original query statement and crash information into the large language model so that the large language model can generate a simplified query statement according to the preset simplified rule set.

[0059] After the workflow starts, beginning at the start node, it receives the original query statement and crash information from the system and passes this information to the assistant node according to the path defined by the architecture. In the assistant node, the LLM model, based on its powerful reasoning capabilities and domain-specific fine-tuning knowledge, analyzes the data using user-provided prompts (including a pre-defined set of simplification rules). The model first infers the possible causes of the crash based on the crash information (such as stack traces and crash logs), then simplifies the original query while preserving its semantics according to the simplification rules, generating a simplified query statement and outputting the rationale for each step of the change.

[0060] It's important to note that the output of the LLM model falls into two categories. In one category, if the LLM model determines that the original query statement is already in its simplest form and requires no further simplification, it directly outputs the original query statement. In the other category, if the LLM model performs a simplification operation on the original query statement, its output will include, in addition to the simplified query statement, a tool invocation request containing the name of the external tool to be invoked and its related information, for use by subsequent nodes for execution and verification.

[0061] Furthermore, the simplified rule set includes constraint rules and multiple simplified rules arranged in descending order of priority;

[0062] The simplification rules include: removing unused variables, simplifying path patterns, removing redundant expression elements or complete statements, and simplifying tag or attribute filtering conditions.

[0063] The constraints include: each simplification operation applies only to one statement element in the query, optimizer hints and instance select statements are preserved, and original variable names, label names, attribute names, and expression operators are not changed.

[0064] Specifically, the simplification rule set consists of constraint rules and a set of simplification rules ordered from highest to lowest priority. The priority order of the simplification rules is as follows: remove unused variables, simplify path patterns, remove redundant expression elements or complete statements, and simplify label or attribute filtering conditions. In practical applications, the system inputs high-priority simplification rules as core prompts into the LLM model to significantly improve the success rate of query simplification. If a simplification operation fails due to semantic conflicts or logical errors, the LLM model will automatically trigger a rollback mechanism to restore the original query state, ensuring the robustness of the process. The constraint rules strictly stipulate that each simplification operation only applies to a single statement element in the query; optimizer hints (such as the OPTIMIZER directive) and instance selection statements must be fully preserved; and modification of any variable names, label names, attribute names, or expression operators is strictly prohibited, thereby ensuring the integrity of query semantics and system compatibility.

[0065] S130. Execute the simplified query statement and check if the graph database crashes again.

[0066] If a simplified query is generated and an external tool needs to be invoked, the process will enter the tools node. In the tools node, the system uses the Model Context Protocol (MCP) to invoke the specified external tool (such as query_and_check_crash) to execute the simplified query and detect whether the graph database exhibits the same crash behavior as the original failure.

[0067] After execution, the process enters the `post_tools_hook` node, which is responsible for compressing the session history to avoid memory overflow due to excessively long context. The interaction history between the system and the LLM model is stored in a message list in chronological order. This historical information provides the LLM model with crucial inference context, helping it understand executed operations and their effectiveness, thereby improving inference accuracy. However, as the number of interaction rounds increases, the context length may exceed reasonable limits. Therefore, the system sends all current historical messages to the LLM, appending an instruction such as "Please summarize the above historical information." The LLM model returns a new summarized message, which the system uses to clear the original message list and uses as the context for the new round of dialogue, thus achieving efficient compression of the session history.

[0068] If the output is the original query statement, there is no need to call the tool. The process will directly enter the try_again node, which will generate a new system prompt and then return to the assistant node.

[0069] S140. Based on the execution and detection results, state updates and iterative loop control are performed through an iterative control architecture.

[0070] The `post_tools_hook` node, as the core of state update and iteration control, directly depends on the execution results of the `tools` node. After receiving execution feedback, this node needs to complete two tasks: state update and iteration loop control.

[0071] In this context, state updates refer to the post_tools_hook node dynamically updating the internal state of the system based on the execution results of the current simplified query (such as whether an original crash was triggered, execution time, and return error type). This state information provides crucial context for subsequent reasoning and decision-making, ensuring that the LLM model and workflow operate based on the latest and most accurate environmental information.

[0072] Iterative loop control refers to the post_tools_hook node determining the next step of the workflow based on the updated state, thereby achieving closed-loop control.

[0073] Furthermore, state updates and iterative loop control are performed, including:

[0074] If the simplified query statement does not cause a crash after execution, the previous simplified query statement is output as the minimized query statement.

[0075] If a crash occurs after executing a simplified query statement, then determine whether the length of the current simplified query statement is greater than a set threshold.

[0076] If the value exceeds the set threshold, the current simplified query statement will be used as the input for a new round of iterations to continue simplification.

[0077] If the value is not greater than the set threshold, the termination condition is determined to be met and the minimized query statement is output.

[0078] Specifically, after the external tool executes the current simplified query statement, the `post_tools_hook` node immediately checks whether the query successfully triggered the original crash of the graph database. If the original crash is not triggered, it means that the current simplified query can no longer reproduce the original failure scenario. The system will determine that the simplified query statement generated in the previous round is a valid result, and then the process enters the `end` node, outputting the simplified query statement obtained in the previous round as the final minimal query statement. If the original crash is successfully triggered, the `post_tools_hook` node will further determine whether the length of the current simplified query statement is greater than a set threshold (e.g., 256 characters). If it is greater than the threshold, the system will update the state and use the current simplified query statement as input for the new round, passing it to the `assistant` node again to continue the simplification operation; if it is not greater than the threshold, the `post_tools_hook` node considers the current simplified query statement to be the minimum crashible query that meets the termination condition, the process enters the `end` node, terminates the iteration, and outputs this minimal query statement.

[0079] The post_tools_hook node effectively acts as the "decision center" of the workflow, transforming execution results into specific control instructions that drive the entire simplified process to iterate efficiently and automatically toward the goal of obtaining the minimum query.

[0080] S150. When the preset termination condition is met, output the minimized query statement that triggers the graph database crash.

[0081] When the system determines that any preset termination condition is met, the current simplified query statement will be output as the minimum crash query (i.e., the minimum query statement that can reproduce the original crash of the graph database).

[0082] Furthermore, the termination conditions include at least one of the following: the length of the simplified query statement is less than a set threshold, the number of iterations reaches the upper limit, and the simplified query statement no longer triggers the graph database to crash.

[0083] In this embodiment of the disclosure, the termination conditions include the following three situations: 1. The length of the current simplified query statement is less than a set threshold (e.g., 256 characters); 2. The number of iterations for simplification has reached a preset upper limit (e.g., 256 times); 3. The current simplified query statement cannot trigger the original crash of the graph database.

[0084] These termination conditions collectively ensure that the system converges efficiently while strictly preserving its crash triggering capability. By dynamically verifying the minimization of queries and crash reproducibility, the system avoids ineffective iterations. The output minimal crash query not only significantly shortens the query length but also fully reproduces the original crash scenario, providing accurate input for problem diagnosis.

[0085] The graph database fault query simplification method provided in this disclosure utilizes the inference capabilities of LLM models to automatically generate simplified query statements. It integrates external tools via the MCP protocol to achieve real-time query execution and crash detection. The system can iteratively optimize the query until the minimum query statement that can trigger a fault is obtained. This method significantly reduces the need for manual intervention, has a high degree of automation, and improves simplification efficiency. It is also compatible with various LLM models (such as Azure OpenAI, LMStudio, and DeepSeek) and graph database systems, exhibiting good scalability and adaptability.

[0086] like Figure 4 As shown in the embodiments of this disclosure, a simplified fault query device for graph databases based on large language models is also provided, including:

[0087] The information processing module is used to obtain the original query statement that triggered the graph database crash and its associated crash information, and to build an iterative control architecture for managing the query simplification, execution and verification process;

[0088] The query simplification module is used to input the original query statement and crash information into the large language model, so that the large language model can generate a simplified query statement according to the preset simplification rule set;

[0089] The execution detection module is used to execute simplified query statements and detect whether the graph database has crashed again;

[0090] The iterative control module is used to perform state updates and iterative loop control based on execution and detection results through an iterative control architecture.

[0091] The results output module is used to output the minimized query statement that triggers a graph database crash when a preset termination condition is met.

[0092] This embodiment is used to implement the method provided in the above embodiments and has the corresponding beneficial effects of the method. Technical details not described in detail in this embodiment can be found in the methods provided in all the foregoing embodiments of this invention.

[0093] like Figure 5 As shown, this disclosure also provides an electronic device, including a memory 501 and a processor 502. The memory 501 is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor 502 to implement the above-described simplified method for fault querying of graph databases based on large language models.

[0094] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the electronic device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0095] A computer-readable storage medium storing a computer program that, when executed by a computer, enables a simplified method for fault querying of a graph database based on a large language model, as described above.

[0096] For example, a computer program can be divided into one or more modules / units. One or more modules / units are stored in memory 501 and executed by processor 502. Data I / O interface transmission is completed by input interface 505 and output interface 506 to complete the present invention. One or more modules / units can be a series of computer program instruction segments capable of performing specific functions. The instruction segments are used to describe the execution process of the computer program in the computer device.

[0097] The computer device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device may include, but is not limited to, a memory 501 and a processor 502. Those skilled in the art will understand that this embodiment is merely an example of a computer device and does not constitute a limitation on the computer device. It may include more or fewer components, or a combination of certain components, or different components. For example, the computer device may also include an input device 507, a network access device, a bus, etc.

[0098] Processor 502 can be a Central Processing Unit (CPU), or other general-purpose processor 502, Digital Signal Processor (DSP), Application Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processor 502 can be a microprocessor 502, or any conventional processor 502, etc.

[0099] The memory 501 can be an internal storage unit of a computer device, such as a hard drive or memory. The memory 501 can also be an external storage device of a computer device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 501 can include both internal and external storage units. The memory 501 is used to store computer programs and other programs and data required by the computer device. The memory 501 can also be used for temporary storage in the output device 508. The aforementioned storage media include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM) 503, random access memory (RAM) 504, discs, or optical discs.

[0100] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A simplified method for fault querying in graph databases based on large language models, characterized in that, Includes the following steps: Obtain the original query statement that triggered the graph database crash and its associated crash information, and build an iterative control architecture for managing the query simplification, execution and verification process; The original query statement and crash information are input into a large language model so that the large language model can generate a simplified query statement according to a preset set of simplified rules. Execute the simplified query statement and check if the graph database crashes again; Based on the execution and detection results, state updates and iterative loop control are performed through the iterative control architecture. When the preset termination condition is met, output the minimized query statement that triggers the graph database to crash; The simplified rule set includes constraint rules and multiple simplified rules arranged in descending order of priority; The simplification rules include: removing unused variables, simplifying path patterns, removing redundant expression elements or complete statements, and simplifying label or attribute filtering conditions. The constraint rules include: each simplification operation only targets one statement element in the query, retains optimizer hints and instance selection statements, and does not change the original variable names, label names, attribute names, and expression operators; The state update and iterative loop control includes: If the simplified query statement does not cause a crash after execution, the simplified query statement of the previous round is output as the minimized query statement. If the simplified query statement causes a crash after execution, then determine whether the length of the current simplified query statement is greater than a set threshold. If the value exceeds the set threshold, the current simplified query statement will be used as the input for a new round of iterations to continue simplification. If the value is not greater than the set threshold, the termination condition is determined to be met and the minimized query statement is output.

2. The simplified method for fault querying in graph databases based on large-scale language models according to claim 1, characterized in that, The iterative control architecture is a directed workflow state graph, including query simplification nodes, query execution nodes, state update nodes, and iterative control nodes.

3. The simplified method for fault querying in graph databases based on large-scale language models according to claim 1, characterized in that, The large language model is fine-tuned for domain adaptation to analyze the cause of the crash based on the crash information and generate simplified query statements that retain the original crash semantics.

4. The simplified method for fault querying in graph databases based on large language models according to claim 1, characterized in that, The termination conditions include at least one of the following: the length of the simplified query statement is less than a set threshold, the number of iterations reaches the upper limit, and the simplified query statement no longer triggers the graph database to crash.

5. The simplified method for fault querying in graph databases based on large language models according to claim 1, characterized in that, The simplified query statement is executed by calling an external tool through the model context protocol, and the session history is compressed after execution.

6. The simplified method for fault querying in graph databases based on large language models according to claim 1, characterized in that, The iterative control architecture supports branch selection and cyclic execution based on execution results, and dynamically determines subsequent iteration paths based on crash detection results.

7. A simplified fault query device for graph databases based on large-scale language models, characterized in that, include: The information processing module is used to obtain the original query statement that triggered the graph database crash and its associated crash information, and to build an iterative control architecture for managing the query simplification, execution and verification process; The query simplification module is used to input the original query statement and crash information into a large language model, so that the large language model can generate a simplified query statement according to a preset simplification rule set. The execution detection module is used to execute the simplified query statement and detect whether the graph database has crashed again; The iterative control module is used to perform state updates and iterative loop control based on the execution and detection results through the iterative control architecture. The result output module is used to output a minimized query statement that triggers the graph database to crash when a preset termination condition is met. The simplified rule set includes constraint rules and multiple simplified rules arranged in descending order of priority; The simplification rules include: removing unused variables, simplifying path patterns, removing redundant expression elements or complete statements, and simplifying label or attribute filtering conditions. The constraint rules include: each simplification operation only targets one statement element in the query, retains optimizer hints and instance selection statements, and does not change the original variable names, label names, attribute names, and expression operators; The state update and iterative loop control includes: If the simplified query statement does not cause a crash after execution, the simplified query statement of the previous round is output as the minimized query statement. If the simplified query statement causes a crash after execution, then determine whether the length of the current simplified query statement is greater than a set threshold. If the value exceeds the set threshold, the current simplified query statement will be used as the input for a new round of iterations to continue simplification. If the value is not greater than the set threshold, the termination condition is determined to be met and the minimized query statement is output.

8. A computer-readable storage medium storing a computer program, characterized in that, The computer program enables the computer to implement, when executed, a simplified method for fault querying of graph databases based on a large language model, as described in any one of claims 1 to 6.

Images