Double-layer cost risk control method for external large language model SQL diagnosis

Abstract

The application provides a double-layer cost risk control method for external large language model SQL diagnosis. Through the double-layer cost risk control architecture, most diagnosis suggestions can complete risk judgment in the code space without crossing the privacy boundary. Only a few suggestions that are judged to have high execution cost risk are translated back to the real space for accurate cost evaluation, thereby simultaneously meeting the requirements of privacy protection and execution cost risk control at the architecture level. In the scenario of using external large language models for SQL diagnosis, the execution cost risk of the suggestions is pre-controlled without sending all diagnosis suggestions to the real space for accurate cost evaluation.

Description

Technical Field

[0001] This invention relates to the field of database operation and maintenance and large language model collaboration technology, and in particular to a two-layer cost risk control method for external large language model SQL diagnosis, as well as a two-layer cost risk control system, electronic device and computer-readable storage medium for external large language model SQL diagnosis. Background Technology

[0002] With the increasing capabilities of large language models in natural language understanding and code generation, the database operations and maintenance field has begun to see practices of using external large language models for SQL diagnostics. In these scenarios, operations and maintenance personnel submit the SQL statement to be diagnosed and its execution context to the external large language model, which then provides query optimization suggestions or rewrite solutions. The operations and maintenance personnel or automated processes then decide whether to adopt these suggestions. This approach can lower the diagnostic threshold and accelerate problem localization, and has already seen initial applications in tasks such as slow query management, index recommendation, and execution plan analysis.

[0003] However, the above process faces an inherent contradiction.

[0004] On the one hand, for external large language models to provide targeted diagnostic suggestions, database schema information needs to be provided to the model, including table names, column names, index structure, data distribution characteristics, and other contextual information. This information is business-sensitive, and directly exposing it to the external model poses a data leakage risk. To address this issue, academia and industry have proposed several anonymization solutions. For example, MaskSQL replaces real database objects with meaningless symbols, hiding sensitive identifiers while preserving the SQL structure. This allows the external model to complete the diagnosis within the symbol space, and then the local system translates the symbolic suggestions back into executable real SQL. Such solutions effectively alleviate privacy protection issues on the input side.

[0005] On the other hand, diagnostic suggestions returned by external large language models may themselves introduce execution cost risks. The rewrite scheme provided by the model may be grammatically valid, but its actual execution cost may far exceed expectations, such as introducing a full table scan, generating a Cartesian product, or triggering unnecessary sorting operations. If the suggestions are translated back and executed without careful consideration, it can waste computational resources at best, and at worst affect the availability of the online database. For the prediction and control of execution costs, the database field already has query cost prediction models based on machine learning, such as Bao and Neo. These models can provide cost estimates before query execution by learning the relationship between the execution plans and actual running costs of historical queries. However, these models are internal optimization components of the database; their training and inference rely on real schema information, do not involve privacy constraints across trust boundaries, and are not designed for collaborative scenarios with external large language models.

[0006] The two approaches described above each only address a portion of the problem. The anonymization approach addresses the requirement of "not leaking the real schema," but assumes that suggestions returned by the external model can be directly back-translated and executed, without any prior assessment of the execution cost. The cost-based approach addresses the need for execution cost evaluation, but its training and inference both rely on real schema information, making it impossible to operate in the anonymized code space. When attempting to simply combine the two, a fundamental circular contradiction arises: cost assessment of diagnostic suggestions requires real schema information; however, real schema information is precisely what privacy protection requires to be hidden. If every code-based suggestion is back-translated into the real space for cost assessment, then all suggestions, without exception, must enter the real space for processing. The privacy boundary established by the anonymization mechanism is completely breached during the back-translation stage, thus negating the protective significance of anonymization itself. In scenarios requiring multiple rounds of diagnostic iteration, the above combined approach also faces additional structural flaws. When the cost assessment determines that a suggestion is unacceptable and requires the external model to regenerate, the system needs to feed the assessment results back to the model to guide the next round of generation. However, the cost model's assessment results are generated in the real space, containing information such as real table names and real execution plan nodes, which cannot be securely transmitted back to the external model. If transmitted directly, the real schema is leaked in the feedback stage; if the assessment results are anonymized before being transmitted, a second anonymization process is required on the execution plan output, and since the structure of the execution plan is completely different from SQL statements, the anonymization complexity increases dramatically. Therefore, a simple combination of anonymization scheme and cost model cannot form an effective feedback loop in multi-round diagnostic scenarios.

[0007] However, the aforementioned circular contradiction is not entirely unsolvable. It's worth noting that while the anonymization process replaces real database objects with meaningless symbols, hiding semantic identifiers like table and column names, the structural information of the SQL statements is still retained after anonymization. Structural features such as the number and type of joins, the nesting depth of predicates, the hierarchical structure of subqueries, and the combination of aggregation and sorting do not depend on specific table or column names. Furthermore, in actual diagnostic scenarios, not all suggestions returned by external models carry a high execution cost risk; most suggestions have acceptable structural complexity, with only a few potentially causing abnormally high execution costs. This means that if the structural information retained in the symbol space can be used to perform coarse-grained risk differentiation of suggestions, it's possible to directly assess most low-risk suggestions within the symbol space without back-translating to the real space for precise cost evaluation, only back-translating to the real space for precise evaluation of the few suggestions deemed high-risk. This avoids the need for complete back-translation while maintaining control over high-risk suggestions.

[0008] However, there is currently no solution that translates the above ideas into a workable technical architecture. Specifically, what is lacking is: how to build the ability to assess execution cost risk in the code space, how to determine the switching conditions from the code space to the real space, and how to ensure that omissions in coarse-grained assessments do not affect the overall control of execution cost risk. Specifically, the existing technology has the following technical contradictions: assessing the execution cost of diagnostic suggestions usually requires real schema information, while privacy protection requires that real schema information not be directly exposed to external models, nor should a full back-translation and precise cost evaluation be performed on every suggestion. Summary of the Invention

[0009] To address the technical problems existing in the prior art, this invention provides a method and system for pre-controlling the execution cost risk of diagnostic suggestions when using an external large language model for SQL diagnostics.

[0010] On the one hand, a two-layer cost risk control method for external large language model SQL diagnostics is provided, including the following steps:

[0011] Receive the SQL statement to be diagnosed and its execution context;

[0012] The SQL statement and the real database object in the execution context are converted into code form by semantic preservation mapping to obtain code-based diagnostic requests, while the bidirectional mapping relationship between the code and the real database object is saved.

[0013] The code-based diagnostic request is sent to an external large language model, and the code-based diagnostic suggestions returned by the model are received.

[0014] Structural features are extracted from the code-based diagnostic suggestions and input into the code-layer risk judgment model, which then outputs a high-risk probability or risk score.

[0015] When the high-risk probability or risk score is lower than a preset threshold, the code-based diagnostic suggestion is released and enters the translation and execution process;

[0016] When the high-risk probability or risk score reaches or exceeds a preset threshold, the code-based diagnostic suggestion is translated back into real SQL through the bidirectional mapping relationship, and a precise cost assessment is performed in a controlled environment; based on the precise cost assessment result, a decision is made to allow or block access.

