Method and device for converting natural language into SQL (Structured Query Language)

Abstract

The embodiment of the invention discloses a method and a device for converting a natural language into an SQL (Structured Query Language). The method comprises the following steps: receiving a to-be-queried natural language input by a user; judging whether the to-be-queried natural language is a first-round query or not; when the to-be-queried natural language is the first round of query, determining a query type corresponding to the to-be-queried natural language, positioning a target database according to the query type, determining a target SQL statement corresponding to the to-be-queried natural language according to the target database, and caching the target SQL statement; and when the to-be-queried natural language is not queried in the first round, determining a context relationship corresponding to the to-be-queried natural language, modifying the cached SQL statement according to the context relationship to obtain a target SQL statement corresponding to the to-be-queried natural language, and caching the target SQL statement. By applying the scheme provided by the embodiment of the invention, the efficiency of converting the natural language into the SQL can be improved.

Description

Technical Field

[0001] This application relates to the field of language conversion, and more specifically, to a method and apparatus for converting natural language to SQL. Background Technology

[0002] In some data query domains, results matching the user's natural language input can be retrieved and returned to the user. Specifically, since the system can only recognize SQL (Structured Query Language), it first needs to convert the user's natural language input into the corresponding SQL, then perform a query on the database based on the converted SQL, and finally return the query results to the user.

[0003] Known methods for natural language to SQL conversion are primarily rule-based and template-based. These methods use predefined grammar rules and query templates to enable the system to understand query requirements and parse natural language into structured SQL query language. However, these methods rely on manually constructed domain ontologies and intent recognition rules, making them ill-suited for handling complex natural language expressions. Consequently, when faced with multi-turn dialogue queries, they struggle to identify contextual relationships and can only directly convert the currently input natural language, resulting in low conversion efficiency. Therefore, improving the efficiency of natural language to SQL conversion has become a pressing technical problem. Summary of the Invention

[0004] This application provides a method and apparatus for converting natural language to SQL, so as to improve the efficiency of natural language to SQL conversion. The specific technical solution is as follows.

[0005] In a first aspect, embodiments of this application provide a method for converting natural language to SQL, the method being applied to a language conversion model, the method comprising: Receive natural language input from the user to query; Determine whether the natural language query is the first query; When the natural language to be queried is the first round of query, determine the query type corresponding to the natural language to be queried, locate the target database according to the query type, determine the target SQL statement corresponding to the natural language to be queried according to the target database, and cache the target SQL statement; When the natural language to be queried is not the first query, the context relationship corresponding to the natural language to be queried is determined, and the cached SQL statement is modified according to the context relationship to obtain the target SQL statement corresponding to the natural language to be queried, and the target SQL statement is cached.

[0006] Optionally, the step of modifying the cached SQL statement according to the context relationship to obtain the target SQL statement corresponding to the natural language to be queried includes: When the context relationship is a conditional accumulation, the corresponding conditions are added to the cached SQL statement to obtain the target SQL statement corresponding to the natural language to be queried; When the context relationship is conditional overriding, conditional replacement is performed in the cached SQL statement to obtain the target SQL statement corresponding to the natural language to be queried.

[0007] Optionally, the step of performing conditional substitution in the cached SQL statement to obtain the target SQL statement corresponding to the natural language to be queried includes: Identify the parameter types in the natural language to be queried; the parameter types include one or more of the following: geographic code, time interval, and proportion threshold; Based on the parameter type, conditional replacement is performed in the cached SQL statement to obtain the target SQL statement corresponding to the natural language to be queried.

[0008] Optionally, after caching the target SQL statement, the method further includes: The target SQL statement is executed and validated, wherein the validation includes at least: syntax validation, semantic consistency validation, and execution result analysis.

[0009] Optionally, when the natural language to be queried is the first-round query, the method further includes: Clear cached SQL statements.

[0010] Optionally, the training process of the language conversion model includes: Obtain the seed task; Based on the seed task and the automatic training data generation system, training samples corresponding to the seed task are generated; the automatic training data generation system includes: a seed task processor, a sample generator, a diversity enhancement component, and a quality validator; The language conversion model is trained based on the training samples.

[0011] Secondly, embodiments of this application provide a natural language to SQL conversion apparatus, the apparatus being applied to a language conversion model, the apparatus comprising: The language receiving module is used to receive the natural language input by the user for the query. The judgment module is used to determine whether the natural language to be queried is the first round of query; The language conversion module is used to determine the query type corresponding to the natural language to be queried when the natural language to be queried is the first round of query, locate the target database according to the query type, determine the target SQL statement corresponding to the natural language to be queried according to the target database, and cache the target SQL statement; The language conversion module is further configured to determine the context relationship corresponding to the natural language to be queried when the natural language to be queried is not the first query, and modify the cached SQL statement according to the context relationship to obtain the target SQL statement corresponding to the natural language to be queried, and cache the target SQL statement.

[0012] Optionally, the language conversion module is specifically used for: When the context relationship is a conditional accumulation, the corresponding conditions are added to the cached SQL statement to obtain the target SQL statement corresponding to the natural language to be queried; When the context relationship is conditional overriding, conditional replacement is performed in the cached SQL statement to obtain the target SQL statement corresponding to the natural language to be queried.

[0013] In this embodiment, the effective storage, understanding and utilization of contextual information in multi-turn dialogues can be achieved. This mechanism enables the system to remember and understand the previous dialogue content, accurately grasp the continuity of user intent, and replace only the cached SQL statements during multi-turn queries, thereby improving the efficiency of natural language to SQL conversion. Attached Figure Description

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

[0015] Figure 1 A flowchart illustrating a natural language to SQL method provided in an embodiment of this application is shown; Figure 2 A schematic diagram of the structure of a natural language to SQL converter provided in an embodiment of this application is shown. Detailed Implementation

[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0017] It should be noted that the terms "comprising" and "having," and any variations thereof, in the embodiments and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0018] Structured Query Language (SQL) is a special-purpose programming language used for database querying and programming. It's used to access, query, update, and manage relational database systems. SQL is a high-level, non-procedural programming language that allows users to work on high-level data structures. It doesn't require users to specify how data is stored, nor does it require them to understand the specific data storage methods. Therefore, different database systems with completely different underlying structures can use the same SQL as an interface for data input and management. SQL statements can be nested, giving it great flexibility and powerful functionality.

[0019] Known methods for converting natural language to SQL only support single-round query conversion and have limited ability to handle query sessions that span multiple rounds or involve multiple semantic references. Specific problems include: 1. Lack of intent coherence: The existing system cannot effectively inherit the context of previous queries when users ask questions in multiple rounds. For example, when users ask "Check the same period last year again" or "Narrow the scope to Guangdong Province", these queries cannot be accurately generated SQL or will produce empty queries without the support of the preceding context, which seriously affects the interactive experience.

[0020] 2. Lack of parameter continuation capability: Most models cannot understand the inheritance and replacement relationship between parameters in multi-round queries. For example, if a user queries "data that meets condition one in 2023" in the first round and "which data meets condition two" in the second round, the system has difficulty associating "meets condition two" with the "data that meets condition one" field in the previous round result.

[0021] 3. Broken query chain and inability to continue logic: In scenarios involving context aggregation or further filtering based on subquery results, existing technologies struggle to maintain the continuity of the query chain. For example, when filtering out data added in the first quarter of last year and then looking at the proportion of each type of data, it is often impossible to construct a coherent nested SQL statement.

[0022] In some application scenarios, most user queries are multi-round scenarios, and the known methods are severely inadequate in maintaining context, causing users to repeatedly enter the complete query or the system to return an error SQL, which reduces the efficiency of intelligent interaction and user satisfaction.

[0023] Based on this, embodiments of this application disclose a method and apparatus for converting natural language to SQL, which can improve the efficiency of natural language to SQL conversion. The embodiments of this application are described in detail below.

[0024] Figure 1 The diagram illustrates a flowchart of a natural language to SQL conversion method provided in an embodiment of this application. This method can be applied to a natural language to SQL (Text-to-SQL) system, specifically to a language conversion model. The method includes the following steps: S110: Receives natural language input from the user to be queried; S120: Determine whether the natural language to be queried is the first query; if yes, proceed to step S130; if no, proceed to step S140. S130: Determine the query type corresponding to the natural language to be queried, locate the target database according to the query type, determine the target SQL statement corresponding to the natural language to be queried according to the target database, and cache the target SQL statement; S140: Determine the context relationship corresponding to the natural language to be queried, and modify the cached SQL statement according to the context relationship to obtain the target SQL statement corresponding to the natural language to be queried, and cache the target SQL statement.

