Method for semantic verification and automatic correction of natural language to structured query language

Abstract

The application provides a natural language to structured query language semantic verification and automatic correction method, the method comprises the following steps: receiving the initial SQL code generated based on the natural language question, and taking the SQL code as the SQL code to be verified; obtaining the current SQL code to be verified and its associated context information to form the current state; performing a decision step: based on the decision model trained by reinforcement learning, selecting an action from the action space according to the current state; if the action selected in the decision step is the action of calling the verification tool, then further verifying the current SQL code to be verified by the corresponding verification tool and generating feedback information, and updating the current state according to the feedback information; after the current state is updated, then re-entering the step of performing the decision step until the commit action is selected, and outputting the final SQL code. The above scheme can gradually optimize the semantic correctness of the SQL code, and finally output the SQL code highly consistent with the user's intention.

Description

Technical Field

[0001] This invention relates to the field of database query technology, and in particular to a semantic verification and automatic correction method for converting natural language to structured query language. Background Technology

[0002] In today's digital age, the value of data as a core asset is increasingly prominent, and businesses and individuals rely on Structured Query Language (SQL) to interact with databases and extract key information. However, the high technical barrier to SQL writing poses a significant obstacle for non-technical users, giving rise to Text-to-SQL (TTO) technology. This technology allows users to ask questions in natural language, and the system automatically generates executable SQL code, significantly reducing the complexity of data queries. While advancements in large-scale language modeling technology have improved TTO capabilities, deeper semantic correctness issues are gradually emerging. Existing technologies often generate syntactically correct and executable SQL code, but fail to accurately capture the user's true intent, leading to frequent "silent errors." A "silent error" refers to a piece of SQL code that, while syntactically correct and executable in the database, returns results, but whose internal logic is flawed, thus returning an incorrect answer that does not match the user's intent. For example, a user might want to query "the average salary of employees in the R&D department," but the code queries "the average salary of all employees in the company." Such errors are highly insidious and harmful. Because the database executes without reporting errors, users can easily make decisions based on erroneous data without realizing it, which may lead to serious consequences in critical areas such as finance and healthcare.

[0003] Existing technical solutions for semantic verification mainly fall into two categories. The first category is a self-correcting mechanism based on execution feedback, which relies on database runtime error information: the system executes the generated SQL code, catches errors such as syntax errors or object non-existence, and then feeds the error information and the original code back to the language model for correction. While this method can handle basic syntax issues, its fundamental flaw lies in its complete dependence on the database error reporting mechanism. For silent errors caused by logical intent deviations, since the SQL code is grammatically correct and executes without anomalies, the database cannot provide effective feedback, rendering this type of solution completely ineffective for such errors. The second category is a consistency check scheme based on static rules, which uses preset fixed rules for verification, such as a multi-version SQL code voting mechanism or reverse translation into natural language to compare intent. While this method can identify some logical deviations, its verification strategy is rigid, forcing a uniform check process on all SQL code, ignoring differences in query complexity. This results in a double negative effect: redundant checks are performed for simple queries, wasting computing resources and user waiting time; when facing deep logical errors, limited checking methods are insufficient to cover complex scenarios, leading to verification blind spots. More critically, existing solutions generally suffer from a disconnect between verification and correction phases. The verification phase can only output general error signals, failing to deliver structured diagnostic information, while the correction phase lacks targeted guidance, resulting in inefficient and limited-success-rate trial-and-error processes, much like the blind men and the elephant. Furthermore, the system lacks experience accumulation and evolutionary capabilities, relying on manually written static rules and failing to learn optimal verification paths or efficient correction strategies from historical cases, leading to stagnant processing capabilities. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a semantic verification and automatic correction method for natural language to structured query language, so as to eliminate or improve one or more defects existing in the prior art.

[0005] One aspect of the present invention provides a method for semantic verification and automatic correction from natural language to structured query language, comprising: Receive initial SQL code generated based on a natural language question, and use it as SQL code to be verified; Obtain the SQL code currently to be verified and its associated context information to form the current state; Decision execution step: Based on the decision model trained by reinforcement learning, select an action to execute from the action space according to the current state, wherein the action space includes actions to call different verification tools and submission actions; If the action selected in the execution decision step is to call the verification tool, then the corresponding verification tool will further verify the SQL code to be verified and generate feedback information, and update the current state according to the feedback information; wherein, if the feedback information indicates that the verification failed, the correction of the SQL code to be verified will be triggered and the current state will be updated according to the correction result and the feedback information. After the current state is updated, the process re-enters the execution decision step until the submit action is selected, and the final SQL code is output. The training objective function of the decision model is designed as follows: when the action is to call the verification tool, a negative reward corresponding to the preset execution cost of the verification tool is given; when the action is to submit the action, a corresponding positive or negative reward is given based on the semantic equivalence of the final output SQL code with the standard answer.

[0006] In some embodiments of the present invention, the current state further includes verification history information; The step of updating the current state based on feedback information includes: If the feedback information indicates that the verification is successful, the SQL code to be verified is used as the SQL code in the next state after the current state is updated, and the tool call and the success result are recorded in the verification history information of the next state. If the feedback indicates that the verification failed, the corrected SQL code will be used as the SQL code in the next state, and the tool call and failure result will be recorded in the verification history information of the next state.

[0007] In some embodiments of the present invention, the current state further includes a number of decision steps; The selection submission action includes: When the accumulated number of decision steps reaches a preset threshold, a submit action is selected; wherein, the corresponding decision step count is incremented by one each time a decision step is executed; or, The decision model selects a submission action based on the current state.

[0008] In some embodiments of the present invention, the verification tool includes at least: A reasonableness check tool, configured to check whether the results of SQL code execution conform to preset common sense rules; An intent inspection tool, configured to check whether the query logic of the SQL code is consistent with the intent of natural language questions. Figure 1 To; A behavior checking tool configured to check the correctness of SQL code behavior under boundary data conditions.

