Method, apparatus, and system for intelligent natural language-to-query (text2sql) conversion based on retrieval-augmented generation and automatic error recovery

Abstract

One embodiment of the present invention relates to an intelligent natural language-to-query (Text2SQL) conversion method, apparatus, and system based on search augmentation generation and automatic error recovery, which analyzes the intent of a question entered in natural language, generates an optimal query by referring to a database schema and a history of similar past queries, and converts it into an executable query through a self-correcting loop when an error occurs.

Description

Technology Field

[0001] The following embodiments relate to an intelligent natural language-to-query (Text2SQL) conversion method, apparatus, and system based on search augmentation generation and automatic error recovery, which analyzes the intent of a question entered in natural language, generates an optimal query by referring to a database schema and a history of similar queries, and converts it into an executable query through a self-correcting loop in the event of an error. Background Technology

[0002] Recently, Text2SQL (Text-to-SQL) technology has been gaining attention as it enables general users without specialized database knowledge to easily query data using natural language. In particular, alongside the advancement of Large-Scale Language Models (LLM), numerous systems have been proposed that understand the context of natural language and convert it into SQL queries.

[0003] However, existing language model-based Text2SQL systems expose various structural limitations as they generate queries by simply referencing the database's entire schema information. First, hallucinations frequently occur, where the language model invents arbitrary table or column names that do not exist in the actual database. Second, syntax errors frequently occur during execution because the system fails to perfectly reflect the differing syntactic structures across heterogeneous database systems such as Oracle, MySQL, and PostgreSQL. Third, the consistency of system responses is significantly compromised because different query forms are generated every time, even for identical or similar questions.

[0004] Above all, the most significant problem is the serious inconvenience caused by the fact that if an error occurs during the execution of a generated query, the system halts operation and returns an error message, forcing users to manually analyze the cause of the error and re-enter the natural language query. This disrupts service continuity and serves as a core cause hindering data accessibility for non-experts. Prior art literature

[0005] (Patent Document 0001) KR 10-2926030 B (Patent Document 0002) KR 10-2893522 B The problem to be solved

[0006] The problem that an embodiment of the present invention aims to solve is to provide an intelligent natural language-to-query (Text2SQL) conversion method, apparatus, and system based on search augmentation generation and automatic error recovery, which improves accuracy by referencing the history of similar queries that were previously successful using a search augmentation (RAG) technique, and which automatically analyzes the cause of an error, corrects the query, and re-executes it when an error occurs, in order to overcome the limitations of hallucination caused by relying solely on the conventional large-scale language model (LLM) described above, syntax errors between heterogeneous databases, and the requirement for the user to directly intervene and re-execute when query execution fails. means of solving the problem

[0007] According to one embodiment, an intelligent natural language-to-text query (Text2SQL) conversion method based on search augmentation generation and automatic error recovery is performed by the processor by executing a program stored in the non-transient storage medium, wherein the device includes a processor, memory, a communication module, and a non-transient storage medium. The method comprises: receiving a natural language-based current question from a user terminal; classifying a scenario corresponding to the current question and performing a similarity search using a search augmentation generation (RAG) method based on the current question and the scenario to extract one or more past query (SQL) examples; constructing a first prompt by combining schema information of a target database, the past query examples, and the current question, and generating a current query by inputting the first prompt into a language model (LLM); and executing the current query in the target database. The present invention provides an intelligent natural language-to-query (Text2SQL) conversion method based on search augmentation generation and error automatic recovery, comprising: an automatic recovery (Fallback) step in which, if an error occurs during the execution of the current query, a second prompt including a message regarding the error, the current query, and information on the number of retries is configured and input into the language model to analyze the error and modify the current query; and a step of re-executing the current query in the target database, and if an error occurs again during re-execution, repeating the automatic recovery step and the re-execution process until the number of retries exceeds a preset maximum number of retries, and returning an error termination message when the maximum number of retries is exceeded.

[0008] Additionally, the step of extracting the above-mentioned past query examples comprises: transmitting a search request including the above-mentioned current question and scenario to a RAG server capable of vector similarity-based search; receiving a plurality of query example candidates from the RAG server as a response to the search request; and determining the top N query example candidates with a high similarity ranking with the above-mentioned current question and scenario among the plurality of query example candidates as past query examples in order to limit token consumption of the language model; and the step of generating the above-mentioned current query comprises: obtaining a unique identifier (history_id) that identifies the history of the above-mentioned current question; configuring the above-mentioned query examples into an example set in the form of a past-mentioned question-past-mentioned query example and generating a first prompt including the current question, the example set, and schema information of the target database; and inputting the first prompt into the language model to derive the current query. and the step of mapping the unique identifier and the current query to a query cache and saving them in an up-to-date state; wherein the automatic recovery step comprises: the step of accumulating the number of retries by mapping the unique identifier to a retry count cache; the step of retrieving the immediately preceding query retrieved by the unique identifier from the query cache; the step of omitting the extraction of the previously executed query example and generating a second prompt including a message regarding the error, the immediately preceding query, the number of retries, and actual schema information of the target database; and the step of inputting the second prompt into a language model to analyze the error type to determine whether the error corresponds to at least one of a typo in the table name, an error in a column name not existing in the schema, a syntax error due to heterogeneous database support, and a data type mismatch.The method may include a step of updating the current query by replacing the components of the immediately preceding query with names corresponding to the actual schema information of the target database or by substituting them with type conversions or grammatical structures suitable for the target database according to the analyzed error type; and a step of updating and storing the unique identifier and the current query in the query cache in an up-to-date state.

[0009] And, the RAG server comprises: a step of converting the current question included in the search request into a multidimensional query vector normalized through an embedding model, and extracting a query feature token from the current question that includes at least one of a target entity, an aggregation intent, a filter condition, a time condition, and a sorting condition; a step of identifying a specific example partition corresponding to a scenario included in the search request in a vector database where question-query examples are stored; a step of searching for a primary candidate group by calculating vector similarity between the past question vectors stored within the specific example partition and the query vector; a step of calculating the degree of alignment between at least one of a table tag, a column tag, an aggregate function tag, a join structure tag, and a time condition tag assigned to the past question-query example corresponding to each of the primary candidate group and the query feature token; and a step of calculating an integrated search score for each candidate by assigning weights to the vector similarity and the degree of alignment, respectively. The method is controlled according to a control method comprising the step of determining the top N query example candidates within the token consumption limit of the language model according to the descending order of the integrated search scores, and the step of searching for the primary candidate group may include: designating an example partition having the same scenario tag as the scenario among a plurality of example partitions stored in the vector database as the primary search space, and if no example partition having the same scenario tag exists, designating an adjacent scenario partition having a similarity on a predefined similar scenario mapping table with the scenario above a preset standard as the secondary search space; performing unit vector normalization on each of the past question vectors included in the primary search space or the secondary search space and then calculating the cosine similarity with the query vector; and selecting only the past question vectors whose cosine similarity is above a preset valid threshold as the primary candidate group.

[0010] In addition, the step of calculating the degree of consistency comprises: a step of subdividing the query feature tokens into schema tokens that map directly to the structure of the target database and function tokens that instruct operation processing; a step of reclassifying the schema tokens into table name designation tokens and column name designation tokens, and reclassifying the function tokens into aggregation intent tokens, time condition tokens, join request tokens, and sorting request tokens; a step of calculating a first weighted score by comparing the number of exact matches, the number of partial matches, and the hierarchical association based on the table-column inclusion relationship between the table tag and column tag, which are pre-parsed and attached to the past question-past query example of each of the first candidate group, and the table name designation tokens and column name designation tokens; and a step of calculating a second weighted score of a different scale from the first weighted score by comparing whether there is a logical match between at least one of the aggregation function tag, join structure tag, time condition tag, and sorting tag of each of the first candidate group and the corresponding function token among the aggregation intent token, join request token, time condition token, and sorting request token. The method may include: a step of deducting a preset penalty score for a past question-past query example that includes redundant table tags, unnecessary join structure tags, unnecessary time condition tags, or unnecessary aggregate function tags that do not explicitly correspond to the query feature token of the current question; and a step of combining the first weighted score and the second weighted score and deriving the degree of alignment for each candidate by reflecting the penalty score.

[0011] Additionally, the step of identifying the specific example partition comprises: a step of normalizing a string of a scenario included in the search request into a standard scenario identifier by performing at least one of synonym substitution, abbreviation expansion, delimiter unification, and typographical correction by referring to a pre-built scenario normalization dictionary; a step of decomposing the standard scenario identifier into a first upper business domain code and a first lower query object code; a step of generating a scenario key for partition routing by recombining the first upper business domain code and the first lower query object code according to a pre-established combination rule; a step of generating a partition routing key by applying a hash function to the scenario key for partition routing; a step of querying a partition index mapped to the partition routing key in a partition routing table associated with the vector database; and a step of obtaining metadata of an example partition corresponding to the partition index and verifying whether the second standard scenario identifier, the second upper business domain code, and the second lower query object code included in the metadata match the standard scenario identifier, the first upper business domain code, and the first lower query object code, respectively. If the result of the match verification is valid, the step of confirming the example partition as the specific example partition; if the result of the match verification is invalid, the step of re-querying an alternative partition index in the partition routing table corresponding to an adjacent third subquery object code, where the first upper business domain code is identical and the similarity with the first subquery object code is greater than or equal to a preset standard; and the step of obtaining metadata of an alternative example partition corresponding to the alternative partition index to verify whether the third upper business domain code of the alternative example partition matches the first upper business domain code and whether the third subquery object code of the alternative example partition corresponds to the first subquery object code with a similarity greater than or equal to a preset standard.The method may include: a step of confirming the alternative example partition as the specific example partition if the similarity verification result for the alternative example partition is valid; a step of querying the basic partition index of the basic example partition, which stores integrated past question-past query term examples corresponding to the first upper business domain code and a plurality of lower-level query target codes, if the similarity verification result for the alternative example partition is invalid; a step of obtaining metadata of the basic example partition corresponding to the basic partition index and verifying whether the fourth upper business domain code of the basic example partition matches the first upper business domain code; a step of confirming the basic example partition as the specific example partition if the verification result for the basic example partition is valid; and a step of generating partition identification failure information if the verification result for the basic example partition is also invalid.