[0025] The steps of modifying the cached SQL statement according to the context to obtain the target SQL statement corresponding to the natural language to be queried include: when the context is condition accumulation, adding the corresponding conditions to the cached SQL statement to obtain the target SQL statement corresponding to the natural language to be queried; when the context is condition overriding, performing condition replacement in the cached SQL statement to obtain the target SQL statement corresponding to the natural language to be queried.

[0026] In this embodiment, the conversion from natural language to SQL can be achieved based on a large language model. Specifically, the language conversion model can be pre-trained. The training process of the language conversion model in this embodiment is described below. To ensure the accuracy of the model, the training process needs to address the following issues: lack of parameter mapping mechanism, efficiency of generating training data for specialized domains, lack of SQL quality verification mechanism, and domain adaptability.

[0027] The parameter mapping mechanism is lacking. In some application scenarios, there is a large amount of natural language input involving key parameters such as administrative divisions, time intervals, and proportion thresholds, but known methods are insufficient in parameter understanding and standardization processing. 1. Regional code mapping problem: It is impossible to accurately convert the administrative region names in natural language (such as "Guangdong Province") into the standard codes used in the database (such as "440000"), resulting in incorrect query results or query failure.

[0028] 2. Time range parsing problem: For vague time expressions such as "first half of the year" and "fourth quarter of last year", the existing system has difficulty converting them into precise SQL time range conditions, especially when it needs to deal with nested time expressions (such as "compared with the same period of this year in the first quarter of last year"), it is almost impossible to generate correct SQL statements.

[0029] 3. Numerical threshold and ratio conversion issues: For ratio expressions such as "more than 50%" and "less than one-third", known methods are prone to incorrect conversion (e.g., "=50" or "<50"), resulting in significant deviations between query results and users' actual needs.

[0030] These shortcomings directly affect the logical correctness of SQL statements and are key technical bottlenecks restricting the application of Text-to-SQL systems.

[0031] Efficiency issues in generating training data for specialized fields To achieve high-precision Text-to-SQL conversion, a large amount of structured data is needed for model fine-tuning, but the following problems are encountered: 1. High cost of manual annotation: To obtain professional-quality training data, a large number of domain experts are required to perform manual annotation. A complete training dataset is usually expected to take 3-6 months and dozens of people to work together, which is costly and time-consuming.

[0032] 2. Insufficient sample coverage: Existing datasets are insufficient to fully cover the terminology and business scenarios specific to the professional field, leading to frequent misunderstandings in the model during practical applications.

[0033] 3. Difficulty in adapting to new table structures: In some scenarios, the database structure is often adjusted frequently with changes in business. Known methods are difficult to adapt quickly to new fields or changes in table structure. Each adaptation requires rebuilding a large number of training samples, which seriously affects the practicality and sustainable development of the system.

[0034] The problem of missing SQL quality verification mechanism The core goal of Text-to-SQL is to generate executable, verifiable, and intent-based SQL statements, but the current system mainly suffers from the following problems: 1. Insufficient syntax and semantic validation: Most systems only focus on syntax-level checks and ignore semantic correctness. This results in SQL statements that are syntactically correct but whose execution results do not match the user's intent, and may even cause performance problems. For example, "oldest person" implies a uniqueness assumption, but there may be duplicate records in the database.

[0035] 2. Lack of execution result feedback: The lack of a closed-loop feedback mechanism based on SQL execution results prevents the system from automatically learning and improving from erroneous executions, leading to repeated occurrences of similar errors and hindering the system's ability to self-optimize.

[0036] 3. Weak handling of complex scenarios: Accuracy drops significantly when processing advanced SQL constructs such as complex nested queries, multi-table joins, and window functions. Especially in complex queries involving three or more tables, accuracy falls far short of actual business requirements.

[0037] The aforementioned defects make it difficult to guarantee the stability and business effectiveness of Text-to-SQL systems in actual operation.

[0038] Adaptability issues in professional fields Text-to-SQL systems that lack domain knowledge and business logic modeling capabilities will struggle to correctly understand technical terminology and complex query requirements, even with high training accuracy. 1. Superficial understanding of domain terminology: Insufficient understanding of some professional terms leads to inaccurate or completely wrong SQL query conditions.

[0039] 2. Limited support for business scenarios: For some specific scenarios, the existing technical support capabilities are weak, which seriously limits the application scope of the system.

[0040] 3. Insufficient cross-table reasoning capability: In scenarios that require correlation analysis from multiple business domains, the existing model has limited understanding of the complex relationships between tables, making it difficult to generate correct multi-table relational queries.

[0041] 4. Poor ability to handle complex business logic: Existing technologies cannot effectively support complex business analysis requirements that require a combination of subqueries and aggregate functions, resulting in the inability to meet high-value business analysis needs.

[0042] To address the aforementioned problems, this application provides a natural language to SQL conversion system, the objective of which is: 1. Implement a semantic mapping and intelligent replacement mechanism for key parameters, especially for the accurate conversion of special parameters such as regional codes, time intervals, and proportion thresholds; 2. Construct a multi-turn dialogue context preservation and intent connection model to realize the accumulation of semantic information, parameter transmission and intent evolution in continuous user dialogue, ensure the coherence of query logic, and significantly improve the naturalness and accuracy of interactive business analysis.

[0043] 3. Provides a professional training data expansion method based on seed samples, reducing data acquisition costs and improving sample diversity and domain coverage; 4. Introduce a three-level SQL validation feedback system linking syntax, semantics, and execution to ensure the syntactic correctness, semantic consistency, and execution reliability of the generated SQL; 5. Establish a domain-specific knowledge modeling and multi-table reasoning framework to accurately understand industry terminology and complex business logic, and support precise conversion of multi-table associations and complex conditions.

[0044] Specifically, the natural language to SQL system of this application embodiment mainly includes the following components: 1. User Interaction Layer The interface module provides natural language input and output, mainly including: The natural language query interface supports multi-turn interaction and query context management.

[0045] The query results visualization module dynamically presents the SQL execution output.

[0046] The query intent recognition and intent clarification module is used to handle user input that is semantically ambiguous or structurally incomplete.

[0047] 2. Semantic parsing layer To achieve deep semantic structure analysis and parameter extraction of user input, the main components include: The domain terminology recognition and standardization module is used to identify industry-specific terms and map them to standard expressions.

[0048] The parameter mapping engine supports the parsing and replacement of key parameters such as region codes, time representations, and ratio thresholds.

[0049] The query intent extraction module uses deep learning methods such as attention mechanisms to analyze the core intent of user queries.

[0050] 3. SQL Generation Layer This layer is responsible for mapping standardized natural language input to structured query language. Its main modules include: A Text-to-SQL conversion model optimized for specific business domains.

[0051] A semantic-structure mapping component that is aware of data table structure.

[0052] A reusable SQL template library and dynamic optimization engine can be used to improve the efficiency and accuracy of SQL generation.

[0053] 4. Verification and Execution Layer The core functional modules for executing SQL statements and validating their effectiveness include: A three-tier SQL validation subsystem (syntax validation, semantic consistency validation, and execution result analysis).

[0054] The query execution evaluation system is used to identify execution deviations and trigger a backtracking mechanism.

[0055] The error identification and correction module based on feedback enables dynamic updates of training data.

[0056] 5. Training and Adaptation Layer This layer supports continuous system optimization and cross-library adaptation capabilities. Its core modules include: A seed task management platform for maintaining and expanding high-quality seed data.

[0057] An automated training sample generation engine is responsible for generating high-quality samples by combining domain templates and language models.

[0058] Incremental training mechanism and model version management system enable rapid adaptation to new scenarios and improvement of model accuracy.

[0059] The performance of a Text-to-SQL system largely depends on the quality and quantity of training data (samples). Known methods primarily rely on manually constructing training samples, which presents the following significant problems: first, they are costly, requiring personnel with both SQL expertise and general knowledge; second, they lack coverage, failing to encompass diverse query scenarios and expressions; and third, they lack flexibility, making it difficult to adapt to constantly changing business needs and query patterns.