[0009] In some embodiments of the present invention, the feedback information includes indications of whether the verification passed or failed, and a structured error diagnosis report, the error diagnosis report including error type and error details; the correction is performed based on the error diagnosis report.

[0010] In some embodiments of the present invention, the generation of the error diagnosis report and / or the execution of the correction process are accomplished by prompting the engineering team to call a large language model or by using a rule-based code transformation engine.

[0011] In some embodiments of the present invention, the training process of the decision model adopts a generalized rejection sampling strategy optimization algorithm, and the training data includes multiple training samples, each training sample including a natural language question, a database schema, an initial erroneous SQL code, and a standard correct SQL code.

[0012] Another aspect of the present invention provides a semantic verification and automatic correction system for natural language to structured query language, including a processor, a memory, and a computer program / instructions stored in the memory, the processor being configured to execute the computer program / instructions, and the system implementing the steps of the method described in any of the preceding claims when the computer program / instructions are executed.

[0013] This invention presents a semantic verification and automatic correction method for converting natural language to structured query language. By introducing a reinforcement learning decision model, it achieves adaptive verification and correction of SQL code generated during the natural language to structured query language conversion process. This method dynamically selects whether to call a verification tool for inspection based on the current state of the SQL code, and corrects problems when they are found, effectively avoiding the omission of "silent errors" and the resource waste caused by fixed strategies in traditional solutions. Through continuous decision-making loops, the semantic correctness of the SQL code can be gradually optimized, ultimately outputting SQL code that is highly consistent with the user's intent, thus improving the reliability of natural language to structured query language conversion.

[0014] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the description, or may be learned by practice of the invention. The objects and other advantages of the invention can be realized and obtained by means of the structures specifically pointed out in the description and drawings.

[0015] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to those specifically described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, are not intended to limit the scope of the invention. The components in the drawings are not drawn to scale but are merely illustrative of the principles of the invention. For ease of illustration and description of certain parts of the invention, corresponding portions in the drawings may be enlarged, i.e., may appear larger relative to other components in an exemplary device actually manufactured according to the invention. In the drawings: Figure 1 This is a flowchart of a semantic verification and automatic correction method for converting natural language to structured query language in one embodiment of the present invention.

[0017] Figure 2 This is a block diagram of a semantic verification and automatic correction system for converting natural language to structured query language, according to an embodiment of the present invention.

[0018] Figure 3 This is a schematic diagram of the training process of a decision model in one embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this invention are used to explain the invention, but are not intended to limit the invention.

[0020] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the structures and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.

[0021] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0022] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection involving an intermediary.

[0023] In the following description, embodiments of the invention will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0024] Figure 1 This is a flowchart of a semantic verification and automatic correction method for converting natural language to structured query language according to an embodiment of the present invention. Figure 1 As shown, the semantic verification and automatic correction method for converting natural language to structured query language includes: Step S101: Receive the initial SQL code generated based on the natural language question, and use it as the SQL code to be verified; Step S102: Obtain the SQL code to be verified and its associated context information to form the current state; Step S103: Execute decision step: Based on the decision model trained by reinforcement learning, select an action to execute from the action space according to the current state, wherein the action space includes actions to call different verification tools and submission actions; Step S104: If the action selected in the execution decision step is to call the verification tool, then the corresponding verification tool further verifies the SQL code to be verified and generates feedback information, and updates the current state according to the feedback information; wherein, if the feedback information indicates that the verification failed, the correction of the SQL code to be verified is triggered and the current state is updated based on the correction result and the feedback information. Step S105: After the current state is updated, the process re-enters the execution decision step until the submit action is selected, and the final SQL code is output.

[0025] The semantic verification and automatic correction method for natural language to structured query language disclosed in this application aims to solve the problem of "silent error" that is common in existing Text-to-SQL technology, and overcome the shortcomings of rigid strategies and low efficiency of existing verification schemes.

[0026] In principle, this application addresses the core decision-making problem of "how to perform verification" by introducing reinforcement learning, an artificial intelligence technology. Instead of presupposing any fixed inspection process, this application abstracts the entire verification and correction process into a Markov Decision Process (MDP) model. Within this mathematical framework, at each step of the verification process, based on the current state (e.g., the SQL code to be verified and its associated context information) and the decision-making strategy (cost-aware strategy) learned by the decision model through extensive training, it decides which action to take next (e.g., choosing to call the verification tool or submitting the code after confirming its correctness). The core of the cost-aware strategy is to dynamically balance "verification cost" and "final accuracy." To achieve this, this application provides a semantic verification toolkit containing various verification tools, each with different verification capabilities and corresponding computational costs. Through reinforcement learning, the decision model learns how to cost-effectively combine these tools based on different input conditions.

[0027] Furthermore, this application addresses the disconnect between "verification" and "correction" in existing technologies. This application designs a closed-loop workflow that tightly couples verification and correction. When the verification tool detects an error, it generates feedback information, such as a structured "error diagnosis report" containing detailed reasons for the error. This report serves as a precise instruction and is passed to a dedicated "automatic correction module." This "diagnose first, then fix" approach makes the correction process highly targeted and efficient. After correction, the new code re-enters the verification loop, forming a complete "verification-diagnosis-correction-re-verification" closed loop until the code is committed.

[0028] The MDP model mentioned above includes a state space, an action space, a state transition function, and a reward function.

[0029] Specifically, the state space S refers to the set of all possible states. In this invention, a state s∈S is defined as a structured data object containing at least the following four key fields: s.sql: a string representing the SQL code to be verified; s.context: context information, i.e., a static object containing natural language and database schema; s.history: a list where each element is a tuple (action, result) recording historical actions and results. For example, (intent check, failure); s.step_count: an integer representing the current decision round.

