Structured query statement generation method and device, equipment, medium and product

Abstract

The invention relates to a structured query statement generation method and device, equipment, a medium and a product. The method comprises the following steps: receiving a data query demand described by a natural language and user permission information associated with the data query demand; generating a first security constraint condition based on the data query demand; the first security constraint condition is used for constraining field selection and structural integrity in a structured query statement to be generated; generating a second security constraint condition based on the user permission information; the second security constraint condition is used for constraining a data query range in the to-be-generated structured query statement; calling a trained large language model, and generating an original structured query statement based on the data query demand; and generating a target structured query statement in combination with the first security constraint condition, the second security constraint condition and the original structured query statement. By adopting the method, the data security can be improved.

Description

Technical Field

[0001] This application relates to the fields of financial technology and database security technology, and in particular to a method, apparatus, device, medium and product for generating structured query statements. Background Technology

[0002] With the significant advancements in large language model technology within the field of natural language processing, text-to-SQL (TTO) technology based on large models has emerged. This technology aims to directly convert users' natural language queries into standardized structured query statements, thereby significantly reducing the operational threshold for database queries. This technology holds broad application prospects in data-sensitive industries such as finance and healthcare.

[0003] However, applying general text-to-structured query conversion models directly to enterprise-level, especially banking scenarios, presents serious data security and compliance challenges. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, device, medium, and product for generating structured query statements that can improve data security, addressing the aforementioned technical problems.

[0005] Firstly, this application provides a method for generating structured query statements, including:

[0006] Receive data query requests described in natural language and the user permission information associated with those data query requests;

[0007] A first security constraint is generated based on the data query requirements; the first security constraint is used to constrain the field selection and structural integrity in the generated structured query statement.

[0008] A second security constraint is generated based on the user permission information; the second security constraint is used to constrain the data query range in the structured query statement to be generated.

[0009] The trained large language model is invoked to generate the original structured query statement based on the data query requirements;

[0010] By combining the first security constraint, the second security constraint, and the original structured query statement, a target structured query statement is generated.

[0011] In one embodiment, generating the first security constraint based on the data query requirement includes:

[0012] Based on the query intent indicated by the data query request, determine the target business scenario corresponding to the data query request;

[0013] Based on a pre-configured semantic decision tree, target data query rules matching the target business scenario are determined; the semantic decision tree includes data query rules under different business scenarios.

[0014] The first security constraint is generated based on the target data query rules.

[0015] In one embodiment, the target data query rule includes at least one of field disambiguation rules and mandatory field rules;

[0016] The field disambiguation rules are used to indicate the mapping relationship between ambiguous fields in the data query requirements and database fields in the structured query statement to be generated;

[0017] The required field rules are used to indicate the fields that must appear in the structured query statement to be generated.

[0018] In one embodiment, generating the second security constraint based on the user permission information includes:

[0019] Based on the user identifier and department indicated by the user permission information, the department-level data permission information and field-level permission information corresponding to the data query request are determined; the department-level data permission information is used to constrain the range of departments to which the data records accessed by the structured query statement to be generated belong, and the field-level permission information is used to constrain the range of fields that are allowed to be accessed in the structured query statement to be generated.

[0020] The second security constraint is generated by combining the department-level data permission information and the field-level permission information.

[0021] In one embodiment, the method further includes:

[0022] Based on a preset set of syntax security rules, a third security constraint is generated; the third security constraint is used to define the disabled fields and / or syntax structures in the structured query statement to be generated.

[0023] The step of combining the first security constraint, the second security constraint, and the original structured query statement to generate the target structured query statement includes:

[0024] The target structured query statement is generated by combining the first security constraint, the second security constraint, the third security constraint, and the original structured query statement.

[0025] In one embodiment, the step of invoking a trained large language model to generate a raw structured query statement based on the data query requirements includes:

[0026] Enhanced context information is obtained by extracting the database schema information related to the data query requirements from the preset vector database;

[0027] The data query requirement and the enhanced context information are input into the trained large language model to obtain the original structured query statement generated by the trained large language model.

[0028] In one embodiment,

[0029] In one embodiment,

[0030] Secondly, this application also provides an apparatus for generating structured query statements, comprising:

[0031] The receiving module is used to receive data query requests described in natural language and user permission information associated with the data query requests;

[0032] The first module is used to generate a first security constraint based on the data query requirements; the first security constraint is used to constrain the field selection and structural integrity in the structured query statement to be generated.