[0017] Preferably, the semantic preservation mapping preserves the join connectivity, predicate nesting structure, and subquery reference relationship of the SQL statement when performing code conversion on the real database object, so that the code-converted SQL statement is structurally equivalent to the original SQL statement.

[0018] Preferably, the code-layer risk judgment model adopts an architecture that decouples training and inference, wherein:

[0019] During the training phase, the actual execution cost of historical queries on the real schema is used as the label. Specifically, the historical query statements on the real schema of the target database are used as samples. After the samples are processed by symbolization, structural features are extracted, and the actual execution cost of the samples on the target database is used as the label for model training.

[0020] During the inference phase, risk prediction is completed using only the structural feature vectors extracted from the code-based diagnostic suggestions, without relying on any real database schema information.

[0021] Preferably, the code-layer risk judgment model adopts three risk levels—low risk, medium risk, and high risk—during training, and these three risk levels are used for label division during model training; in the triage decision during the inference phase, the triage decision of allowing passage or entering the precise cost assessment is determined only based on the comparison result between the high risk probability or risk score and the preset threshold.

[0022] Preferably, the accurate cost assessment is achieved using any one or more of the following methods: the cost estimation function built into the database execution engine, the actual cost information obtained from execution in a controlled environment, and the cost assessment model based on machine learning for querying full real schema information.

[0023] Preferably, the preset threshold is determined based on the statistical distribution of execution costs of historical diagnostic cases in the target database. By adjusting the preset threshold, a dynamic balance is achieved between the high-risk recall rate of execution costs and the call volume for accurate cost assessment and the exposure surface of real schema information.

[0024] Preferably, before performing risk assessment on the code-based diagnostic suggestions, the method further includes a code space validity verification step on the content returned by the external large language model:

[0025] The system checks whether there are plaintext values ​​in the code-based diagnostic suggestions returned by the external large language model that do not appear in the original code mapping. If an unauthorized plaintext value is detected, the system replaces the current code-based diagnostic suggestion with a preset fallback suggestion and continues subsequent processing, or terminates the processing flow of the current diagnostic suggestion.

[0026] Preferably, when the high-risk probability or risk score reaches or exceeds a preset threshold, a code space feedback step is included before translating the code-based diagnostic suggestions back into real SQL:

[0027] Based on the contribution of the code-layer risk judgment model to each structural feature of the current sample, the structural feature with the highest contribution is extracted, and the structural feature is located to the specific code token involved in the abstract syntax tree of the code-based diagnostic suggestion, generating risk attribution information in the code space.

[0028] The risk attribution information is fed back to an external large language model to request the regeneration of diagnostic suggestions.

[0029] The regenerated code-based diagnostic suggestions will undergo code space legality verification, structural feature extraction, and risk assessment processes again.

[0030] If, within the preset maximum number of iterations, the high-risk probability or risk score of the code-based diagnostic recommendations generated in a certain round is lower than the preset threshold, then the recommendations for that round will be approved.

[0031] If, after reaching the maximum number of iterations, the high-risk probability or risk score of the generated code-based diagnostic suggestions still reaches or exceeds the preset threshold, then the code-based diagnostic suggestions of the last round will be translated back into real SQL statements to execute the precise cost evaluation process.

[0032] On the other hand, a two-layer cost-risk control system for external large language model SQL diagnosis is provided to implement the aforementioned method. The system includes a code generation module, an external model interaction module, a coarse screening module, a traffic splitting decision module, a back-translation module, and a fine-judgment module, wherein:

[0033] The code-based module is used to receive the SQL statement to be diagnosed and its execution context, convert the real database object into a code form, obtain the code-based diagnostic request, and save the bidirectional mapping relationship between the code and the real object.

[0034] The external model interaction module is used to send the code-based diagnostic request to an external large language model and receive the code-based diagnostic suggestions returned by it.

[0035] The coarse screening module is used to extract structural features from the code-based diagnostic suggestions and use the code-layer risk judgment model to output a high-risk probability or risk score.

[0036] The triage decision module is used to allow the code-based diagnostic suggestion when the high-risk probability or risk score is lower than a preset threshold, and to start the slow path when the high-risk probability or risk score reaches or exceeds the preset threshold.

[0037] The back-translation module is used to restore the code-based diagnostic suggestions into real SQL based on the bidirectional mapping relationship;

[0038] The precision assessment module is used to perform accurate cost evaluation on the real SQL in a controlled environment, and output a decision to allow or block based on the evaluation results.

[0039] Preferably, it further includes:

[0040] The legality verification module is used to perform code space legality verification on the content returned by the external large language model before the coarse screening module processes it. It detects whether there are plaintext values ​​that do not appear in the original code mapping. If a plaintext value is detected, it triggers a rollback process or terminates the current suggested processing.

[0041] When the triage decision module determines that the high-risk probability or risk score reaches or exceeds a preset threshold, it performs code space feedback processing before initiating the slow path: based on the contribution of the coarse screening module to each structural feature of the current sample, code-layer risk attribution information is generated. The risk attribution information is fed back to the external large language model through the external model interaction module to request the regeneration of diagnostic suggestions. The new suggestions are processed again by the legality verification module and the coarse screening module. If the judgment in a certain round is lower than the preset threshold within the preset maximum number of iterations, a release result is given. If the preset threshold is still reached or exceeded after reaching the maximum number of iterations, the slow path is initiated to call the back-translation module and the fine judgment module to continue processing.

[0042] On the other hand, an electronic device is provided, comprising: a processor; and a memory storing computer-readable instructions, which, when executed by the processor, implement the method described above.

[0043] On the other hand, a computer-readable storage medium is provided, wherein at least one instruction is stored therein, the at least one instruction being loaded and executed by a processor to implement the above method.

[0044] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following:

[0045] This invention achieves the following technical effects in the context of large language model SQL diagnostics through a two-layer cost risk control architecture.

[0046] First, the exposure surface of real-world information is reduced. By performing a coarse screening of diagnostic suggestions based on execution cost and risk in the code space, most suggestions with low execution cost and risk can be judged and directly approved without entering the real-world space for fine-tuning. In the verification of the embodiment, the number of fine-tuning calls was reduced by about 56%, and the number of suggestions that needed to be translated back to the real-world space was correspondingly reduced, thus lowering the data exposure surface.

[0047] Second, the ability to intercept high-risk suggestions with high execution costs. The coarse screening can identify high-risk suggestions with a high recall rate and send them to the slow path for fine-tuning. In the embodiment, the recall rate is approximately 91%, and the false negative rate for suggestions allowed on the fast path is less than 5%. In actual deployment, a small number of false negatives can be mitigated by the operation and maintenance monitoring mechanism.

[0048] Third, the coarse screening and fine-grained judgment complement each other. Coarse screening can complete the execution cost risk classification using only the structural features of the code space and without relying on the real schema information. The accuracy of coarse screening does not need to reach the level of the precise cost model, because suggestions judged as having high execution cost risk are covered by the fine-grained judgment of the slow path. The conservative misjudgment of coarse screening only leads to a slight increase in the number of fine-grained judgment calls and does not affect the correctness of the final decision.