[0030] Action space A is the set of all choices that the decision model can make in any state. In this invention, it is a discrete, finite set whose elements are string identifiers representing different operations: A = {Submit Action, Reasonableness Check, Intent Check, Behavior Check}. Furthermore, each invocation action a∈A (except for the Submit Action) is associated with a predefined cost value cost(a), for example, cost(Intent Check) = 0.5.

[0031] The state transition function T(s, a)>s' describes which new state s' the system will enter after performing action a in state s. In this invention, this is not a random process, but a deterministic function defined by program logic, the core of which is as follows: If action 'a' is a submit action, then the state transition terminates.

[0032] If action 'a' is a call action, it is validated by the called tool. If the tool returns a 'pass' signal, the new state 's' is calculated as follows: s'.sql = s.sql; s'.context = s.context; s'.history = s.history + [(a, 'pass')]; s'.step_count = s.step_count + 1.

[0033] If the tool returns a 'fail' signal, a correction process is triggered, generating a corrected SQL code new_sql. The new state s' is calculated as follows: s'.sql = new_sql; s'.context = s.context; s'.history = s.history + [(a, 'fail'), ('refine', 'success')] (the history is incremented twice); s'.step_count = s.step_count + 1.

[0034] The reward function R(s, a, s') defines the reward obtained after transitioning from state s to s' by performing action a. In this invention, it is a function that combines immediate cost and sparse termination reward: If action a is a calling action, then R(s, a, s') = -cost(a). That is, the reward is equal to the negative cost of the calling action.

[0035] If action 'a' is a submission action, then R(s, a, s') is calculated by comparing s.sql with the standard answer. If they are semantically equivalent, then R = +10 (or another large positive number); otherwise, R = -10 (or another large negative number).

[0036] In all other cases, the reward is 0.

[0037] In this embodiment, the natural language question can be a data query or operation request submitted by a user in everyday language. The initial SQL code can be a preliminary structured query language code generated based on the natural language question, serving as the starting point for subsequent verification and correction. The initial SQL code can be manually written and input into the system, for example, manually constructed by a database administrator according to user needs. As another implementation, the initial SQL code can be generated by a basic natural language to SQL conversion module, which is only responsible for converting the natural language question into a preliminary SQL syntax structure without performing in-depth semantic analysis. The final SQL code can be the SQL code determined after a series of verification and correction decisions.

[0038] In this embodiment, context information can be auxiliary information related to the SQL code currently being verified, such as the database schema definition, user query history, or other background knowledge related to the current query. The database structure definition refers to the database schema information, including table names, column names, data types, primary keys, foreign keys, indexes, etc., which is the basis for the correct execution of the SQL code. In some embodiments, context information refers to information including natural language processing and the database schema. The current state refers to the complete set of information used to describe the current state of the system during the decision-making process, guiding the decision model in selecting actions. In this embodiment, the current state includes, but is not limited to, the SQL code currently being verified and its associated context information.

[0039] In this embodiment, a decision step refers to the process of selecting an action and updating the state once during the entire verification and correction process. The decision model is a model trained through reinforcement learning that outputs a probability distribution for an action selection or directly outputs an action based on the current state. The action space refers to the set of all possible actions that the decision model can choose to execute at each decision step, such as calling different verification tools or submitting the current SQL code. Verification tools can be modules used to perform specific types of checks on the SQL code, capable of identifying potential semantic errors or logical deviations in the SQL code.

[0040] In this embodiment, the feedback information can be the result returned by the verification tool, indicating whether the verification passed and details of any possible errors. The feedback information can include a simple Boolean value indicating whether the verification passed or failed. If the feedback information indicates verification failure, it triggers the correction of the SQL code currently being verified. This correction process can be performed manually by a user based on the feedback information, or by a pre-defined code conversion module based on simple rules, such as automatically replacing common syntax errors. After the correction is complete, the current state is updated based on the correction result and the feedback information.

[0041] In this embodiment, the training objective function of the decision model is designed as follows: when the action is to call the verification tool, a negative reward corresponding to the preset execution cost of the verification tool is given; when the action is to submit the action, a corresponding positive or negative reward is given based on the semantic equivalence of the final output SQL code with the standard answer. The preset execution cost can be a fixed value, for example, deducting one unit of reward for each call to the verification tool. Semantic equivalence can be determined by human experts comparing the output of the final SQL code with the standard answer.

[0042] The preset execution cost of the verification tool can be determined based on at least one of computational complexity, execution time, and resource consumption. Linking the preset execution cost of the verification tool to at least one objective indicator of computational complexity, execution time, and resource consumption allows the decision model to more accurately perceive and evaluate the actual overhead of different verification tools during training. This avoids the arbitrariness or subjectivity of the preset execution cost and ensures that the setting of negative rewards has solid physical meaning and technical basis. Therefore, the decision model can learn a better decision-making strategy, namely, prioritizing verification tools with lower execution costs while ensuring verification quality, thereby effectively reducing the resource consumption and time cost of the overall verification and correction process, and improving the efficiency and practicality of the method.

[0043] This application introduces a reinforcement learning decision model to achieve adaptive verification and correction of SQL code generated during the natural language to structured query language (NML) conversion process. This method dynamically selects whether to invoke a verification tool based on the current state of the SQL code, and corrects problems as they are discovered, effectively avoiding the omission of "silent errors" and the resource waste caused by fixed strategies in traditional solutions. Through continuous decision-making loops, the system can gradually optimize the semantic correctness of the SQL code, ultimately outputting SQL code highly consistent with the user's intent, thus improving the reliability of the NML conversion.

[0044] In some embodiments of the present invention, the current state further includes verification history information; The step of updating the current state based on feedback information includes: If the feedback information indicates that the verification is successful, the SQL code to be verified is used as the SQL code in the next state after the current state is updated, and the tool call and the success result are recorded in the verification history information of the next state. If the feedback indicates that the verification failed, the corrected SQL code will be used as the SQL code in the next state, and the tool call and failure result will be recorded in the verification history information of the next state.

[0045] In this embodiment, verification history information refers to the record of executed verification actions and their corresponding results during the SQL code verification and correction process. This information is typically stored in the form of a list, where each entry details the verification tool invoked at a specific decision step, the tool's execution result (e.g., verification passed or failed), and may also include key data such as error diagnosis reports that may be generated when verification fails. By maintaining this historical record, the decision model can gain a "memory" of the entire verification process, thereby avoiding the repetition of invalid operations in subsequent decisions and better understanding the current verification stage of the SQL code and the correction paths already attempted.

[0046] Once the verification tool verifies the SQL code to be verified and generates feedback information, it updates the current state and verification history information based on the feedback. Specifically, if the feedback indicates successful verification, the SQL code to be verified is used as the SQL code in the next state, and the verification history information of the next state is appended with the record of this tool call and its success. This means that even if the SQL code has not changed, its verification history is updated, indicating that the code has passed a specific verification. Conversely, if the feedback indicates failed verification, the system triggers a correction to the SQL code to be verified. After correction, the corrected SQL code is used as the SQL code in the next state, and the verification history information of the next state is appended with the record of this tool call and its failure. This update mechanism ensures that the verification history information is always synchronized with the current state of the SQL code, providing the decision model with accurate and real-time historical context.

[0047] By incorporating historical verification information into the current state, the decision-making model can make decisions not only based on the current SQL code and context information but also by fully utilizing past verification experience. The model can learn to identify and avoid repeatedly calling verification tools that have proven invalid or passed, significantly reducing unnecessary computational overhead and time consumption. Furthermore, by analyzing the failure results and correction processes recorded in the verification history, the model can more effectively infer the possible error types in the current SQL code and select the most appropriate verification tool or correction strategy, forming a more targeted and efficient verification and correction path. This effective use of historical information greatly enhances the decision-making intelligence of the reinforcement learning model, making the entire semantic verification and correction process from natural language to structured query language more efficient and accurate, and better able to handle complex and ever-changing SQL code error scenarios.

[0048] In some embodiments of the present invention, the current state further includes a number of decision steps; The selection submission action includes: When the accumulated number of decision steps reaches a preset threshold, a submit action is selected; wherein, the corresponding decision step count is incremented by one each time a decision step is executed; or, The decision model selects a submission action based on the current state.

[0049] In this embodiment, the number of decision steps refers to the total number of decision steps executed by the decision model from the start of the method execution to the current moment. This number of steps, as part of the current state, provides the decision model with quantitative information about the progress of the verification and correction process, helping the model assess its current stage and whether verification needs to continue or be terminated in a timely manner. To ensure the finiteness and controllability of the verification and correction process, this application introduces a rule-based submission mechanism: when the accumulated number of decision steps reaches or exceeds a preset threshold, a submission action will be forced. This preset threshold is a pre-determined maximum allowed number of decision steps, which can be set based on experience, resource constraints, or expectations of the efficiency of the verification and correction process, thereby preventing the verification process from continuing indefinitely and ensuring the finiteness and controllability of the entire method. Simultaneously, each time a decision step is executed, the corresponding decision step count is incremented by one; this accumulation method ensures that the decision step count accurately reflects the actual progress of the verification and correction process.

[0050] Furthermore, the decision model can still select a submission action based on the current state. During training, the decision model learns which current states will yield higher rewards when selecting a submission action. When the model evaluates that the current SQL code is sufficiently optimized, or the cost of continuing verification outweighs the potential benefits, it will autonomously select a submission action based on the current state (including SQL code, context information, verification history information, and number of decision steps, etc.) to output the final SQL code.

[0051] By incorporating the decision-making steps into the current state and introducing a submission mechanism based on a decision-making step threshold, this application effectively solves the problem of decision models potentially getting stuck in infinite loops or over-validating during SQL code semantic verification and correction. When the decision-making steps reach a preset threshold, a forced submission action ensures the finiteness of the verification process, avoiding unnecessary resource consumption and time waste, and improving the robustness and efficiency of the method. Simultaneously, the decision model can still autonomously choose its submission action based on the current state, which maintains sufficient flexibility and intelligence while ensuring an efficiency ceiling, allowing for the output of high-quality SQL code at the optimal time. This submission strategy, combining rule constraints and intelligent decision-making, makes the entire verification and correction process more efficient and controllable, effectively balancing the thoroughness of verification with the economy of resources.

[0052] In some embodiments of the present invention, the verification tool includes at least: A reasonableness check tool, configured to check whether the results of SQL code execution conform to preset common sense rules; An intent inspection tool, configured to check whether the query logic of the SQL code is consistent with the intent of natural language questions. Figure 1 To; A behavior checking tool configured to check the correctness of SQL code behavior under boundary data conditions.

[0053] In this embodiment, the rationality check tool aims to check whether the results of SQL code execution conform to preset common-sense rules. For example, for SQL code that queries age, the result should not be negative; for SQL code that counts quantities, the result should not be a decimal or negative; for SQL code that sums percentages, the result should be close to 100%. The tool can be implemented by: predefining a series of domain-knowledge-based rule sets and comparing the SQL query results using a rule engine; or by using statistical models to analyze historical data, establishing common-sense boundaries for the result distribution, and determining whether the current result is abnormal.

[0054] Intent inspection tools are used to check whether the query logic of SQL code is consistent with the intent of natural language processing. Figure 1 This means the tool needs to understand the semantics of the natural language question and compare it with the query intent expressed by the SQL code. For example, if the natural language question is "find the highest-paid employee," then the SQL query logic should include sorting by salary in descending order and retrieving the first record, rather than calculating the average salary. The tool could be implemented by converting both the natural language question and the SQL code into a unified semantic representation (such as a logical form or abstract syntax tree) and then comparing them; or by using a large language model (LLM) to assess semantic similarity or determine consistency between the two.

[0055] The behavior inspection tool is configured to check the correctness of SQL code behavior under boundary data conditions. Boundary data conditions refer to data scenarios that may cause abnormal or erroneous SQL code behavior, such as an empty database table, a table containing only one record, a large number of NULL values, or numeric fields containing extremely large or small values. This tool constructs or simulates these boundary data conditions, executes the SQL code, and verifies whether its output meets expectations. Its implementation can include: automatically generating a series of boundary test cases and executing the SQL code for each case and checking the results; or using fuzzing techniques to randomly generate a large number of abnormal data inputs to discover potential errors.

[0056] By introducing rationality checking tools, intent checking tools, and behavior checking tools, this application enables multi-dimensional and in-depth semantic verification of SQL code. The rationality checking tool ensures the common-sense correctness of the SQL code execution results, avoiding obvious logical errors; the intent checking tool focuses on the consistency between the SQL code and the semantics of the original natural language question, ensuring the accuracy of the query logic; and the behavior checking tool further enhances the robustness of the SQL code under various extreme or boundary data conditions. The synergistic effect of these specific verification tools allows the decision model to obtain more comprehensive and refined feedback information during the decision-making process, thereby significantly improving the verification efficiency and accuracy of SQL code correction, ultimately ensuring the semantic correctness and reliability of the output SQL code.

[0057] In some embodiments of the present invention, the execution cost of the rationality check tool is lower than that of the intent check tool, and the execution cost of the intent check tool is lower than that of the behavior check tool.

[0058] In this embodiment, differentiated preset execution costs are set for different verification tools: the rationality check tool has the lowest execution cost, followed by the intent check tool, and the behavior check tool has the highest execution cost. This cost-tiering mechanism, combined with the training objective function of the decision model, enables the model to learn a resource-optimized tool invocation strategy during the decision-making process. Specifically, the decision model is incentivized to prioritize the rationality check tool with lower execution costs to quickly capture and correct common, obvious errors, thereby avoiding unnecessary resource consumption. If the initial check passes, the decision model will further consider invoking the intent check tool for deeper semantic verification. Only when the SQL code passes the first two levels of verification, or faces complex problems that are difficult to detect with low-cost tools, will the decision model be guided to invoke the behavior check tool with the highest execution cost for comprehensive and thorough boundary condition verification. This hierarchical tool invocation strategy significantly improves the efficiency of the entire verification and correction process, reduces unnecessary computational overhead and time consumption, and helps the decision model converge to the optimal decision more quickly, ultimately outputting high-quality and semantically correct SQL code.

[0059] In some embodiments of the present invention, the feedback information includes indications of whether the verification passed or failed, and a structured error diagnosis report, the error diagnosis report including error type and error details; the correction is performed based on the error diagnosis report.

[0060] In this embodiment, the feedback information comprises two parts: first, an indication of whether the verification passed or failed, used to quickly determine the verification result; and second, a structured error diagnosis report, which provides detailed error context. The structured error diagnosis report can be a predefined data format, such as a JSON object or an XML document, containing machine-readable error information. The error diagnosis report is further refined, including error type and error details. The error type categorizes the detected problem, such as syntax errors, semantic errors, logical errors, database schema mismatches, data type mismatches, performance issues, or security vulnerabilities. The error details provide a specific description of the error, such as the SQL line number, column number, involved SQL segment, specific error message, and the difference between expected and actual behavior. This information makes the error diagnosis report highly operable. The correction is performed based on the error diagnosis report. This means that the correction mechanism (whether it's an automated correction engine, a rule-based code transformation engine, or correction through a large language model) will parse and utilize the error type and error details provided in the error diagnosis report to guide the correction operation. For example, if the error type is indicated as "syntax error" and the error details specify the exact location of the syntactic defect, the correction mechanism can directly correct the syntax at that location. If the error type is indicated as "semantic error" and the error details indicate that the query logic does not match the intent of the natural language question, the correction mechanism can adjust the query logic based on the semantic deviation information provided in the report.

[0061] For example, if a reasonableness check tool finds that the results do not conform to preset common sense rules (e.g., age over 150 years old, negative number, etc.), the diagnostic report it generates will include: Error type: Invalid result; Error details: The value of field [field name] in the query result is [specific value], which violates the default common sense rule: [specific rule description, such as "age should be between 0-120 years old"].

[0062] The intent inspection tool uses natural language processing technology to extract the core query intent of the user's natural language question and SQL code. If a discrepancy is found, the generated diagnostic report will include: Error type: Query intent mismatch; Error details: The user intent is [the parsing result of the user's question, such as "query the department with the most employees"], but the actual logic of the SQL code is [the parsing result of the SQL code, such as "query the department with the highest average employee salary"]. There is a conflict between the two in [critical operations, such as "aggregate functions"].

[0063] This behavior checking tool simulates database boundary conditions (e.g., the target table is empty or contains a large number of NULL values) and then tests the SQL code's behavior under these conditions. If anomalies are found, it generates a diagnostic report that includes: Error type: Boundary behavior exception; Error details: Under the test conditions [specific boundary condition description, such as "when table [table name] is empty"], the SQL code [abnormal behavior occurs, such as "returned a database error instead of the expected empty result set"].

[0064] By introducing a structured error diagnostic report and clearly defining the error type and details, this application provides precise and actionable guidance for SQL code correction. When the validation tool detects a problem, it no longer simply returns a simple failure indication but provides detailed error context, such as the specific location of the syntax error, the cause of the semantic mismatch, or the type of logical defect. Performing corrections based on this detailed diagnostic report makes the correction process more intelligent and automated, avoiding the inefficiency of blind trial and error or manual troubleshooting. This significantly improves the accuracy and efficiency of corrections, reduces the number of iterations in the validation-correction loop of the decision model, thereby accelerating the convergence from the initial SQL code to the final correct SQL code, and ultimately improving the performance and user experience of the entire semantic validation and correction method from natural language to structured query language.

[0065] In some embodiments of the present invention, the generation of the error diagnosis report and / or the execution of the correction process are accomplished by prompting the engineering team to call a large language model or by using a rule-based code transformation engine.

[0066] In this embodiment, generating an error diagnosis report refers to the process of conducting in-depth analysis of the reasons for SQL code verification failure and outputting key information such as error type, error location, and error details in a structured form. This process aims to provide clear guidance for subsequent corrections. Executing the correction process refers to modifying the SQL code to be verified based on the error information specified in the error diagnosis report to eliminate errors and make it conform to the expected semantics.

[0067] Hint engineering, which utilizes a pre-trained large language model (LLM), is a method for generating error diagnostic reports or correcting SQL code. Taking the correction process as an example, a carefully designed input prompt provides the large language model with task instructions, raw context information including the user's natural language question and database schema, the SQL code to be corrected, and an error diagnostic report (if generated). Leveraging its powerful language understanding and generation capabilities, the large language model analyzes this input information and directly outputs the corrected SQL code. The key to hint engineering lies in constructing effective prompts to guide the large language model to accurately understand the task and generate high-quality output. For example, techniques such as few-shot learning and thought chains can be used to improve its performance.

[0068] A rule-based code transformation engine is a method that generates error diagnostic reports or corrects SQL code using a pre-defined, explicit set of rules. The engine contains a series of rules defined for specific error types and correction patterns. When it receives feedback of a validation failure and / or a preliminary error diagnostic report, the engine parses the SQL code and transforms or modifies it according to the matching rules. For example, if the error diagnostic report indicates that a table alias is misused, there might be a rule to identify and correct this type of name error. This method is characterized by high determinism and strong controllability, and is suitable for handling known errors with clearly defined correction logic.

[0069] In some embodiments of the present invention, the training process of the decision model adopts a generalized rejection sampling strategy optimization algorithm, and the training data includes multiple training samples, each training sample including a natural language question, a database schema, an initial erroneous SQL code, and a standard correct SQL code.

[0070] In this embodiment, the training data includes multiple training samples, each comprising a natural language question, a database schema, initial incorrect SQL code, and standard correct SQL code. This structured training sample provides the decision model with a comprehensive learning context. The natural language question clarifies the user's query intent, the database schema defines the data structure operated on by the SQL code, the initial incorrect SQL code simulates the actual input that the model needs to identify and correct, and the standard correct SQL code serves as the "gold standard" or target output for model learning. These training samples can be constructed in various ways. For example, natural language questions and corresponding correct SQL codes can be extracted from existing natural language to SQL code datasets (such as WikiSQL, Spider, etc.), and initial incorrect SQL codes can be generated by introducing common SQL code errors (such as syntax errors, semantic errors, logical errors, etc.). The database schema can be directly obtained from the database structure provided by the dataset. By constructing a large-scale, diverse training dataset, it can be ensured that the decision model can fully understand natural language questions of varying complexity, database schemas, and various types of SQL code errors, thereby possessing stronger generalization ability in practical applications.

[0071] The training process of the decision model employs the Group Relative Policy Optimization (GRPO) algorithm. GRPO is a reinforcement learning policy optimization algorithm whose core idea is: for the same input, a group of complete decision trajectories is generated using the current policy sampling; the cumulative reward of each trajectory is calculated; and the relative advantage of each trajectory is calculated using the average reward of all trajectories within the group as a benchmark. Subsequently, the algorithm constructs a policy gradient objective function based on this relative advantage value, reinforcing decision actions corresponding to trajectories with cumulative rewards higher than the group average, while suppressing decision actions corresponding to trajectories with rewards lower than the average. This algorithm eliminates the need to train an independent value network to estimate the baseline value; instead, it directly utilizes the statistics sampled within the group as the baseline, significantly reducing computational resource overhead and memory usage during training while maintaining the stability of policy updates. Furthermore, by introducing a KL divergence constraint term between the current policy and the reference policy, the algorithm prevents the policy from deviating excessively from the initial capabilities of the pre-trained language model during updates, ensuring that the decision model retains its language understanding foundation while acquiring the ability to validate and correct decision-making.

[0072] Corresponding to the above method, the present invention also provides a semantic verification and automatic correction system for natural language to structured query language. The system includes a computer device, which includes a processor and a memory. The memory stores computer instructions, and the processor is used to execute the computer instructions stored in the memory. When the computer instructions are executed by the processor, the system implements the steps of the method described above.

[0073] In some embodiments of the present invention, such as Figure 2 As shown, the semantic verification and automatic correction system for converting natural language to structured query language includes: A planner, configured to receive SQL code to be verified generated from a natural language problem and output verified SQL code, is a decision model trained by reinforcement learning. The planner is configured to execute a decision step: based on the decision model trained by reinforcement learning, select an action to execute from the action space according to the current state, wherein the action space includes actions to call different verification tools and submission actions; the current state includes the SQL code to be verified and its associated context information. The semantic verification toolkit contains multiple verification tools, which are configured to verify the SQL code to be verified and generate feedback information in response to the action of calling the verification tool. An automatic correction module is configured to, in response to a verification failure, correct the currently unverified SQL code based on the feedback information and generate corrected SQL code, and then feed the corrected SQL code back to the planner. The planner is also configured to re-enter the execution decision step after the current state is updated, until the submit action is selected and the final SQL code is output.

[0074] The training objective function of the decision model is designed as follows: when the action is to call the verification tool, a negative reward corresponding to the preset execution cost of the verification tool is given; when the action is to submit the action, a corresponding positive or negative reward is given based on the semantic equivalence of the final output SQL code with the standard answer.

[0075] In this embodiment, the planner, the semantic verification toolbox, and the automatic correction module constitute a semantic verification agent. In some embodiments, the system further includes an interactive environment coupled to the planner, the semantic verification toolbox, and the automatic correction module, configured to maintain the current state, execute the action, update the current state based on the feedback information, or call the automatic correction module and update the current state based on the correction result and the feedback information.

[0076] In this embodiment, the system's workflow is as follows: Step 1: The process begins with an external generator, such as a large language model, which generates an initial SQL code based on the user's natural language question and serves as the SQL code to be verified.

[0077] Step 2: The initial SQL code is passed as initial input to the semantic verification agent. Upon receiving the initial SQL code, the decision model within the semantic verification agent initiates the verification loop.

[0078] Step 3: The decision model analyzes the current state and makes a decision. It has two options: Option A (Submit): If the decision model determines, based on its strategy, that the current SQL code is sufficiently credible, it will choose to submit. At this point, the current SQL code is directly output as the verified SQL code, and the entire process ends.

[0079] Option B (Validation): If the decision model believes that the current SQL code needs further inspection, it will choose to call a specific validation tool.

[0080] Step 4: The selected validation tool (e.g., the intent checker) is activated from the semantic validation toolbox and performs its specific check logic on the current SQL code.

[0081] Step 5: After the verification tool completes its execution, two possible results will be produced: Result A (Pass): If the tool returns a pass signal, this signal is relayed back to the decision model. Upon receiving this successful feedback, the decision model updates its internal state (e.g., records "Intent check passed"), and then returns to step 3 to begin a new round of decision-making. At this point, it may choose another tool to continue checking, or it may choose to submit the action due to increased confidence.

[0082] Result B (Failure): If the tool returns a failure signal, this signal, along with detailed error feedback information, will be sent to the auto-correction module.

[0083] Step 6: After receiving the error feedback, the automatic correction module makes targeted modifications to the current SQL code and generates a modified SQL code.

[0084] Step 7: The modified SQL code is sent back to the decision model, replacing the original SQL code. Upon receiving this new version of the SQL code, the decision model returns to Step 3 and begins a new round of verification and decision-making regarding the corrected SQL code. This "decision-verification-correction-re-decision" cycle continues indefinitely.

[0085] Step 8: This iterative process will terminate when one of the following two conditions occurs: 1) The decision model selected the submit action at a certain step; 2) The loop reached the preset maximum number of decision steps to prevent infinite loop.

[0086] Finally, the system will output a verified SQL code.

[0087] In some embodiments of the present invention, such as Figure 3 As shown, the training process of the decision model includes the steps of data collection, reward calculation, storage of experience data, and policy update.

[0088] Data acquisition steps: First, a training dataset is provided, where each sample is a quadruple: (Natural Language Question, Database Schema, Initial Error SQL Code, Standard Correct SQL Code). The initial error SQL code can be generated by an existing, imperfectly performing Text-to-SQL model, while the standard correct SQL is a manually labeled answer that is guaranteed to be 100% correct.

[0089] The semantic verification agent interacts with the interactive environment to generate a complete trajectory data based on the current planner policy. In each round of training, the system takes a sample from the training dataset. Then, according to the current version of the planner policy, steps S1-S5 in the above method embodiment are executed. This complete interaction sequence from start to finish, including the state, action, and immediate reward for each decision step, is fully recorded to form a trajectory data. For example, a trajectory data is (state S0, action A0, reward R0)>(state S1, action A1, reward R1)>...>(state ST, action AT, reward RT). Each (St, At, Rt) tuple corresponds to a decision step of the planner.

[0090] For example, in step 0 (t=0): S0 contains the initial SQL, an empty validation history, and a step count of 0. The planner analyzes S0, makes a decision, and selects action A0 = invoking the intent check. The system executes this action and returns an immediate reward R0 = -0.5 (the cost of the intent check). Suppose the intent check returns "failure" and triggers a "correction" process, generating a new SQL code.

[0091] Step 1 (t=1): S1 contains the new SQL, and the validation history is updated to [(Intent Check, Failure), (Correction, Success)], with a step count of 1. The planner analyzes S1 and, based on the history, finds that the intent check failed last time. This time, it might choose a different action, such as A1 = calling a rationality check. The system executes this action and returns an immediate reward R1 = -0.1 (the cost of the rationality check). Assume the rationality check returns "Pass".

[0092] Step 2 (t=2): The SQL in S2 remains unchanged. The verification history is updated to [...], (reasonableness check, passed)], with a step count of 2. The "planner" analyzes S2 and sees that there is already a "passed" record in the history, which increases its confidence. Therefore, it makes a decision to choose action A2 = submit the result. The system executes this termination action, calculates whether the final SQL is correct, and returns a termination reward R2 = +10 (assuming it is correct).