[0033] The second module is used to generate a second security constraint based on the user permission information; the second security constraint is used to constrain the data query range in the structured query statement to be generated.

[0034] The model module is used to call the trained large language model and generate the original structured query statement based on the data query requirements.

[0035] The generation module is used to combine the first security constraint, the second security constraint, and the original structured query statement to generate a target structured query statement.

[0036] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method for generating structured query statements provided in the first aspect of this application.

[0037] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the method for generating structured query statements provided in the first aspect of this application.

[0038] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method for generating structured query statements provided in the first aspect of this application.

[0039] The aforementioned method, apparatus, device, medium, and product for generating structured query statements receive data query requirements described in natural language and user permission information associated with those requirements. Based on the data query requirements, a first security constraint is generated to constrain field selection and structural integrity in the structured query statement to be generated. Based on the user permission information, a second security constraint is generated to constrain the data query scope in the structured query statement to be generated. A trained large language model is invoked to generate an original structured query statement based on the data query requirements. Combining the first and second security constraints with the original structured query statement, a target structured query statement is generated. This application, by using business semantic constraints and user permission constraints as prerequisites and deeply coupling them temporally and logically with the generation capabilities of the large language model, enables the synchronous injection and mandatory compliance of security constraints during the conversion from natural language to structured query statements. This ensures that the final generated target structured query statement is semantically faithful to the user's intent, structurally strictly adheres to business rules, and precisely limits its execution scope to user permissions. This fundamentally avoids unauthorized access and semantic ambiguity that may arise from freely generated models, thereby improving data security. Attached Figure Description

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

[0041] Figure 1 This is an application environment diagram of a method for generating structured query statements in one embodiment;

[0042] Figure 2 This is a flowchart illustrating a method for generating structured query statements in one embodiment;

[0043] Figure 3 This is a schematic diagram of the process for generating the first security constraint in one embodiment;

[0044] Figure 4 This is a flowchart illustrating the process of generating a second security constraint in one embodiment;

[0045] Figure 5This is a flowchart illustrating the process of generating the original structured query statement in one embodiment;

[0046] Figure 6 This is a structural block diagram of a structured query statement generation device in one embodiment;

[0047] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0049] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0050] The current Text-to-SQL method used in the banking sector has the following technical shortcomings:

[0051] Firstly, it exhibits lag in access control. Due to the lack of a dynamic permission injection mechanism, in free-response question-and-answer scenarios rather than fixed-page queries, the SQL statements generated by the model often bypass the bank's internal permission system. A typical example is the direct use of an unmodified generic model, which resulted in temporary worker accounts with basic query permissions being able to directly access sensitive data such as executive salary details.

[0052] Secondly, there are shortcomings in semantic understanding. When faced with synonyms or near-synonyms specific to banks, the model cannot accurately distinguish them based on business context, and its generalization ability is poor. A typical example is the incorrect mapping between deposit accounts (DEP_ACCT) and wealth management accounts (FIN_ACCT), which could lead to mismatch incidents involving large sums of money.

[0053] The aforementioned two types of defects together make it difficult for existing technologies to meet the stringent requirements of banking operations for both data security and semantic accuracy.

[0054] The method for generating structured query statements provided in this application can be applied to, for example, Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or placed on a cloud or other network server. Terminal 102 or server 104 can receive data query requests described in natural language and user permission information associated with those requests. Based on the data query requests, it generates a first security constraint, and based on the user permission information, it generates a second security constraint. It then calls a trained large language model to generate a raw structured query statement based on the data query requests. Finally, it combines the first and second security constraints with the raw structured query statement to generate a target structured query statement.

[0055] Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection equipment. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0056] In one exemplary embodiment, such as Figure 2 As shown, a method for generating structured query statements is provided, which can be applied to... Figure 1 Taking the server in the example, the explanation includes the following steps 202 to 210. Wherein:

[0057] Step 202: Receive the data query request described in natural language and the user permission information associated with the data query request.

[0058] Data query requests refer to user requests expressed in natural language, expressing their desire to retrieve specific information or perform specific analyses from the database. User permission information refers to metadata that represents the current user's identity and the scope of data, operation types, and access levels they are authorized to access within the database system.

[0059] For example, the server receives natural language text input by the user through its front-end interactive interface, such as "Please list the names of customers in region A whose transaction volume exceeded 1 million last month and their account balances." At the same time, the server can obtain the permission identifier associated with the user session through the identity authentication and session management module, such as structured information like user role, department, and data access level, providing a basis for subsequent constraint generation.