[0060] Furthermore, some specific areas face additional challenges, including: 1. The special nature of domain-specific vocabulary: Some specific domains have a large number of proper nouns and terms that are difficult to accurately express using ordinary data generation methods.

[0061] 2. Differences in query patterns: The query patterns in some specific fields differ significantly from those in general fields, and there are some specific analytical needs.

[0062] 3. Insufficient data scale: Some domain-specific query samples are scarce, making it difficult to meet the data volume requirements for fine-tuning the model.

[0063] 4. Lack of diversity: The manually constructed samples have a single expression mode, which is difficult to cover the diverse expressions of natural language.

[0064] These challenges make it difficult for known training data construction methods to meet the needs of high-quality domain-specific Text-to-SQL systems.

[0065] Based on this, this application provides a large-model-driven automatic training data generation system. This system comprises a seed task processor, a sample generator, a diversity enhancement component, and a quality validator. It can automatically generate a large number of diverse training samples based on a small number of high-quality seed tasks. Leveraging the generative capabilities of a large language model and its understanding of specific management domain knowledge, this system can generate training data that is both domain-specific and possesses natural language diversity.

[0066] The overall architecture design is based on the "seed expansion" principle and has the following core features: 1. Few-shot driven: Starting from a small number (dozens) of manually created high-quality seed tasks, a large number (thousands or more) of training samples are generated.

[0067] Specifically, a small number of seed tasks can be initially constructed by manually building a real business rule knowledge base. This knowledge base contains a large number of business rules and business scenario query SQL commands that are used in daily life. Then, a large model is called to generate subsequent seed tasks, i.e. training samples, based on the above business rule knowledge base and business processes.

[0068] 2. Multi-level expansion: Samples are expanded at multiple levels, including query intent, expression method, and parameter changes.

[0069] 3. Closed-loop quality control: Ensure the quality and validity of generated samples through automated verification and screening.

[0070] 4. Domain knowledge integration: Combine professional terminology and knowledge from specific management fields to generate samples with strong domain relevance.

[0071] This architecture solves the problem of insufficient training data while ensuring the quality and diversity of generated samples, providing sufficient domain-adaptive training data for the Text-to-SQL model.

[0072] Specifically, the seed task processor is responsible for loading and processing the initial seed task, providing the foundation for subsequent sample generation. The core functions of this component include: Seed task loading: Loads the initial seed task from the seed task library, including natural language queries and corresponding SQL statements.

[0073] Task classification and labeling: Seed tasks are classified and labeled. Specifically, the overall judgment can be made through the large model. The judgment criteria include the query scenario type, the complexity level of the standard reference SQL statement, and the number of tables involved.

[0074] Meta-information extraction: Extracting meta-information such as query intent, parameter types, and table join methods for subsequent mutation generation.

[0075] Each seed task requires the extraction of this metadata. Specifically, metadata can be extracted by building a business rule knowledge base for real business scenarios and corresponding real operation processes, including metadata such as the type of query and the query scenario.

[0076] The seed task processor acts as a "data source" in the system, ensuring the high quality and diversity of the initial input data.

[0077] Sample generators (such as those for extended high-variability models) are the core components of automatic training data generation systems, responsible for generating diverse training samples based on seed tasks.

[0078] With the seed data, the next step is to build a prompt template, put the seed data into the prompt as an example, and call the large model API to generate it. The main process is to use the in-context learning capabilities of the large model, combined with the business rule knowledge base and the structured prompt template expression, to provide only a few examples, and the large model can generate high-quality sample data in accordance with the requirements of the prompt.

[0079] The main functions of this component include: Cue word construction: Build structured cue words based on the seed task and cue word template.

[0080] Large model invocation: Invoking a large language model via API (Application Programming Interface) to generate new samples.

[0081] Sample parsing: Extracting and formatting the generated samples from the model response.

[0082] Batch processing: Supports batch generation and parallel processing to improve generation efficiency.

[0083] The sample generator guides a large model to generate diverse samples using carefully crafted prompts, while maintaining consistency between query intent and SQL structure. The prompt design includes the following key elements: Seed task example: Provides example pairs of raw natural language queries and SQL.

[0084] Variation guidance: Instructs the model on how to mutate query expressions, such as changing sentence structure or adding modifiers.

[0085] Domain knowledge integration: Introducing professional terminology and expressions specific to the management field.

[0086] Constraints: Limit the range of variation to ensure that the generated samples match the original query intent. Figure 1 To.

[0087] With this design, the sample generator can generate multiple samples with different expressions but different query meanings based on a single seed task. Figure 1 Consistent training samples.

[0088] The diversity enhancement component is responsible for further processing the initially generated samples, increasing their diversity in terms of intent, representation, and parameters. This component implements three main diversity enhancement methods: Parameter variation: Change the parameter values ​​in the query, such as changing the region, time range, or percentage threshold.

[0089] Expression transformation: Adjust the way the query is expressed, such as switching between active and passive voice, and between question and declarative sentences.

[0090] SQL structure transformation: Transform the structure and writing of SQL while maintaining the equivalence of query results.

[0091] The diversity enhancement component significantly expands the coverage of training samples through systematic mutation rules, enabling the model to adapt to various expressions and query variants.

[0092] The quality validator is responsible for evaluating and filtering the generated training samples to ensure their correctness and validity. This component includes three main validation steps: SQL syntax validation: Verify that the generated SQL statement is syntactically correct.

[0093] SQL semantic validation: Verifies whether the SQL matches the database schema and whether the tables and fields are used correctly.

[0094] NL-SQL (Natural Language to SQL) consistency verification: Verifying the consistency between natural language queries and SQL queries. Figure 1 To the point of being responsive.

[0095] The quality validator scores each generated sample, and samples below a threshold are filtered out to ensure that the final training dataset is of high quality and effective.

[0096] When the sample generator generates large-scale sample data (SQL) for training, the validity of the sample data (SQL) can be verified by inputting these SQL into the language conversion model API to generate 5 simulated data and examining the correlation between these simulated data and real data.

[0097] Because real business data in certain specific domain scenarios is sensitive to privacy, it is usually not allowed to be used directly. Generally, only business rules and a few business scenario query SQLs can be obtained, and it is also difficult to obtain real business data. Therefore, when only limited access to real business data is available, the effectiveness of the sample data (SQL) used for training is judged by comparing the correlation between simulated business data and real business data (if the effectiveness cannot reach 90%, we go back to the previous steps to continuously optimize), thereby protecting the security of real business data.

[0098] To meet different data requirements and generation scenarios, the automatic training data generation system in this application embodiment can also implement various scalability and adaptive designs: 1. Supports multiple data generation strategies Single-turn dialogue: Generate training samples of a single question-answer pair.

[0099] Multi-turn dialogue: Generate training samples for continuous dialogues, including context dependencies.

[0100] Task diffusion: Diffusion from existing tasks to new query domains.

[0101] 2. Multi-model adaptation mechanism It supports access to different large language model APIs (Application Programming Interfaces).

[0102] Customized and optimized prompt word templates for different models.

[0103] Adaptively handles the output format of different models.

[0104] 3. Domain-specific customization features Domain-specific vocabulary integration.

[0105] Customized templates for specific business scenarios.

[0106] Domain-specific SQL mode support.

[0107] These designs enable the system to flexibly respond to different data generation needs and to be adjusted and expanded as business requirements change.

[0108] In multi-turn dialogue scenarios, users frequently modify query parameters through simple statements, such as "What is the data for Guangdong Province?" followed by "What about Jiangxi Province?" Existing technologies mainly rely on general context processing or simple substitution, which struggles to accurately and efficiently identify and map specialized parameter expressions specific to management domains, particularly regarding regional codes, time intervals, and proportional thresholds. In other words, existing technologies face the following core challenges: 1. Difficulty in parameter identification: Existing systems struggle to accurately identify the type and content of parameters to be replaced from brief follow-up queries.

[0109] 2. Insufficient contextual understanding: Unable to effectively combine the content of the previous round of dialogue to understand the contextual meaning of the parameters.

[0110] 3. Missing mapping rules: There is a lack of a professional parameter mapping rule library for specific management areas.