[0093] Thus, for the current sample, we have obtained trajectory data containing 3 decision steps.

[0094] Reward calculation steps: Calculate the final reward value of the trajectory data based on the final result of the trajectory data (whether the submitted SQL code is correct) and the process cost.

[0095] The formula for calculating the final return value Rfinal is: Rfinal = Rcorrectness – Ctotal.

[0096] Rcorrectness is the correctness reward. After an action is submitted, the system compares the final SQL code with the standard correct SQL in the dataset. If they are semantically equivalent, Rcorrectness is a large positive number (e.g., +10); if they are not equivalent, Rcorrectness is a large negative number (e.g., -10). Ctotal is the total cost, which equals the sum of the costs of all actions performed in the trajectory data. The cost of each action is predefined, for example: cost (reasonableness check) = 0.1, cost (intent check) = 0.5, cost (behavior check) = 1.0.

[0097] The process of storing experience data involves the system collecting trajectory data and calculating the final reward value, and storing it in a large-capacity storage area called the "Experience Replay Pool." This storage area saves tens of thousands of recent trajectories, providing learning material for subsequent strategy updates.

[0098] Policy Update Steps: Once sufficient data has accumulated in the experience replay pool, the system initiates the core policy update process. This invention employs the GRPO algorithm to update the "planner's" policy network. The core idea of ​​the GRPO algorithm is to prioritize learning from high-reward trajectories in the experience replay pool, while also appropriately referencing low-reward trajectories to learn from past mistakes.