[0060] In one possible implementation, after receiving a data query request, the server uses natural language processing technology to perform intent recognition on the user's input data query request and obtain the intent recognition result. For example, it determines whether the user's intent is "detailed data query" or "data statistics", and extracts key entities (such as "Branch X", "last month", "total transaction amount").

[0061] Step 204: Generate the first security constraint based on the data query requirements.

[0062] The first security constraint is used to constrain the field selection and structural integrity in the generated structured query statement.

[0063] In the embodiments of this application, the first security constraint can be a set of predefined rules to ensure that the generated query statement is syntactically and semantically compliant and complete. Specifically, the first security constraint can be used to limit the specific fields that the structured query statement to be generated must include or exclude, the association conditions that must be met, and the syntactic structure that must be followed.

[0064] For example, the server uses natural language processing technology to identify the intent of the user's input data query request, obtaining the intent identification result. The computer device can extract key business concepts and operation types from the intent identification result, and generate corresponding constraint rules from a pre-set business rule base corresponding to the key business concepts or operation types to determine the first security constraint condition. For example, for a query involving "customer information," the first security constraint condition may require that the structured query statement to be generated must include the "customer ID" field to maintain the traceability of the results, and prohibit queries from including sensitive fields beyond the scope such as "ID card number," thereby ensuring the business compliance and structural security of the generated statement.

[0065] Step 206: Generate a second security constraint based on user permission information.

[0066] The second security constraint is used to constrain the data query range in the generated structured query statement.

[0067] For example, the server can parse the received user permission information and extract the access control attributes contained therein. These access control attributes include at least one or more of the following: user identifier, department identifier, role identifier, and associated data tags. Based on a preset access control policy, the server converts the access control attributes into one or more conditional expressions that can be embedded in a structured query statement, thereby serving as filtering conditions for the database query. For instance, when the permission information indicates that the user's role is "Department Manager" and their department is "Branch A," the server generates corresponding conditional statements according to the policy to limit the data range to "Department = 'Branch A'" in the final query.

[0068] Step 208: Call the trained large language model to generate the original structured query statement based on the data query requirements.

[0069] Here, the original structured query statement can refer to the initial query code generated by the large language model based on its understanding of the intent recognition results corresponding to the data query requirements. It conforms to the syntax of the target database but has not yet embedded any security constraints.

[0070] For example, the computer device inputs the normalized data query request text or the intent recognition result corresponding to the data query request, as well as the necessary database schema context (such as table names, field names, and relationships), into a trained large language model, and uses the trained large language model to output the original structured query statement that conforms to the target database.

[0071] Step 210: Combine the first security constraint, the second security constraint, and the original structured query statement to generate the target structured query statement.

[0072] Specifically, the server applies the field selection and structural integrity rules defined by the first security constraint, as well as the data query range rules defined by the second security constraint, to the original structured query statement. Based on the first and second security constraints, the server performs at least one transformation operation on the original structured query statement, including field adjustment, condition injection, and modification of association relationships. Based on the syntactic structure representation after the transformation operation, the server generates the target structured query statement.

[0073] In the aforementioned method for generating structured query statements, the system receives a data query requirement described in natural language and user permission information associated with that requirement. Based on the data query requirement, it generates a first security constraint, which constrains the field selection and structural integrity of the structured query statement to be generated. Based on the user permission information, it generates a second security constraint, which constrains the data query scope of the structured query statement. A trained large language model is then invoked to generate an original structured query statement based on the data query requirement. Finally, the first and second security constraints, along with the original structured query statement, are combined to generate a target structured query statement. This embodiment of the application, by using business semantic constraints and user permission constraints as prerequisites and deeply coupling them with the generation capabilities of the large language model in terms of timing and logic, enables the synchronous injection and mandatory compliance of security constraints during the conversion from natural language to structured query statements. This ensures that the final generated target structured query statement is semantically faithful to the user's intent, structurally strictly adheres to business rules, and precisely limits its execution scope to user permissions. This fundamentally avoids unauthorized access and semantic ambiguity that may arise from freely generated models, thereby improving data security.