[0012] A device according to one embodiment may be combined with hardware and controlled by a computer program stored on a medium to execute the method of any one of the methods described above. Effects of the invention

[0013] According to one embodiment, the accuracy and consistency of initial query generation can be significantly improved by injecting past similar query examples corresponding to natural language questions into a language model using a search augmentation generation method, and even if an error occurs during query execution, the system can provide a seamless data retrieval service by independently analyzing the error message and the previous query to modify and re-execute it without user intervention.

[0014] In addition, by caching the history of query execution processes as unique identifiers, unnecessary vector similarity search processes are omitted when entering error recovery mode, thereby minimizing the waste of language model token costs and computing resources. Furthermore, the recovery success rate can be maximized by actively replacing names or syntax to conform to the actual schema, tailored to specific error types such as table name typos or data type mismatches.

[0015] In addition, instead of simply scanning the entire vector database, scenario and query feature tokens are extracted from the user's question to narrow the search scope to a specific example partition, and by performing a multidimensional evaluation that combines not only cosine similarity but also the consistency between tags, it is possible to fundamentally prevent the extraction of irrelevant examples that are only semantically similar but have completely different structures.

[0016] In addition, if past examples contain redundant table joins or unnecessary aggregate functions that are not required by the user's current question, they are thoroughly excluded from the candidates by applying a pre-set penalty, thereby preventing database system overload (Full Scan, Deadlock, etc.) caused by indiscriminate join operations and ensuring the stability of system operations.

[0017] In addition, by providing multiple safeguards that perform a stepwise bypass search to a predefined similar-purpose partition or the primary partition of the parent domain when an exact match partition index does not exist or is invalidated during the process of identifying a specific hash-mapped partition based on a query scenario, it is possible to robustly defend against search failure errors that may occur due to data imbalance or empty partitions in a large-scale vector database environment. Brief explanation of the drawing

[0018] FIG. 1 is a schematic diagram showing an intelligent natural language-to-query (Text2SQL) conversion system based on search augmentation generation and automatic error recovery according to an embodiment of the present invention. FIG. 2 is a flowchart illustrating an intelligent natural language-to-query (Text2SQL) conversion method based on search augmentation generation and automatic error recovery according to an embodiment of the present invention. FIG. 3 is a flowchart illustrating the step of extracting past query examples of an intelligent natural language-to-query (Text2SQL) conversion method based on search augmentation generation and automatic error recovery according to an embodiment of the present invention. FIG. 4 is a flowchart illustrating the step of generating the current query of an intelligent natural language-to-query (Text2SQL) conversion method based on search augmentation generation and automatic error recovery according to an embodiment of the present invention. FIG. 5 is a flowchart illustrating the automatic recovery step of an intelligent natural language-to-query (Text2SQL) conversion method based on search augmentation generation and automatic error recovery according to an embodiment of the present invention. Specific details for implementing the invention

[0019] Hereinafter, embodiments are described in detail with reference to the attached drawings. However, various modifications may be made to the embodiments, and thus the scope of the patent application is not limited or restricted by these embodiments. It should be understood that all modifications, equivalents, and substitutions to the embodiments are included within the scope of the rights.

[0020] Specific structural or functional descriptions of the embodiments are disclosed for illustrative purposes only and may be modified and implemented in various forms. Accordingly, the embodiments are not limited to the specific disclosed forms, and the scope of this specification includes modifications, equivalents, or substitutions that fall within the technical concept.

[0021] Terms such as "first" or "second" may be used to describe various components, but these terms should be interpreted solely for the purpose of distinguishing one component from another. For example, the first component may be named the second component, and similarly, the second component may be named the first component.

[0022] When it is stated that a component is "connected" to another component, it should be understood that it may be directly connected to or coupled with that other component, or that there may be other components in between.

[0023] The terms used in the embodiments are for illustrative purposes only and should not be interpreted as intended to be limiting. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this specification, terms such as "comprising" or "having" are intended to indicate the existence of the features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

[0024] In particular, where a 'step' in this specification is described as 'comprising' one or more detailed steps or sub-steps, said 'step' may be interpreted as including its own basic processing step while simultaneously performing the described detailed steps as well.

[0025] For example, if it is stated that 'a step of doing B to A' includes 'a step of doing D to C; a step of doing F to E; and a step of doing H to G,' the 'step of doing B to A' may be interpreted not merely as the basic operation of doing B to A, but as a configuration that performs detailed procedures together, such as a step of doing D to C, a step of doing F to E, and a step of doing H to G.

[0026] Accordingly, the above configuration does not exclude various sub-procedures included within the scope of execution of the corresponding step, and may be included within the scope of the present invention even if other procedures or means performing substantially the same or equivalent functions are substituted.

[0027] Expressions such as 'end part', 'both ends', 'one end', 'other end', and 'side end' of a component can be interpreted as referring to at least / any one of the end parts of that component.

[0028] In the description of the present invention, 'a method in which a device comprises a processor, a memory, a communication module, and a non-transient storage medium, and a program stored in the non-transient storage medium is executed by the processor,' the term 'method' may be interpreted as referring to the program stored in the non-transient storage medium itself or a part of the program.

[0029] The term 'Return' as used in the description of the present invention may refer to a result value being output, returned, or returned from a method, procedure, function, etc. used in a given program language / structure.

[0030] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as generally understood by those skilled in the art to which the embodiments pertain. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and should not be interpreted in an ideal or overly formal sense unless explicitly defined in this application. For example, the term 'artificial intelligence model' may be selected from one or more of known general artificial intelligence models.

[0031] In addition, when describing with reference to the attached drawings, identical components are assigned the same reference numeral regardless of drawing symbols, and redundant descriptions thereof are omitted. In describing the embodiments, if it is determined that a detailed description of related prior art could unnecessarily obscure the essence of the embodiments, such detailed description is omitted.

[0032] According to one embodiment, an intelligent natural language-to-text query (Text2SQL) conversion method based on search augmentation generation and automatic error recovery is performed by the processor by executing a program stored in the non-transient storage medium, wherein the device includes a processor, memory, a communication module, and a non-transient storage medium. The method comprises: receiving a natural language-based current question from a user terminal; classifying a scenario corresponding to the current question and performing a similarity search using a search augmentation generation (RAG) method based on the current question and the scenario to extract one or more past query (SQL) examples; constructing a first prompt by combining schema information of a target database, the past query examples, and the current question, and generating a current query by inputting the first prompt into a language model (LLM); and executing the current query in the target database. The present invention provides an intelligent natural language-to-query (Text2SQL) conversion method based on search augmentation generation and error automatic recovery, comprising: an automatic recovery (Fallback) step in which, if an error occurs during the execution of the current query, a second prompt including a message regarding the error, the current query, and information on the number of retries is configured and input into the language model to analyze the error and modify the current query; and a step of re-executing the current query in the target database, and if an error occurs again during re-execution, repeating the automatic recovery step and the re-execution process until the number of retries exceeds a preset maximum number of retries, and returning an error termination message when the maximum number of retries is exceeded.

[0033] The step of receiving a natural language-based current question from a user terminal is the step in which the device receives a natural language query including a data lookup request from the user terminal through a communication module.

[0034] Here, a user terminal may refer to a computing device such as a PC, smartphone, tablet, laptop, or industrial terminal operated by a user who wishes to query information stored in a database.

[0035] The current question refers to a data retrieval request statement written in everyday human language rather than a structured query language such as SQL, and may include the target, period, condition, aggregation method, sorting method, and output format. For example, the current question may be text in the form of “Show me the monthly average defect rate of production line A over the last 3 months,” “Retrieve the top 5 equipment utilization rates for this month,” or “Tell me which items among the products shipped yesterday are at risk of stock shortage.”

[0036] The step of receiving a current natural language-based question from a user terminal is not limited to receiving only a question string, but may also include receiving at least one of session information, terminal identification information, request time, language settings, a target system identifier, and user authorization information associated with the current question. Accordingly, the device can distinguish which user or system environment inputs a question with the same expression, and can improve accuracy by reflecting this in the subsequent scenario classification and query generation processes. For example, even if the expression “production volume this month” is input identically, the referenced tables, columns, and join relationships may differ depending on whether the environment is connected to a production performance database or a quality analysis database.

[0037] Here, the device may include a processor, memory, a communication module, and a non-transient storage medium, and the processor may perform operations for receiving a current question, classifying scenarios, searching for past query examples, generating a prompt, generating a query, executing a database, and recovering errors. The memory may be a volatile storage area that temporarily stores the current question, prompt, generated query, execution results, and error information, and the non-transient storage medium may be a non-volatile storage area that stores a program for performing the method, scenario classification rules, an example search model, a prompt template, cache data, and database connection setting information.

[0038] The step of classifying scenarios corresponding to the above-mentioned current question and extracting one or more past query examples by performing a similarity search using a search augmentation generation method based on the above-mentioned current question and scenarios is a step for interpreting the meaning of the received current question into a query type suitable for the business context, searching for past successful query examples corresponding to that query type, and utilizing them as reference information for generating subsequent queries.

[0039] Here, a scenario may be classification information used to distinguish the business domain or business type to which the current question belongs, and may be defined, for example, as a combination of a higher-level business domain such as production performance inquiry, quality analysis, inventory management, production planning, facility operation, shipment status, or cost analysis, and a lower-level query objective such as monthly aggregation, period comparison, anomaly detection, ranking inquiry, or trend analysis. The device can classify the scenario by analyzing the entity name, metric name, period expression, aggregation expression, and condition expression included in the current question.