[0099] The specific execution steps of the GRPO algorithm are as follows: Data sampling: A batch of trajectory data is sampled from the experience replay pool according to certain rules (prioritizing the sampling of trajectories with high return values).

[0100] Advantage Calculation: For each time step t in each sampled trajectory, calculate its "advantage function value" A(St, At). This value measures how "good" choosing action At is compared to the average level in state St. The advantage function calculation takes into account both immediate costs and eventual rewards.

[0101] Constructing the loss function: The GRPO algorithm constructs a special loss function. The goal of this loss function is to enable the policy network, after updates, to increase the probability of selecting "good" actions that bring high rewards, while decreasing the probability of selecting "bad" actions that lead to low rewards.

[0102] Parameter update: Using optimization algorithms such as gradient descent, the internal parameters of the "planner's" policy network (a model based on a large language model or other neural networks) are slightly adjusted (updated) based on the calculated loss function.

[0103] By repeating the large cycle of "data collection > reward calculation > strategy update" thousands of times, the policy network parameters of the "planner" will gradually converge, eventually enabling the "planner" to master an optimal strategy that can efficiently and accurately perform SQL verification and correction.

[0104] The specific technical details of the embodiments disclosed herein can be found in the above method embodiments, and will not be repeated here.

[0105] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the aforementioned edge computing server deployment method. The computer-readable storage medium can be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, floppy disks, hard disks, removable storage disks, CD-ROMs, or any other form of storage medium known in the art.