[0111] 4. Low replacement accuracy: Simple string replacement cannot handle complex scenarios, such as changes in time intervals and numerical ranges.

[0112] These challenges lead to a significant decrease in query efficiency in multi-turn conversations, requiring users to repeatedly provide complete queries to achieve a natural and smooth conversational experience.

[0113] Based on this, the language conversion model in this application provides a parameter replacement intelligent mapping mechanism. This mechanism consists of a parameter mapping processor, a professional mapper cluster, and a mapping verification component, enabling accurate mapping of professional parameters such as regional codes, time intervals, and proportion thresholds in multi-turn dialogues. This mechanism can accurately identify the user's parameter change intentions in multi-turn dialogues and accurately convert natural language expressions into corresponding SQL conditions.

[0114] Specifically, the overall architecture of the parameter replacement intelligent mapping mechanism is based on plug-in mapper combinations and unified mapping process management, and has the following core features: 1. Layered Design: Functions such as parameter identification, type distribution, specialty mapping, and verification correction are implemented in layers, with each layer having a clearly defined responsibility. In other words, the network model can be layered according to its functions, with each layer corresponding to different functions.

[0115] 2. Scalability: It adopts a plug-in mapper architecture, which can flexibly extend the mapper to new parameter type according to business needs.

[0116] 3. Mapping closed loop: A closed loop is formed through verification and correction to ensure the accuracy and reliability of parameter mapping.

[0117] 4. Domain Adaptation: Customize mapping rules and validation standards for specific domain characteristics.

[0118] This architecture supports both general parameter mapping needs and specialized parameter processing for specific domains, providing a comprehensive solution for parameter replacement in multi-turn dialogues.

[0119] The parameter mapping processor is the central control component of the intelligent parameter replacement mapping mechanism. It is responsible for identifying parameter types and scheduling the corresponding specialized mappers for processing. This component implements three key functions: Parameter type identification: The system identifies parameter types in queries using carefully designed regular expression patterns. It employs various pattern matching rules for geographic codes, time intervals, and proportion thresholds, accurately extracting various parameter representations from natural language. For example, the system can first pre-scan user queries, using common patterns (such as number strings, specific punctuation marks, etc.) to initially identify all potential parameter fragments; then, for each fragment, a pre-defined set of matching rules is applied according to preset priorities (geographic, time, proportion) for precise classification.

[0120] Mapper Coordination: Based on the identified parameter type, the system invokes the appropriate specialized mapper for processing. Through a unified mapper interface design, the system enables flexible combination and invocation of mappers.

[0121] Mapping verification: Verify the mapping results to ensure the correctness and validity of the mapping.