[0040] The step of classifying scenarios corresponding to the above-mentioned current question and extracting one or more past query examples by performing a similarity search using a search augmentation generative method based on the above-mentioned current question and scenarios may be a step of not simply inputting only the current question into the language model, but rather first searching for past questions that are semantically similar to the current question and their corresponding queries from an external vector database or example repository, and then utilizing them together.

[0041] Here, "past query examples" may refer to question-query pairs that have been generated or verified in the past, and may include at least one of a natural language question sentence, a corresponding SQL statement, information on the table used, information on the column used, information on the aggregate function, time condition information, join structure information, domain tags, and scenario tags. For example, if the current question is "Show yesterday's production volume of Factory A," the system classifies this as a production performance scenario and can extract past questions and corresponding queries that were successfully executed in production performance scenarios in the past, such as "last week's production volume of Factory B" or "inquiry into daily production performance of a specific line," based on vector similarity.

[0042] The step of constructing a first prompt by combining schema information of the target database, the above-mentioned past query example, and the above-mentioned current question, and generating the current query by inputting the first prompt into a language model, is a step of structuring input information so that the language model can generate a query that simultaneously reflects the intent of the current question and the actual structure of the target database.

[0043] Here, the schema information of the target database may refer to at least one of the table name, column name, data type, primary key and foreign key relationship, allowed join relationship, view information, index information, reserved word information, and database dialect information included in the target database. The first prompt may refer to language model input information that combines the above schema information, past query examples, and the current question into a single text document or structured input data form.

[0044] The step of constructing a first prompt by combining schema information of a target database, the aforementioned past query example, and the aforementioned current question, and inputting the first prompt into a language model to generate a current query, may be a step of structuring and including the current question into query purpose, lookup target, condition, sorting, and aggregation items, and arranging the past query example in a question-query correspondence format to provide the language model with the ability to learn query patterns. The language model may generate an executable current query that corresponds to the current question by referring to the actual schema structure included in the first prompt and the grammatical structure of the past query example.

[0045] Here, the current query may refer to an SQL statement, SQL-like syntax, or a query statement dependent on a specific DBMS that is generated to correspond to the current question. For example, if the current question is to query the average defect rate of production line A for the last three months, and the schema information contains columns such as `defect_rate`, `line_name`, and `stat_month`, and the past query examples include a monthly average aggregation pattern, the language model can derive a current query that includes a production line filter, a period condition, monthly grouping, and average aggregation.

[0046] The step of executing the current query in the target database is the step of the device transmitting the generated current query to the target database system to perform actual data retrieval and receiving the execution result or error result thereof.

[0047] Here, the target database may be at least one of a relational database, a columnar database, a data warehouse, a time-series database, or a heterogeneous data storage system.

[0048] The device may perform grammar validation, table existence validation, column existence validation, or execution permission validation prior to executing the current query, or it may determine the validity of the query through the actual execution results of the database engine. If the execution result is normal, a response in the form of a query result table, numeric data, graph data, or a summary sentence may be generated and provided to the user terminal.

[0049] The automatic recovery step, which analyzes the error and modifies the current query by configuring a second prompt containing a message regarding the error, the current query, and information on the number of retries and inputting it into the language model when an error occurs during the execution of the current query, is a step for automatically correcting the initially generated current query without user intervention when it does not match the actual environment of the target database.

[0050] Here, the error message may include system log strings, error codes, error location information, failed token information, or exception logs returned by the database system or the intermediate execution layer. The retry count information may refer to the cumulative number of times the automatic recovery step has been operated for a single current query. The second prompt may refer to a recovery input data structure configured to instruct the language model to debug by combining the current query source, error message, retry count, and, if necessary, actual schema information.

[0051] When an error occurs during the execution of the current query, the automatic recovery step of analyzing the error and modifying the current query by configuring a second prompt containing a message regarding the error, the current query, and information on the number of retries, and inputting it into the language model, may be a step of specifically correcting the current query according to the cause of the error. For example, if the current query refers to a non-existent table name, it may be replaced with a table of a similar name existing in the actual schema information, and if it refers to a non-existent column name, it may be replaced with the column name that is semantically closest. In addition, if syntax not supported by a specific database is used, it may be converted to syntax that matches the dialect of the target database, and if a data type mismatch occurs, such as a comparison between a date type column and a string literal, the current query may be updated by inserting a type conversion function or changing the comparison structure. For example, if a column named `avg_defect_rate` does not actually exist and only `defect_rate` exists, the device may generate an updated current query by replacing the column name with `defect_rate` based on the error message and schema information.

[0052] The step of re-executing the current query in the target database, and if an error occurs again during re-execution, repeating the automatic recovery step and re-execution process until the number of retries exceeds a preset maximum number of retries, and returning an error termination message when the maximum number of retries is exceeded, is a step of cycling through the automatic recovery loop until the modified current query returns a valid execution result.

[0053] Here, the maximum number of retries may be a limit value pre-set by an administrator or system policy to prevent infinite loops or the waste of language model token costs. If the data retrieval is successful by re-executing the modified current query, the loop can be terminated immediately and the query results provided to the user terminal; if an error occurs again, the retry count value can be increased and a second prompt configured to perform automatic recovery.

[0054] The step of re-executing the current query in the target database, and if an error occurs again during re-execution, repeating the automatic recovery step and the re-execution process until the number of retries exceeds a preset maximum number of retries, and returning an error termination message when the maximum number of retries is exceeded, may be a step of stopping meaningless repetition of operations and clearly notifying the failure status when the scope of automatic recovery is exceeded. Here, the error termination message is not limited to a simple failure notification and may include at least one of a summary of the cause of failure, the current query last attempted, information on the failed schema object, whether an administrator review is required, and a message prompting for subsequent manual input. Accordingly, users can verify why a query failed even when automatic recovery is not possible, and administrators can collect patterns of repeatedly failing queries to improve scenario classification models, a repository of past query examples, schema consistency judgment logic, and error recovery prompts. Consequently, the above method can form a closed-loop query processing structure that includes query generation, execution, recovery, and failure history accumulation.

[0055] Additionally, the step of extracting the above-mentioned past query examples comprises: transmitting a search request including the above-mentioned current question and scenario to a RAG server capable of vector similarity-based search; receiving a plurality of query example candidates from the RAG server as a response to the search request; and determining the top N query example candidates with a high similarity ranking with the above-mentioned current question and scenario among the plurality of query example candidates as past query examples in order to limit token consumption of the language model; and the step of generating the above-mentioned current query comprises: obtaining a unique identifier (history_id) that identifies the history of the above-mentioned current question; configuring the above-mentioned query examples into an example set in the form of a past-mentioned question-past-mentioned query example and generating a first prompt including the current question, the example set, and schema information of the target database; and inputting the first prompt into the language model to derive the current query. and the step of mapping the unique identifier and the current query to a query cache and saving them in an up-to-date state; wherein the automatic recovery step comprises: the step of accumulating the number of retries by mapping the unique identifier to a retry count cache; the step of retrieving the immediately preceding query retrieved by the unique identifier from the query cache; the step of omitting the extraction of the previously executed query example and generating a second prompt including a message regarding the error, the immediately preceding query, the number of retries, and actual schema information of the target database; and the step of inputting the second prompt into a language model to analyze the error type to determine whether the error corresponds to at least one of a typo in the table name, an error in a column name not existing in the schema, a syntax error due to heterogeneous database support, and a data type mismatch.The method may include a step of updating the current query by replacing the components of the immediately preceding query with names corresponding to the actual schema information of the target database or by substituting them with type conversions or grammatical structures suitable for the target database according to the analyzed error type; and a step of updating and storing the unique identifier and the current query in the query cache in an up-to-date state.

[0056] The step of transmitting a search request including the current question and scenario to a RAG server capable of vector similarity-based search is a step in which the device packages the current question and the previously classified scenario into a format suitable for search augmentation generation and transmits it to an example search server.

[0057] Here, vector similarity-based search may refer to a search technique that converts text into numerical vectors in a multidimensional space and then calculates the distance or angle between vectors to find the semantically closest data. Accordingly, compared to methods that rely on simple keyword matching, it can more precisely reflect the context, intent, and business context of the question. For example, if the current question is “Show me the monthly average defect rate of production line A over the last 3 months” and the scenario is classified as quality analysis, the search request may include at least one of the current question string, quality analysis scenario identifier, request time, session identifier, language setting, user permission information, and target database identifier.

[0058] The step of transmitting a search request including the current question and scenario to a RAG server capable of vector similarity-based search may be a step in which the device does not input only the current question into the language model, but first searches for successful past question-query examples and utilizes them as reference information for generating subsequent queries.

[0059] Here, a RAG server may refer to a separate server or logical functional block that searches for and returns past question-query examples semantically similar to the current question based on a vector database or embedding index. Past query examples may refer to question-query pairs that were actually generated or validated in the past, and may be example data containing at least one of a natural language question sentence, a corresponding SQL statement, the table name, column name, aggregate function, time condition, join relationship, scenario tag, and execution success status.

[0060] The step of receiving multiple query example candidates from the RAG server in response to a search request is a step in which the RAG server returns multiple question-query candidates as a result of performing a vector similarity or semantic-based search, and the device receives them.

[0061] Here, a query example candidate is not limited to an example that is exactly the same as the current question, but may refer to a past question-past query pair that satisfies at least one of semantic similarity, scenario consistency, structural similarity, or schema consistency. Each of the above query example candidates may include at least one of the past question original text, corresponding query, similarity score, scenario tag, used table tag, column tag, aggregate function tag, and execution success history. For example, the above RAG server may return multiple candidates such as “querying the monthly average defect rate by production line for the last 3 months,” “querying quality indicators by period for a specific factory,” and “aggregating the monthly defect rate by line.”

