Electric power NL2SQL exploration optimization method based on Monte Carlo tree search

Abstract

The invention belongs to the technical field of data query in the electric power field, and particularly relates to an electric power NL2SQL exploration optimization method based on Monte Carlo tree search. In a large model SQL generation data query task in the electric power field, aiming at the problems that small and medium-sized large language models are difficult to accurately understand query requirements and correct SQL is difficult to generate at one time, a Monte Carlo tree search method is integrated into an SQL generation process, so that the accuracy of SQL generation is improved. Specifically, an NL2SQL task is modeled into a sequence decision problem, an action space conforming to SQL grammar and power business logic is constructed, multiple candidate paths are dynamically explored and evaluated through four stages of selection, extension, simulation and back propagation, and finally the path with the highest accumulated reward is selected to generate an SQL statement.

Description

Technical Field

[0001] This invention belongs to the field of data query technology in the power industry, specifically involving a power NL2SQL (Natural Language to SQL) exploration and optimization method based on Monte Carlo Tree Search (MCTS). Background Technology

[0002] With the development of artificial intelligence technology, the application of Large Language Model (LLM) in the power sector continues to deepen. Significant progress has also been made in developing natural language to SQL (NL2SQL) for power data based on large models. This enables power business personnel to directly complete data queries through natural language commands (such as "query the failure rate of substations in XX region in 2025") without relying on technical personnel or customized systems, thereby alleviating the core pain points of high data access threshold, slow response, and low efficiency in traditional methods.

[0003] Current mature NL2SQL implementation solutions in the power sector typically rely on domain-specific large models and fine-tuning of these models to achieve good results in specific business scenarios. This reliance presents significant implementation obstacles, causing LLM-based NL2SQL to face numerous challenges in practical applications. Its limitations are mainly reflected in the following aspects: (1) High cost: With the increase in the number of model parameters and the enhancement of capabilities, the work of data collection, cleaning, annotation and subsequent fine-tuning and iteration for the power industry has become extremely arduous. The whole process not only consumes a lot of resources and has a long cycle, but also often requires multiple rounds of repeated optimization to obtain relatively ideal performance. In many cases, it is a waste of effort.

[0004] (2) Weak generalization ability: The fine-tuned model is usually highly adapted to specific business scenarios. Once the task requirements or data structure changes (such as switching to a new database table or query logic), it is difficult to migrate effectively. It often requires data preparation and model training again, resulting in a serious lack of flexibility.

[0005] (3) Deployment limitations: In actual production environments, users are limited by computing power and resources, and can usually only deploy LLMs with a small number of parameters. These models have limited performance in complex SQL generation tasks, making it difficult to meet the accuracy and robustness requirements of power businesses, resulting in poor overall performance.

[0006] However, without fine-tuning, small-to-medium parameter models often exhibit limited performance in areas such as domain knowledge understanding and SQL generation capabilities. On the one hand, they lack prior knowledge of power industry terminology, business logic, and database structures, making it difficult to accurately interpret the professional intent in users' natural language. On the other hand, in complex query scenarios (such as multi-table joins, nested subqueries, and aggregation conditions), they are prone to generating SQL statements with grammatical errors or semantic biases, leading to query failures or distorted results. Therefore, effectively improving the NL2SQL capabilities of small-to-medium parameter models in the power sector without relying on large-scale fine-tuning and models with hundreds of billions of parameters has become a key challenge in promoting the implementation of this technology in the power industry.

[0007] To address the aforementioned problems, this invention proposes an exploratory optimization method for power NL2SQL based on Monte Carlo tree search. Summary of the Invention

[0008] To overcome the problems in the prior art, this invention proposes a power NL2SQL exploration optimization method based on Monte Carlo tree search.

[0009] The technical solution of the present invention to solve the above-mentioned technical problems is as follows: This invention provides a power NL2SQL exploration optimization method based on Monte Carlo tree search, comprising the following steps: The NL2SQL task is decomposed into multiple subtasks, and corresponding inference actions are constructed for each subtask to form a structured search space covering all valid SQL. Within the structured search space, Monte Carlo tree search is used to dynamically explore multiple candidate generation paths based on a predefined action space that conforms to SQL syntax and power business logic. The SQL generation path with the highest cumulative reward is selected through a reward evaluation mechanism.

[0010] Furthermore, the predefined action space that conforms to SQL syntax and power business logic includes: problem rewriting action, case retrieval action, table schema exploration action, column value condition matching action, column function identification action, SQL generation action, SQL correction action, and end / termination action.

[0011] Furthermore, the reward evaluation mechanism includes a reward function that comprehensively evaluates SQL compliance, semantic rationality, and result consistency to obtain a comprehensive reward function score, thereby quantifying the quality of the currently generated path and guiding the direction of the Monte Carlo tree search. Specifically, SQL compliance is determined by a pre-set SQL syntax detector to determine whether candidate SQL conforms to standard syntax structures; semantic rationality is determined by SQL correction actions or termination / end actions driven by a large language model; and result consistency includes randomly selecting from the existing set of candidate SQL. kThe statement is processed, and the execution result of the current candidate SQL statement is compared with the extracted statement. k The execution results of each statement are compared to obtain a consistency score.