[0122] The parameter mapping processor can identify various parameter types, including regional parameters (such as "Guangdong Province"), time parameters (such as "first half of 2023" and "last quarter"), and percentage threshold parameters (such as "more than 50%" and "not less than 30%). For each identified parameter type, the system calls the corresponding specialized mapper to process it, converting it into the corresponding SQL statement, and then verifies and corrects the mapping results.

[0123] Specifically, the parameter mapping processor can identify various parameter types according to the following rules. For example, for the regional code parameter, it can match text fragments with entries in a pre-known regional information dictionary, as follows: Rule 1: Perform fuzzy or exact matching between extracted candidate words (such as "Shanghai Pudong") and the built-in dictionary of provincial, municipal, and district place names; Rule 2: When a place name is identified, prioritize matching fragments that contain keywords such as "province", "city", "located in", or "region". Rule 3: Match postal codes or specific district codes.

[0124] For time interval parameters, matching can be performed by using text snippets containing explicit date / time formats or time-related keywords, as detailed below: Rule 1 (Absolute Time Format): Matches standard date and time formats, such as: "2023-01-05", "2023 / 1 / 5", "January 5, 2023", etc. Rule 2 (Interval Keywords): Match structures that indicate a time range, such as "from * to *" or "between * and *". Rule 3 (Relative Time Expression): Matches expressions relative to the current time and incorporates built-in conversion logic. For example, keywords can include: last year, last quarter, last 30 days, etc. After matching, the system will call date functions to convert them into absolute start and end dates.

[0125] For the percentage threshold parameter, matching can be performed by using text fragments that are numbers and immediately adjacent to a percentage symbol or keywords related to comparison or thresholds, as detailed below: Rule 1 (Symbol Matching): Matches numbers containing the % or ‰ symbol, such as "50%", "85.5%", etc. Rule 2 (Keyword Matching): Matches combinations of comparison words and numbers, such as "greater than 50", "more than 80.5", "less than 30", etc. Rule 3 (Colloquial Proportion): Matches words such as "half", "one-third", etc., and maps them to their corresponding decimal values ​​(e.g., 0.5, 0.333).

[0126] Through this cascaded recognition logic, the processor can efficiently and accurately parse various parameters in the query, laying a solid foundation for subsequent accurate mapping.

[0127] After identifying the parameter type, the system can call the corresponding specialized mapper to process it, convert it into the corresponding SQL statement, and verify and correct the mapping result. Corresponding to the parameter type, the aforementioned specialized mappers can specifically include: regional code mapper, time interval mapper, and proportional threshold mapper.

[0128] The region code mapper is responsible for converting regional expressions in natural language (such as "Guangdong Province") into standard region codes (such as "440000"). This component contains a two-way mapping from region names to codes, and also supports the conversion between region abbreviations and full names.

[0129] The region code mapper maintains a complete region mapping table, including code mapping relationships for provincial-level administrative regions, municipalities, and special administrative regions. The region code mapper not only supports mapping standard region names but can also handle abbreviations, such as identifying and mapping "B" to "Province B," and further mapping it to the region code "120000." This multi-level mapping mechanism ensures the system's compatibility with various region representation formats.

[0130] Region code mapping is mainly achieved through the following steps: Extract the geographical description (e.g., "Guangdong Province") from the current query.

[0131] Identify the corresponding regional parameters and codes from the previous query and SQL.

[0132] Convert the current region description into the corresponding region code.

[0133] Replace the region code parameter in SQL.

[0134] The time interval mapper can handle various time representations (such as "first half of 2023", "second half", "first quarter", etc.) and convert them into standard SQL date conditions. This component supports multiple time representation formats, including absolute and relative time representations.

[0135] For example, a hybrid mechanism combining rules and real-time calculation can be employed. The system has a built-in logical rule module. When it receives an input such as "First Quarter of 2023," this module triggers a calculation: start date: 2023-01-01, end date: 2023-03-31. This calculation process considers leap years; for example, when "First Quarter of 2024" is input, the end date is automatically calculated as 2024-03-31, and February has 29 days. For relative time expressions such as "last year" and "last month," the module can obtain the current system date as a baseline and then perform dynamic calculations. For example, if today is 2024-11-04, "last year" would be calculated as BETWEEN '2023-01-01' AND '2023-12-31'; "last month" would be calculated as BETWEEN '2024-10-01' AND '2024-10-31'.

[0136] This dynamic calculation mechanism ensures that the definition of relative time can be accurately converted whenever a query is made, making it far more flexible and powerful than static mapping tables.

[0137] The core functions of time interval mapping include: Identify various time expressions (absolute time such as "first half of 2023" and relative time such as "last year").

[0138] Parse year and interval information (such as "first half of the year" and "first quarter").

[0139] Generate standard SQL date conditions (such as "BETWEEN '20230101' AND '20230630'").

[0140] Replace the corresponding date conditions in the SQL.

[0141] The time interval mapper can handle various time representation formats, including annual, semi-annual, quarterly, and monthly representations. This mapper particularly handles relative time representations, calculating the corresponding specific time range based on the current date. The system specifically considers leap year handling and accurate conversion of relative time representations (such as last year, next quarter).

[0142] The proportion threshold mapper can handle various proportion and threshold expressions (such as "proportion exceeding 50%", "not less than 30%", etc.) and convert them into precise SQL conditions. This component supports multiple proportion threshold expression formats, including percentages, absolute values, and Chinese numeric expressions.

[0143] The main functions of proportional threshold mapping include: Identify various proportion and threshold expressions (such as "accounting for more than 50%" or "greater than 30%").

[0144] Parse operators and numbers (such as "more than", "50%").

[0145] Convert to an exact SQL conditional expression (such as ">0.5").

[0146] Replace the corresponding conditions in the SQL.

[0147] This mapper employs a multi-level representation recognition mechanism to handle both simple threshold conditions (e.g., greater than 50%) and complex threshold conditions (e.g., between 30% and 50%). The system also implements intelligent unit conversion and precision handling for different representations of percentages and absolute values.

[0148] To ensure the accuracy of parameter mapping, this application provides a complete verification and correction mechanism. This mechanism performs multi-level verification of the mapping results and provides correction suggestions when problems are found.

[0149] The verification mechanism mainly includes the following aspects: 1. Basic Validation: Ensure that the mapped SQL is not empty and has a substantial difference from the original SQL. This is the most basic validation step to avoid invalid or empty mappings.

[0150] For example, we can save the complete SQL statement from the previous round of dialogue. When the user's query intent remains consistent across multiple rounds, the query structure of the SQL statement we ultimately save will also be consistent, with only the parameter part changing. Therefore, we can compare the mapped SQL with the complete SQL from the previous round of dialogue, which can improve response speed and query accuracy.

[0151] 2. Structure Validation: Ensures that the main structure of the SQL (such as the SELECT clause, FROM clause, GROUP BY clause, etc.) does not undergo unnecessary changes. The system analyzes each part of the SQL using regular expressions to ensure that only the parameter parts change, while the query structure remains unchanged.

[0152] 3. Parameter verification: Ensure that all parameters that need to be mapped have been correctly mapped, especially check whether the original parameter values ​​have been completely replaced.

[0153] 4. Confidence verification: Evaluate the overall confidence of the mapping results to ensure that the quality of the changes meets the preset threshold.

[0154] When a problem is detected during verification, the system will apply appropriate corrective strategies based on the problem type, for example: Regarding SELECT clause issues, the system will retain the original SELECT clause structure.

[0155] Regarding FROM and JOIN clauses, the system ensures that table relationships remain consistent.

[0156] For GROUP BY and ORDER BY issues, the system will maintain the original grouping and sorting logic.

[0157] This verification and correction mechanism ensures that parameter mapping accurately replaces relevant parameters while preserving the original SQL semantics, greatly improving the stability and accuracy of queries in multi-turn dialogues.

[0158] For example, when a user first queries "the number of projects in Province A in 2023", the system generates an SQL statement containing the region code for Province A (110000) and returns the result. When the user submits a subsequent query for "Province B", the parameter mapping processor recognizes this as a change in region parameter and calls the region code mapper to handle it. The region code mapper completes the mapping from "Province B" to "120000", finds the code "110000" for Province A in the original SQL and replaces it, generating a new SQL statement. The entire process does not require regenerating the complete SQL; instead, it achieves efficient conversion through precise parameter mapping.

[0159] The advantages of the parameter replacement intelligent mapping mechanism are reflected in: Precise identification: It can accurately identify the parameter type and description from a short follow-up query.

[0160] Contextual understanding: Understanding the contextual meaning of parameters based on the previous dialogue and SQL.

[0161] Specialized parameter processing: Precise mapping of specialized parameters (such as regional codes) for specific management areas.

[0162] Structure Preservation: Replace only relevant parameters while keeping the overall SQL structure unchanged.

[0163] Verification and correction: Verification mechanisms ensure the accuracy and reliability of the mapping.

[0164] This mechanism not only supports mapping of geographic parameters, but also handles the replacement of various parameter types such as time intervals (e.g., "What about the previous quarter?") and proportion thresholds (e.g., "What about those exceeding 40%?"), greatly improving query efficiency and user experience in multi-turn dialogues.

[0165] In multi-turn dialogue scenarios, there is also the issue of maintaining context. For example, in real-world business scenarios, users typically need to delve deeper into data analysis through multiple rounds of interaction. For instance, a user might first inquire about the general data overview of a province, then follow up with details about the distribution of specific data types, and then inquire about specific data types, and so on. Known single-turn dialogue patterns struggle to maintain the contextual information of this continuous dialogue, requiring each query to restart, resulting in a poor user experience and low query efficiency.

[0166] Known technologies face the following major challenges: insufficient context memory, difficulty in maintaining specialized information, inadequate support for incremental analysis, and complex state management. These challenges prevent users from smoothly exploring continuous data, requiring them to repeatedly provide complete context in each query round, significantly reducing efficiency.

[0167] Based on this, the language conversion model in this application provides a multi-turn dialogue context preservation mechanism. This mechanism consists of a context manager, a context memory module, a context understanding module, and a context merging module, enabling the effective preservation, understanding, and utilization of contextual information in multi-turn dialogues. This mechanism allows the system to remember and understand previous dialogue content, accurately grasp the continuity of user intent, and generate SQL queries that better meet user expectations.

[0168] The overall architecture has the following core features: Layered memory: Contextual information is stored in three layers: dialogue layer, intent layer, and result layer.

[0169] Intelligent understanding: It understands the relationship between the current query and the history through techniques such as referential resolution and implicit information completion.

[0170] Dynamic merging: The context merging strategy is dynamically adjusted based on the progress of the dialogue.

[0171] Specialized Enhancement: Provides special handling for specialized terminology and query patterns in specific management fields.

[0172] This architecture supports both standard context processing requirements and specialized enhancements tailored to specific management domains, providing comprehensive support for data exploration and analysis in multi-turn conversations.

[0173] The context manager is the central control component for the multi-turn dialogue context preservation mechanism, responsible for coordinating the work of various modules and providing a unified context processing interface. This component implements three key functions: Context lifecycle management: creating, updating, retrieving, and cleaning up conversation contexts.

[0174] Module coordination: Coordinate the work of memorizing, understanding, and merging modules.

[0175] Interface encapsulation: Provides a unified context processing interface for external systems.

[0176] The context manager manages contextual information for multi-turn dialogues, including dialogue history, user intent, query parameters, and result sets. It provides structured contextual representations and context-enhanced prompt word construction capabilities, enabling the model to better understand and process consecutive user queries.

[0177] The context memory module is responsible for storing and managing various types of information from multi-turn dialogues, including dialogue history, query intent, and result sets, providing necessary historical information for continued dialogue. This module employs a hierarchical memory design, dividing context information into three levels: Dialogue layer: Records the original dialogue content, including user queries and system responses.

[0178] Intent Layer: Extracts and records the query intent structure, such as operation type, query object, and filtering conditions. This information can be extracted from the original dialogue content and recorded in the context engineering library by calling the larger model.

[0179] Result layer: Caches query results and result set structure to provide a reference for subsequent queries.

[0180] This hierarchical memory design enables the system to understand and utilize historical information at different levels of abstraction, maintaining the integrity of the original dialogue while extracting key structured information for intent understanding and parameter mapping.

[0181] The context understanding module is responsible for analyzing the relationship between the current query and historical content, understanding the continuation and changes in user intent. The core functions of this module include: Reference resolution: Parse references in a query (such as "they", "these data") to determine the specific objects they refer to.

[0182] Implicit information completion: Based on the dialogue history, complete the implicit information in the current query (such as omitted query objects or filter conditions).

[0183] Terminology processing: Identifying and processing specialized terms and abbreviations in specific management areas.

[0184] To achieve accurate contextual understanding, the core analysis logic of this module is based on a decision-making mechanism that categorizes intent relationships. The system classifies the current query Q_t into several preset relationships based on the linguistic features and relevance of historical dialogues H, and then triggers the corresponding context merging module.

[0185] When determining the query intent of the current query Q_t and the historical dialogue H Figure 1 If Q_t satisfies the following two conditions, it triggers referential resolution, retracing the query subject from the previous round of dialogue metadata and replacing the referent in the current query with that query subject to form a complete query content: It contains explicit referents such as "they," "these," "their," or specific indicators such as "the data"; the query itself lacks a subject or core query object. For example, in "Where do they belong?", "they" is the subject, but its referent is unclear.

[0186] When determining the query intent of the current query Q_t and the historical dialogue H Figure 1 While the query is consistent, it introduces new constraints but does not change the core query content. For example, after querying "all data that meets the criteria," a follow-up question "only look at the real estate industry" triggers condition accumulation. It inherits the complete information and meta-information from the previous round of dialogue and adds the constraints from the current dialogue content to form a complete query.

[0187] When determining the query intent of the current query Q_t and the historical dialogue H Figure 1 However, Q_t is for the results of the previous query, requesting the display of new information dimensions or a change in aggregation method. For example, asking "show their processing dates" triggers implicit information completion, inheriting complete information and meta-information from the previous dialogue, and modifying the newly added instructions into the previous query SQL command.

[0188] When it is determined that there is a conflict between the query intent of the current query Q_t and the query intent of the historical dialogue H, Q_t introduces a completely new query intent that is unrelated to the historical dialogue, triggering the development of a new task. The content of the previous round of dialogue will be filtered out, and only the meta-information of the previous round of dialogue will be retained. Q_t will be processed in combination with the dialogue context and business rule knowledge base.

[0189] The context understanding module, through the above functions, can transform short follow-up queries into complete query intents, providing the necessary context information for SQL generation.

[0190] The context merging module is responsible for merging the current query intent with historical intents to form a complete query representation. This module implements two key functions: Historical merging strategy: Select an appropriate historical merging strategy based on the progress of the dialogue, such as inheritance merging, condition accumulation, condition overriding, etc.

[0191] Conflict resolution strategy: When information conflicts occur, an appropriate resolution strategy is selected based on the dialogue context and business rules. The conflict resolution strategy is applied to situations where the query intent is inconsistent across multiple rounds of dialogue. When the query intent is inconsistent, the system can determine the user's true query intent based on the context of the current dialogue content and previously accumulated dialogue metadata, using a large model. This, combined with the business rule knowledge base, generates an SQL command that matches the user's current query.

[0192] The context merging module ensures the coherence and consistency of query intent across multiple rounds of dialogue, supporting users to refine and deepen their queries step by step.

[0193] In other words, when the query intent Figure 1 When the query intent is inconsistent, the complete information of the previous round of dialogue can be retained, and the metadata of the previous round of dialogue can be inherited and merged. Conditions are accumulated or overwritten based on the continuity between the current round of query content and the previous round of dialogue content to generate SQL commands. Finally, the content of the two rounds of dialogue is merged into a whole, and the metadata of the two rounds of dialogue is obtained. When the query intent is inconsistent, the complete information of the previous round of dialogue is not retained. Irrelevant information of the previous round of dialogue is filtered out, and only the metadata of the previous round of dialogue is inherited (it will not be discarded because the metadata accumulated from multiple rounds of dialogue can be combined to determine the user's true intent, but this will not waste tokens excessively). At the same time, SQL commands are generated based on the query content of the current round. Finally, only the latest round of dialogue content is retained, and the metadata of the two rounds of dialogue are obtained.

[0194] Existing natural language to SQL systems typically complete their task after generating the SQL, lacking the ability to verify and correct the generated results. This leads to two serious problems: first, the generated SQL may contain syntax errors, inappropriate semantics, or violations of business rules; second, even if the SQL can be executed, its result set may not match the user's actual intent, or the large amount of data may cause efficiency issues. Business domain-specific rules (such as specific table join logic and field usage restrictions) are particularly difficult to verify using general methods, requiring targeted verification mechanisms.

[0195] The language conversion model in this application also provides a closed-loop SQL execution verification mechanism. This mechanism achieves high-quality assurance of the generated SQL results through multi-layer verification and correction. The core components of the system include an SQL validator, a multi-level verification module, and a correction strategy engine, which together constitute a closed-loop verification and correction process.

[0196] The mechanism is designed following the principle of "early detection, early correction," with verification levels progressing from shallow to deep to gradually ensure the correctness of the SQL. 1. Syntax validation and correction: First, check the syntax structure of the SQL, find and correct syntax errors.

[0197] 2. Semantic Validation and Correction: Check the semantic rationality of the SQL, including the correctness of tables and fields, type matching, etc.

[0198] 3. Business rule verification and correction: Verify against the business rules of the specific domain to ensure that the SQL complies with business constraints.

[0199] 4. Execution verification and correction: Verify its efficiency and the rationality of the result set by actually executing the SQL (or simulating execution).

[0200] Each verification step has a corresponding correction strategy, forming a closed loop of verification-correction-re-verification, ensuring that the final generated SQL is not only correct and executable, but also conforms to user intent and business rules.

[0201] The SQL validator is the core component of the entire validation mechanism, responsible for coordinating the various validation modules and collecting and processing validation results. The main functions of the validator include: Organize and manage the verification process.

[0202] Collect the results from each verification module.

[0203] Invoke the appropriate correction strategy.

[0204] Monitor the overall verification process.

[0205] The SQL validator provides a unified verification interface and supports multiple verification modes, including full-process verification and specific-stage verification.

[0206] The SQL validation mechanism comprises four layers of validation modules, progressively strengthening each other to ensure the correctness of the SQL: Syntax validation module: responsible for checking the syntax structure of SQL to ensure that the SQL statement is syntactically correct, including parsing the SQL statement and building a syntax tree, checking the integrity and correctness of the syntax structure, and identifying and locating syntax errors.

[0207] Semantic validation module: responsible for checking the semantic rationality of SQL statements, including the existence of tables and fields, type matching, and correct use of functions, to ensure that SQL statements are semantically consistent with the database structure.

[0208] Business rule validation module: responsible for checking whether SQL conforms to specific business rules in a specific management area, including the correctness and completeness of table associations, business constraints on field usage, business rationality of conditions and filters, and business logic of aggregation and grouping.

[0209] The execution verification module verifies the execution efficiency and rationality of the result set by simulating or actually executing SQL. This includes estimating the SQL execution plan and resource consumption, checking whether the result set size is reasonable, verifying whether the execution time is within an acceptable range, and analyzing potential performance optimization opportunities.

[0210] The correction strategy engine is responsible for optimizing and correcting SQL queries based on the issues identified during verification, applying appropriate correction strategies. This engine includes various correction strategies for different problems, enabling automatic or semi-automatic improvement of SQL queries.

[0211] With its rich library of correction strategies, the correction strategy engine can handle various SQL problems, including incorrect table names, incorrect fields, improper JOIN conditions, conflicting WHERE conditions, and performance issues, greatly improving the quality and reliability of generated SQL.

[0212] To support SQL validation and correction, this system has built a business rule knowledge base specifically for a particular management domain. This knowledge base includes common table join rules, field usage constraints, and business logic limitations for queries in this specific domain, providing crucial domain knowledge support for the validation and correction process.

[0213] The main contents of the business rules knowledge base include: table join rules, field usage constraints, business logic restrictions, and performance optimization rules. Through this business rules knowledge base, the SQL validation and correction process can fully integrate domain knowledge to ensure that the generated SQL is not only technically correct but also conforms to the business specifications of specific management domains.

[0214] The core value of the SQL execution closed-loop verification mechanism lies in forming a complete closed loop of "generation-verification-correction-re-verification," ensuring the quality and executability of SQL. This closed-loop process is superior to known one-way generation methods, effectively improving the accuracy and usability of SQL.

[0215] Specifically, the entire verification closed-loop process includes multiple core steps, from generating the initial SQL to multi-level verification, problem identification, application correction, and then re-verification, finally returning the result. Simultaneously, this closed-loop design can rapidly generate training SQL statements for fine-tuning through a sample generator, giving the system a "self-correcting" capability, continuously improving the generated SQL, reducing the error rate, and increasing query efficiency.

[0216] It is understandable that certain specialized fields possess unique characteristics that preclude language conversion using general methods. For example, general-purpose natural language to SQL systems face significant domain adaptation challenges when applied to specialized fields (such as business analysis and specialized data processing). These challenges primarily manifest in the following aspects: 1. Insufficient understanding of professional terminology: Unable to accurately understand professional terms and abbreviations specific to certain management fields.

[0217] 2. Vague relationships between domain concepts: Lack of understanding of the hierarchy and relationships between concepts in a specific domain.

[0218] 3. Business process mismatch: Lack of understanding of business processes in a specific domain makes it difficult to correctly parse queries related to business processes.

[0219] 4. Difficulty in data model conversion: It is impossible to accurately map domain-specific representations to the database model, resulting in generated SQL that does not conform to the actual data structure.

[0220] These challenges significantly reduce the effectiveness of general models in specific management domains, necessitating specialized domain adaptation mechanisms to compensate for this deficiency.

[0221] The domain-specific adaptation mechanism consists of components such as a domain pre-processor, domain knowledge enhancement, professional terminology mapping, domain schema conversion, and domain post-processor, achieving domain adaptation throughout the entire process from natural language query to SQL generation. This mechanism deeply integrates knowledge of the specific management domain, ensuring that the system can accurately understand user intent and generate SQL queries that conform to domain specifications.

[0222] The overall architecture is based on the "two-way adaptation" concept, namely forward adaptation from user query to system understanding, and backward adaptation from initial generation to the final SQL. It has the following core characteristics: 1. Full-process domain adaptation: Covers the entire process from user input to final SQL generation.

[0223] 2. Deep knowledge integration: This is not a simple replacement of terminology, but rather the integration of domain concept systems and business rules.

[0224] 3. Two-way correction mechanism: It enhances the model's understanding of domain queries and ensures that the generated SQL conforms to domain specifications.

[0225] 4. Scalable knowledge base: Supports continuous expansion and updating of domain knowledge to adapt to business changes.

[0226] This architecture enables the system to fully understand the specific needs of a particular management domain, greatly improving the accuracy and usability of natural language to SQL conversion.

[0227] The domain preprocessor is the entry point component of the domain adaptation mechanism, responsible for preliminary processing of the user's original query and domain relevance analysis. Its core functions include: Domain relevance identification: Determine whether the query is relevant to a specific management domain, and the degree of relevance.

[0228] Terminology Recognition: Identifies specific management-related terms and abbreviations in queries.

[0229] Query intent classification: Classify queries into different business scenarios, such as risk analysis, performance analysis, etc.

[0230] Through these preliminary analyses, the domain preprocessor provides direction for subsequent domain knowledge enhancement, ensuring that the system can apply domain knowledge in a targeted manner.

[0231] The domain knowledge enhancement component is responsible for integrating specific management domain knowledge into the query understanding process, enabling the system to understand user intent from a domain-specific perspective. Its main functions include: Conceptual system injection: Injecting conceptual systems such as classification systems and rating standards for specific management fields into the query understanding.

[0232] Business process mapping: Identify the business processes involved in the query, such as data management and processing.

[0233] Implicit knowledge supplementation: Based on domain common sense, supplement the query with implicit but not explicitly expressed domain knowledge.

[0234] This component greatly improves the system's ability to understand professional queries by deeply integrating management knowledge from specific management fields.

[0235] The domain schema conversion component is responsible for converting the user's domain-centric description into a database model perspective, ensuring that the system can be correctly mapped to the database structure. Its main functions include: Concept-to-table mapping: Mapping domain concepts to corresponding database tables.

[0236] Metrics-to-Field Mapping: Mapping business metrics to corresponding database fields.

[0237] Business logic transformation: Convert business logic rules into SQL conditions and join relationships.

[0238] Domain schema conversion ensures accurate conversion from business language to technical implementation by maintaining a complete mapping relationship between the domain model and the database model.

[0239] The domain post-processor is responsible for performing domain-specific validation and optimization on the initially generated SQL, ensuring that the SQL conforms to the business rules and best practices of the specific management domain. Its main functions include: Business rule validation: Validates whether the SQL statement conforms to the business rules of a specific management domain.

[0240] Domain consistency correction: Corrects inconsistencies in SQL based on business rules, such as table join methods and condition combinations.

[0241] Domain-specific optimization suggestions: Provide SQL optimization suggestions tailored to the characteristics of the domain, such as index usage and common query patterns.

[0242] The domain post-processor ensures the business correctness and usability of the generated SQL through business rule verification and domain consistency correction.

[0243] To support the effective operation of the domain adaptation mechanism, this system has constructed a comprehensive knowledge base for specific management domains, including a terminology database, a conceptual framework, a business rule base, and data model mappings. This knowledge base is the core support for domain adaptation, providing the system with rich domain knowledge. By constructing a comprehensive domain knowledge base, the system can accurately understand professional queries for specific management domains and generate SQL statements that conform to domain specifications.

[0244] The above core technologies work together to construct a complete natural language to SQL system tailored to a specific management domain. The system achieves efficient parameter changes in multi-turn dialogues through an intelligent parameter substitution mapping mechanism, ensures the correctness and executability of generated SQL through a closed-loop SQL execution verification mechanism, supports continuous and in-depth data exploration through a multi-turn dialogue context preservation mechanism, solves the problem of insufficient training data through a large model-driven automatic training data generation system, and achieves a deep understanding of the specific management domain through a domain-adaptive mechanism. The entire system achieves the goal of building high-precision information retrieval capabilities starting from a small number of specialized seed tasks, significantly improving the efficiency and quality of data analysis and decision-making in specific management domains.

[0245] In summary, this application proposes a systematic and modular technical solution for the natural language to structured query language (SQL) conversion task in a specific management scenario. It achieves several technical breakthroughs in parameter replacement, training data construction, SQL generation quality control, and professional domain adaptability. The specific technical advantages are as follows: 1.1 Advantages of the intelligent parameter replacement mechanism To address the shortcomings of known "domain-specific fine-tuning methods based on large language models" in terms of parameter mapping accuracy, this invention designs and implements a parameter intelligent replacement framework with strong semantic recognition and mapping capabilities, specifically including: 1. High-precision mapping mechanism for administrative division codes: A hierarchical tree-structured model for administrative division identification and mapping was constructed, enabling accurate conversion between the names of provincial, municipal, and county-level administrative units and their standard codes. This mechanism can semantically normalize non-standard place names (such as "Guangdong" instead of "Guangdong Province") and map them to unified codes (such as "440000"). Actual testing shows that the accuracy of regional code recognition has increased from 75% to over 98%, significantly reducing the SQL execution failure rate.

[0246] 2. Semantic Parsing Mechanism for Fuzzy Time Representations: The time representation parsing module developed in this invention supports over 30 common natural language time representations (including "first half of the year," "first quarter," "first three months," etc.) and can determine the reference time (such as the current time or a historical reference point) based on the context to generate precise SQL time conditions. For complex time descriptions with nested structures such as "compared to the same period last year in the first half of the year," the parsing accuracy reaches over 95%, which is superior to known solutions.

[0247] 3. Proportional Threshold Semantic Conversion Mechanism: A dedicated semantic parsing module was designed for common proportional threshold descriptions in specific business scenarios (such as "proportion exceeding 50%" or "less than one-third"). This module accurately converts natural language descriptions into SQL numerical comparison logic. Verification has shown that this module significantly improves the accuracy of proportional expression conversion compared to known solutions, effectively avoiding query distortion caused by semantic bias.

[0248] 1.2 Advantages in Training Data Generation Efficiency 1. Small-sample expansion generation mechanism: Based on 50–100 manually constructed seed tasks, combined with the diverse generation capabilities of large-scale language models and domain-constrained rules, large-scale, semantically diverse but logically consistent training data samples are automatically generated. Empirical results show that 100 seed tasks can be expanded into more than 10,000 high-quality training data samples, with data construction efficiency approximately 100 times that of traditional manual annotation methods.

[0249] 2. Database Structure Adaptation Mechanism: A database schema parsing and mapping module has been developed, possessing the capabilities of structure parsing, entity recognition, and relational graph generation, enabling rapid adaptation to newly added table structures. Model training and adaptation can be completed within approximately 1-2 business days after the introduction of a new structure, far exceeding the adaptation cycle of known methods which typically takes weeks to months, significantly improving the system's flexibility and adaptability.

[0250] 3. Comprehensive Business Scenario Template System: A scenario template library covering multiple business roles and operational processes has been built to ensure that training data can cover the entire business chain. In practical applications, the scenario coverage rate reaches over 95%, far exceeding the 60-70% level of known solutions.

[0251] 1.3 Advantages of SQL Quality Verification Mechanism To address the technical shortcomings of SQL generation systems that only perform syntax verification but not semantic or result verification, this invention proposes a three-tiered SQL quality assurance system, including: 1. Triple Validation Structure: A multi-layered validation mechanism is constructed, including syntax structure verification, semantic consistency verification, and SQL execution result evaluation, achieving comprehensive protection from surface syntax to deep semantics. Experimental data shows that the overall SQL generation accuracy is improved by approximately 20% compared to a single syntax verification method.

[0252] 2. Feedback-based self-learning mechanism: An error collection and pattern summarization system based on SQL execution feedback is introduced. This system automatically records execution failures or result deviations, forming an error pattern knowledge base, which is then fed back into the training process to promote continuous model self-optimization. Long-term testing shows that this mechanism can improve the system's accuracy by approximately 15% within one month.

[0253] 3. Complex Structure Optimization Module: This application constructs an optimization module for complex SQL structures such as multi-table joins, nested subqueries, and window functions, possessing the capabilities of structure rewriting and performance optimization. In multi-table join query scenarios, the SQL execution success rate is increased from 60% of known methods to over 90%, significantly enhancing the system's complex query capabilities.

[0254] 1.4 Advantages of Adaptability to Professional Fields To address the issues of weak understanding and poor generalization ability of general models in specific professional fields, this application proposes a domain-adaptive fine-tuning and ontology knowledge enhancement strategy, specifically implemented as follows: 1. High-accuracy terminology recognition mechanism: A domain-specific ontology knowledge base with over 1500 terminology entries is constructed, covering core terms, logical relationships, and contextual rules, significantly improving the model's ability to recognize and understand key industry terms. Real-world testing shows a terminology recognition accuracy exceeding 95%, more than double that of general-purpose models.

[0255] 2. Semantic Modeling Capabilities for Inter-Table Relationships: By introducing a table structure awareness mechanism and combining graph structure modeling and semantic analysis techniques, accurate modeling of relationships such as primary and foreign keys, implicit associations, and business rules can be achieved. In multi-table join scenarios, the SQL generation accuracy is improved by approximately 30% compared to known technologies.

[0256] 3. Logical Reasoning Engine: Develop a logical reasoning module that supports conditional comparison, aggregation analysis, and nested structures to meet the needs of complex computational logic in specific business scenarios.

[0257] 4. Dialogue Context Semantic Inheritance Mechanism: A multi-turn dialogue context management mechanism based on user intent tracking is constructed, supporting context state maintenance and semantic inheritance, significantly reducing semantic interruptions. In more than five consecutive rounds of dialogue, the context understanding accuracy remains consistently above 85%.

[0258] 1.5 Overall Performance and Deployment Advantages This application not only achieves breakthroughs in multiple aspects of core technologies, but also demonstrates significant advantages in system integration and deployment efficiency in practical applications: 1. Significantly improved task efficiency: By integrating parameter optimization, semantic enhancement and structural optimization modules, the overall accuracy of natural language to SQL conversion in this application exceeds 90%, and the average response time of user query tasks is reduced by 60%, which greatly improves operational efficiency.

[0259] 2. Significantly reduced computing power consumption: This application adopts a dedicated fine-tuning model with a parameter scale of only 30% of that of the general model, which can be efficiently deployed in ordinary computing environments, reducing hardware costs and improving model response efficiency.

[0260] 3. Enhanced Business Value: After the system went live, even non-technical personnel could perform complex data queries using natural language, significantly lowering the threshold for data analysis and better meeting actual business needs.

[0261] 4. Strong cross-organizational deployment capability: It adopts a highly modular architecture design and has good system migration and rapid adaptation capabilities.

[0262] Figure 2 This illustration shows a structural diagram of a natural language to SQL conversion device according to an embodiment of this application. The device is applied to a language conversion model and includes: The language receiving module 210 is used to receive the natural language input by the user for querying; The judgment module 220 is used to determine whether the natural language to be queried is the first round of query; The language conversion module 230 is used to determine the query type corresponding to the natural language to be queried when the natural language to be queried is the first round of query, locate the target database according to the query type, determine the target SQL statement corresponding to the natural language to be queried according to the target database, and cache the target SQL statement; The language conversion module 230 is further configured to determine the context relationship corresponding to the natural language to be queried when the natural language to be queried is not the first query, and modify the cached SQL statement according to the context relationship to obtain the target SQL statement corresponding to the natural language to be queried, and cache the target SQL statement.

[0263] In this embodiment, the effective storage, understanding and utilization of contextual information in multi-turn dialogues can be achieved. This mechanism enables the system to remember and understand the previous dialogue content, accurately grasp the continuity of user intent, and replace only the cached SQL statements during multi-turn queries, thereby improving the efficiency of natural language to SQL conversion.

[0264] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of one embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application.

[0265] Those skilled in the art will understand that the modules in the apparatus of the embodiments can be distributed in the apparatus of the embodiments as described in the embodiments, or they can be located in one or more devices different from this embodiment with corresponding changes. The modules of the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0266] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 this application.

Claims

1. A method for converting natural language to SQL, characterized in that, The method is applied to a language conversion model, and the method includes: Receive natural language input from the user to query; Determine whether the natural language query is the first query; When the natural language to be queried is the first round of query, determine the query type corresponding to the natural language to be queried, locate the target database according to the query type, determine the target SQL statement corresponding to the natural language to be queried according to the target database, and cache the target SQL statement; When the natural language to be queried is not the first query, the context relationship corresponding to the natural language to be queried is determined, and the cached SQL statement is modified according to the context relationship to obtain the target SQL statement corresponding to the natural language to be queried, and the target SQL statement is cached.

2. The method according to claim 1, characterized in that, The step of modifying the cached SQL statement according to the context relationship to obtain the target SQL statement corresponding to the natural language to be queried includes: When the context relationship is a conditional accumulation, the corresponding conditions are added to the cached SQL statement to obtain the target SQL statement corresponding to the natural language to be queried; When the context relationship is conditional overriding, conditional replacement is performed in the cached SQL statement to obtain the target SQL statement corresponding to the natural language to be queried.

3. The method according to claim 2, characterized in that, The step of performing conditional replacement in the cached SQL statement to obtain the target SQL statement corresponding to the natural language to be queried includes: Identify the parameter types in the natural language to be queried; the parameter types include one or more of the following: geographic code, time interval, and proportion threshold; Based on the parameter type, conditional replacement is performed in the cached SQL statement to obtain the target SQL statement corresponding to the natural language to be queried.

4. The method according to claim 1, characterized in that, After caching the target SQL statement, the method further includes: The target SQL statement is executed and validated, wherein the validation includes at least: syntax validation, semantic consistency validation, and execution result analysis.

5. The method according to any one of claims 1-4, characterized in that, When the natural language to be queried is the first-round query, the method further includes: Clear cached SQL statements.

6. The method according to claims 1-4, characterized in that, The training process of the language conversion model includes: Obtain seed task; Based on the seed task and the automatic training data generation system, training samples corresponding to the seed task are generated; the automatic training data generation system includes: a seed task processor, a sample generator, a diversity enhancement component, and a quality validator; The language conversion model is trained based on the training samples.

7. A device for converting natural language to SQL, characterized in that, The device is applied to a language conversion model, and the device includes: The language receiving module is used to receive the natural language input by the user for the query. The judgment module is used to determine whether the natural language to be queried is the first round of query; The language conversion module is used to determine the query type corresponding to the natural language to be queried when the natural language to be queried is the first round of query, locate the target database according to the query type, determine the target SQL statement corresponding to the natural language to be queried according to the target database, and cache the target SQL statement; The language conversion module is further configured to determine the context relationship corresponding to the natural language to be queried when the natural language to be queried is not the first query, and modify the cached SQL statement according to the context relationship to obtain the target SQL statement corresponding to the natural language to be queried, and cache the target SQL statement.

8. The apparatus according to claim 7, characterized in that, The language conversion module is specifically used for: When the context relationship is a conditional accumulation, the corresponding conditions are added to the cached SQL statement to obtain the target SQL statement corresponding to the natural language to be queried; When the context relationship is conditional overriding, conditional replacement is performed in the cached SQL statement to obtain the target SQL statement corresponding to the natural language to be queried.

9. The apparatus according to claim 8, characterized in that, The language conversion module is specifically used for: Identify the parameter types in the natural language to be queried; the parameter types include one or more of the following: geographic code, time interval, and proportion threshold; Based on the parameter type, conditional replacement is performed in the cached SQL statement to obtain the target SQL statement corresponding to the natural language to be queried.

10. The apparatus according to claim 7, characterized in that, The device further includes: The statement verification module is used to execute the target SQL statement and verify the target SQL statement, wherein the verification includes at least: syntax verification, semantic consistency verification, and execution result analysis.

Images