[0062] To limit token consumption of the language model, the step of selecting the top N query example candidates with a high similarity ranking to the current question and scenario from among multiple query example candidates and determining them as past query example candidates is a step of controlling prompt length and computational cost by selecting only a small number of examples within a valid range, rather than inputting all searched candidates into the language model.

[0063] Here, token consumption refers to the amount of computation, response delay, and billing costs that increase in proportion to the number of tokens, which are the basic units for a language model to process text. Top N refers to a predetermined number of candidates at the beginning of a set of candidates sorted based on similarity scores, scenario consistency, schema consistency, or a combined score thereof; N can be set as an integer between 1 and 10, inclusive, depending on the language model's allowed input length, average example length, administrator settings, or system load status. For example, even if 10 example candidates with high similarity are received from the RAG server, if N is set to 3, only the top 3 candidates can be confirmed as the final past query examples and passed to the next stage. Accordingly, the problem of semantically irrelevant candidates being excessively injected, which can cloud the language model's judgment, can be reduced, and processing delays caused by increased token costs can also be suppressed.

[0064] The step of obtaining a unique identifier (history_id) that identifies the history of the current question is a step of generating or assigning an identifier to track the entire flow of a single current question and its corresponding query generation, execution, error occurrence, and automatic recovery on the same session unit.

[0065] Here, a unique identifier may refer to a key value assigned to identify the processing status, previous query history, and recovery history of a specific current question without confusion, even in an environment of simultaneous requests from multiple users. The unique identifier may be implemented in the form of a string, integer, hash value, UUID, or a combined timestamp value, and may be newly generated within the device or transmitted together from a user terminal or a higher-level application server.

[0066] The step of configuring the above-mentioned past query example into an example set in the past question-past query correspondence format and generating a first prompt including the current question, the example set, and schema information of the target database is a step of assembling input data into a text block of a specific structure or a structured data format so that the language model can accurately understand the context.

[0067] Here, an example set may refer to a data set arranged by grouping past inputs and correct query terms into pairs, such as “Question: What was the production volume of Factory A yesterday? / Query: SELECT amount FROM production WHERE factory = 'A' AND date = 'yesterday'”. The first prompt may include at least one of the current question, the example set, a list of tables in the target database, column information, data types, joinable relationships, and query generation rules. Accordingly, the language model can generate a more accurate query term by simultaneously referring to the intent of the current question, the grammatical structure of past successful cases, and the actual schema structure.

[0068] The step of inputting the first prompt into a language model to derive a current query is a step of transmitting the first prompt, assembled by the device, to a large-scale language model or a query generation specialized model to generate a current query that is executable in an actual target database.

[0069] Here, the current query term may refer to an SQL statement generated to correspond to the query intent of the current question, or a structured query statement suitable for a specific DBMS dialect. For example, if the current question is to query the average defect rate of production line A over the last three months, the language model can derive a query that includes a production line filter, a period condition, monthly grouping, and average aggregation. In this case, the language model can select table names, column names, and join structures existing in the target database by referring to the grammatical structure and schema information of past queries included in the example set.

[0070] The step of mapping the unique identifier and the current query to the query cache and storing them in an up-to-date state is a step of recording the current query generated by the language model in a cache memory or temporary storage so that it can be referenced in subsequent automatic recovery and re-execution steps.

[0071] Here, a query cache may be a logical storage area that stores the current query that has been recently created or modified by a unique identifier. The query cache may be implemented in the form of an in-memory cache, a key-value store, a session table, or a database table, and when storing, the previously obtained unique identifier may be used as the key and the current query may be mapped as the value. Accordingly, when an execution error occurs later, the device can immediately look up the previous execution query corresponding to the current question and configure a recovery prompt that accurately reflects which query the language model generated immediately before.

[0072] The step of accumulating the number of retries by mapping them to the unique identifier in the retry count cache is a step for managing how many times the automatic recovery step has been performed for the same current question.

[0073] Here, the retry count cache may refer to a management storage area that stores at least one of the number of times automatic recovery has been performed, the time of the last recovery, whether recovery was successful, and the final state for each unique identifier. The device may initialize the number of retries to 0 or 1 upon the first execution of the current query, and may increase the number by 1 each time automatic recovery is performed thereafter. Such retry count management can be used to prevent a situation where the automatic recovery loop repeats infinitely and as a basis for determining whether the maximum number of retries has been reached.

[0074] The step of retrieving the immediately preceding executed query retrieved by the unique identifier from the above query cache is a step of restoring from the query cache the query that was last executed or attempted to be executed immediately before performing automatic recovery.

[0075] Here, the immediately preceding query may be the current query that was initially generated or a query that was saved again after being modified during a previous recovery process. Even if multiple modifications have been made to the same current question, the device can always retrieve the latest query corresponding to the unique identifier as the immediately preceding query and reflect it in the second prompt. Accordingly, the language model can perform additional modification operations based on the most recent version of the query rather than the initial version, thereby ensuring the cumulative nature and continuity of recovery.

[0076] The step of generating a second prompt that includes the error message, the immediately preceding query, the number of retries, and the actual schema information of the target database, while omitting the extraction of the aforementioned past query examples, constitutes a step of constructing new instructions specialized for debugging, unlike the initial query generation. At this time, since the intent of the current question and the basic query structure have already been identified, the process of vector similarity search and example extraction via a RAG server can be omitted to save unnecessary computational resources and time. Instead, the second prompt can be generated by placing the error message returned by the database and the failed immediately preceding query side by side, and adding the number of retries and the actual schema information of the target database to enable the language model to automatically find and correct the errors. For example, if the immediately preceding query failed by referencing a non-existent column name, the second prompt may include the corresponding error message and a list of similar columns existing in the actual schema.

[0077] The step of inputting the second prompt into the language model to analyze the error type—specifically whether the error corresponds to at least one of a typo in the table name, an error in a column name not existing in the schema, a syntax error due to heterogeneous database support, and a data type mismatch—is a step for utilizing the reasoning ability of the language model to categorize the cause of failure and select a recovery strategy appropriate thereto.

[0078] Here, a table name typo may refer to a case where a table name that does not actually exist in the database is referenced, and a column name error may refer to a case where a non-existent column name or an incorrect alias is referenced. Syntax errors related to heterogeneous database support may include cases where a function or syntax that works only in MySQL is used when the current target database is Oracle, and data type mismatch may refer to cases such as attempting numeric operations on a string column or improperly comparing a date column with a string literal. The above language model can determine which of these reasons the execution failed by comparing the error message with the actual schema information.

[0079] The step of updating the current query by replacing the components of the immediately preceding query with names corresponding to the actual schema information of the target database, or by substituting them with type conversions or grammatical structures suitable for the target database, according to the analyzed error type, is a step of specifically modifying the problematic query into an actually executable form based on the diagnosed cause. For example, if the language model analyzes the error type as a column name error, the `production_quantity` part of the immediately preceding query can be replaced with `prod_qty`, which exists in the actual schema; if the non-existent table name `prod_line_stat` is used, it can be changed to `production_line_stat`, which exists in the actual schema. Additionally, if a specific DBMS does not support the `LIMIT` clause, it can be converted to `FETCH FIRST` or another syntactic structure suitable for the target database; and if a type mismatch occurs during date comparison, it can be modified to compare by converting the string to a date type or converting the date column to a specified format. As a result of this step, the immediately preceding query can be replaced with an updated current query that is highly executable.

[0080] The step of mapping the unique identifier and the current query to the query cache to update and store them in the latest state involves overwriting the query cache with the current query newly generated by automatic recovery, thereby enabling the most recent version of the query to be referenced in the next re-execution or next automatic recovery. Accordingly, even if an error occurs again after re-execution, the device can perform subsequent recovery based on the most recently recovered query rather than the initially generated query. For example, if an incorrect column name is corrected in the first recovery and syntax is corrected due to DBMS differences in the second recovery, each recovery result can be sequentially stored in the query cache in the latest state. Consequently, by organically combining the extraction of past query examples, prompt configuration, query generation, cache-based history management, and error recovery, the above steps can form a structure in which query generation and recovery for the current question are performed continuously.

[0081] And, the RAG server comprises: a step of converting the current question included in the search request into a multidimensional query vector normalized through an embedding model, and extracting a query feature token from the current question that includes at least one of a target entity, an aggregation intent, a filter condition, a time condition, and a sorting condition; a step of identifying a specific example partition corresponding to a scenario included in the search request in a vector database where question-query examples are stored; a step of searching for a primary candidate group by calculating vector similarity between the past question vectors stored within the specific example partition and the query vector; a step of calculating the degree of alignment between at least one of a table tag, a column tag, an aggregate function tag, a join structure tag, and a time condition tag assigned to the past question-query example corresponding to each of the primary candidate group and the query feature token; and a step of calculating an integrated search score for each candidate by assigning weights to the vector similarity and the degree of alignment, respectively. The method is controlled according to a control method comprising the step of determining the top N query example candidates within the token consumption limit of the language model according to the descending order of the integrated search scores, and the step of searching for the primary candidate group may include: designating an example partition having the same scenario tag as the scenario among a plurality of example partitions stored in the vector database as the primary search space, and if no example partition having the same scenario tag exists, designating an adjacent scenario partition having a similarity on a predefined similar scenario mapping table with the scenario above a preset standard as the secondary search space; performing unit vector normalization on each of the past question vectors included in the primary search space or the secondary search space and then calculating the cosine similarity with the query vector; and selecting only the past question vectors whose cosine similarity is above a preset valid threshold as the primary candidate group.

[0082] The step of converting the current question included in the above search request into a multidimensional query vector normalized through an embedding model, and extracting a query feature token from the current question that includes at least one of a target entity, an aggregation intent, a filter condition, a time condition, and a sorting condition, is a step of simultaneously converting the current question in natural language form into a mathematical expression and a structured query expression that a machine can compute.