[0049] Fourth, the system offers an adjustable threshold for balancing execution cost risk, recall rate, and information exposure. By adjusting the risk assessment threshold of the coarse-screening model, the system can flexibly balance high-risk recall rate with high-precision call volume. System administrators can select an appropriate threshold based on the requirements of their specific deployment environment.

[0050] Fifth, in the optional implementation that includes code space feedback, the system can directly feed back the expressible feedback information within the code space to an external large language model, guiding the model to regenerate suggestions and forming multiple rounds of diagnostic iterations. The entire feedback process does not need to cross privacy boundaries, nor does it require secondary anonymization of the feedback content. Attached Figure Description

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

[0052] Figure 1 This is the overall architecture and dual-path flow diagram of the present invention;

[0053] Figure 2 This is a general flowchart of the implementation process of the present invention;

[0054] Figure 3 This is a schematic diagram of a training and inference decoupling framework provided in an embodiment of the present invention. Detailed Implementation

[0055] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0056] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0057] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0058] I. Introduction to the Technical Principles of this Method

[0059] (I) Overall Scheme Architecture

[0060] Figure 1 shows the overall architecture and dual-path routing relationship of the present invention.

[0061] This invention proposes a two-layer cost risk control architecture that diverts diagnostic suggestions returned by an external large language model into two processing paths based on their execution cost risk level. The first layer is a fast path, completed in the symbol space, without involving real schema information; the second layer is a slow path, completed in the real space, using full information for accurate cost assessment. The essential difference between the two paths lies not in processing speed, but in the different security domains they occupy: the fast path always operates in the symbol space and does not cross privacy boundaries; the slow path operates in the real space, requiring back-translation and full information access. By judging and directly allowing most low-risk suggestions in the fast path, and directly initiating the slow path for high-risk suggestions according to system configuration, or by first performing feedback iteration in the symbol space before initiating the slow path, this architecture achieves pre-control of the execution cost of diagnostic suggestions while maintaining anonymization protection.

[0062] It should be noted that the "risk" and "high risk" mentioned in this architecture refer to execution cost risk, that is, the abnormally high cost that may occur when the diagnostic recommendations are actually executed on the database, rather than information leakage risk. Information leakage risk is handled by the code-based de-identification and legality verification process, and belongs to a different dimension from the judgment of execution cost risk.

[0063] Combined with appendix Figure 2 As shown, the complete processing flow of this architecture is as follows:

[0064] First, the system receives the SQL statement to be diagnosed and its execution context, and converts the real database objects in it into code form through semantic preservation mapping, generating a code-based diagnostic request.

[0065] Then, the code-based diagnostic request is sent to an external large language model, which provides diagnostic suggestions in the code space. Upon receiving the code-based diagnostic suggestions, the system first performs a validity check in the code space, checking for any unauthorized plaintext leaks. Suggestions that pass the check enter the fast path: the system extracts structural feature vectors from the code-based suggestions and calls the code-layer risk assessment model (hereinafter referred to as the coarse screening) to classify their risk.

[0066] If the risk is determined to be low, the recommendation is to proceed directly to the subsequent translation and execution process;

[0067] If deemed high-risk, the system selects a subsequent processing method based on the current configuration: Under the basic configuration, the suggestion directly enters the slow path; under the configuration with code space feedback enabled, the system first enters the code space feedback stage, generates risk attribution information at the code layer based on the coarse screening results, feeds this information back to the external large language model, requests the model to regenerate the suggestion, and the new suggestion re-enters the legality verification and coarse screening process. If a round of coarse screening determines the suggestion to be low-risk within the preset maximum number of iterations, the suggestion is directly allowed in the fast path; if the coarse screening still determines the suggestion to be high-risk after reaching the maximum number of iterations, it enters the slow path: the system translates the code-based suggestion back into real SQL through mapping relationships, performs precise cost evaluation in a controlled environment, and decides to allow or block it based on the evaluation results.

[0068] The decision-making logic of the above process can be represented by the following pseudocode:

[0069] Input: SQL statement Q to be diagnosed, execution context ctx. Step 1: Code-making masked_Q, mapping ← Semantic-preserving mapping (Q, ctx). Step 2: External model diagnosis masked_suggestion ← Call external large language model (masked_Q). Step 3: Legality verification If unauthorized plaintext values ​​exist in masked_suggestion: If a pre-defined fallback suggestion exists: masked_suggestion ← Fallback suggestion Otherwise: Terminate processing of the current suggestion Return. Step 4: Code-layer risk judgment features ← Extract structural features (masked_suggestion) risk_prob ← Coarsely screen the model (features). Step 5: Triage decision and code space feedback If risk_prob [high risk] < threshold: ── Fast path ── Allow the suggestion, enter subsequent back-translation and execution process Return ── Code space feedback loop ── iteration ← 0 When iteration < maximum number of iterations: feedback ← Generate code-layer risk attribution (features, masked_suggestion ← Call external large language model (masked_Q, feedback) Repeat step 3 (legality check) features ← Extract structural features (masked_suggestion) risk_prob ← Coarse screening of the model (features) If risk_prob [high risk] < threshold: allow the suggestion, proceed to subsequent back-translation and execution process Return to iteration ← iteration + 1 ── Slow path ── real_sql ← Back-translation (masked_suggestion, mapping) cost ← Precise cost evaluation (real_sql) If cost is within acceptable range: allow; otherwise: block.

[0070] (ii) Code-based desensitization

[0071] The code-based desensitization is a pre-processing module in this architecture. Its function is to replace the real database objects with meaningless codes before sending the diagnostic request to the external large language model, so that the external model cannot access the real table names, column names, literals and other sensitive information.

[0072] The core requirement of symbolization is semantic preservation: the replacement process must retain the structural information of the SQL statement, including join relationships between tables, nested predicate levels, and subquery referencing structures, making the symbolized SQL structurally equivalent to the original SQL. This requirement serves two purposes: first, to enable external large language models to provide meaningful diagnostic suggestions based on the structural information of the symbolized SQL; and second, to enable subsequent coarse-screening models to extract effective structural features from the symbolized SQL.

[0073] The code-making process simultaneously generates and saves a mapping relationship, recording the bijection between each real object and its corresponding code. This mapping relationship is only stored in the local system and is not sent to external models. It is used to restore the code-making suggestions to the real SQL when back-translation is required later.

[0074] In one optional implementation, the tokenization module employs a session seed rotation mechanism. Specifically, the system uses different mapping seeds for different diagnostic sessions, allowing the same real database object to correspond to different token representations in different sessions. Since the coarse screening stage relies on the structural features retained in the tokenized SQL rather than the specific values ​​of the tokens, session seed rotation does not change the feature basis of subsequent risk assessments, but it can reduce the possibility of external models inferring the real schema through cross-session comparisons.

[0075] The specific implementation of the code-based module is not the focus of this invention. Rule mapping based on abstract syntax trees, template-based desensitization, and other solutions that can meet semantic preservation requirements can all be used as implementations of this module. This invention focuses on the two-layer risk control process after code-based ...

[0076] 1. Code space validity verification

[0077] Before assessing the risks of code-based suggestions, the system first verifies the legality of the code space of the content returned by the external large language model.

[0078] The necessity of this validation stems from the fact that the behavior of external large language models cannot be fully controlled. Even if the prompt explicitly requires the model to keep the token unchanged, the model may still introduce plaintext values ​​of real database objects into the output. For example, the model might replace the token S001 with an actual string literal, or mention the real table name in the comments. This behavior cannot be completely eliminated through prompt engineering.

[0079] The validity check logic is as follows: It checks whether the returned symbolic suggestion SQL contains any string literals or identifiers that did not appear in the original symbolic mapping. If an unauthorized plaintext value is found, the system determines that the output poses a risk of leakage. In this case, if the system has pre-set available fallback suggestions, the current output is replaced with those fallback suggestions, and the subsequent process continues; if no available fallback suggestions exist, the processing of the current suggestion is terminated, and the output is not included in subsequent risk assessment and back-translation processes.

[0080] This verification step demonstrates that, in this architecture, the security of the code space not only relies on the anonymization process on the input side, but also requires active verification of the content returned by the external model on the output side. This is an integral part of ensuring the integrity of the code space in the two-layer architecture.

[0081] 2. Rapid risk assessment at the code level

[0082] Rapid risk assessment at the code-layer level is a core component of this architecture. Its goal is to perform coarse-grained risk grading of execution costs for code-based diagnostic recommendations without relying on real schema information.

[0083] The technical implementation of this step involves two stages: structural feature extraction and risk classification prediction.

[0084] During the structural feature extraction phase, the system extracts a set of structural features from the code-based suggested SQL to form a feature vector. These features are entirely derived from the code space, containing no actual table names, column names, or any post-execution information. The structural features cover the following dimensions: number of table references and unique tables, number of column references and columns with table prefixes, number of joins, number of subqueries and maximum nesting depth, occurrence of GROUP BY and ORDER BY, number of aggregate functions, number of various predicates, number of nodes and maximum depth of the abstract syntax tree, number of common table expressions, number of window functions, number of correlated subqueries, and several ratio features such as average number of columns per table and average number of predicates per table. A common characteristic of these features is that they describe the structural complexity of the SQL statement, rather than the specific data objects operated on by the statement; therefore, they can be fully obtained from the code space.

[0085] In the risk grading prediction stage, the system inputs feature vectors into a coarse-screening model, which outputs the probability distribution of each risk level. In other optional implementations, the model can also output a comprehensive risk score instead of a probability distribution, as long as the output can be compared with a preset threshold to make a routing decision. As described in the overall architecture section, "risk" here refers to execution cost risk. During training, the model divides execution cost risk into three levels: low, medium, and high risk. Introducing an intermediate level allows the model to learn the gradual pattern of execution cost from low to high, thus outputting a more discriminative probability distribution. However, at the basic routing decision level, the system only makes a binary decision based on whether the high-risk probability exceeds a preset threshold: if the high-risk probability is below the threshold, the suggestion is to directly allow passage in the fast path; if the high-risk probability reaches or exceeds the threshold, the suggestion is to enter the slow path, and the final decision is made by the accurate cost assessment in the real space. In one optional implementation, the code space feedback step described in Section 5 can be executed before starting the slow path; if the risk is still not reduced after feedback, then the slow path is entered. In other words, the three-tiered risk level serves to improve the precision of model training, while the basic routing decision is always one of two paths: "allow" or "enter the slow path." The threshold setting and adjustment mechanism will be detailed in Section 4.

[0086] The coarse-screening model employs a key decoupling design between training and inference. During training, the model uses historical queries on the real schema as training samples, labeling them with the actual execution cost (obtained from the database execution engine) and categorizing them into low, medium, and high risk levels based on cost quantiles. However, the input features during training are still structural features extracted from the symbolic SQL, not real schema information. This means that the model learns the "statistical correlation between structural complexity patterns and execution cost levels" during training, rather than "whether a query on a specific table is necessarily fast or slow." During inference, the model only receives the symbolic layer structural feature vectors and does not need to access real schema information, thus allowing it to operate independently in the symbolic space.

[0087] This training-inference decoupling allows the coarse-screen model to complete inference without relying on real schema information after deployment, which is a technical prerequisite for the fast path to run independently in the symbol space.

[0088] The decoupling relationship between training and inference of the coarse-screening model is shown in Figure 3. In actual deployment, training samples are derived from the historical query logs of the target database. Database systems typically record the execution time of each query; these logs, after being coded and having their structural features extracted, can be used as training data. As the logs accumulate, the model can be retrained periodically to adapt to load changes. The larger the scale and coverage of the training samples, the stronger the coarse-screening model's ability to judge query risks in that database environment.

[0089] The specific algorithm type of the coarse screening model is not a limitation of this invention. The architecture requires the model to be able to accept the feature vectors of the code layer structure as input and output the probability distribution of each risk level. Any method that meets this interface requirement can be used as an implementation of this model, including but not limited to traditional machine learning methods such as gradient boosting trees, random forests, and support vector machines, as well as deep learning methods such as deep neural networks and pre-trained language models. When using a pre-trained language model as the coarse screening model, the text representation or structural features of the code-based SQL can be used as input, and the model outputs the probability distribution or risk score of the risk level. The focus of this invention is on the decoupled training-inference architecture design and the risk diversion logic in the code space, rather than a specific model algorithm.

[0090] It's important to note that the design goal of coarse screening is not to accurately predict the absolute execution cost of queries, but rather to identify and allow most low-risk suggestions within the code space with relatively low computational overhead. The accuracy of coarse screening does not need to reach the level of an accurate cost model, because suggestions deemed high-risk by coarse screening will enter the slow path where a more thorough, full-information-based judgment will provide a safety net. For the small number of high-risk samples that were missed and allowed through the fast path, subsequent operational monitoring or upper-level control logic can provide a safety net.

[0091] 3. Precise Judgment of Real Space

[0092] For diagnostic suggestions that are determined to require entering the slow path in the coarse screening, the system transfers them from the code space to the real space for precise cost evaluation.

[0093] The first step in transitioning to the real space is back translation: the system uses the mapping relationship saved in the code-making stage to restore the code token in the code-making suggestion to the real table name, column name and literal, and obtain the SQL statement that can be executed on the real database.

[0094] After back-translation, the system performs a cost assessment on the real SQL in a controlled environment. The fine-tuning can utilize the cost estimation function of the database execution engine, obtain actual cost information through controlled execution, or employ a query cost assessment model based on full real information. The query cost assessment model can be an existing machine learning cost model, including but not limited to Bao, Neo, and Lero, whose common feature is the ability to access the real schema, real plan information, or other real spatial features during inference. The results of the fine-tuning are categorized as follows: if the execution cost is within an acceptable range, the system determines that the suggestion passes the fine-tuning and allows it to proceed to the subsequent adoption process; if the execution cost exceeds a preset threshold, or if timeouts, errors, or other anomalies occur during execution, the system determines that the suggestion is unacceptable and makes a blocking decision.

[0095] The decision-making process for slow paths is an end-user decision. Allowing the path means the suggestion has undergone two layers of verification and can proceed to the next stage; blocking means the suggestion has been intercepted by the architecture and will not be executed. After blocking, the system can report the reason for the blocking to the upper-layer scheduling logic, which will then decide whether to initiate a new round of diagnostic requests. However, this decision is not within the scope of responsibility of this architecture.

[0096] It is important to emphasize that the existence of the slow path is not a flaw in the architecture, but rather an integral part of the architectural design. The fast path coarsely filters out most low-risk suggestions, allowing them to pass through the code space and reducing the number of suggestions that need to enter the real space. The slow path, on the other hand, performs fine-tuning on the few high-risk suggestions, ensuring the completeness of execution cost risk control. The cooperation of these two paths allows the system to both reduce the information exposure surface in the real space (fewer suggestions need to be translated back to the real space) and maintain the ability to intercept high-risk suggestions.

[0097] 4. Two-layer switching logic and threshold setting

[0098] The switching between the fast and slow paths is determined by the output of the coarse screening model. The model outputs a probability distribution for each risk level for each suggestion, and the system maps the probability distribution to specific processing decisions based on preset thresholds.

[0099] The threshold setting directly impacts the trade-off between two core metrics: recall (high-risk, high-execution-cost) and precision-judgment calls. Lowering the threshold for entering the slow path (making it easier to classify suggestions as high-risk, high-execution-cost) increases recall, but simultaneously increases precision-judgment calls, requiring more suggestions to be back-translated into the real space for processing, thus expanding the information exposure. Conversely, raising the threshold allows more suggestions to pass directly into the code space, reduces precision-judgment calls, and shrinks the information exposure, but may miss some high-risk, high-execution-cost suggestions.

[0100] The specific value of the threshold is determined based on the cost distribution statistics of historical diagnostic cases in the target database. System administrators can adjust the threshold according to the requirements of the actual scenario, achieving a balance between high-risk recall and high information exposure suitable for the specific deployment environment. This adjustability is an architectural design feature and does not depend on the specific implementation of the coarse screening model.

[0101] 5. Code space feedback and multi-round diagnostic support

[0102] In one optional implementation, when a code-based suggestion fails to meet the corresponding requirements within the code space, the system feeds back the adjustment information that can be expressed within the code space to an external large language model, requesting the model to regenerate the suggestion, thus forming multiple rounds of diagnostic iterations. There are two scenarios that trigger feedback: the content returned by the external model fails the validity check, or the code-based suggestion is judged to have a high execution cost risk during the initial screening. For the former, the system uses the specific reason for the validation failure as the feedback content; for the latter, the system generates risk attribution information for the code layer.

[0103] The generation process of risk attribution information at the code-layer is as follows. First, based on the prediction results of the coarse-screening model for the current sample, the system analyzes the contribution of each structural feature to the high-risk judgment and extracts the structural features with the highest contribution. Then, the system returns to the abstract syntax tree of the code-based suggestions and locates these structural features to the specific code tokens involved. For example, the feature "number of associated subqueries" can be located by traversing the syntax tree to the specific code table and associated predicates involved in the association. Finally, the system converts the location results into a natural language description within the code space, such as "the nesting level of the subqueries is too deep (3 levels: T003 → T004 → T005), and there are associated subqueries (T005 is associated with T003 through C010 = C005)". The above attribution information is expressed entirely in the code space and does not contain any real schema information. Therefore, it can be directly sent as feedback to an external large language model without crossing privacy boundaries.

[0104] The system sends the risk attribution information along with the original code-based request to an external model, requesting the model to regenerate recommendations for the identified structural risk factors. The new recommendations then re-enter the validity verification and coarse-grained screening process. If a round of coarse-grained screening determines the new recommendation to be low-risk, it is directly approved in the fast path. If, after reaching the preset maximum number of iterations, the coarse-grained screening still determines it to be high-risk, the system terminates the feedback loop and sends the final round of code-based recommendations to the slow path for precise cost assessment. The maximum number of iterations is set by the system administrator based on the actual scenario.

[0105] It is important to clarify that the code space feedback loop is an optional pre-processing step before the slow path, not a replacement for it. The goal of the feedback loop is to guide the external model to generate low-risk suggestions within the code space as much as possible before entering the real space. If the risk cannot be reduced after the feedback loop is exhausted, the slow path serves as a fallback for precise cost assessment. The results of the slow path's fine-tuning do not constitute the source of content for multiple rounds of feedback within this architecture. If a suggestion has already entered the real space and undergone fine-tuning, the results are only used to make terminal decisions on whether to allow or block access; whether a new round of diagnostic requests is initiated by the upper layer after blocking is a scheduling behavior outside this architecture.

[0106] The entire multi-round iterative process is completed within the symbol space, without needing to back-translate to the real space or perform secondary anonymization on the feedback content. In contrast, if a simple combination of the aforementioned anonymization scheme and cost model is used, the information from multiple rounds of feedback often originates in the real space, requiring secondary anonymization before being sent back to the external model. This process is complex, and each round of back-translation creates a new information exposure point. This architecture avoids this problem at the architectural level by confining the multi-round feedback within the symbol space.

[0107] II. System Composition Introduction

[0108] Corresponding to the above methods, this invention also provides a two-layer cost-risk control system for SQL diagnosis of large language models. This system includes a code-based module, an external model interaction module, a validity verification module, a coarse screening module, a traffic splitting decision module, a back-translation module, and a fine-tuning module. The code-based module receives the SQL statement to be diagnosed and its execution context, converts the real database object into a code form, and stores the mapping relationship between the code and the real object. The external model interaction module sends the code-based diagnostic request to an external large language model and receives the code-based diagnostic suggestions returned by the model.

[0109] The legitimacy verification module is connected to the external model interaction module and is used to check whether there are unauthorized plaintext values ​​in the content returned by the external large language model. If the verification passes, the code-based suggestion is sent to the coarse screening module; if the verification fails, a fallback suggestion is sent to the coarse screening module if a preset fallback suggestion exists, or the current suggestion processing flow is terminated. The coarse screening module is used to extract structural features from the code-based suggestions and output the risk level or high-risk probability based on the code-layer risk judgment model.

[0110] The routing decision module is connected to the coarse screening module and is used to determine the processing path of the suggestions based on the risk assessment results output by the coarse screening module. When a suggestion is determined to be low-risk, the routing decision module directly issues a pass result, allowing the suggestion to enter the subsequent back-translation and execution process. When a suggestion is determined to be high-risk, the routing decision module initiates a slow path, calling the back-translation module and the fine-judgment module to continue processing. In an optional implementation, before initiating the slow path, the routing decision module can also generate code-layer risk attribution information, and feed the attribution information back to the external large language model through the external model interaction module, requesting the model to regenerate the suggestion. The new suggestion is then processed again by the legality verification module and the coarse screening module. If a round of coarse screening determines the suggestion to be low-risk within the preset maximum number of iterations, the routing decision module issues a pass result; if the suggestion is still considered high-risk after reaching the maximum number of iterations, the routing decision module then initiates the slow path.

[0111] The back-translation module is used to restore the coded suggestions to the actual SQL based on the mapping relationship saved in the coded stage. The precision judgment module is connected to the back-translation module and is used to perform accurate cost evaluation of the actual SQL in a controlled environment, and output a decision to allow or block based on the evaluation results. The precision judgment module can call the cost estimation capability and controlled execution capability of the database execution engine, or call the cost evaluation model based on real spatial information.

[0112] In one optional implementation, the code-based module, the validity verification module, the coarse screening module, and the risk diversion decision module are deployed in the code-space processing link, while the back-translation module and the fine-judgment module are deployed in the real-space processing link, thus forming fast and slow paths in the system structure. The former is responsible for completing input protection, output verification, and risk diversion without exposing the real schema information, while the latter is responsible for back-translating and accurately evaluating a small number of high-risk suggestions. Therefore, the system implements a two-layer cost-risk control architecture consistent with the aforementioned methods at the module level.

[0113] The implementation process and effects of this application will be described in detail below with reference to the embodiments.

[0114] Example 1

[0115] 1. Implementation Environment and Data Preparation

[0116] The operating environment for this embodiment is as follows: the database is PostgreSQL 14, and the Python version is 3.12.

[0117] This embodiment uses two standard database benchmarks to construct the diagnostic request set for verification: TPC-H and TPC-DS, both with a data size of SF=1. TPC-H contains 8 tables, with the largest table, lineitem, having approximately 6 million rows; TPC-DS contains 24 tables. The diagnostic request set includes 22 standard queries from TPC-H, 262 parameter-level and structure-level variants of TPC-H, and 99 standard queries from TPC-DS, totaling 377 valid samples. The actual execution time of each sample was obtained on PostgreSQL using EXPLAIN ANALYZE, with an execution timeout threshold of 15 seconds.

[0118] The risk labels used to train the coarse-grained model are divided into three levels based on the execution time quantiles of all samples: those with execution times no higher than the 60th percentile (approximately 578 milliseconds) are labeled as low risk; those with execution times higher than the 60th percentile but no higher than the 90th percentile (approximately 1839 milliseconds) are labeled as medium risk; and those with execution times exceeding the 90th percentile are labeled as high risk. The final label distribution is 182 low-risk, 91 medium-risk, and 104 high-risk. As explained earlier regarding the rapid risk assessment at the code layer, the three-level labels serve to refine the model training; the routing decision is based solely on whether the high-risk probability output by the model exceeds a threshold for binary judgment.

[0119] 2. Example of code-based implementation

[0120] In this embodiment, the symbolization is implemented based on the SQL abstract syntax tree. The system uses the sqlglot library to parse SQL statements into a syntax tree. During the traversal of the syntax tree, replacements are performed according to node type: table names are replaced with sequence symbols such as T001, T002, etc.; column names are replaced with symbols such as C001, C002, etc.; string literals are replaced with symbols such as S001, S002, etc.; and numeric literals are replaced with sequential numbers. During the replacement process, an independent mapping table is maintained for each SQL statement, recording the bijective relationship between each real object and its symbol.

[0121] Taking the TPC-H standard query for Q06 as an example, the original SQL is:

[0122] SELECT SUM(l_extendedprice * l_discount) AS revenueFROM lineitemWHEREl_shipdate >= DATE '1994-01-01' AND l_shipdate < DATE '1994-01-01' +INTERVAL '1 year' AND l_discount BETWEEN 0.06 - 0.01 AND 0.06 + 0.01 AND l_quantity < 24

[0123] The SQL after code generation is:

[0124] SELECT SUM(C004 * C002) AS O001FROM T001WHERE C001 >= CAST('S001' ASDATE) AND C001 < CAST('S001' AS DATE) + INTERVAL 'S002 YEAR' AND C002BETWEEN 1 - 2 AND 1 + 2 AND C003 < 3

[0125] The corresponding mapping relationships are as follows: lineitem corresponds to T001, l_shipdate corresponds to C001, l_discount corresponds to C002, l_quantity corresponds to C003, l_extendedprice corresponds to C004, revenue corresponds to O001, 1994-01-01 corresponds to S001, 0.06 corresponds to 1, 0.01 corresponds to 2, and 24 corresponds to 3.

[0126] As can be seen from the above examples, the SQL after being coded retains the complete structure of the original query: the structural information such as single-table queries, range predicates, BETWEEN predicates, and aggregate functions are not lost, but the true meaning of table names, column names, and literals has been hidden.

[0127] 3. Feature Extraction and Model Training

[0128] For each coded SQL statement, the system extracts a structural feature vector from its abstract syntax tree. The features extracted in this embodiment include: number of table references, number of unique tables, number of column references, number of columns with table prefixes, number of joins, number of subqueries, maximum subquery nesting depth, whether it contains GROUP BY, ORDER BY, DISTINCT, or LIMIT, number of aggregate functions, number of ordinary function calls, number of various predicates, number of string literals, number of numeric literals, total number of nodes in the abstract syntax tree, maximum syntax tree depth, number of common table expressions, number of window functions, number of CASE expressions, number of HAVING clauses, number of CAST expressions, number of correlated subqueries, and proportional features such as the average number of columns per table and the average number of predicates per table. All of these features are obtained from the coded SQL statement and do not depend on the actual table names, actual column names, or post-execution information.

[0129] In this embodiment, the coarse screening model uses XGBoost gradient boosting trees as the classifier. The model training process adopts the training-inference decoupling design described in the technical solution: During the training phase, the system first performs code-based processing and structural feature extraction on historical queries in the target database. Then, using the actual execution time of these queries on the real database as the label source, it classifies them into three risk levels—low, medium, and high—according to quantiles. During training, the model learns the statistical correlation between the code-layer structural feature patterns and the execution cost level. After training, the model's input interface only receives code-layer structural feature vectors and does not require or accept real schema information. Therefore, during the inference phase, the model can run independently in the code space, performing risk classification on new code-based suggestions without accessing the real space. As described in the technical solution, this model position can be replaced by other supervised learning methods that satisfy the same input-output interface.

[0130] 4. Risk classification capability of the coarse screening model and the diversion behavior of the two-layer architecture

[0131] This embodiment uses all 377 samples as the evaluation objects, performing a leave-one-out evaluation for each sample: the current sample is excluded from the training set, and the coarse-screening model is trained using the remaining 376 samples. The trained model is then used to predict the current sample, thus evaluating the model's ability to classify the risk of new diagnostic requests in the same database environment. This evaluation method corresponds to a real-world deployment scenario: the coarse-screening model is trained on the historical load of the target database and used to classify the risk of new diagnostic requests in the same environment. Under a three-class classification evaluation caliber, the coarse-screening model achieves a classification accuracy of approximately 0.79, a macro-average F1 score of approximately 0.76, with a precision of approximately 0.88 and a recall of approximately 0.86 for the high-risk class.

[0132] The coarse-screening model was deployed in a two-tier architecture, and the 377 diagnostic requests were processed according to the basic traffic routing logic described in Part (I). Under the routing scope of the two-tier architecture, the system decides whether to enter the slow path based on the comparison between the high-risk probability and a preset threshold. Under the default threshold, 213 of the 377 requests were determined to be low-risk by the coarse-screening and were directly allowed in the code space without needing to enter the real space for fine-tuning; 164 requests entered the slow path for precise cost evaluation. In the post-verification, 95 of the 104 requests that were truly high-risk were correctly intercepted by the coarse-screening and sent to fine-tuning, with a high-risk recall rate of approximately 91%; of the 213 requests allowed in the fast path, only 9 were high-risk requests that were missed, with an allowance safety rate of approximately 95.8%. The aforementioned recall rate of approximately 0.86 corresponds to the ability of the model in the three-class classification assessment to directly predict samples as high-risk categories; the approximately 91% high-risk recall rate here corresponds to the ability of the two-layer architecture to trigger the diversion of the slow path according to the probability threshold, and the two have different statistical calibers.

[0133] System administrators can modify routing behavior by adjusting the risk assessment threshold of the coarse screening model. For example, in a two-tier routing architecture, adjusting the high-risk probability threshold from the default value to 0.3 increases the proportion of fast path approvals, reduces the number of fine-grained calls by approximately 70%, and achieves a high-risk recall rate of approximately 88%.

[0134] 5. End-to-end processing example

[0135] The following three specific examples illustrate the three traffic splitting paths in a two-tier architecture.

[0136] The first case involves low-risk direct approval. After receiving the SQL query to be diagnosed, the system coded it and sent the coded request to an external large language model. The model returned the following coded suggestion SQL:

[0137] SELECT SUM(C004 * C002) AS O001FROM T001WHERE C001 >= CAST('S001' ASDATE) AND C001 < CAST('S001' AS DATE) + INTERVAL 'S002 YEAR' AND C002BETWEEN 1 - 2 AND 1 + 2 AND C003 < 3

[0138] The system first performs a validity check on the suggestion, confirming that it does not contain any unauthorized plaintext values. Then, it proceeds to a coarse-grained screening stage: the system extracts structural features from the coded suggestion. This suggestion is a single-table query, containing only range predicates and aggregate functions, resulting in low structural complexity. The coarse-grained model determines this suggestion to be low-risk (high-risk probability approximately 0.004), and the system directly allows it in the coded space, avoiding the slow path. The actual execution time after back-translation is approximately 378 milliseconds, falling within the low-risk range, thus verifying the correctness of the coarse-grained judgment.

[0139] The second case involved a high-risk, carefully assessed case followed by approval. The system coded another SQL query to be diagnosed and sent it to an external model. The model returned the following coded suggested SQL:

[0140] SELECT SUM(C006) / 7.0 AS O001FROM T001, T002WHERE C001 = C002 ANDC003 = 'S001' AND C004 = 'S002' AND C005 < (SELECT 1 * AVG(C005) FROM T001WHERE C002 = C001 )

[0141] The system performs a validity check on the suggestion. In this actual operation, the external model replaced the code S001 with the real brand name Brand#28. The validation logic found that the string literal was not registered in the original code mapping, and determined it to be an unauthorized plaintext value, triggering the rollback mechanism. The system uses the rollback suggestion (i.e., the above code-based SQL) to continue the subsequent process. Then it enters the coarse screening stage: the suggestion involves a two-table join and contains a related subquery, with a structural complexity significantly higher than the first case. The coarse screening model determines that the suggestion is high-risk (high-risk probability approximately 0.983), and the system sends it to the slow path. The system translates the code-based suggestion back into the real SQL through the mapping relationship:

[0142] SELECT SUM(l_extendedprice) / 7.0 AS avg_yearlyFROM lineitem,partWHERE p_partkey = l_partkey AND p_brand = 'Brand#28' AND p_container ='MED BOX' AND l_quantity < (SELECT 0.2 * AVG(l_quantity) FROM lineitem WHEREl_partkey = p_partkey )

[0143] In the real-world fine-tuning process, the actual execution time of the suggestion was approximately 14 milliseconds, far below the fine-tuning threshold. The system approved the suggestion and allowed its adoption. This case demonstrates the necessity of the slow path: the coarse screening, based on a conservative strategy, classified the suggestion as high-risk, while the fine-tuning, through a comprehensive information evaluation, avoided unnecessary obstruction.

[0144] The third case involved high-risk, precise assessment followed by blocking. The system coded the third SQL query to be diagnosed and sent it to an external model. The model returned the following coded suggested SQL:

[0145] SELECT C001, C002FROM T001, T002WHERE C003 IN (SELECT C004 FROM T003WHERE C005 IN (SELECT C006 FROM T004 WHERE C007 LIKE 'S001')AND C008 >(SELECT 1 * SUM(C009) FROM T005 WHERE C010 = C005 AND C011 = C004 AND C012 >=CAST('S002' AS DATE) AND C012 < CAST('S002' AS DATE) + INTERVAL 'S003 YEAR'))AND C013 = C014 AND C015 = 'S004'ORDER BY C001

[0146] The system performs a legality check on the suggestion. In this actual operation, the external model incorporated real country names into its output, and the validation logic also identified these as unauthorized plaintext values ​​and triggered a rollback. The system used the rollback suggestion to continue the subsequent process. Entering the coarse screening stage: the suggestion involves five tables, includes three levels of nested subqueries and relational predicates, and has the highest structural complexity among the three cases. The coarse screening model determines this suggestion to be high-risk (high-risk probability approximately 0.978), and the system sends it to the slow path. The actual SQL obtained after system back-translation contains nested relational queries on five tables: supplier, nation, partsupp, part, and lineitem. In the real-world fine-tuning stage, the suggestion timed out (exceeding 15 seconds), and the system made a blocking decision.

[0147] 6. Example of Code Space Feedback and Multi-Round Diagnosis

[0148] After the coarse screening model determines the suggestion to be high-risk, the system generates risk attribution information at the code layer according to the process described in Part (II). Specifically, the system first analyzes the contribution of the coarse screening model to each structural feature of the current sample, and determines that the features with the highest contribution are the maximum nesting depth of subqueries, the number of associated subqueries, and the number of tables involved. Then, the system locates these features to specific code tokens in the syntax tree of the code-based suggestion: the maximum nesting depth of subqueries is 3 (corresponding to three levels of nesting: T003, T004, and T005), the number of associated subqueries is 1 (the subquery on T005 is associated with the outer layer through C010 = C005), and the number of tables involved is 5. This attribution information is expressed entirely in the code space and does not contain any real table names or real column names.

[0149] The system sends the above attribution information as feedback to the external large language model, requesting the model to reduce the nesting complexity of the queries. The feedback is in the following format: "It is suggested that the execution cost risk is high. The main risk factors are: the subquery nesting level is too deep (3 levels), and there are related subqueries (T005 related to T003). Please try to reduce the nesting level or eliminate the related subqueries."

[0150] The external model generates new coded suggestions based on this feedback, such as rewriting a three-level nested subquery into a join form. The new suggestions then undergo validity checks and a coarse-grained screening process. If the new suggestion is deemed low-risk in the coarse-grained screening, it is directly approved in the fast path. If it is still deemed high-risk, the system continues to generate risk attributions and initiates the next iteration. If the risk level does not decrease to low risk after reaching the maximum number of iterations, the final round of suggestions enters the slow path for a final decision by a refined assessment. The entire feedback iteration process is completed within the coded space, without needing to be back-translated to the real space or undergo secondary anonymization of the feedback content.

[0151] 7. Session seed rotation

[0152] The code-based module in this embodiment supports a session seed rotation mechanism. Using different mapping seeds in different diagnostic sessions allows the same real database object to correspond to different codes in different sessions, increasing the difficulty for external models to infer the real schema through cross-session comparisons.

[0153] Specifically, the mapping seed generates a 4-character session tag using SHA-256 hashing and embeds it in the prefix of the token. For example, in the default mode without using a seed, a table corresponds to T001 and a column corresponds to C001. When using seed session-a (session tag FA57), the same table corresponds to TFA57_001 and the same column corresponds to CFA57_001. When using seed session-b (session tag E8DE), the same table corresponds to TE8DE_001 and the same column corresponds to CE8DE_001.

[0154] Session seed rotation does not affect the judgment results of the coarse-screening model. Under different seed configurations, the coarse-screening prediction probability and the routing decision for the same suggestion are completely consistent. This is because the coarse-screening model uses structural features extracted from the code-based SQL, and the structural features do not depend on the specific value of the code token; therefore, seed rotation does not change the feature vector.

[0155] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center containing one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0156] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0157] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0158] It should be understood that, in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0159] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0160] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0161] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0162] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0163] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0164] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0165] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A two-layer cost risk control method for external large language model SQL diagnostics, characterized in that, Includes the following steps: Receive the SQL statement to be diagnosed and its execution context; The SQL statement and the real database object in the execution context are converted into code form by semantic preservation mapping to obtain code-based diagnostic requests, while the bidirectional mapping relationship between the code and the real database object is saved. The code-based diagnostic request is sent to an external large language model, and the code-based diagnostic suggestions returned by the model are received. Structural features are extracted from the code-based diagnostic suggestions and input into the code-layer risk judgment model, which then outputs a high-risk probability or risk score. When the high-risk probability or risk score is lower than a preset threshold, the code-based diagnostic suggestion is released and enters the translation and execution process; When the high-risk probability or risk score reaches or exceeds a preset threshold, the code-based diagnostic suggestion is translated back into real SQL through the bidirectional mapping relationship, and a precise cost assessment is performed in a controlled environment; based on the precise cost assessment result, a decision is made to allow or block access.