[0074] Furthermore, this method moves the verification and injection of security policies from traditional post-audit or static configuration to the real-time generation process of structured query statements, effectively overcoming the lag in access control and the ambiguity in business semantic understanding of general models. This ensures that the generated results strictly comply with data security and business compliance requirements while guaranteeing the accurate implementation of query functions, thus meeting the dual stringent standards for data access in sensitive fields such as finance.

[0075] In some embodiments, the method for generating structured query statements further includes generating a third security constraint based on a preset set of syntax security rules. The third security constraint is used to define the disabled fields and / or syntax structures in the structured query statement to be generated.

[0076] The preset set of syntax security rules includes prohibitive policies to prevent specific security risks, such as disabling sensitive fields that may lead to information leakage (such as password, id_card_no), or prohibiting the use of syntax structures that pose injection risks.

[0077] For example, the server loads a set of syntax security rules simultaneously with or after generating the first and second security constraints. Based on the intent recognition results of the data query request (such as the business scenario and operation type involved) and user permission information, the server matches corresponding prohibited items from the set of syntax security rules and converts them into explicit filtering or rejection rules, forming the third security constraint. For instance, if the set of syntax security rules stipulates that querying "customer's home address" is prohibited in a "credit approval" scenario, the server will generate the corresponding constraint.

[0078] It should be noted that, in practical applications, the embodiments of this application can process the steps of generating security constraints and generating the original structured query statement based on the large language model in parallel. That is, after the server receives the data query request and the user permission information associated with the data query request, performs intent recognition on the data query request, and obtains the intent recognition result, it simultaneously executes the process of generating security constraints based on the intent recognition result and the user permission information, and the process of calling the large language model to generate the original structured query statement based on the intent recognition result. The security constraints serve as the security control line, and the generation of the original structured query statement serves as the intelligent generation line; the security control line and the intelligent generation line operate simultaneously.

[0079] The security control line of the embodiments of this application will be introduced first below.

[0080] In some embodiments, the security constraints include a first security constraint, a second security constraint, and a third security constraint.

[0081] The first security constraint can be implemented using a semantic decision tree approach. For example, based on the intent recognition results from step 1.2, a predefined semantic decision tree can be traversed. This tree defines the range of data and logic allowed for queries under different business scenarios, ensuring that the semantics of the question conform to business specifications.

[0082] The second security constraint can be implemented using a permission policy tree approach. For example, the user's organizational hierarchy data table can be designed as a tree structure, and the permission policy tree can be invoked synchronously. Based on the current user's role, the user's authorized access tables and row-level permissions for specific fields (e.g., only allowed to query data within their own department) can be determined.

[0083] The third security constraint can be implemented using a grammar parsing tree, for example, to perform a grammatical security pre-check to ensure that the user's question does not contain keywords or patterns that could lead to SQL injection attacks or other security risks.

[0084] In this embodiment, a three-level tree collaborative architecture is adopted, utilizing the dynamic coupling mechanism of the syntax tree, permission tree, and semantic tree to achieve real-time security control of the SQL generation process. The syntax tree can be responsible for syntax security pre-checking, the permission tree can dynamically inject access rules based on user roles (such as field-level permission control), and the semantic tree can resolve ambiguities of synonymous fields through predefined decision rules (e.g., prioritizing "customer main table ID" over "user ID").

[0085] In one exemplary embodiment, such as Figure 3 As shown, step 204 may include steps 302 to 306. Wherein:

[0086] Step 302: Based on the query intent indicated by the data query requirement, determine the target business scenario corresponding to the data query requirement.

[0087] The query intent can refer to the user's core purpose as parsed from the natural language description, such as "statistics," "detailed query," or "correlation analysis." The target business scenario refers to the standardized business category to which the query intent belongs in a specific field (such as the banking industry), such as "deposit business query," "credit approval transaction statistics," or "customer risk profile generation."

[0088] For example, the server performs natural language processing on data query requests, extracts key verbs, business entities, and operation objects, and maps user requests to one or more specific business scenario identifiers by matching them with a predefined business scenario classification model. For instance, for the query request "list all large transfer transactions of branch A this month", the server can identify its intent as "detail query" and determine its target business scenario as "transaction log query".

[0089] Step 304: Based on the pre-configured semantic decision tree, determine the target data query rules that match the target business scenario.

[0090] The semantic decision tree includes data query rules for different business scenarios. A semantic decision tree is a rule engine organized in a tree structure, used to output specific data query constraints based on business scenarios. Each node in the tree represents a business scenario or decision condition, and leaf nodes or specific branches are associated with a set of predefined data query rules specific to that scenario.