[0083] Here, an embedding model refers to an artificial intelligence model that identifies the meaning of words or sentences and converts them into coordinate values ​​in a multidimensional space, specifically into a vector form composed of multiple real values. A normalized multidimensional query vector refers to a state in which the size of the vector generated by the aforementioned embedding model is adjusted according to a certain standard, thereby allowing the comparison of semantic directionality itself rather than the absolute length of the vector during the subsequent similarity calculation process. Accordingly, this can reduce the problem of similarity calculations being distorted due to differences in question length or expression style.

[0084] The step of converting the current question included in the above search request into a multidimensional query vector normalized through an embedding model, and extracting a query feature token from the above question that includes at least one of a query target entity, aggregation intent, filter condition, time condition, and sorting condition, may be a step of not merely generating a semantic vector of the entire sentence, but also extracting key query elements to be used for subsequent matching calculation.

[0085] Here, query feature tokens refer to the core requirements of the current question that must be identified for database querying. For example, if a user inputs "Tell me the top 3 best-selling smartphones last month," the target entity for the query could be smartphones or products, the aggregation intent could be summing sales volume, the time condition could be last month, and the sorting condition could be descending order and the top 3 based on sales volume. Additionally, filter conditions can refer to conditions that limit the scope of the query, such as specific factories, lines, items, status values, or organizations.

[0086] In a vector database where question-query examples are stored, the step of identifying a specific example partition corresponding to a scenario included in the search request is a step for limiting the search target to only the portion of the entire example storage space related to the business context of the current question.

[0087] Here, a vector database may refer to a storage structure capable of similarity-based querying, which stores at least one of a question vector (a vectorized version of past questions), a corresponding query term, a scenario tag, a table tag, a column tag, an aggregate function tag, a join structure tag, and a time condition tag. An example partition may refer to a storage area in which multiple examples of past questions and past query terms stored within the vector database are logically or physically divided by scenario or domain. Accordingly, examples from different business areas, such as production performance, quality analysis, inventory management, personnel information, or shipment status, may be stored separately in different example partitions.

[0088] In a vector database storing question-query examples, the step of identifying a specific example partition corresponding to the scenario included in the search request may be a step intended to simultaneously ensure search efficiency and accuracy by prioritizing the targeting of only the data area corresponding to the domain of the current question, rather than blindly traversing the entire vast history of past queries. For example, the expression “production volume this month” may refer to the production volume aggregation table in a production performance scenario, but may refer to the planned quantity table in a plan management scenario. Therefore, the RAG server can first select a specific example partition corresponding to the domain to which the current question belongs using the scenario identifier included in the search request, and by performing a similarity search only within that partition, reduce the problem of incorrect past query examples being selected due to the mixing of similar vocabulary from other business domains.

[0089] The step of searching for a first set of candidates by calculating the vector similarity between the past question vectors stored within the specific example partition and the query vector is a step of primarily selecting past questions that are semantically close to the current question.

[0090] Here, a past question vector may refer to a multidimensional vector obtained by transforming a past question sentence through an embedding model. Vector similarity may be calculated using at least one of cosine similarity, Euclidean distance-based similarity, or inner product-based similarity, but in this embodiment, comparison may be made based on cosine similarity between normalized vectors. As a result of this step, multiple past question-past query examples that are contextually or structurally similar to the current question may be derived as a primary candidate group.

[0091] The step of searching for the first candidate group may include designating an example partition having the same scenario tag as the scenario among a plurality of example partitions stored in the vector database as the primary search space, and if no example partition having the same scenario tag exists, designating an adjacent scenario partition having a similarity level greater than or equal to a pre-set standard on a pre-defined similar scenario mapping table as the secondary search space.

[0092] Here, the primary search space refers to the search range of example partitions that directly match the scenario of the current question, while the secondary search space refers to the search range of adjacent domains that are additionally referenced to handle cases where the example partition corresponding to the primary search space does not exist or the number of examples is insufficient. For example, if the example partition corresponding to the "New Hire Training Status" scenario is empty, an adjacent scenario partition such as "Performance Appraisal Status" or "Personnel Placement Status" can be designated as the secondary search space by referring to a predefined similar scenario mapping table. Accordingly, situations where a search fails due to the complete absence of appropriate examples can be reduced.

[0093] The step of calculating the cosine similarity with the query vector after performing unit vector normalization on each of the past question vectors included in the above basic search space or auxiliary search space is a step of calculating the semantic agreement between past questions and current questions as a mathematical score.

[0094] Here, unit vector normalization refers to the process of eliminating the influence of differences in vector size on the results of similarity calculations by adjusting the length of each vector to 1. Cosine similarity is a method of calculating the cosine value of the angle formed by two vectors in a multidimensional space; it can be an indicator for measuring contextual similarity by utilizing the characteristic that the value is closer to 1 when the meanings of two sentences are very similar, and the value is closer to 0 when the correlation is low. For example, if the current question is “monthly average defect rate of production line A over the past 3 months” and a past question is “inquiry into the monthly average defect rate of a specific line over the last 3 months,” the cosine similarity between the two vectors may be calculated as a relatively high value.

[0095] The step of selecting only past question vectors whose cosine similarity is above a preset valid threshold as a primary candidate group is a step to exclude irrelevant examples whose similarity scores fall below the threshold from prompt injection targets.

[0096] Here, the valid threshold refers to a standard value representing the minimum semantic similarity between the current question and past questions, and can be adjusted based on administrator settings, model performance, or the average similarity distribution. For example, if the valid threshold is set to a cosine similarity of 0.7, candidates falling below 0.7 may be considered semantically irrelevant data and excluded from the initial candidate pool, even if their similarity ranking is relatively high. Accordingly, this reduces the problem of past examples irrelevant to the current question being included in the top candidates simply because they share some words.

[0097] The step of calculating the degree of alignment between at least one of the table tag, column tag, aggregate function tag, join structure tag, and time condition tag assigned to the past question-past query example corresponding to each of the above first candidate groups and the above query feature token is a step for quantifying structural compatibility that is difficult to distinguish by vector similarity alone.

[0098] Here, a table tag may refer to table information referenced by the relevant past query, and a column tag may refer to the column name or column type used. Aggregate function tags may indicate operation methods such as `SUM`, `AVG`, and `COUNT`, join structure tags may indicate which tables are combined through which key, and time condition tags may be information indicating daily, weekly, monthly, quarterly, or specific period ranges. The RAG server compares the query feature tokens extracted from the current question with the tags attached to each candidate; for example, if the current question includes an intent to aggregate averages, it may assign a higher degree of match to a candidate with the `AVG` tag, and if it includes monthly conditions, it may assign a higher score to a candidate with the monthly time condition tag.

[0099] The step of calculating the degree of consistency between at least one of the table tag, column tag, aggregate function tag, join structure tag, and time condition tag assigned to the past question-past query example corresponding to each of the above primary candidate groups and the above query feature token may go beyond merely finding semantically similar sentences and involve cross-verifying how well the actual database query structure matches the requirements of the current question. For example, if the current question is to query the monthly average defect rate by production line, the vector similarity may be high, but an example querying the total production volume may yield a low degree of consistency because the aggregate function tag and the target entity differ. On the other hand, an example where the used table structure, time condition, and aggregation method are all similar may have a high degree of consistency. Through such calculation of the degree of consistency, the above RAG server can reflect both simple contextual similarity and technical structural similarity.

[0100] The step of calculating an integrated search score for each candidate by assigning weights to the vector similarity and the matching degree, respectively, is a step for determining the final priority by integrating semantic similarity and structural suitability into a single numerical value.

[0101] Here, weighting refers to a ratio indicating which element—vector similarity or consistency—is given more importance, and it can be adjusted based on the scenario type, query complexity, or administrator settings. For example, in a simple statistical query, 60 percent of the weight can be given to the vector similarity score and 40 percent to the consistency score, whereas in a complex join query, the weight of the consistency score can be set relatively higher. Accordingly, candidates that are most helpful for generating the actual query can be selected by excluding candidates that are similar in meaning but different in structure, or candidates that are structurally correct but far removed from the intent of the current question.

[0102] The step of determining the top N query example candidates within the token consumption limit of the language model according to the descending order of the above integrated search scores is a step of determining the core examples to be finally provided to the language model among the primary candidate group.

[0103] Here, descending order may mean sorting examples from highest to lowest integrated search scores. Additionally, the token consumption limit may refer to the maximum input length or cost limit that the language model can process at once. Therefore, the RAG server prioritizes selecting examples with high integrated search scores; however, if the total length of the selected examples exceeds the language model's token consumption limit, it may exclude some examples or adjust them into a summarized format to ultimately determine the top N candidate query examples. Consequently, these steps can serve to improve the accuracy and feasibility of the subsequent current query generation step by selecting examples that are suitable for both the meaning and structure of the current question and injecting them into the language model.

[0104] In addition, the step of calculating the degree of consistency comprises: a step of subdividing the query feature tokens into schema tokens that map directly to the structure of the target database and function tokens that instruct operation processing; a step of reclassifying the schema tokens into table name designation tokens and column name designation tokens, and reclassifying the function tokens into aggregation intent tokens, time condition tokens, join request tokens, and sorting request tokens; a step of calculating a first weighted score by comparing the number of exact matches, the number of partial matches, and the hierarchical association based on the table-column inclusion relationship between the table tag and column tag, which are pre-parsed and attached to the past question-past query example of each of the first candidate group, and the table name designation tokens and column name designation tokens; and a step of calculating a second weighted score of a different scale from the first weighted score by comparing whether there is a logical match between at least one of the aggregation function tag, join structure tag, time condition tag, and sorting tag of each of the first candidate group and the corresponding function token among the aggregation intent token, join request token, time condition token, and sorting request token. The method may include: a step of deducting a preset penalty score for a past question-past query example that includes redundant table tags, unnecessary join structure tags, unnecessary time condition tags, or unnecessary aggregate function tags that do not explicitly correspond to the query feature token of the current question; and a step of combining the first weighted score and the second weighted score and deriving the degree of alignment for each candidate by reflecting the penalty score.