[0012] Furthermore, the specific actions for problem rewriting, case retrieval, table schema exploration, column value condition matching, column function identification, SQL generation, SQL correction, and termination include: The question rewriting action is used to semantically clarify and standardize the original query, transforming it into a complete and standard natural language question that conforms to the database context. The case retrieval action is used to retrieve similar SQL question and answer examples based on the power historical case knowledge base, as a reference for generating SQL; The table schema exploration action is used to retrieve candidate tables related to the question step by step from values, fields and tables based on the semantic clues of the user's question, and then filter them through the LLM to inject only the simplified table schema information into the LLM context. The column value condition matching action is used to perform semantic alignment and candidate matching between the potential filter values ​​mentioned in the user query and the actual values ​​of the corresponding columns in the database before the SQL is generated. The column function identification action is used in the process of parsing user queries to determine the mathematical and statistical operations that need to be performed, and select the appropriate SQL function to express them accordingly; SQL generation actions are used to input diverse knowledge information obtained from different actions into the LLM to generate SQL query statements for user requirements. SQL correction actions are used to input user questions, SQL statements, and SQL execution results into the LLM, guiding it to make targeted corrections; The end / termination action is invoked when the inference process generates a final SQL query that matches the user's intent and is syntactically correct.

[0013] Furthermore, the problem rewriting action includes: The design problem rewrites the Prompt template. The problem rewrite Prompt template, the original user problem, and the context information are taken as input. The large language model drives the process to obtain the rewritten problem.

[0014] Furthermore, the case retrieval process includes: If the user's original question has been rewritten before the case retrieval is performed, the rewritten question will be used as the user query; otherwise, the original question will be used as the user query. Based on user queries, the system searches the historical power case knowledge base. If similar cases are found, the system further judges and filters the similar cases to evaluate their relevance, semantic consistency and applicability to the current user's question, and outputs reference cases. If no case meets the criteria, output "No reference case found".

[0015] Furthermore, the table pattern exploration actions include: If the question rewriting action has been performed before the table schema exploration, the rewritten question will be used as the user query; otherwise, the original question will be used as the user query. The big language identifies three-level keywords aligned with the database schema from user queries, including table-level keywords, field-level keywords, and value-level keywords. Based on three levels of keywords, searches are performed in the corresponding table knowledge base, field knowledge base, and field value knowledge base to obtain the database schema information most relevant to the user's query.

[0016] Furthermore, the column function identifies actions including: If the question rewriting action has been performed before the column function recognition, the rewritten question will be used as the user query; otherwise, the original question will be used as the user query. The design incorporates a column function recognition Prompt template, user query, and contextual information as input. Driven by a large language model, the result text of the column function recognition is obtained.

[0017] Furthermore, column value condition matching actions include: If the question rewriting action has been performed before the column value condition matching is performed, the rewritten question will be used as the user query; otherwise, the original question will be used as the user query. Design a column value condition matching Prompt template, take the column value condition matching Prompt template, user query and context information as input, use a large language model to drive, and obtain the column value condition matching result text.

[0018] Furthermore, the SQL generation process includes: If the question rewriting action has been performed before the SQL is generated, the rewritten question will be used as the user query; otherwise, the original question will be used as the user query. Design an SQL Prompt template, based on the SQL Prompt template, user query and context information as input, and use a large language model to drive the generation of SQL query statements.

[0019] Furthermore, the SQL correction actions include: If the issue rewriting action has been performed before the SQL correction is executed, the rewritten issue will be used as the user query; otherwise, the original issue will be used as the user query. Design an SQL correction prompt template, take the SQL correction prompt template, user query and context information as input, use a large language model to drive, and obtain the corrected SQL query statement.

[0020] Compared with the prior art, the present invention has the following technical effects: (1) Exploration and optimization method of power NL2SQL based on Monte Carlo tree search: The generation process of natural language to SQL (NL2SQL) is modeled as a sequential decision problem. Monte Carlo tree search is used to dynamically explore multiple candidate generation paths in a predefined action space that conforms to SQL syntax and power business logic. The best SQL generation path and SQL in the tree are selected by the reward function.

[0021] (2) SQL action space construction method in the power field: Based on the business knowledge of the power field and the table schema, field semantics and typical query patterns of the database, eight SQL generation actions and action sequence constraints (such as question rewriting, table schema exploration, column value condition matching, case retrieval, etc.) are defined to constrain the search space and improve generation efficiency and accuracy.

[0022] (3) Design of multi-dimensional reward function for power scenarios: Combining real-time feedback of LLM and rule engine, candidate SQL paths are evaluated and scored from three dimensions: syntax compliance, semantic rationality and result consistency, to guide the backtracking and optimization direction of MCTS. Attached Figure Description

[0023] To more clearly illustrate the technical solutions and advantages in the embodiments of the present invention 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 A simplified diagram of the Monte Carlo search tree; Figure 2 This is a flowchart of the MCTS-SQL method proposed in this invention; Figure 3 This demonstrates an example of rewriting a Prompt template based on a question; Figure 4 This demonstrates an example of the content of the case judgment Prompt template; Figure 5 This demonstrates an example of a keyword extraction Prompt template. Figure 6 This demonstrates an example of a table-patterned Prompt template for filtering. Figure 7 This shows an example of a Prompt template for matching column value conditions; Figure 8 This demonstrates an example of using column functions to identify Prompt templates; Figure 9 This demonstrates an example of generating a Prompt template using SQL. Figure 10 This shows an example of the SQL correction prompt template. Detailed Implementation

[0025] To further illustrate the technical means and effects adopted by the present invention to achieve its intended purpose, the specific implementation methods, structures, features, and effects of the technical solutions proposed according to the present invention are described in detail below with reference to the accompanying drawings and preferred embodiments. Specific features, structures, or characteristics in one or more embodiments may be combined in any suitable form. Unless otherwise defined, all technical and scientific terms used in this invention have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0026] In large-scale SQL generation data query tasks in the power industry, to address the problem that large language models struggle to accurately understand query requirements and generate correct SQL on the first attempt, this invention incorporates the Monte Carlo tree search method into the SQL generation solution process, thereby improving the accuracy of SQL generation. By modeling the natural language to SQL generation process as a sequential decision problem, a search space is constructed using a pre-defined series of actions conforming to SQL syntax and power business logic. Multiple candidate generation paths are dynamically explored and evaluated through four steps: selection, expansion, simulation, and backpropagation, and the optimal SQL generation path is selected.