2. The method as described in claim 1, characterized in that, The semantic preservation mapping, when performing code conversion on the real database object, preserves the join connectivity, predicate nesting structure, and subquery reference relationship of the SQL statement, making the code-converted SQL statement structurally equivalent to the original SQL statement.

3. The method as described in claim 1, characterized in that, The code-layer risk assessment model adopts an architecture that decouples training and inference, wherein: During the training phase, the actual execution cost of historical queries on the real schema is used as the label. Specifically, the historical query statements on the real schema of the target database are used as samples. After the samples are processed by symbolization, structural features are extracted, and the actual execution cost of the samples on the target database is used as the label for model training. During the inference phase, risk prediction is completed using only the structural feature vectors extracted from the code-based diagnostic suggestions, without relying on any real database schema information.

4. The method as described in claim 1, characterized in that, The code-layer risk judgment model uses three risk levels—low risk, medium risk, and high risk—during training, and these three risk levels are used for labeling during model training. In the triage decision during the inference phase, the triage decision of allowing passage or entering the precise cost assessment is determined solely based on the comparison between the high-risk probability or risk score and the preset threshold.

5. The method as described in claim 1, characterized in that, The accurate cost assessment mentioned above is achieved using any one or more of the following methods: the cost estimation function built into the database execution engine, the actual cost information obtained from execution in a controlled environment, and the cost assessment model based on machine learning for querying full real schema information.