[0105] The step of calculating the degree of consistency above is a step for quantitatively evaluating whether the past question-past query word examples included in the first candidate group are suitable not only in terms of semantic similarity to the current question but also in terms of the actual query structure.

[0106] Here, consistency refers to a numerical value representing the degree of match between query features extracted from the current question and the structural tags attached to each candidate example. This consistency value goes beyond simply selecting candidates with high vector similarity; by also reflecting which tables and columns are referenced, which aggregate functions and time conditions are used, and whether the current question contains unnecessary tags, it can serve as a criterion to improve the quality of examples provided to subsequent language models.

[0107] The step of subdividing the above query feature tokens into schema tokens that map directly to the structure of the target database and function tokens that direct operation processing is a step for identifying the core information included in the current question by dividing it into database structure correspondence elements and query processing intent elements.

[0108] Here, a schema token may refer to a noun-like expression that directly corresponds to the physical location where the data is actually stored or the target of the query, and a function token may refer to an operational or conditional expression that indicates how the queried data should be processed, restricted, and arranged. For example, if the current question is “Show me the monthly average defect rate of production line A over the last 3 months,” “production line,” “defect rate,” and “month” can be classified as schema tokens that are likely to map directly to the schema of the target database, and “average,” “last 3 months,” and “sort by month” can be classified as function tokens.

[0109] The step of reclassifying the above schema tokens into table name specification tokens and column name specification tokens, and reclassifying the above function tokens into aggregation intent tokens, time condition tokens, join request tokens, and sorting request tokens, is a step of further subdividing the previously broadly classified tokens so that they directly correspond to the actual SQL syntax structure.

[0110] Here, a table name token may refer to an expression designating a specific table or domain object, and a column name token may refer to an expression directly corresponding to an actual column, such as a numeric value, status value, identifier value, or date value. Additionally, an aggregation intent token may refer to an operation purpose such as sum, average, count, maximum value, or minimum value, and a time condition token may refer to period information such as daily, monthly, quarterly, the last three months, last year, or yesterday. A join request token may be information indicating whether there is a need to query by combining two or more tables, and a sort request token may refer to the result arrangement method, such as ascending, descending, top 5, or chronological sorting. For example, if the question “Show the total production volume by product for the Busan and Seoul factories in the first quarter of 2025 in descending order” is entered, “factory,” “product,” and “production volume” are classified as schema tokens and can be specified as table name tokens or column name tokens, and “total,” “first quarter of 2025,” “Busan and Seoul factories,” and “descending order” can be reclassified as aggregation intent tokens, time condition tokens, join request tokens, and sort request tokens, respectively.

[0111] The step of calculating a first weighted score by comparing the number of exact matches, the number of partial matches, and the hierarchical association based on the table-column inclusion relationship between the table tag and column tag attached by pre-parsing for each of the above-mentioned first candidate group's past question-past question query examples is a step of evaluating the degree of agreement between the current question and the candidate examples from the perspective of schema structure.

[0112] Here, pre-parsed and attached tags refer to information attached in the form of metadata, which has been pre-analyzed regarding which tables and columns were used by past question-query examples stored in the vector database. The exact match count refers to the number of cases where a table name token or column name token extracted from the current question corresponds identically or equally to the tag of a candidate example. The partial match count refers to the number of cases where, even if not exactly identical, they belong to the same domain or similar attribute group, and hierarchical association may be an association indicator assigned by considering the relationship where a specific column is included in a specific table or the relationship where specific tables are linked through foreign keys.

[0113] The step of calculating a first weighted score by comparing the number of exact matches, the number of partial matches, and the hierarchical association based on the table-column inclusion relationship between the table tag and column tag attached via pre-parsed for each of the above-mentioned first candidate group's past question-past query keyword examples, and the table name designation token and column name designation token, may be a step that considers not only whether simple names match but also the actual schema structure and hierarchical relationships. For example, if the current question includes "production line" and "defect rate," and the tags of the candidate examples consist of `line_info`, `defect_stat`, `line_name`, and `defect_rate`, then even if the names themselves differ slightly, if "production line" corresponds semantically to `line_info` and "defect rate" corresponds to `defect_rate`, and `defect_rate` is included in the `defect_stat` table, then partial matches and hierarchical associations may be recognized. Accordingly, it is possible to calculate a score that more realistically reflects the actual database structure compared to a method that mechanically searches only for identical expressions.

[0114] The step of comparing whether there is a logical match between at least one of the aggregation function tag, join structure tag, time condition tag, and sorting tag of each of the above-mentioned first candidate group and the corresponding function token among the aggregation intent token, join request token, time condition token, and sorting request token, and calculating a second weighted score of a different scale from the first weighted score is a step of evaluating how appropriately the past example reflects the operation purpose and processing structure required by the current question.

[0115] Here, the aggregate function tag may refer to aggregate operation information used in past query terms, such as `SUM`, `AVG`, `COUNT`, `MAX`, and `MIN`, and the join structure tag may refer to a tag indicating which tables are combined using which key. The time condition tag may refer to period information such as monthly, the last three months, yearly, the previous day, or the previous month, and the sort tag may refer to information indicating whether the results are sorted in ascending or descending order, or whether top rankings are extracted. The fact that the second weighted score has a different scale from the first weighted score may mean that schema consistency and functional consistency are evaluated using different scoring systems, thereby reflecting the two types of information independently. For example, if it is determined that an error referencing the wrong table in a database query is more critical than a sorting direction error, the scoring structure may be altered by setting the maximum score of the first weighted score to 70 points and the maximum score of the second weighted score to 30 points.

[0116] The step of calculating a second weighted score of a different scale from the first weighted score by comparing whether there is a logical match between at least one of the aggregate function tag, join structure tag, time condition tag, and sorting tag of each of the first candidate group and the corresponding function token among the aggregate intent token, join request token, time condition token, and sorting request token, may be a step of filtering out candidates that have similar meanings but different actual operation intentions. For example, if the current question is to query the monthly average defect rate, and a candidate example has a structure that calculates the sum of production volumes, the second weighted score may be calculated low even if the vector similarity is high, because the aggregate intent and time condition do not match. Conversely, if the current question requests the average value of the last three months and a monthly array, and the candidate example includes the same aggregate function, time condition, and sorting condition, the second weighted score may be calculated high. In this way, the second weighted score can be used as an indicator reflecting the consistency between the functional requirements of the current question and the actual SQL processing method of the candidate example.

[0117] The step of deducting a pre-set penalty score for past question-past query example containing redundant table tags, unnecessary join structure tags, unnecessary time condition tags, or unnecessary aggregate function tags that do not explicitly correspond to the query feature token of the current question is a step to deduct points from past examples containing complex operations that the user did not ask for, thereby pushing candidates with a high probability of hallucination to a lower priority.

[0118] Here, the redundant table tag may refer to additional tables unrelated to the query target or conditions of the current question, and the unnecessary join structure tag may refer to join relationships that are not essential to satisfying the requirements of the current question. The unnecessary time condition tag may refer to cases where a time range not required by the current question is arbitrarily added, and the unnecessary aggregate function tag may refer to cases where an inappropriate aggregate function is included despite the current question having no intention of aggregation or requiring a different aggregation intent. For example, if a candidate example additionally joins the product master table or includes quarterly conditions even though the current question only requires the monthly average defect rate of a specific line, a pre-set penalty score may be deducted from that candidate. Through such negative filtering, excessive join structures or unnecessary data references that are difficult to detect with simple similarity-based searches can be suppressed.

[0119] The step of deriving the degree of alignment for each candidate by combining the first and second weighted scores and reflecting penalty scores is a step of calculating a final fit score that reflects deductions for unnecessary structures while considering both schema alignment and functional alignment.

[0120] Here, the combination of the first weighted score and the second weighted score can be performed using simple summation, weighted summation, summation after normalization, or non-linear combination methods. The penalty score can be directly deducted from the combination result, or it can be reflected by immediately excluding a candidate if it falls below a specific threshold. For example, Candidate A may have a medium level of vector similarity but possess a high degree of match because its table tag, column tag, aggregate function tag, and time condition tag closely match the current query, while Candidate B may have a high level of vector similarity but possess a low degree of match due to the inclusion of unnecessary joins and redundant tables. In this case, if vector similarity and the degree of match are considered together in the subsequent integrated search score calculation step, Candidate A may be determined to be a more suitable example in reality. Consequently, the degree of match calculation step can serve to reduce incorrect joins, incorrect aggregations, and unnecessary data references that may occur from example selection based on simple sentence similarity, and ultimately improve the accuracy and feasibility of the current query generation step.

[0121] Additionally, the step of identifying the specific example partition comprises: a step of normalizing a string of a scenario included in the search request into a standard scenario identifier by performing at least one of synonym substitution, abbreviation expansion, delimiter unification, and typographical correction by referring to a pre-built scenario normalization dictionary; a step of decomposing the standard scenario identifier into a first upper business domain code and a first lower query object code; a step of generating a scenario key for partition routing by recombining the first upper business domain code and the first lower query object code according to a pre-established combination rule; a step of generating a partition routing key by applying a hash function to the scenario key for partition routing; a step of querying a partition index mapped to the partition routing key in a partition routing table associated with the vector database; and a step of obtaining metadata of an example partition corresponding to the partition index and verifying whether the second standard scenario identifier, the second upper business domain code, and the second lower query object code included in the metadata match the standard scenario identifier, the first upper business domain code, and the first lower query object code, respectively. If the result of the match verification is valid, the step of confirming the example partition as the specific example partition; if the result of the match verification is invalid, the step of re-querying an alternative partition index in the partition routing table corresponding to an adjacent third subquery object code, where the first upper business domain code is identical and the similarity with the first subquery object code is greater than or equal to a preset standard; and the step of obtaining metadata of an alternative example partition corresponding to the alternative partition index to verify whether the third upper business domain code of the alternative example partition matches the first upper business domain code and whether the third subquery object code of the alternative example partition corresponds to the first subquery object code with a similarity greater than or equal to a preset standard.The method may include: a step of confirming the alternative example partition as the specific example partition if the similarity verification result for the alternative example partition is valid; a step of querying the basic partition index of the basic example partition, which stores integrated past question-past query term examples corresponding to the first upper business domain code and a plurality of lower-level query target codes, if the similarity verification result for the alternative example partition is invalid; a step of obtaining metadata of the basic example partition corresponding to the basic partition index and verifying whether the fourth upper business domain code of the basic example partition matches the first upper business domain code; a step of confirming the basic example partition as the specific example partition if the verification result for the basic example partition is valid; and a step of generating partition identification failure information if the verification result for the basic example partition is also invalid.