[0027] Specifically, this method fully leverages the heuristic search capabilities of the Monte Carlo tree search method, integrates structured knowledge in the power sector (such as table schemas and table relationships) with real-time feedback from LLM, and performs multiple rounds of simulation, evaluation, and backtracking optimization to ensure the syntax compliance, result consistency, and semantic rationality of SQL. Under the practical constraints of limited model capabilities, this invention transforms the SQL generation paradigm from "relying on a single high-quality output" to "exploring multiple candidate paths and making optimal decisions," thereby improving the accuracy, robustness, and generalization ability of small- to medium-sized models in power scenarios without relying on large-parameter models or complex fine-tuning.

[0028] In this embodiment, refer to Figures 1-10 This paper presents an exploratory optimization method for power NL2SQL based on Monte Carlo tree search, which includes the following steps: The NL2SQL task is decomposed into multiple subtasks, and corresponding inference actions are constructed for each subtask to form a structured search space covering all valid SQL. Within the structured search space, Monte Carlo tree search is used to dynamically explore multiple candidate generation paths based on a predefined action space that conforms to SQL syntax and power business logic. The SQL generation path with the highest cumulative reward is selected through a reward evaluation mechanism.

[0029] The following is a detailed explanation of each of the above steps: Step 100: Decompose the NL2SQL task into multiple subtasks, construct corresponding reasoning actions for each subtask, and form a structured search space with a tree model as the core.

[0030] In this embodiment, the NL2SQL task is decomposed into multiple subtasks, and corresponding inference actions are constructed for each subtask, thereby constructing a structured search space.

[0031] Based on this, the task of generating a complete SQL statement "once" is transformed into the problem of searching for the optimal generation path in the search space, where the search space S contains all valid SQL query statements for user question q under a given database D, and is denoted as a tree model: ; in, This represents a directed graph used to model the generation process of SQL query statements. V is a set of nodes, each node... This represents the state at a specific point in the SQL construction process, including generated SQL fragments, rewritten problem results, table schema information, and context state; the root node is... It contains the user's original question q and the table schema information of database D; leaf nodes This indicates a completed SQL query or that execution has terminated. E is the set of edges, where each edge... It represents a specific reasoning action in the process of constructing an SQL query statement, such as question rewriting, case retrieval, table schema exploration, etc., and represents the transition from one state to another.

[0032] From the root node To leaf node The path constitutes a feasible SQL generation trajectory / path, each trajectory consisting of a series of action sequences, ultimately generating... n Candidate SQL set In this process, the selection of each action is determined by the large language model M through sampling or inference within a predefined action space A.

[0033] Specifically, in the SQL inference process, the first... i Step (state) The Monte Carlo tree search method is used to select subsequent actions from the defined action space. Based on the existing reasoning trajectory, the action is executed via LLM to generate the next state. This process can be formally represented as: ; Where M represents the large language model; Indicates starting from the initial state To the current state The complete reasoning action trajectory; For specific actions The LLM prompt is used to guide the LLM to generate the corresponding inference output. See the complete process below. Figure 2 .

[0034] Step 200: Predefined action space that conforms to SQL syntax and power business logic.

[0035] As an example, step 200 specifically includes: Step 210: Based on the characteristics of SQL generation, define multiple different reasoning actions in the action space, including question rewriting action, case retrieval action, table schema exploration action, column value condition matching action, column function identification action, SQL generation action, SQL correction action, and end / termination action.

[0036] Action space A An LLM-driven action set was designed to progressively construct complete and user-relevant SQL query statements through decomposition and incremental reasoning.

[0037] This invention, based on the characteristics of SQL generation, shares the action space. A Eight different reasoning actions are defined in the document: ; The query rewriting process is crucial for NL2SQL tasks. While NL2SQL tasks rely on clear, structured natural language input, user queries often contain ambiguities, missing information, or non-standard terminology due to varying expression habits, professional backgrounds, or vague wording. To improve the LLM's understanding of SQL generation requirements, the original query needs semantic clarification and standardization rewriting. This transforms the query into a more explicit, complete, and database-contextualized standard natural language question, preserving the user's intent. For example, rewriting "Query the substation failure rate in XX region last year" as "Query the substation failure rate in XX region in 2024." This process not only eliminates ambiguity but also lays a solid foundation for subsequent table identification, field mapping, and condition construction.

[0038] Case Retrieval: Based on a historical case knowledge base, this action retrieves past SQL query examples that are highly similar to the current user query in terms of semantics, business scenario, or database structure. By introducing similar cases as contextual references, it not only provides effective pattern demonstrations for the LLM (such as typical table join methods and condition expression habits), but also significantly improves its SQL generation accuracy and robustness under complex or fuzzy queries. Especially in professional fields such as power, historical success cases often contain rich domain knowledge and business logic. Integrating them into the reasoning process helps the model better understand user intent and generate SQL statements that meet actual needs.

[0039] Table schema exploration is a process where, given a database D, there may be hundreds or even thousands of tables, inputting all table schema information into the LLM (Local Management Module) at once would not only easily exceed its context length (token) limit, but also cause information overload, making it difficult for the model to focus on key tables and fields, thus reducing the accuracy of SQL generation. Therefore, this invention introduces a dynamic table schema exploration process: based on semantic clues from the user's question, it progressively retrieves candidate tables related to the question from values, fields, and tables, and then filters them through the LLM, injecting only the simplified table schema information into the LLM context.

[0040] Column Value Matching (COLUMN VALUE MATCH) action. In NL2SQL tasks, many SQL generation errors stem from inaccurate column value identification or improperly constructed filter conditions. For example, mismapping "East China" as a non-existent enumeration value, or omitting key filtering conditions. To alleviate these problems, this invention designs a column value matching action. Before officially generating the SQL, the LLM proactively performs semantic alignment and candidate matching between the potential filter values ​​mentioned in the user query (such as time, location, device name, etc.) and the actual values ​​of the corresponding columns in the database.