6. The method as described in claim 1, characterized in that, The preset threshold is determined based on the statistical distribution of execution costs of historical diagnostic cases in the target database. By adjusting the preset threshold, a dynamic balance is achieved between the high-risk recall rate of execution costs and the call volume of accurate cost assessment and the exposure surface of real schema information.

7. The method as described in claim 1, characterized in that, Before assessing the risks of the code-based diagnostic suggestions, the process also includes a code space validity verification step on the content returned by the external large language model: The system checks whether there are plaintext values ​​in the code-based diagnostic suggestions returned by the external large language model that do not appear in the original code mapping. If an unauthorized plaintext value is detected, the system replaces the current code-based diagnostic suggestion with a preset fallback suggestion and continues subsequent processing, or terminates the processing flow of the current diagnostic suggestion.

8. The method as described in claim 1, characterized in that, When the high-risk probability or risk score reaches or exceeds a preset threshold, a code space feedback step is included before translating the code-based diagnostic suggestions back into real SQL. Based on the contribution of the code-layer risk judgment model to each structural feature of the current sample, the structural feature with the highest contribution is extracted, and the structural feature is located to the specific code token involved in the abstract syntax tree of the code-based diagnostic suggestion, generating risk attribution information in the code space. The risk attribution information is fed back to an external large language model to request the regeneration of diagnostic suggestions. The regenerated code-based diagnostic suggestions will undergo code space legality verification, structural feature extraction, and risk assessment processes again. If, within the preset maximum number of iterations, the high-risk probability or risk score of the code-based diagnostic recommendations generated in a certain round is lower than the preset threshold, then the recommendations for that round will be approved. If, after reaching the maximum number of iterations, the high-risk probability or risk score of the generated code-based diagnostic suggestions still reaches or exceeds the preset threshold, then the code-based diagnostic suggestions of the last round will be translated back into real SQL statements to execute the precise cost evaluation process.