[0122] The step of identifying the specific example partition mentioned above is a step for determining the search space most suitable for the current question among multiple example partitions within the vector database based on the scenario included in the search request.

[0123] Here, a specific example partition may refer to a logical or physical partitioned area where past question-query keyword examples that most directly correspond to the business domain and purpose of the current question are stored. The above step may be intended to reduce search latency and mitigate the problem of mixing similar vocabulary from other domains by first restricting the search space through a scenario-based routing procedure and then performing a similarity search within that space, rather than indiscriminately searching the entire single integrated vector space.

[0124] Here, a partition refers to a logical or physical storage unit for managing the entire data within a vector database or example repository by dividing it according to certain criteria. The partition may have independent indexes, metadata areas, access paths, or search ranges, and may be configured to selectively search only specific partitions instead of searching the entire data set in bulk. For example, the partitions may be created by distinguishing business domains, query purposes, database types, SQL dialects, organizational units, or service tenants, and each partition may manage a separate vector index file, partition identifier, creation time, last update time, number of stored examples, active status, and priority information. Accordingly, the device can reduce search latency by narrowing the search target range in advance and mitigate the problem of distorted similarity calculation results caused by the mixing of examples from different domains.

[0125] Additionally, an example partition may refer to a dedicated partition among the above partitions where past question-query examples are grouped and stored according to specific criteria. The example partition may store at least one of the following: the original past question text, the past query, the question embedding vector, the scenario tag, the table tag, the column tag, the aggregate function tag, the join structure tag, the time condition tag, the execution success status, the verification status, the creation or update time, and the target DBMS information. For example, a first example partition storing only examples related to monthly defect rate inquiries in the quality analysis domain, a second example partition storing only daily production volume aggregation examples in the production performance domain, and a basic example partition storing multiple sub-objective examples within the same parent domain may each be separately configured. Accordingly, the device can select only the example partition corresponding to the scenario of the current question to calculate the similarity between the past question vectors and the query vectors within it, and can efficiently select only the examples that are actually helpful for generating subsequent queries.

[0126] The step of normalizing a string of a scenario included in the above search request into a standard scenario identifier by performing at least one of synonym substitution, abbreviation expansion, separator unification, and typographical correction by referring to a pre-built scenario normalization dictionary is a step for converting a scenario string received from a user terminal or upper system into a standardized format by removing irregularities.

[0127] Here, a scenario normalization dictionary refers to a dictionary in the form of a database table, file, or rule set that is pre-mapped to convert synonyms, abbreviations, mixed notations, delimiter variations, and frequently occurring typos used in various business domains where database queries occur into standardized names. For example, even if different expressions such as “production performance,” “production results,” “production volume,” and “production status” are entered, the normalization step can unify them all into a single standard scenario identifier such as “production_performance.” Through such normalization processing, the problem of incorrect partition selection caused by differences in the notation of scenario strings can be reduced.

[0128] The step of decomposing the above standard scenario identifier into a first upper business domain code and a first lower query object code is a step for interpreting the normalized scenario into a hierarchical business structure.

[0129] Here, the first upper-level business domain code may be a code representing a major business area of ​​a company or system, such as production, quality, inventory, human resources, shipping, or facility operation. The first lower-level query objective code may be a code representing a more specific purpose of data utilization within the aforementioned upper-level business domain, such as performance inquiry, planning, defect analysis, ranking aggregation, trend analysis, or cause analysis. For example, if the standard scenario identifier is “Production_Performance,” the first upper-level business domain code may correspond to production, and the first lower-level query objective code may correspond to performance. By decomposing into a logical hierarchical structure of upper and lower levels in this way, queries with different specific purposes can be managed separately even within the same upper-level domain.

[0130] The step of generating a scenario key for partition routing by recombining the above-mentioned first upper business domain code and first lower query object code according to a pre-established combination rule is a step for generating a reference key to be used in a subsequent routing table lookup.

[0131] Here, a partition routing scenario key refers to a key value generated by combining a parent business domain code and a child query target code according to a defined order and separation rules. The aforementioned combination rules may be, for example, in the format “parent_code_child_code”, “parent_code-child_code”, or as a string containing a specific separator. For instance, if the parent code is “PROD” and the child code is “PERF”, the partition routing scenario key may be generated in the form of “PROD#PERF”. Accordingly, the same routing key can always be generated for the same scenario and can be used as a consistent standard during subsequent partition lookups.

[0132] The step of generating a partition routing key by applying a hash function to the above-mentioned partition routing scenario key is a step to improve lookup efficiency by converting the scenario key, which is in the form of a variable-length string, into a fixed-length numeric or string value.

[0133] Here, a hash function refers to a mathematical algorithm that takes arbitrary data as input and converts it into a hash value of a fixed length. The partition routing key can be used as an identifier to improve the indexing efficiency of the partition routing table and enable the rapid retrieval of a large number of scenario keys. In other words, querying using a hashed partition routing key, rather than directly comparing the aforementioned partition routing scenario keys, can improve search speed while reducing the consumption of computing resources.

[0134] The step of querying the partition index mapped to the partition routing key in the partition routing table associated with the vector database is a step for obtaining location information of the actual example partition corresponding to the routing key.

[0135] Here, the partition routing table may be a management table that maps a partition routing key to at least one of a partition index, a partition metadata identifier, a partition active status, a partition creation time, and a last update time within a vector database where actual data is stored. The partition index may refer to an index number or reference identifier that identifies a specific example partition within the vector database. By referring to the partition routing table, the device can quickly determine which partition among numerous examples needs to be accessed.

[0136] The step of obtaining metadata of an example partition corresponding to the above partition index and verifying whether the second standard scenario identifier, the second upper business domain code, and the second lower query object code included in the metadata match the standard scenario identifier, the first upper business domain code, and the first lower query object code, respectively, is a step for double-checking whether the result of querying the partition routing table actually matches the scenario of the current question.

[0137] Here, metadata for an example partition may refer to supplementary information indicating which standard scenario identifier the partition corresponds to, what the parent business domain and sub-query objectives are, the number of examples stored in the partition, and whether the partition status is active. Such metadata verification may be a procedure to prevent hash collisions, where different strings coincidentally have the same hash value, or inconsistencies caused by delays in routing table updates. Match verification can be performed by comparing the exact match of the standard scenario identifier, the identity of the parent business domain code, and the identity of the sub-query objective code, respectively.

[0138] If the match verification result is valid, the step of confirming the above example partition as the above specific example partition is a step of finally approving it as the search target space for a subsequent vector similarity search when the retrieved partition is determined to be suitable for the scenario of the current question.

[0139] The specific example partition determined here can become the target space where similarity calculations between the past question vector and the query vector are actually performed in subsequent steps. In this way, when the standard scenario identifier, the upper business domain code, and the lower query target code all match, the most direct corresponding partition is selected, thereby simultaneously improving search efficiency and precision.

[0140] If the match verification result is invalid, the step of re-querying an alternative partition index in the partition routing table corresponding to an adjacent third sub-query object code that is identical to the first upper business domain code and has a similarity to the first sub-query object code greater than or equal to a preset standard is the first bypass search step to continue the search even if there is no exactly matching partition or the metadata is misaligned.

[0141] Here, the adjacent third sub-query objective code refers to a code that represents a functionally similar detailed objective within the same parent business domain, even if it is not exactly identical to the first sub-query objective code. For example, if the “Production_Performance” partition is not found, the parent domain “Production” is maintained, but an alternative path can be explored to find a partition corresponding to a sub-objection code similar to “Performance,” such as “Plan” or “Aggregation.” The aforementioned similarity criteria can be calculated based on administrator settings or training data, and alternative partition indices corresponding to sub-objection codes that meet or exceed this criterion can be re-queried.

[0142] The step of obtaining metadata of an alternative example partition corresponding to the above alternative partition index and verifying whether the third parent business domain code of the alternative example partition matches the first parent business domain code and whether the third sub-query object code of the alternative example partition corresponds to the first sub-query object code by a similarity threshold greater than or equal to a preset threshold is a step for confirming whether the alternative partition has sufficiently similar sub-objectives within at least the same parent domain. The third parent business domain code may refer to the parent region to which the alternative example partition belongs, and the third sub-query object code may refer to the detailed query object of the alternative example partition. Through this verification, it is possible to prevent the incorrect selection of partitions of different parent domains while enabling somewhat flexible object code matching within the same parent domain.

[0143] If the similarity verification result for the aforementioned alternative example partition is valid, the step of confirming the alternative example partition as the specific example partition involves using a functionally similar partition as the target space for subsequent searches instead of an exact match partition. In this case, even if there are no examples corresponding to the exact same query objective as the current question, examples that are sufficiently semantically close within the same higher-level business domain can be utilized for the search. Accordingly, it becomes possible to generate subsequent queries without search failures, even for new or sparse scenarios where the accumulated amount of examples is insufficient.