[0041] Column Function Identification: In the power industry, user questions often involve calculations of specific metrics, such as total electricity consumption, average load, and maximum load. Therefore, accurately identifying and applying appropriate aggregate functions (such as SUM, AVG, MAX, etc.) and scalar functions (such as ROUND, POWER, etc.) is crucial when generating SQL queries. This invention, based on LLM design, features a dedicated column function identification action that intelligently determines the required mathematical and statistical operations during user query parsing and selects the appropriate SQL function accordingly.

[0042] SQL Generation Action: Design SQL generation actions to input diverse knowledge information obtained from different actions into the LLM and generate the SQL query statements required by the user.

[0043] SQL Revision Action. Faced with complex query requirements, LLMs often struggle to generate syntactically correct and semantically accurate SQL statements in one go. To address this, this invention designs an SQL Revision action, constructing a closed-loop feedback mechanism that inputs user questions, SQL statements, and SQL execution results into the LLM, guiding it to perform targeted corrections.

[0044] : Termination action. The termination action is invoked when the inference process generates a final SQL query that matches the user's intent and is syntactically correct, marking the completion of the current inference trajectory.

[0045] Step 211: Problem rewriting action: The question rewriting action aims to optimize, enrich, and rewrite the user's original question statement, making it clearer, more explicit, and more structured, thus better guiding the generation of SQL query statements. This action is driven by the large language model M, and the question rewriting Prompt template is designed as follows: (See Figure 3 ).