[0091] For example, the server loads a semantic decision tree and traverses it using the target business scenario as the entry point. During the traversal, the path can be further refined based on additional conditions in the query (such as the type of product involved, customer level, etc.). The server can locate the node that perfectly matches the current query context and obtain the target data query rules bound to that node.

[0092] In one possible implementation, the target data query rules include at least one of field disambiguation rules and required field rules. The field disambiguation rules indicate the mapping relationship between ambiguous fields in the data query requirement and database fields in the generated structured query statement. The required field rules indicate fields that must appear in the generated structured query statement.

[0093] For example, a semantic tree example is shown in Table 1:

[0094] Table 1

[0095]

[0096] For example, suppose a data query request is "query cross-border remittance records for customer ID 123". Based on the intent recognition result, the server can determine that the business scenario of this data query request is "cross-border remittance". The server then determines the target data query rule corresponding to the "cross-border remittance" scenario from the semantic decision tree. This target data query rule can specifically include field disambiguation rules. For example, for conflicting fields such as CUST_ID and USER_ID, the field disambiguation rule includes prioritizing the customer's main table ID, that is, mapping "customer ID" in the data query request to CUST_ID (instead of USER_ID).

[0097] For example, in the "cross-border remittance" business scenario, even if the data query requirement only mentions "query customer 123's remittance records", the server will also add required fields such as transaction serial number, transaction amount, and currency to the SELECT clause according to the required field rules included in the target data query rules, to ensure that the returned results meet the business specifications and completeness requirements.

[0098] Step 306: Generate the first security constraint based on the target data query rules.

[0099] For example, abstract target data query rules can be converted into specific constraint instructions that can be directly applied in the subsequent query synthesis stage.

[0100] In this embodiment, dynamic selection of conflicting bank-specific fields (such as "BALANCE" and "AVAIL_BALANCE") is resolved based on semantic trees, and decision-making is driven by business context (such as transaction type), thereby improving semantic accuracy.

[0101] In one exemplary embodiment, such as Figure 4 As shown, step 206 may include steps 402 to 404. Wherein:

[0102] Step 402: Based on the user identifier and department indicated by the user permission information, determine the department-level data permission information and field-level permission information corresponding to the data query request.

[0103] Among them, department-level data permission information is used to constrain the scope of departments to which the data records accessed by the structured query statement to be generated belong, and field-level permission information is used to constrain the scope of fields that are allowed to be accessed in the structured query statement to be generated.

[0104] For example, upon receiving a data query request from a user, the server can simultaneously obtain the user's identifier and permission information. Based on the user identifier, the server queries the user's profile and role permission configuration to determine the user's organizational level (e.g., head office, branch in region A, sub-branch in region B, etc.) and their authorized role (e.g., teller, account manager, risk administrator). Based on this information, the server determines the user's data access permissions by querying a pre-defined permission tree. The permission tree is a tree-like structure with the organizational structure as its framework and role permissions as its rules.

[0105] For example, the server can determine department-level data permission information. The permission policy tree defines the data levels that different roles can access within the tree-structured organizational structure. For instance, a branch teller may only be able to access customer transaction data within their own branch, and their department-level permission constraint can be expressed as BRANCH_ID = 'current branch ID'; while a branch manager may be authorized to access data from all branches under that branch, and their constraint can be expressed as BRANCH_ID IN (a list of all branch IDs under the branch). The server can traverse the permission tree based on the current user information to extract and generate the corresponding row-level data filtering conditions, which constitute the department-level data permission information.

[0106] For example, a server can determine field-level permission information, and a permission tree can manage field permissions. Different roles may be allowed to view different ranges of data fields. For instance, a regular teller may be prohibited from viewing sensitive fields such as a customer's "annual income" or "credit score," while a risk administrator may be allowed to. The server extracts the whitelist of fields that the current user role is allowed to access, or the blacklist of fields that are prohibited from access, from the permission policy tree; this constitutes the field-level permission information.

[0107] Step 404: Combine department-level data permission information and field-level permission information to generate the second security constraint.

[0108] For example, a permission tree construction example can be represented as:

[0109] {"node_type":"FIELD_LEVEL","field_name": "mobile_phone","access_rule":

[0110] { "roles": ["CUSTOMER_SERVICE","MANAGER"], "masking":

[0111] "CONCAT(LEFT(phone,3),'****',RIGHT(phone,4))"}}.