[0144] If the similarity verification result for the above-mentioned alternative example partition is invalid, the step of querying the base partition index of the base example partition, which corresponds to the above-mentioned first-level business domain code and stores integrated past question-past query term examples for multiple sub-query target codes, is a step for querying the representative partition at the top-level business domain as a final supplementary path when both the exact match partition and the adjacent scenario partition are inappropriate.

[0145] Here, the basic example partition refers to a broad partition in which representative or common past question-query term examples for multiple sub-query object codes belonging to a specific top-level business domain are stored in an integrated manner. For example, if a basic example partition representing the entire quality analysis domain exists, it can be used as an alternative search space even if partitions for specific object codes—such as monthly defect rates, quality comparisons by period, and outlier detection—are all absent or unsuitable.

[0146] The step of obtaining metadata of a basic example partition corresponding to the above basic partition index and verifying whether the fourth parent business domain code of the basic example partition matches the first parent business domain code is a step for confirming whether the last found basic example partition belongs to at least the same parent domain as the current question.

[0147] Here, the fourth parent business domain code may be a code indicating the domain affiliation of the base example partition. This verification prevents examples from completely unrelated fields from being selected as the base example partition by applying the constraint that the parent business domain itself must be identical to the current question, even if the base example partition is somewhat generalized at the subquery purpose level.

[0148] If the validation result for the above-mentioned basic example partition is valid, the step of confirming the basic example partition as the above-mentioned specific example partition is a step of selecting a representative partition belonging to the same parent domain as the current question as the final search space. Accordingly, even if there is no example partition that matches down to the detailed objective code, similarity search can continue to be performed based on a common group of examples within the same domain. This structure can guarantee minimum search stability even for early systems with insufficient data accumulation or for query purposes that are rarely used.

[0149] If the verification result for the above basic example partition is also invalid, the step of generating partition identification failure information is a step for explicitly recording the state in which a referenceable example space was not secured even after going through all multiple fallback structures for identifying the above specific example partition.

[0150] Here, partition identification failure information refers to management information including at least one of a scenario string corresponding to the current question, a standard scenario identifier, a first parent business domain code, a first sub-query object code, a time of failure, a routing key, and a failure cause code. The partition identification failure information can be utilized in administrator logs, monitoring systems, example partition enrichment operations, scenario normalization pre-update operations, or processing the transition to a general generation mode without RAG. Consequently, the step of identifying the specific example partition can reliably determine the search target space most suitable for the current question through a multi-step procedure of standard scenario identifier normalization, routing key generation, partition lookup, metadata validation, alternative partition search, primary partition search, and failure information generation.

[0151] An apparatus according to one embodiment includes a processor and memory. The processor may include at least one apparatus described above through the drawings or perform at least one method described above through the drawings. The memory may store information related to the method described above or store a program in which the method described above is implemented. The memory may be volatile memory or non-volatile memory.

[0152] The processor can execute a program and control the device. The code of the program executed by the processor can be stored in memory. The device can be connected to an external device (e.g., a personal computer or a network) through an input / output device (not shown in the drawing) and exchange data.

[0153] The embodiments described above may be implemented as hardware components, software components, and / or combinations of hardware and software components. For example, the devices, methods, and components described in the embodiments may be implemented using one or more general-purpose or special-purpose computers, such as, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing unit may execute an operating system (OS) and one or more software applications executed on said operating system. Additionally, the processing unit may access, store, manipulate, process, and generate data in response to the execution of the software. For ease of understanding, the processing unit may be described as being used as a single unit, but those skilled in the art will understand that the processing unit may include multiple processing elements and / or multiple types of processing elements. For example, the processing unit may include multiple processors or one processor and one controller. Additionally, other processing configurations, such as parallel processors, are also possible.

[0154] The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., either alone or in combination. The program instructions recorded on the medium may be those specifically designed and configured for the embodiment, or they may be those known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical recording media such as CD-ROMs and DVDs; magneto-optical media such as floptical disks; and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, and flash memory. Examples of program instructions include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. The hardware devices described above may be configured to operate as one or more software modules to perform the operation of the embodiment, and vice versa.

[0155] Software may include computer programs, code, instructions, or a combination of one or more of these, and may configure a processing unit to operate as desired or command the processing unit independently or collectively. Software and / or data may be permanently or temporarily embodied in any type of machine, component, physical device, virtual equipment, computer storage medium, or device so as to be interpreted by the processing unit or to provide instructions or data to the processing unit. Software may be distributed over networked computer systems and may be stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

[0156] Although the embodiments have been described above with reference to the limited drawings, those skilled in the art can apply various technical modifications and variations based on the above. For example, suitable results may be achieved even if the described techniques are performed in a different order than described, and / or if the components of the described system, structure, device, circuit, etc. are combined or assembled in a form different from described, or replaced or substituted by other components or equivalents.

[0157] Therefore, other implementations, other embodiments, and equivalents to the claims also fall within the scope of the claims set forth below. Explanation of the symbols

[0158] S100: The current step of receiving questions S200: Step to extract past query examples S210: A step of sending a search request to a RAG server capable of vector similarity-based search. S220: Step of receiving query example candidates S230: Step of selecting the top N candidate query examples and determining them as past query examples. S300: The stage where the current query is generated S310: Step to obtain a unique identifier S320: Step to generate the first prompt S330: The stage of deriving the current query S340: A step to map a unique identifier and the current query to the query cache and save it in the latest state. S400: The stage where the current query is executed S500: Automatic recovery steps S510: Step for accumulating the number of retries S520: Step to retrieve the previous execution query S530: Step to generate the second prompt S540: Step to analyze error types S550: The stage of updating the current query S560: A step of mapping a unique identifier and the current query to the query cache to update and save it to the latest state. S600: Repetitive execution step

Claims

Claim 1 An intelligent natural language-to-text query (Text2SQL) conversion method based on search augmentation generation and automatic error recovery, wherein the device includes a processor, memory, a communication module, and a non-transient storage medium, and the processor executes a program stored in the non-transient storage medium. The method comprises: receiving a natural language-based current question from a user terminal; classifying a scenario corresponding to the current question and performing a similarity search using a search augmentation generation (RAG) method based on the current question and the scenario to extract one or more past query (SQL) examples; constructing a first prompt by combining schema information of a target database, the past query examples, and the current question, and inputting the first prompt into a language model (LLM) to generate the current query; executing the current query in the target database; and, if an error occurs during the execution of the current query, constructing a second prompt including a message regarding the error, the current query, and information on the number of retries, and inputting it into the language model to analyze the error and correct the current query (Fallback). and, if an error occurs again during re-execution, the method includes the step of re-executing the current query in the target database, repeating the automatic recovery step and the re-execution process until the number of retries exceeds a preset maximum number of retries, and returning an error termination message when the maximum number of retries is exceeded; and the step of extracting the past query example comprises: the step of transmitting a search request including the current question and scenario to a RAG server capable of vector similarity-based search; and the step of receiving a plurality of query example candidates from the RAG server as a response to the search request.To limit token consumption of the language model, the method includes the step of selecting the top N query example candidates with a high similarity ranking to the current question and scenario among a plurality of query example candidates and determining them as past query example candidates; and the step of generating the current query includes: the step of obtaining a unique identifier (history_id) that identifies the history of the current question; the step of configuring the past query example into an example set in the past question-past query example correspondence format and generating a first prompt including the current question, the example set, and schema information of the target database; the step of inputting the first prompt into the language model to derive the current query; and the step of mapping the unique identifier and the current query to a query cache to save it in an up-to-date state; and the automatic recovery step includes: the step of accumulating the number of retries by mapping the unique identifier to a retry count cache; and the step of retrieving the immediately preceding executed query retrieved by the unique identifier from the query cache. A step of omitting the extraction of the above-mentioned past query example and generating a second prompt including a message regarding the error, the immediately preceding query, the number of retries, and actual schema information of the target database; a step of inputting the second prompt into a language model to analyze the error type to determine whether the error corresponds to at least one of a typo in the table name, an error in a column name not existing in the schema, a syntax error due to heterogeneous database support, and a data type mismatch; a step of updating the current query by replacing the components of the immediately preceding query with names corresponding to the actual schema information of the target database, or by substituting them with type conversions or grammatical structures suitable for the target database, according to the analyzed error type; and a step of mapping the unique identifier and the current query to a query cache to update and store them in the latest state.The method comprises: a step of converting the current question included in the search request into a multidimensional query vector normalized through an embedding model, and extracting a query feature token from the current question that includes at least one of a target entity, an aggregation intent, a filter condition, a time condition, and a sorting condition; a step of identifying a specific example partition corresponding to a scenario included in the search request in a vector database where question-query examples are stored; a step of searching for a primary candidate group by calculating vector similarity between the past question vectors stored within the specific example partition and the query vector; a step of calculating the degree of alignment between at least one of a table tag, a column tag, an aggregate function tag, a join structure tag, and a time condition tag assigned to the past question-query example corresponding to each primary candidate group and the query feature token; and a step of calculating an integrated search score for each candidate by assigning weights to the vector similarity and the degree of alignment, respectively. Controlled according to a control method comprising: determining the top N query example candidates within the token consumption limit of the language model according to the descending order of the integrated search scores; and the step of searching for the primary candidate group comprises: designating an example partition having the same scenario tag as the scenario among a plurality of example partitions stored in the vector database as the primary search space, and if no example partition having the same scenario tag exists, designating an adjacent scenario partition having a similarity on a predefined similar scenario mapping table with the scenario above a preset threshold as the secondary search space; performing unit vector normalization on each of the past question vectors included in the primary search space or the secondary search space and then calculating the cosine similarity with the query vector; and selecting only the past question vectors whose cosine similarity is above a preset valid threshold as the primary candidate group.An intelligent natural language-to-query (Text2SQL) conversion method based on search augmentation generation and automatic error recovery, including Claim 2 delete Claim 3 delete

Images