[0046] In this implementation, the following standards are followed for Prompt templates, such as the design problem rewriting Prompt template and the design case judgment Prompt template: ; in, This represents the complete prompt, which is the sequence of natural language instructions input into the large language model M; Indicates task instructions ( Instruction This clearly specifies the operations that the model needs to perform, such as a series of instructions for setting roles, setting task objectives, and setting types; Represents context information ( Context (Optional) Provides task-related background knowledge, user intent, dialogue history, time or other domain knowledge to enhance the model's understanding of the current request; Example sample ( Examples ), in a small sample size ( few-shot prompting The input-output examples introduced in ) are used to demonstrate the expected response format or inference path, and are optional; Representing constraints ( Restrictions This specifies the format, style, length, language, or other restrictive requirements that the output of the current SQL generation task should meet; This represents a structured composition operation used for text concatenation.

[0047] The problem rewriting action can then be represented formally as: ; in, This indicates the problem after rewriting; This indicates that contextual information needs to be embedded in the prompt words, including business rules, user information, and the current date in the question rewriting.

[0048] Step 212: Case retrieval action: Case retrieval aims to retrieve information from a case knowledge base. The system identifies historical case information most similar to the user's question and provides it as auxiliary context to the large language model to enhance its understanding of query intent and database structure, thereby generating corresponding SQL query statements more accurately.

[0049] If the action was performed before the case retrieval was executed. Then use the rewritten version. Use it as a search query; otherwise, use the original question. This process can be formally represented as: ; ; in, This represents a search query statement; This represents a knowledge base containing historical questions and SQL statements. Indicates the first in the knowledge base i A historical issue, This represents the SQL statement corresponding to the historical issue. n This represents the total number of historical question-SQL statement pairs in the case knowledge base. i Indicates an index variable; This represents the model parameters used to calculate semantic similarity, including the embedding model, similarity threshold, etc. This represents the knowledge base factory function, which is responsible for uniformly scheduling the retrieval process. This represents the set of relevant case text blocks retrieved from the knowledge base.

[0050] If the relevant case text block set If not empty, the retrieved similar cases are further judged and filtered to evaluate their relevance, semantic consistency, and applicability to the current user's question. This process aims to identify the most matching example from the candidate cases as a reference for generating SQL. The case judgment Prompt template is designed as follows: Formally, it can be expressed as: ; in, The similarity level is represented by several grades. arrive Four levels; To indicate contextual information, the case judgment includes the current date and relevant case text blocks. And the table format / schema information of the tables involved in the SQL in the example text block. See details... Figure 4 Case judgment prompts.

[0051] Through parallel mechanisms, the LLM is driven to process relevant case text blocks in parallel. Perform case judgment operations on each text block to obtain a set of similarity levels. This indicates a similarity level of 1. A collection of cases, among which The final output reference case will then adopt the following logic: ; in, Filter the logic functions to define reference cases; Indicates the similarity level as The number of case text blocks; Indicates from Each level is In the given cases, at most n cases can be selected as reference cases for output; if no cases meet the conditions, then the reference case is None.

[0052] pass Filtering logic, final output reference case .

[0053] Step 213: Table Pattern Exploration Action: The table schema exploration process (also known as table schema discovery) aims to accurately identify the tables and their structural information most relevant to the user's problem from a large-scale database schema. This avoids misunderstandings or exceeding context length limits when generating SQL due to excessive redundant tables. The table schema exploration process mainly consists of two parts: three-level keyword extraction and table schema retrieval.

[0054] Three-level keyword extraction aims to structurally identify three types of key semantic elements aligned with the database schema from user questions using LLM: table-level keywords (corresponding to potentially relevant data tables), field-level keywords (corresponding to columns or attributes within tables), and value-level keywords (corresponding to specific query conditions or instance values). To improve recall and enhance semantic generalization, this process allows for synonym expansion or normalization of keywords and the repetition of the same keyword at different levels.

[0055] (1) Keyword extraction: This process is driven by LLM, designing a keyword extraction Prompt template. (See Figure 5 If an action has already been performed before this action is performed. Then use the rewritten version. Use keywords from the user's question; otherwise, use the original question. This process can be formally represented as: ; ; in, This represents the extracted third-level keywords; This represents a search query statement.

[0056] (2) Table pattern retrieval: From the extracted third-level keywords Extracting keywords from the table Field keywords Sum of keywords The system then searches three corresponding structured knowledge bases to retrieve the database schema information most relevant to the user's question. The three knowledge bases are the table knowledge bases corresponding to database D. Field knowledge base With field value knowledge base This process can be formally represented as: ; ; ; in, , and These represent the sets of tables, fields, and values ​​retrieved from the corresponding knowledge bases. The final selection of tables follows this logic: First, through the set of value information... First, by analyzing the field value information, locate the field to which the field value belongs, and then deduce the table it belongs to based on the field; secondly, directly analyze the set of field information. Derive the table to which the field belongs; finally, synthesize the table information. Field information collection Sum value information set Regarding the inference results for the tables, a statistical voting method was used to count the occurrences of each table, sorted in descending order, and the top_k tables were selected as the candidate table set, denoted as . .

[0057] Initially obtain the candidate table set Then, the required tables are determined using LLM, and the final set of tables is output. The design table-based filter Prompt template is as follows: (See Figure 6 Then, formally, it can be expressed as: ; ; in, The index number of the filtered table; This indicates contextual information; the table schema filter includes user information, time information, and data table information. , The corresponding table index number information.

[0058] Finally passed Retrieve the table schema of the corresponding table to obtain the table schema set. .

[0059] Step 214: Column value condition matching action: The column value condition matching action is primarily designed to match the condition columns in the user's question with the table schema, thereby mitigating issues such as inaccurate column value identification or improperly constructed filtering conditions. This action is mainly driven by LLM, and the column value condition matching Prompt template is designed as follows: (See Figure 7In form, it can be represented as: ; ; in, This represents the text indicating the column value condition matching results in the LLM output; This indicates contextual information, including table schema information in the column value matching conditions. If an action was performed before this action was executed... The table schema information is If not, the table schema information is the full table schema of database D. If it exceeds the LLM context limit, it will be automatically truncated.

[0060] Step 215: Column function identification action: The column function recognition action is driven by LLM. The column function recognition Prompt template is designed as follows: (See Figure 8 In form, it can be represented as: ; ; in, This represents the text representing the column function recognition results output by LLM; This indicates contextual information; the column function identification includes table schema information. If an action was performed before this action was executed... The table schema information is If not, the table schema information is the full table schema of database D. If it exceeds the LLM context limit, it will be automatically truncated.

[0061] Step 216: SQL generation action: The SQL generation action aims to gather information from all actions preceding it and integrate that information to generate an SQL query statement that meets the user's problem requirements using an LLM.

[0062] Design an SQL-generated Prompt template for... (See Figure 9 In form, it can be represented as: ; ; in, This represents the SQL query statement generated by LLM; It represents contextual information, including information generated by all preceding actions, such as table schemas and reference cases.

[0063] Step 217: SQL Correction Action: The SQL correction action aims to review the generated SQL statements and their execution results to determine whether they accurately meet the user's needs. If discrepancies or execution errors are found, the causes are analyzed and the SQL statements are corrected accordingly to ensure the correctness and validity of the query results. Also driven by LLM, the SQL correction Prompt template is... (See Figure 10 In form, it can be represented as: ; ; in, This represents the SQL query statement modified by LLM; This indicates contextual information, including table schema information and actions. of And its execution result information.

[0064] Step 218: End / Terminate Action: Without an LLM driver, as a termination marker, the forward action can only be... or .

[0065] Step 220: Define transition constraints in the action space to constrain the structured order of the SQL generation inference path.

[0066] To ensure logical coherence of actions, transition constraints must be set, and the SQL generation reasoning path must proceed according to a structured order. The constraints are as follows: : , , , ,

[0067] : , , ,

[0068] : , , ,

[0069] : , , ,

[0070] : , , ,

[0071] : ,

[0072] :

[0073] The above represents the set of subsequent executable actions for each action, defining the transition constraints in the action space.

[0074] Step 300: Construct a reward function to evaluate the effectiveness of actions in the Monte Carlo tree search method, quantify the quality of the currently generated path, and guide the search process toward generating better SQL queries.

[0075] In MCTS, the reward function is used to evaluate the effectiveness of actions, aiming to guide the search process towards generating better SQL queries. When generating candidate SQL statements, the reward function comprehensively evaluates three aspects: SQL compliance, semantic rationality, and result consistency, to quantify the quality of the current generated path and guide the search direction of MCTS.

[0076] SQL compliance: The preset SQL syntax detector (based on the sqlglot parser) determines whether the candidate SQL conforms to the standard syntax structure. The output is a binary result: 0 indicates non-compliance and 1 indicates compliance.

[0077] Semantic rationality: from the action or The data is obtained from the large language model and then used for judgment.

[0078] Consistency of results: Randomly sample from the existing set of candidate SQL statements. k The statement, and the execution result of the current candidate SQL statement is compared with this. k The execution results of each sampling statement are compared to obtain a consistency score, calculated using the following formula: ; in, This represents the score of the reward function; Indicates the current candidate SQL statement; It is a conditional function used to determine whether the SQL execution results are consistent; This represents the SQL execution function. and Representing the current candidate SQL statement and the first j The execution results between sampled SQL statements.

[0079] Then the overall reward function score for: ; in, This indicates an indicator function that takes values ​​of 0 and 1. and These are indicator functions representing SQL compliance and semantic reasonableness, respectively. These are weighting coefficients. .

[0080] Step 400: Within the structured search space, leveraging the semantic understanding advantage of LLM, Monte Carlo tree search is used to dynamically explore multiple candidate generation paths in a predefined action space that conforms to SQL syntax and power business logic, and the best SQL generation path and SQL are selected from the tree through a reward function.

[0081] As an example, step 400 specifically includes: Step 410: Based on the four stages of Monte Carlo tree search method selection, expansion, simulation and backpropagation, after setting the number of iterations, collect the complete trajectory / path information of all nodes that reach the end node to form the final trajectory set.

[0082] MCTS-SQL is a SQL generation method based on Monte Carlo tree search. MCTS includes four core stages: Selection, Expansion, Simulation, and Backpropagation.

[0083] (1) Selection stage: From the root node Starting from the initial state, MCTS traverses the existing search tree downwards, recursively selecting child nodes according to the tree strategy until it reaches a leaf node that is not fully expanded or the end node. In each selection step, the algorithm weighs exploration against utilization, prioritizing action branches with high reward estimates or low access frequency, thereby efficiently focusing on potentially high-quality SQL construction paths.

[0084] Specifically, a strategy based on Upper Confidence Bound for Trees (UTC) is adopted. For the current node... v and candidate actions for the current node a Its selection priority is defined as: ; in, Indicates at node v Select actiona The priority of the search tree is used to guide the downward traversal of the search tree during the selection phase; Indicates at node v Execute the action a The cumulative reward score; For action a At the node v The number of times it was accessed, then Represents a node v Total number of visits for all actions; This is the exploration coefficient, used to control the degree of preference for paths that have not been fully explored.

[0085] (2) Expansion phase: During the expansion phase, the tree structure is primarily expanded. If the current node has not been fully expanded (there are untried legal subsequent actions), the action transfer constraint is followed, moving from the global action space. A Filter out all valid action sets suitable for the current state. And for each valid action, a corresponding child node is created, thus pushing the search tree forward one step: ; in, This is the state transition function. Indicates the current state v Next action a The generated new state (i.e., the new child node); Represents a node v The set of child nodes is initially empty and is updated after expansion.

[0086] (3) Simulation phase: The simulation phase is no longer limited to ad-hoc deductions, but dynamically grows a complete SQL generation and reasoning path from the current node to the end node through continuous action execution and state expansion. Each intermediate node on the complete SQL generation and reasoning path is persistently stored in the global search tree, thereby achieving the accumulation and reuse of exploration results across rounds. This phase mainly involves two parts: dynamic path construction and persistent tree updates. ;in, ; ; in, This represents the complete SQL inference path generated during the simulation phase; Indicates the first i Effective movement of the step; Indicates the end or termination of the set of nodes; T This represents the existing global search tree; This represents the updated global search tree.

[0087] (4) Backpropagation phase (backtracking phase): After generating the complete SQL generation path during the simulation phase, the reward score is obtained through the reward function. Then, backpropagation begins. In this stage, the reward signal is propagated back along the simulated path from the end / termination node to the root node layer by layer. The path update formula is: ; ; In the above formula, Represents a node v Total number of visits for all actions; Indicates at node v The above action a The cumulative reward score; Indicates the updated node v Total number of visits for all actions; This indicates the updated node. v Execute the action a The cumulative reward score.

[0088] Through the above four stages, the number of rolling iterations is set. ,go through After each iteration, complete trajectory / path information for all routes reaching the final endpoint is collected to form the final trajectory set. ,in This represents a complete path from the starting point to the ending point.

[0089] Step 420: Select the best SQL based on the final set of trajectories.

[0090] For user queries, all candidate SQL statements are extracted from the final trajectory set, executed, and their execution result consistency score and execution efficiency index are obtained. Then, the two are weighted and combined to calculate the comprehensive evaluation score of each SQL statement, and the one with the highest score is selected as the final SQL statement to respond to the user query.

[0091] This experiment sets up baseline method one and baseline method two. Baseline method one uses the DB-GPT open-source framework. Baseline Method 2 is the Chinese invention patent with publication number CN119739837B entitled "A Multi-Knowledge Link-Driven NL2SQL Problem Enhancement Method", hereinafter referred to as HY-SQL.

[0092] Baseline Method 1 Introduction: DB-GPT is an open-source conversational AI framework based on a large model, focusing on intelligent database interaction scenarios. Its SQL generation capability can accurately parse natural language query intent, support complex SQL requirements such as related queries and aggregation calculations, adapt to multiple data source types, and optimize the generation effect through context awareness and syntax verification mechanisms. It can efficiently output compliant and usable SQL statements, greatly reducing the database operation threshold for non-professionals.

[0093] Baseline Method 2 Introduction: HY-SQL focuses on enhancing and optimizing user questions, integrating multiple domain knowledge bases to interpret and reconstruct user questions that are concise and have strong domain attributes, and removing confusing and interfering items to make the questions clearer and more definite, and more suitable for LLM-driven SQL generation logic; at the same time, relying on a multi-level schema linking mechanism, it accurately locates the target database table corresponding to the user question from a large number of tables in the database, further improving the accuracy of SQL generation.

[0094] Testing area: Electricity marketing.

[0095] Database size: 80+ database tables.

[0096] Large Language Model: Qwen3-30B-A3B-Instruct-2507-FP8.

[0097] Test question: "Query the bad debt write-off information of xx power supply bureau that is in the write-off reporting status, group it by fee type and electricity fee category, and count the total application write-off amount, total bad debt write-off amount, the difference between the two and the ratio of the difference to the total application write-off amount for each group, as well as the number of users and write-off batches involved in the group, and filter out groups with an amount difference greater than 1000 and a ratio greater than 50%, and sort them in descending order by the difference."

[0098] Problem complexity description: This query involves multi-indicator aggregation, cross-table joins, condition filtering, ratio calculation and sorting, requiring the model to accurately understand table schema, field ownership, primary and foreign key relationships and business coding semantics, etc.

[0099] Baseline Method 1 Results: ``` Call LLMClient error, Model server error!code=1, error msg is LLMServer Generate Error, Please CheckErrorInfo. : Error code: 400 - {'error': {'message': "This model's maximum context length is 28000 tokens. However, your request has 122030 input tokens. Please reduce the length of the input messages. None", 'type': 'BadRequestError', 'param': None, 'code':400}} ``` A second attempt was made to reduce the number of database tables by half: ``` SELECT h.fylx AS Fee Type m.dflbdm AS Electricity Billing Categories SUM(h.sqhxje) AS Total amount claimed SUM(m.hzhxje) AS Total bad debt write-off amount, (SUM(h.sqhxje) - SUM(m.hzhxje)) AS Amount Difference, ROUND (SUM(h.sqhxje) - SUM(m.hzhxje)) / NULLIF(SUM(h.sqhxje), 0) 100, 2 AS difference percentage COUNT(DISTINCT h.yhbh) AS Number of users, COUNT(DISTINCT h.hxpc) AS Number of batches to be cancelled FROM zw_hzhxjl h INNER JOIN zw_hzhxmx m ON h.yszwlsh = m.yszwlsh WHERE h.hxztdm = '1' AND h.gddwbm = 'xxx' AND h.dqztdm = '1' GROUP BY h.fylx, m.dflbdm HAVING (SUM(h.sqhxje) - SUM(m.hzhxje))>1000 AND (SUM(h.sqhxje) - SUM(m.hzhxje)) / NULLIF(SUM(h.sqhxje), 0) 100>50; ``` Results generated: The first attempt failed to generate SQL statements because too many table schemas were explored, exceeding the LLM context token limit; the second attempt, after reducing the number of database tables, encountered an illusion problem and could not return valid results. Generation time: 20~30s; Core error: a. Illusion problem: The values ​​of hxztdm, gddwbm and dqztdm are guessed by LLM, and their field values ​​do not match the field values ​​required by semantics. In addition, the fields dqztdm and gddwbm are selected incorrectly. b. Omission of table relationships: Only using yszwlsh to join the two tables ignores necessary join fields such as gzdbh, hxpc, and dqbm, leading to the risk of Cartesian product; c. Logic omission: Due to excessive knowledge of table schemas, the LLM ignores the requirement logic and fails to sort in descending order based on the amount difference.

[0100] Baseline Method 2 Results: ``` SELECT t1.fylxAS Cost Type, t2.dflbdmAS Electricity Bill Category Code SUM(t1.sqhxje)AS Total amount claimed for reimbursement, SUM(t1.hzhxje)AS represents the total amount of bad debt write-offs. SUM(t1.sqhxje) - SUM(t1.hzhxje)AS Amount difference, (SUM(t1.sqhxje) - SUM(t1.hzhxje)) / SUM(t1.sqhxje) Percentage of AS difference (100%) COUNT(DISTINCT t1.yhbh)AS Number of users, COUNT(DISTINCT t1.hxpc)AS Quantity of cancelled batches FROM zw_hzhxjl t1 INNER JOIN zw_hzhxmx t2 ON t1.yszwlsh = t2.yszwlsh WHERE t1.dqbm= xxx AND t1.hxztdm = '2' Group by t1.fylx, t2.dflbdm HAVING (SUM(t1.sqhxje) - SUM(t1.hzhxje))>1000 AND (SUM(t1.sqhxje) - SUM(t1.hzhxje)) / SUM(t1.sqhxje) 100>50 ORDER BY Amount Difference DESC; ``` Result generated: A structural error exists, and no valid result can be returned.

[0101] Generation time: 20~30s.

[0102] Core error: a. Field attribution error: The hzhxje field is actually located in the zw_hzhxmx table, but its value is incorrectly retrieved from the zw_hzhxjl table; the reason is that the Qwen3-30B-A3B-Instruct-2507-FP8 model has limited understanding capabilities, and the excessive number of table fields and single-path SQL generation lead to occasional errors in understanding field attribution.

[0103] b. Omission of table relationships: Only using yszwlsh to join the two tables ignores necessary join fields such as gzdbh, hxpc, and dqbm, leading to the risk of Cartesian product.

[0104] Results of the MCTS-SQL method of this invention: SELECT j.fylxAS Cost Type, m.dflbdmAS Electricity Rate Category Code SUM(j.sqhxje)AS Total amount claimed for reimbursement, SUM(m.hzhxje)AS Total bad debt write-off amount, (SUM(j.sqhxje) - SUM(m.hzhxje))AS Amount difference, (SUM(j.sqhxje) - SUM(m.hzhxje)) / SUM(j.sqhxje) AS (Percentage of difference) COUNT(DISTINCT j.yhbh)AS Number of users, COUNT(DISTINCT j.hxpc)AS Quantity of cancelled batches FROM zw_hzhxjl j INNER JOIN zw_hzhxmx m ON j.yszwlsh = m.yszwlsh AND j.gzdbh = m.gzdbh AND j.hxpc = m.hxpc AND j.dqbm = m.dqbm WHERE j.dqbm = xxx AND j.hxztdm= '2' AND NOT j.yszwlsh IS NULL AND NOT m.yszwlsh IS NULL GROUP BY j.fylx, m.dflbdm HAVING (SUM(j.sqhxje) - SUM(m.hzhxje))>1000 AND (SUM(j.sqhxje) - SUM(m.hzhxje)) / SUM(j.sqhxje)>0.5 ORDER BY Amount Difference DESC Result: SQL generated correctly.

[0105] Generation time: 100s-300s. Depending on the problem complexity and the tree search process, it may take more than 300 seconds.

[0106] In the power sector and for LLM scenarios with small to medium parameter counts, MCTS-SQL outperforms baseline comparison methods for complex problems. The DB-GPT framework struggles to accurately match table schemas to user queries, easily leading to model context exceeding limits, and is more prone to SQL generation failures in small to medium model deployment scenarios. HY-SQL, limited by its model understanding capabilities and lacking a multi-path reasoning mechanism for multi-table schemas and field semantics, is prone to occasional structural errors, causing SQL execution failures or returning incorrect results. This invention, MCTS-SQL, utilizes a search-based structured reasoning mechanism to explore multiple paths and select the optimal one, generating syntactically correct, semantically accurate, and highly executable SQL statements, although this comes at the cost of some efficiency.

[0107] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A power NL2SQL exploration optimization method based on Monte Carlo tree search, characterized in that, Includes the following steps: The NL2SQL task is decomposed into multiple subtasks, and corresponding inference actions are constructed for each subtask to form a structured search space covering all valid SQL. Within the structured search space, Monte Carlo tree search is used to dynamically explore multiple candidate generation paths based on a predefined action space that conforms to SQL syntax and power business logic. The SQL generation path with the highest cumulative reward is selected through a reward evaluation mechanism.

2. The power NL2SQL exploration optimization method based on Monte Carlo tree search according to claim 1, characterized in that, The predefined action space, which conforms to SQL syntax and power business logic, includes: problem rewriting action, case retrieval action, table schema exploration action, column value condition matching action, column function identification action, SQL generation action, SQL correction action, and end / termination action.

3. The power NL2SQL exploration optimization method based on Monte Carlo tree search according to claim 2, characterized in that, The reward evaluation mechanism includes a reward function that comprehensively evaluates SQL compliance, semantic rationality, and result consistency to obtain a comprehensive reward function score, which quantifies the quality of the currently generated path and guides the direction of Monte Carlo tree search. Specifically, SQL compliance is determined by a pre-set SQL syntax detector to determine whether candidate SQL conforms to standard syntax structures; semantic rationality is determined by SQL correction actions or termination / end actions driven by a large language model; and result consistency includes randomly selecting from the existing candidate SQL set. k The statement is processed, and the execution result of the current candidate SQL statement is compared with the extracted statement. k The execution results of each statement are compared to obtain a consistency score.

4. The power NL2SQL exploration optimization method based on Monte Carlo tree search according to claim 2, characterized in that, The actions include: problem rewriting, case retrieval, table schema exploration, column value condition matching, column function identification, SQL generation, SQL correction, and termination. The question rewriting action is used to semantically clarify and standardize the original query, transforming it into a complete and standard natural language question that conforms to the database context. The case retrieval action is used to retrieve similar SQL question and answer examples based on the power historical case knowledge base, as a reference for generating SQL; The table schema exploration action is used to retrieve candidate tables related to the question step by step from values, fields and tables based on the semantic clues of the user's question, and then filter them through the LLM to inject only the simplified table schema information into the LLM context. The column value condition matching action is used to perform semantic alignment and candidate matching between the potential filter values ​​mentioned in the user query and the actual values ​​of the corresponding columns in the database before the SQL is generated. The column function identification action is used in the process of parsing user queries to determine the mathematical and statistical operations that need to be performed, and select the appropriate SQL function to express them accordingly; SQL generation actions are used to input diverse knowledge information obtained from different actions into the LLM to generate SQL query statements for user requirements. SQL correction actions are used to input user questions, SQL statements, and SQL execution results into the LLM, guiding it to make targeted corrections; The end / termination action is invoked when the inference process generates a final SQL query that matches the user's intent and is syntactically correct.

5. The power NL2SQL exploration optimization method based on Monte Carlo tree search according to claim 4, characterized in that, The problem rewriting actions include: The design problem rewrites the Prompt template. The problem rewrite Prompt template, the original user problem, and the context information are taken as input. The large language model drives the process to obtain the rewritten problem.

6. The power NL2SQL exploration optimization method based on Monte Carlo tree search according to claim 4, characterized in that, The case retrieval process includes: If the user's original question has been rewritten before the case retrieval is performed, the rewritten question will be used as the user query; otherwise, the original question will be used as the user query. Based on user queries, the system searches the historical power case knowledge base. If similar cases are found, the system further judges and filters the similar cases to evaluate their relevance, semantic consistency and applicability to the current user's question, and outputs reference cases. If no case meets the criteria, output "No reference case found".

7. The power NL2SQL exploration optimization method based on Monte Carlo tree search according to claim 4, characterized in that, The table pattern exploration actions include: If the question rewriting action has been performed before the table schema exploration, the rewritten question will be used as the user query; otherwise, the original question will be used as the user query. The big language identifies three-level keywords aligned with the database schema from user queries, including table-level keywords, field-level keywords, and value-level keywords. Based on three levels of keywords, searches are performed in the corresponding table knowledge base, field knowledge base, and field value knowledge base to obtain the database schema information most relevant to the user's query.

8. The power NL2SQL exploration optimization method based on Monte Carlo tree search according to claim 4, characterized in that, The column function identifies actions including: If the question rewriting action has been performed before the column function recognition, the rewritten question will be used as the user query; otherwise, the original question will be used as the user query. The design incorporates a column function recognition Prompt template, user query, and contextual information as input. Driven by a large language model, the result text of the column function recognition is obtained.

9. The power NL2SQL exploration optimization method based on Monte Carlo tree search according to claim 4, characterized in that, Column value condition matching actions include: If the question rewriting action has been performed before the column value condition matching is performed, the rewritten question will be used as the user query; otherwise, the original question will be used as the user query. Design a column value condition matching Prompt template, take the column value condition matching Prompt template, user query and context information as input, use a large language model to drive, and obtain the column value condition matching result text.

10. The power NL2SQL exploration optimization method based on Monte Carlo tree search according to claim 4, characterized in that, SQL generation actions include: If the question rewriting action has been performed before the SQL is generated, the rewritten question will be used as the user query; otherwise, the original question will be used as the user query. Design an SQL Prompt template, based on the SQL Prompt template, user query and context information as input, and use a large language model to drive the generation of SQL query statements.

Images