[0106] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the desired tasks. The programs or code segments can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave.

[0107] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0108] In this invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0109] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations of the embodiments of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for semantic verification and automatic correction from natural language to structured query language, characterized in that, include: Receive initial SQL code generated based on a natural language question, and use it as SQL code to be verified; Obtain the SQL code currently to be verified and its associated context information to form the current state; Decision execution step: Based on the decision model trained by reinforcement learning, select an action to execute from the action space according to the current state, wherein the action space includes actions to call different verification tools and submission actions; If the action selected in the execution decision step is to call the verification tool, then the corresponding verification tool will further verify the SQL code to be verified and generate feedback information, and update the current state according to the feedback information; wherein, if the feedback information indicates that the verification failed, the correction of the SQL code to be verified will be triggered and the current state will be updated according to the correction result and the feedback information. After the current state is updated, the process re-enters the execution decision step until the submit action is selected, and the final SQL code is output. The training objective function of the decision model is designed as follows: when the action is to call the verification tool, a negative reward corresponding to the preset execution cost of the verification tool is given; when the action is to submit the action, a corresponding positive or negative reward is given based on the semantic equivalence of the final output SQL code with the standard answer.

2. The method according to claim 1, characterized in that, The current status also includes verification of historical information; The step of updating the current state based on feedback information includes: If the feedback information indicates that the verification is successful, the SQL code to be verified is used as the SQL code in the next state after the current state is updated, and the tool call and the success result are recorded in the verification history information of the next state. If the feedback indicates that the verification failed, the corrected SQL code will be used as the SQL code in the next state, and the tool call and failure result will be recorded in the verification history information of the next state.