9. A two-layer cost-risk control system for external large language model SQL diagnostics, used to implement the method of any one of claims 1-8, characterized in that, The system includes a code generation module, an external model interaction module, a coarse screening module, a triage decision module, a back-translation module, and a fine-judgment module, wherein: The code-based module is used to receive the SQL statement to be diagnosed and its execution context, convert the real database object into a code form, obtain the code-based diagnostic request, and save the bidirectional mapping relationship between the code and the real object. The external model interaction module is used to send the code-based diagnostic request to an external large language model and receive the code-based diagnostic suggestions returned by it. The coarse screening module is used to extract structural features from the code-based diagnostic suggestions and use the code-layer risk judgment model to output a high-risk probability or risk score. The triage decision module is used to allow the code-based diagnostic suggestion when the high-risk probability or risk score is lower than a preset threshold, and to start the slow path when the high-risk probability or risk score reaches or exceeds the preset threshold. The back-translation module is used to restore the code-based diagnostic suggestions into real SQL based on the bidirectional mapping relationship; The precision assessment module is used to perform accurate cost evaluation on the real SQL in a controlled environment, and output a decision to allow or block based on the evaluation results.

10. The system as described in claim 9, characterized in that, It also includes a legality verification module, which is used to perform code space legality verification on the content returned by the external large language model before the coarse screening module processes it, and to detect whether there are plaintext values ​​that do not appear in the original code mapping. If plaintext values ​​are detected, a rollback process is triggered or the current suggested processing is terminated. When the triage decision module determines that the high-risk probability or risk score reaches or exceeds a preset threshold, before initiating the slow path, it also performs code space feedback processing: based on the contribution of the coarse screening module to each structural feature of the current sample, code-layer risk attribution information is generated, and the risk attribution information is fed back to the external large language model through the external model interaction module to request the regeneration of diagnostic suggestions. The new suggestions are then processed again by the legality verification module and the coarse screening module; if the judgment in a certain round is lower than the preset threshold within the preset maximum number of iterations, a release result is given. If the preset threshold is reached or exceeded after the maximum number of iterations, the slow path call translation module and the fine judgment module will be activated to continue processing.

Images