[0112] In this embodiment, by constructing and querying a permission tree, abstract user identities and roles are mapped to specific row-level and column-level data access rules, enabling fine-grained and dynamic data security control. This method ensures that the generated structured query statements strictly adhere to the principle of least privilege in both the data record access scope and field visibility dimensions, effectively preventing the risks of horizontal privilege escalation (cross-department access) and vertical privilege escalation (access to sensitive fields), and ensuring precise control of query operations within the permission system.

[0113] The following continues to describe the intelligent line generation embodiments of this application.

[0114] In some embodiments, such as Figure 5 As shown, step 208 may include:

[0115] Step 502: Extract the schema information of the database related to the data query requirements from the preset vector database to obtain enhanced context information.

[0116] For example, by using retrieval enhancement generation technology, user questions can be used as query vectors to retrieve relevant database schema information (such as table structure, field comments, relationships, and sample data) from a vector database, providing accurate contextual knowledge for large models.

[0117] Step 504: Input the data query requirements and enhanced context information into the trained large language model to obtain the original structured query statement generated by the trained large language model.

[0118] For example, the large model generates a raw structured query statement based on the intent recognition results of the data query request and the enhanced context information retrieved in step 502. The raw structured query statement is logically correct, but security constraints are not yet embedded.

[0119] As can be understood, after generating the security constraints and the original structured query statement, the security constraints and the original structured query statement are merged to obtain the target structured query statement. The generated target structured query statement is sent to the database for execution, and the result is returned to the user. Simultaneously, the server can also record this generation process for subsequent model optimization and auditing.

[0120] In some embodiments, the server combines the first security constraint, the second security constraint, the third security constraint, and the original structured query statement to generate the target structured query statement.

[0121] For example, the server intelligently concatenates and merges the original structured query statement generated by the large model with the first, second, and third security constraints. Based on the first security constraint, the server adjusts the field list and relationships of the query; based on the second security constraint, the server injects row-level and column-level filtering or desensitization logic; and based on the third security constraint, the server removes or rewrites risky syntax structures and sensitive field references, ensuring that the final SQL not only satisfies the user's query intent but also strictly adheres to all security and permission rules.

[0122] For example, when the server generates a target structured query statement by combining all security constraints, it can remove or replace disabled fields from the original structured query statement based on a third security constraint, and rewrite or reject query drafts that contain disabled syntax structures.

[0123] In the above embodiments, a parallel workflow is adopted between the security control line (semantic decision tree, permission policy tree, and grammatical analysis tree) and the intelligent generation line (RAG retrieval and large model generation). The security control line preprocesses permission verification and semantic disambiguation, while the intelligent generation line uses retrieval-enhanced generation technology to ensure data accuracy, and finally merges and outputs the data in the SQL synthesis stage.

[0124] The embodiments of this application have the following specific beneficial effects:

[0125] (1) Existing technologies rely on fixed RBAC, which cannot adapt to free question and answer scenarios, leading to permission leakage (such as unauthorized access to data between rows in the case). This application introduces real-time permission tree verification and dynamically injects user permissions to ensure that the SQL is generated in accordance with the "principle of least privilege".

[0126] (2) Existing technologies use fixed rules based on expert experience to process synonymous fields, resulting in poor generalization (e.g., the mapping of "credit balance" is incorrect in the case). This application implements priority decision-making through semantic trees (e.g., dynamically selecting fields based on transaction type) and combines business context disambiguation to improve semantic accuracy.

[0127] (3) Existing technologies review SQL after it is generated, which poses a risk of delay. This application moves security controls (permission verification, syntax checking) to be processed in parallel with intelligent generation (security control line), thus achieving "security left shift".

[0128] (4) Existing technologies have high coupling and are difficult to maintain. This application decouples the rule engine from the large model, separates responsibilities (control and capability are independent), and enhances data accuracy through RAG technology to generate high-quality, highly reliable SQL code that complies with the CBIRC standards.

[0129] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0130] Based on the same inventive concept, this application also provides a structured query statement generation apparatus for implementing the structured query statement generation method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations of one or more structured query statement generation apparatus embodiments provided below can be found in the limitations of the structured query statement generation method described above, and will not be repeated here.

[0131] In one exemplary embodiment, such as Figure 6 As shown, a structured query statement generation apparatus is provided, comprising: a receiving module 602, a first module 604, a second module 606, a model module 608, and a generation module 610, wherein:

[0132] The receiving module 602 is used to receive data query requests described in natural language and user permission information associated with the data query requests.

[0133] The first module 604 is used to generate a first security constraint based on the data query requirements; the first security constraint is used to constrain the field selection and structural integrity in the structured query statement to be generated.

[0134] The second module 606 is used to generate a second security constraint based on the user permission information; the second security constraint is used to constrain the data query range in the structured query statement to be generated.

[0135] Model module 608 is used to call the trained large language model and generate the original structured query statement based on the data query requirements.

[0136] The generation module 610 is used to generate a target structured query statement by combining the first security constraint, the second security constraint, and the original structured query statement.

[0137] In one embodiment, the structured query statement generation device further includes a third module, which is used to: generate a third security constraint based on a preset set of syntax security rules; the third security constraint is used to define the disabled fields and / or syntax structures in the structured query statement to be generated.

[0138] Each module in the aforementioned structured query statement generation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0139] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media to run. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a method for generating structured query statements.

[0140] Those skilled in the art will understand that Figure 7The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0141] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method for generating structured query statements provided in the first aspect of the present application.

[0142] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method for generating structured query statements provided in the first aspect of the embodiments of this application.

[0143] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method for generating structured query statements provided in the first aspect of the embodiments of this application.

[0144] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0145] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0146] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0147] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for generating structured query statements, characterized in that, The method includes: Receive data query requests described in natural language and the user permission information associated with those data query requests; A first security constraint is generated based on the data query requirements; the first security constraint is used to constrain the field selection and structural integrity in the generated structured query statement. A second security constraint is generated based on the user permission information; the second security constraint is used to constrain the data query range in the structured query statement to be generated. The trained large language model is invoked to generate the original structured query statement based on the data query requirements; By combining the first security constraint, the second security constraint, and the original structured query statement, a target structured query statement is generated.

2. The method according to claim 1, characterized in that, The generation of the first security constraint based on the data query requirement includes: Based on the query intent indicated by the data query request, determine the target business scenario corresponding to the data query request; Based on a pre-configured semantic decision tree, target data query rules matching the target business scenario are determined; the semantic decision tree includes data query rules under different business scenarios. The first security constraint is generated based on the target data query rules.

3. The method according to claim 2, characterized in that, The target data query rules include at least one of field disambiguation rules and mandatory field rules; The field disambiguation rules are used to indicate the mapping relationship between ambiguous fields in the data query requirements and database fields in the structured query statement to be generated; The required field rules are used to indicate the fields that must appear in the structured query statement to be generated.

4. The method according to claim 1, characterized in that, The generation of the second security constraint based on the user permission information includes: Based on the user identifier and department indicated by the user permission information, the department-level data permission information and field-level permission information corresponding to the data query request are determined; the department-level data permission information is used to constrain the range of departments to which the data records accessed by the structured query statement to be generated belong, and the field-level permission information is used to constrain the range of fields that are allowed to be accessed in the structured query statement to be generated. The second security constraint is generated by combining the department-level data permission information and the field-level permission information.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: Based on a preset set of syntax security rules, a third security constraint is generated; the third security constraint is used to define the disabled fields and / or syntax structures in the structured query statement to be generated. The step of combining the first security constraint, the second security constraint, and the original structured query statement to generate the target structured query statement includes: The target structured query statement is generated by combining the first security constraint, the second security constraint, the third security constraint, and the original structured query statement.

6. The method according to claim 1, characterized in that, The process of calling the trained large language model to generate a raw structured query statement based on the data query requirements includes: Enhanced context information is obtained by extracting the database schema information related to the data query requirements from the preset vector database; The data query requirement and the enhanced context information are input into the trained large language model to obtain the original structured query statement generated by the trained large language model.

7. A device for generating structured query statements, characterized in that, The device includes: The receiving module is used to receive data query requests described in natural language and user permission information associated with the data query requests; The first module is used to generate a first security constraint based on the data query requirements; the first security constraint is used to constrain the field selection and structural integrity in the structured query statement to be generated. The second module is used to generate a second security constraint based on the user permission information; the second security constraint is used to constrain the data query range in the structured query statement to be generated. The model module is used to call the trained large language model and generate the original structured query statement based on the data query requirements. The generation module is used to combine the first security constraint, the second security constraint, and the original structured query statement to generate a target structured query statement.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images