3. The method according to claim 1, characterized in that, The current state also includes the number of decision steps; The selection submission action includes: When the accumulated number of decision steps reaches a preset threshold, a submit action is selected; wherein, the corresponding decision step count is incremented by one each time a decision step is executed; or, The decision model selects a submission action based on the current state.

4. The method according to claim 1, characterized in that, The verification tool includes at least: A reasonableness check tool, configured to check whether the results of SQL code execution conform to preset common sense rules; An intent inspection tool, configured to check whether the query logic of the SQL code is consistent with the intent of the natural language question; A behavior checking tool configured to check the correctness of SQL code behavior under boundary data conditions.

5. The method according to claim 1, characterized in that, The feedback information includes indications of whether the verification passed or failed, as well as a structured error diagnosis report, which includes the error type and error details; the correction is performed based on the error diagnosis report.

6. The method according to claim 5, characterized in that, The generation of the error diagnosis report and / or the execution of the correction process are accomplished by prompting the engineering team to call a large language model or by using a rule-based code transformation engine.

7. The method according to claim 1, characterized in that, The training process of the decision model adopts a generalized rejection sampling strategy optimization algorithm. The training data includes multiple training samples, each of which includes a natural language question, a database schema, an initial erroneous SQL code, and a standard correct SQL code.

8. A semantic verification and automatic correction system for converting natural language to structured query language, comprising a processor, a memory, and a computer program / instructions stored in the memory, characterized in that, The processor is configured to execute the computer program / instructions, and when the computer program / instructions are executed, the system implements the steps of the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method as described in any one of claims 1 to 7.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 7.

Images