Data query method and device, computer device, and readable storage medium

Abstract

Embodiments of the present application provide a data query method and device, computer equipment and a readable storage medium. The method comprises: obtaining a data query request and parsing to obtain a data query statement, a query object identifier and a tenant identity identifier; obtaining a plurality of authorized access forms based on the tenant identity identifier and the query object identifier; obtaining a plurality of semantic access forms and determining a target semantic access form; generating an initial query statement corresponding to the data query request through a large language model; determining a target authorized access form based on the target semantic access form, querying the access authority based on the target authorized access form, and obtaining the access range of the query object identifier in the target authorized access form; updating the initial query statement based on the access range to obtain a target query statement, and querying in the database based on the target query statement to obtain a data query result of the data query request. In this way, the query accuracy of the data table can be improved, and the risk of unauthorized access to data can be reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data query method, apparatus, computer device, and readable storage medium. Background Technology

[0002] Low-code SaaS platforms are a software development model that allows users to quickly build business applications through graphical interfaces and configuration methods. These platforms store massive amounts of tenant business data. To facilitate data retrieval for business users without technical backgrounds, natural language-based data query technologies have emerged in recent years. Users input questions in everyday conversational language, and the system automatically converts them into executable database query commands and returns the results.

[0003] In related technologies, natural language data query systems typically employ the following approach: receiving a natural language question input by the user, identifying the query intent through semantic parsing, and transforming the question into a structured query statement based on predefined field mapping relationships. This query statement is then executed, and the results are retrieved from the database and returned to the user. However, in multi-tenant SaaS scenarios, such methods often generate query statements that assume the user has full table access privileges. Direct execution of these statements can lead to serious risks of unauthorized data access. Furthermore, for low-code platforms with numerous custom and non-standardized named data tables, existing technologies suffer from low query accuracy and difficulty in precisely locating the target table. Therefore, existing technologies suffer from low query accuracy and a high risk of unauthorized data access. Summary of the Invention

[0004] This application proposes a data query method, apparatus, computer equipment, and readable storage medium, which can improve the accuracy of data table queries while reducing the risk of unauthorized data access.

[0005] To achieve the above objectives, a first aspect of this application proposes a data query method, the method comprising: Obtain a data query request, and parse the data query request to obtain the corresponding data query statement, query object identifier, and tenant identity identifier corresponding to the query object identifier; Based on the tenant identity identifier and the query object identifier, an access permission query is performed to obtain multiple authorized access forms corresponding to the query object identifier; Obtain multiple semantic access forms corresponding to the multiple authorized access forms, and match the multiple semantic access forms with the data query statement to determine the corresponding target semantic access form. The name of each semantic access form is used to describe the business logic of the name of the corresponding authorized access form. Using a large language model, an initial query statement corresponding to the data query request is generated based on the target semantic access form; Based on the target semantic access form, determine the target authorization access form corresponding to the query object identifier, and perform an access permission query on the query object identifier based on the target authorization access form to obtain the access scope of the query object identifier corresponding to the target authorization access form; The initial query statement is updated based on the access range to obtain the target query statement, and a query is performed in a preset database based on the target query statement to obtain the data query result corresponding to the data query request.

[0006] Accordingly, a second aspect of the embodiments of this application provides a data query apparatus, the apparatus comprising: The parsing module is used to obtain data query requests and parse the data query requests to obtain the corresponding data query statement, query object identifier, and tenant identity identifier corresponding to the query object identifier; The query module is used to perform access permission queries based on the tenant identity identifier and the query object identifier, and obtain multiple authorized access forms corresponding to the query object identifier; The matching module is used to obtain multiple semantic access forms corresponding to the multiple authorized access forms, and to match the multiple semantic access forms with the data query statement to determine the corresponding target semantic access form. The name of each semantic access form is used to describe the business logic of the name of the corresponding authorized access form. The generation module is used to generate the initial query statement corresponding to the data query request based on the target semantic access form using a large language model. The determination module is used to determine the target authorization access form corresponding to the query object identifier based on the target semantic access form, and to perform an access permission query on the query object identifier based on the target authorization access form to obtain the access range of the query object identifier corresponding to the target authorization access form; The update module is used to update the initial query statement based on the access range to obtain the target query statement, and to perform a query in a preset database based on the target query statement to obtain the data query result corresponding to the data query request.

[0007] In some implementations, the matching module is further configured to: Obtain a form semantic graph, wherein the form semantic graph is used to store the mapping relationship between each original access form and the corresponding semantic access form; Based on the form semantic graph, each authorized access form is queried to obtain multiple semantic access forms corresponding to multiple authorized access forms.

[0008] In some implementations, the matching module is further configured to: The data query statement is converted into semantic vector and keyword vector, respectively; Obtain a preset semantic vector repository, wherein the semantic vector repository stores form information consisting of semantic access forms and semantic description information corresponding to the semantic access forms; The semantic vector is matched with the form information corresponding to each semantic access form to obtain a first similarity value; Based on the first similarity value corresponding to each semantic access form, determine the first ranking of each semantic access form among the multiple semantic access forms; The keyword vector is matched with the form information corresponding to each semantic access form to obtain a second similarity value; Based on the second similarity value corresponding to each semantic access form, determine the second ranking of each semantic access form among the plurality of semantic access forms; Based on the first ranking and the second ranking corresponding to each semantic access form, the corresponding target semantic access form is determined from the plurality of semantic access forms.

[0009] In some implementations, the matching module is further configured to: Obtain a smoothing constant, and determine a first fusion matching value for each semantic access form based on the first ranking corresponding to each semantic access form and the smoothing constant; Based on the second ranking corresponding to each semantic access form and the smoothing constant, determine the second fusion matching value corresponding to each semantic access form; Based on the first fusion matching value and the second fusion matching value corresponding to each semantic access form, the comprehensive matching value corresponding to each semantic access form is obtained; Based on the size relationship between multiple comprehensive matching values ​​corresponding to multiple semantic access forms, at least one semantic access form with the largest value is selected as the target semantic access form.

[0010] In some implementations, the generation module is further configured to: Based on a preset semantic library of indicator definitions, determine the indicator calculation rules corresponding to the target semantic access form; Obtain the field description information corresponding to the target semantic access form from the preset form semantic graph; Obtain the current system time, and generate prompt text based on the current system time, the indicator calculation rules, the field description information, and the target semantic access form; Using a large language model, an initial query statement corresponding to the data query request is generated based on the prompt text.

[0011] In some implementations, the determining module is further configured to: Obtain the form semantic graph; Based on the target semantic access form, a query is performed in the form semantic graph to obtain the target authorized access form corresponding to the query object identifier.

[0012] In some implementations, the determining module is further configured to: Call the permission interface and pass the query object identifier and the original encoding identifier corresponding to the target authorized access form to the permission interface; Receive the sub-query statement returned by the permission interface, the sub-query statement being used to limit the set of data rows with access permissions for the query object identifier from the target authorization access form; The access range is determined based on the subquery statement.

[0013] Accordingly, a third aspect of the present application provides a computer device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the data query method of any one of the embodiments of the first aspect of the present application.

[0014] Accordingly, a fourth aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the data query method of any one of the embodiments of the first aspect of this application.

[0015] This application embodiment obtains a data query request and parses it to obtain the corresponding data query statement, query object identifier, and tenant identity identifier corresponding to the query object identifier. It then performs an access permission query based on the tenant identity identifier and the query object identifier to obtain multiple authorized access forms corresponding to the query object identifier. Next, it obtains multiple semantic access forms corresponding to these authorized access forms and matches the data query statement with each semantic access form to determine the corresponding target semantic access form. The name of each semantic access form is used to provide a business logic description of the name of the corresponding authorized access form. Using a large language model, it generates an initial query statement corresponding to the data query request based on the target semantic access form. Based on the target semantic access form, it determines the target authorized access form corresponding to the query object identifier and performs an access permission query on the query object identifier based on the target authorized access form to obtain the access scope of the query object identifier corresponding to the target authorized access form. Finally, it updates the initial query statement based on the access scope to obtain the target query statement and performs a query in a preset database based on the target query statement to obtain the data query result corresponding to the data query request. Therefore, by introducing semantic access forms—that is, by describing the names of authorized access forms with business logic—natural language queries can be matched with table names that have more business meaning. This avoids matching errors caused by directly matching custom or non-standard table names in low-code platforms, thus significantly improving the accuracy of target table location. On the other hand, a dual mechanism of pre-access filtering and post-access injection is constructed: first, the set of authorized forms that users are authorized to access is filtered based on tenant identity and query object identifier; then, for the determined target authorized access form, its row-level or column-level access scope is further queried, and the initial query statement is updated with this scope, ensuring that the final executed target query statement strictly adheres to the user's minimum access permissions. In summary, this application can improve the accuracy of data table queries while reducing the risk of unauthorized data access. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the architecture of the data query system provided in the embodiments of this application; Figure 2 This is a flowchart of the data query method provided in the embodiments of this application; Figure 3 This is a schematic diagram of the functional modules of the data query device provided in the embodiments of this application; Figure 4 This is a schematic diagram of the hardware structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0017] 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.

[0018] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0020] Low-code SaaS platforms are a software development model that allows users to quickly build business applications through graphical interfaces and configuration methods. These platforms store massive amounts of tenant business data. To facilitate data retrieval for business users without technical backgrounds, natural language-based data query technologies have emerged in recent years. Users input questions in everyday conversational language, and the system automatically converts them into executable database query commands and returns the results.

[0021] In related technologies, natural language data query systems typically employ the following approach: receiving a natural language question input by the user, identifying the query intent through semantic parsing, and transforming the question into a structured query statement based on predefined field mapping relationships. This query statement is then executed, and the results are retrieved from the database and returned to the user. However, in multi-tenant SaaS scenarios, such methods often generate query statements that assume the user has full table access privileges. Direct execution of these statements can lead to serious risks of unauthorized data access. Furthermore, for low-code platforms with numerous custom and non-standardized named data tables, existing technologies suffer from low query accuracy and difficulty in precisely locating the target table. Therefore, existing technologies suffer from low query accuracy and a high risk of unauthorized data access.

[0022] Based on this, embodiments of this application provide a data query method, apparatus, computer device, and readable storage medium, which can improve the accuracy of data table queries while reducing the risk of unauthorized data access.

[0023] The data query method, apparatus, computer equipment, and readable storage medium provided in the embodiments of this application are specifically described through the following embodiments. First, the data query system in the embodiments of this application is described.

[0024] Please refer to Figure 1 In some embodiments, this application provides a data query system, including a terminal 11 and a server 12.

[0025] In some implementations, terminal 11 can be used to collect natural language query commands input by the user and receive the final data query results for visualization. For example, it can be a smartphone, tablet, personal computer, or any user terminal hardware with display and interactive functions.

[0026] Furthermore, terminal 11 can configure a natural language input interface and result rendering module through the H5 chat box plugin embedded in the low-code SaaS system to realize the function of the front-end H5 interaction module, namely, to collect users' fuzzy or colloquial data query requests and present the structured or chart-based query results returned after execution to the user.

[0027] In some implementations, the server 12 can be used to perform core data processing on query requests sent by the terminal, such as identity verification, permission filtering, semantic matching, query statement generation, dynamic permission injection, and database query execution; for example, it can be a single server, a cluster of multiple servers, or a virtual server instance based on cloud computing.

[0028] Specifically, server 12 can deploy a data synchronization service module, an agent module, and a data query tool to achieve data synchronization, intent parsing, multi-way table name retrieval, SQL generation, access control injection, and query execution in the analytical database, thereby accurately converting natural language requests into executable query statements that conform to tenant permission constraints and obtaining query results.

[0029] Furthermore, terminal 11 and server 12 can communicate via an API interface based on the HTTP / HTTPS protocol: terminal 11 can send the user's natural language query request along with a token carrying the tenant and user's identity information to server 12; server 12 sequentially performs operations such as identity resolution, permission verification, table name retrieval, SQL generation and permission injection, and returns the result data to terminal 11 after completing the data query in the analytical database; terminal 11 receives the result and displays it to the user through an H5 interface, thus completing a complete collaborative query process from natural language input to secure and accurate data output.

[0030] The data query method in this application can be illustrated by the following examples.

[0031] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user will be obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent will the necessary user-related data for the normal operation of the embodiments of this application be obtained.

[0032] In this embodiment, the description will focus on the data query device, which can be integrated into a computer device. See also Figure 2 , Figure 2 This is a flowchart illustrating the steps of a data query method provided in this application embodiment. Taking the data query device specifically integrated into a terminal or server as an example, the specific process when the processor on the terminal or server executes the program instructions corresponding to the data query method is as follows: Step 101: Obtain the data query request, and parse the data query request to obtain the corresponding data query statement, query object identifier, and tenant identity identifier corresponding to the query object identifier.

[0033] In some implementations, in order to provide a secure and reliable basic input for subsequent permission pre-filtering and semantic table retrieval, the data query statement, query object identifier and tenant identity identifier can be obtained by parsing the data query request to establish a mapping relationship between users and tenants and extract the natural language query text to be processed. This ensures that the natural language query can accurately associate user identity and tenant context in the low-code multi-tenant SaaS platform.

[0034] Among them, a data query request can be a complete message unit sent from the terminal to the backend server, which includes all information such as the natural language text input by the user, the authentication token, and the session context.

[0035] Among them, the data query statement can be pure natural language text extracted from the data query request or obtained after preprocessing (such as Agent reconstruction) to express the user's query intent.

[0036] The query object identifier can be identification information used to uniquely distinguish the identity of a specific user on the platform, such as a user ID or user account, which can be obtained by parsing the identity authentication token carried in the request.

[0037] Among them, the tenant identity identifier can be the identification information used to uniquely distinguish different tenants in the low-code SaaS platform, such as tenant ID or enterprise code, which can be parsed from the token carried in the request. It can be used to isolate the data access scope of different tenants and manage the quota of query resources.

[0038] In some implementations, when a user inputs a query intent in the front-end H5 interactive module of a low-code SaaS platform (such as a natural language query chat box embedded in the system interface), the front-end can generate a data query request based on the user's input and send it to the back-end server. This data query request can be encapsulated as an HTTP request message, whose payload includes the natural language text input by the user, the context identifier of the current session, and an authentication token uniformly issued by the platform. Upon receiving the data query request, the back-end server can first perform a request validity check, such as checking whether the request format is complete and whether the token has expired, to ensure the security of the query entry point.

[0039] Furthermore, after verifying the legitimacy of the request, the backend server can perform structured parsing of the data query request. Specifically, it can extract the natural language text input by the user from the request payload. This text is then reconstructed by the dialogue context of the agent module to form an independent and clear query intent text, which serves as the data query statement for subsequent processing. Simultaneously, it can parse the query object identifier (i.e., the unique ID or account identifying the current user) and the tenant identity identifier (i.e., the unique ID identifying the current enterprise or tenant) to which the query object identifier belongs from the authentication token carried in the request.

[0040] Specifically, the parsing process can use the JWT (JSON Web Token) standard. The token contains claims such as user ID (user_id) and tenant ID (tenant_id). The backend can obtain the above identifiers by verifying the signature and extracting the claim fields.

[0041] Optionally, the remaining quota of the large language model token can be parsed to resolve the tenant's identity. If the quota is insufficient, the process will be interrupted in advance and a recharge prompt will be returned to avoid invalid calculations.

[0042] For example, a salesperson enters "Query my contract amount for this quarter" in the chat box. After the data query request generated by the front end is parsed by the server, the resulting data query statement is "Query my contract amount for this quarter", with the query object identifier being "user_18826" and the tenant identity identifier being "tenant_enterprise_A". This example clearly demonstrates the mapping process from natural language input to structured identity parameters.

[0043] By using the above methods, tenant isolation and permission binding can be achieved throughout the entire process from the query entry point to the data exit point, avoiding the risk of unauthorized data access due to missing identity information.

[0044] Step 102: Perform an access permission query based on the tenant identity identifier and the query object identifier to obtain multiple authorized access forms corresponding to the query object identifier.

[0045] In some implementations, to avoid resource waste or unauthorized access risks caused by subsequent recall of tables without permissions, the permission interface can be called based on the tenant identity identifier and the query object identifier to obtain a list of form identifiers that the user is authorized to access under the current tenant, thereby constructing a queryable whitelist range and providing a safe and accurate search boundary for subsequent multi-way table name recall.

[0046] The authorized access form can be a logical identifier corresponding to the data table that the current user has the right to query after the permission verification. It can be used to limit the search scope of subsequent table name retrieval operations and prevent the system from accessing data that the user does not have the right to view.

[0047] In some implementations, the backend server can invoke the unified permission interface of the low-code SaaS platform to perform a table-level permission pre-query based on the parsed tenant identity identifier (such as tenant_id) and query object identifier (such as user_id). Specifically, the server can encapsulate tenant_id and user_id as request parameters, initiate a query to the permission interface, and obtain a list of application identifiers and form identifiers that the user is authorized to access under the current tenant, i.e., multiple authorized access forms. For example, one of the authorized access forms could be form_001.

[0048] It should be noted that the intent of the query object identifier can be identified based on the data query statement using a large language model, and the intent identification result can be obtained. When the intent identification result points to the "application form" query type, the access permission query based on the tenant identity identifier and the query object identifier is executed to obtain multiple authorized access forms corresponding to the query object identifier. If the intent identification result is "address book" or "process center", a fixed table structure is used directly without relying on the permission whitelist for retrieval, and the fixed table structure is directly returned to the query object corresponding to the query object identifier. It is no longer necessary to execute the access permission query based on the tenant identity identifier and the query object identifier to obtain multiple authorized access forms corresponding to the query object identifier and its subsequent steps.

[0049] Optionally, the results of this permission query can be cached for a short period of time (e.g., the cache validity period is 5 minutes). When the same user (query object identifier) ​​initiates multiple queries in a short period of time, there is no need to call the permission interface repeatedly, thereby reducing the load pressure on the permission service.

[0050] For example, a sales manager with tenant identifier "tenant_enterprise_A" and query object identifier "user_18826" initiates a query. The permissions interface returns that the user has the right to access applications including "Sales Management System," and the corresponding list of form identifiers (multiple authorized access forms) is ["form_sales_order", "form_customer_info"]. Subsequent operations will only be performed within these two forms and will not retrieve other forms that the user does not have permission to access.

[0051] By using the above methods, the search space for subsequent multi-way retrieval can be compressed from the entire form to a whitelist subset accessible to users, thereby effectively avoiding invalid recalls and security vulnerabilities caused by lack of permissions, and providing a compliant and efficient filtering prerequisite for the construction of the candidate table set.

[0052] Step 103: Obtain multiple semantic access forms corresponding to multiple authorized access forms, and match them with multiple semantic access forms based on data query statements to determine the corresponding target semantic access form. The name of each semantic access form is used to describe the business logic of the name of the corresponding authorized access form.

[0053] In some implementations, to accurately match user natural language queries with data tables corresponding to user intent in scenarios where there are many non-standard, custom-named physical table names in low-code platforms, the original coded names of authorized access forms can be pre-mapped to semantic access form names with business semantic logic. Then, multi-dimensional matching can be performed based on data query statements with multiple semantic access forms to filter out the most relevant target semantic access forms, thereby significantly improving the accuracy of table name recognition and reducing query errors caused by table name ambiguity.

[0054] Among them, the semantic access form can be a logical name obtained by semantically translating the original coded table name of the authorized access form into a business name. For example, the physical table name "FB_001" can be mapped to the name "sales contract", which has a clear business meaning.

[0055] The target semantic access form can be at least one semantic access form that is most relevant to the user's query intent, determined by matching the data query statement from multiple candidate semantic access forms. For example, the semantic form "sales orders" matched when the user asks "sales amount this month".

[0056] In some implementations, after obtaining the list of authorized access forms (i.e., the set of physical table names), a pre-constructed form semantic graph can be acquired first. This graph uses a graph database (such as Neo4j) as its carrier, where each node represents a form entity, and nodes are connected by "mapping" edges: a directed edge is established between the original authorized access form node (storing the physical table code identifier, such as "FB_001") and the corresponding semantic access form node (storing the business logic name, such as "sales contract"). The server iterates through each obtained authorized access form, querying the form semantic graph using the physical table name as the key, and extracting the corresponding semantic access form name and associated semantic description information from the target node of the mapping edge. If a certain authorized access form is not mapped in the graph, the server can call a large language model to translate the table name in real time and update the graph to ensure mapping integrity. Thus, multiple semantic access forms corresponding one-to-one with the authorized access forms can be obtained.

[0057] It's important to note that the name of a semantic access form is a business logic description of the original authorized access form name. Its purpose is to shield the underlying non-standard, developer-oriented coding naming (e.g., "form_202310_sales_ec") and provide human-understandable business terms (e.g., "East China Sales Orders") for natural language matching. The mapping relationship between the two includes both a direct translation of the table name and a summary of the business domain of the data within the table. For example, in a low-code platform, there is an authorized access form "FB_001," whose corresponding semantic access form is "Sales Contract"; another authorized access form, "FB_002," corresponds to the semantic access form "Customer Information." When a user enters a data query statement like "Query this month's sales contract amount," the server only needs to match it with the semantic access form "Sales Contract," without needing to process the obscure physical table name "FB_001."

[0058] In some implementations, data query statements can be matched with multiple semantic access forms corresponding to multiple authorized access forms to filter out the target semantic access form most relevant to the user's intent. Matching methods can be flexible and varied. For example, matching can be performed by calculating the semantic similarity between the data query statement and the name and description text of each semantic access form (e.g., using vector cosine similarity). Alternatively, relevance scoring can be based on statistical features of keywords (e.g., the BM25 algorithm). The results of these various matching strategies can also be fused and reordered, for example, using Reciprocal Rank Fusion (RRF) or linear weighted fusion to comprehensively evaluate the relevance of each semantic access form, ultimately determining one or more of the top-ranked semantic access forms as the target semantic access form. For instance, if a user enters "top ten products by sales this month," it can be matched semantically and keyword-wise with semantic access forms such as "sales orders," "product information," and "inventory ledger." "Sales orders" is found to rank highest under both strategies; after fusion, it is determined as the target semantic access form for subsequent SQL generation.

[0059] In some implementations, an enhanced retrieval scheme based on entity links can be introduced. Specifically, before generating keyword vectors, Named Entity Recognition (NER) can be performed on the data query statements to extract business entities (such as "sales contract," "customer name," "amount," etc.). Previously, each semantic access form could be pre-labeled with its contained business entity tags in a semantic repository (e.g., the "sales contract" form is labeled with entities: [contract number, contracting party, amount]). During matching, the server calculates the Jaccard similarity between the set of entities identified in the data query statement and the set of entity tags in each semantic access form, using this as a third-way retrieval feature, and feeds it into RRF fusion along with the dense and sparse results. This can significantly improve the accuracy of table name recognition for queries containing explicit business entities (such as "query the customer name of contract number HT2024001").

[0060] In some implementations, a popularity-weighted mechanism based on query logs can be introduced for frequently accessed popular semantic access forms. Specifically, the server counts the number of times each semantic access form has been successfully matched over a period of time from the logs, and calculates its popularity score (e.g., using an exponentially decaying time window). After RRF fusion, the overall matching value of each candidate form is multiplied by (1+ • Popularity score), among which This is a configurable popularity coefficient (e.g., 0.2). This allows frequently queried forms to receive a moderate boost in ranking, reducing occasional false matches caused by minor differences in vector distance, while maintaining the ability to explore new forms.

[0061] By using the above methods, obscure coded table names can be transformed into semantic names that business users can understand. Based on this, multi-way matching can be performed in conjunction with data query statements to accurately locate the target table that the user actually wants to query within the permission whitelist. This provides the correct table structure context for subsequent SQL generation, avoiding query failures or returned incorrect data due to table name misidentification.

[0062] In some implementations, a form semantic graph storing the mapping relationship between original access forms and semantic access forms can be pre-constructed, and a structured query can be performed on each authorized access form based on this graph to quickly retrieve multiple corresponding semantic access forms, thereby significantly reducing the response latency and computational resource consumption of the semantic mapping process. For example, step 103, "obtaining multiple semantic access forms corresponding to multiple authorized access forms," ​​may include: (103.a1) Obtain the form semantic graph, wherein the form semantic graph is used to store the mapping relationship between each original access form and the corresponding semantic access form; (103.a2) Based on the form semantic graph, query each authorized access form to obtain multiple semantic access forms corresponding to multiple authorized access forms.

[0063] The form semantic graph can be a graph database structure used to store the mapping relationship between the original access forms and the corresponding semantic access forms. For example, it can be a graph model that represents forms with nodes and mappings with edges. It can be constructed and stored in the Neo4j graph database after the original encoded table names have been translated into business semantics using a large language model in advance. It can be used to provide deterministic and reusable semantic mapping query capabilities for the query chain, avoiding the performance overhead caused by repeated translation.

[0064] The original access form can be the original coded identifier corresponding to the physical database table storing business data in the low-code platform, such as "FB_001" or "sales_order_202310", which are table names that have not undergone semantic processing and are automatically generated by the system or user-defined. They generally come from the collection name in business databases such as MongoDB and / or the physical table name in the Doris analysis database. They can be used as the basic identifier for interfacing with the permission system and as the source node for mapping in the form semantic graph.

[0065] In some implementations, a form semantic graph can be pre-built and maintained to store the mapping relationship between each raw access form (i.e., the physical table encoding identifier in the underlying database, such as the MongoDB collection name or the Doris physical table name "FB_001") in the low-code platform and the corresponding semantic access form (i.e., the table name with business logic meaning, such as "sales contract").

[0066] Specifically, the form semantic graph can be implemented using a graph database (such as Neo4j). Each original access form node is connected to one or more semantic access form nodes through labeled mapping edges. It can also store auxiliary metadata such as form field descriptions and business tags. This graph can be built offline. Specifically, through a data synchronization service module, the original coded names of all forms can be retrieved from the metadata center of the low-code platform at startup or periodically. A large language model is then used to perform business semantic translation and summarization on each original name, generating one or more candidate semantic names. These are then written into the graph after manual or automated verification. Furthermore, when forms are added or modified in the platform, an event detection mechanism can trigger incremental updates to ensure the real-time performance of the graph.

[0067] Furthermore, after obtaining multiple authorized access forms (i.e., a list of physical table identifiers that the current user has the right to access), the system uses the original coded name of each authorized access form as the query key to perform precise node matching in the form semantic graph. It then retrieves one or more semantic access form nodes associated with each form along the mapping edges, extracting the semantic form name and associated descriptive information. If an authorized access form does not have a mapping edge in the graph, it can be rolled back to perform real-time translation and update the graph to ensure query completeness. After traversing all authorized access forms, the server obtains multiple semantic access forms that correspond one-to-one. For example, the returned authorized access forms could be ["FB_001", "FB_002"]. A query in the form semantic graph reveals that "FB_001" maps to "Sales Contract" and "FB_002" maps to "Customer Information." Therefore, the server obtains two semantic access forms, "Sales Contract" and "Customer Information," for subsequent matching.

[0068] In some implementations, for scenarios where the same physical table name has different business semantics under different tenants in a multi-tenant environment, tenant tags (tenant_id) can be added to the nodes or edges of the form semantic graph. This requires queries to include the tenant's identity identifier for isolation. Specifically, during a query, not only the original coded name of the authorized access form is passed, but also the current tenant's identity identifier, and only mapping edges matching the tenant tag are retrieved. In this way, the form semantic graph can be used to differentiate the semantic mapping of different tenant identities to the same coded table name (e.g., tenant A interprets "leads" as "sales leads," while tenant B interprets it as "potential customers"), further improving the accuracy of semantic adaptation in cross-tenant scenarios.

[0069] By using the above methods, we can provide a fast and stable semantic access form retrieval capability for subsequent multi-way table name matching steps, significantly reducing the overall response time of the query chain.

[0070] In some implementations, to address the challenges of low-code platforms with numerous custom business logics and semantically similar table names, and to balance the deep semantic intent of user queries with literal keyword matching features, thus avoiding missed or false table name retrieval due to a single search method, a dual-path similarity matching process can be performed on the form information of each semantic access form in a pre-defined vector repository to determine the target semantic access form. This significantly improves the recall and accuracy of table name recognition in complex and non-standard table name scenarios. For example, step 103, "matching the data query statement with multiple semantic access forms to determine the corresponding target semantic access form," may include: (103.b1) Convert the data query statement into semantic vector and keyword vector respectively; (103.b2) Obtain a preset semantic vector repository, wherein the semantic vector repository stores form information consisting of semantic access forms and semantic description information corresponding to the semantic access forms; (103.b3) Perform similarity matching between the semantic vector and the form information corresponding to each semantic access form to obtain the first similarity value; (103.b4) Based on the first similarity value corresponding to each semantic access form, determine the first ranking of each semantic access form among multiple semantic access forms; (103.b5) Perform similarity matching between the keyword vector and the form information corresponding to each semantic access form to obtain the second similarity value; (103.b6) Determine the second ranking of each semantic access form among multiple semantic access forms based on the second similarity value corresponding to each semantic access form; (103.b7) Based on the first and second rankings corresponding to each semantic access form, determine the corresponding target semantic access form from multiple semantic access forms.

[0071] Semantic vectors can be dense vector representations obtained by mapping natural language text to a high-dimensional continuous space through a vector embedding model. For example, "query the top ten customers in terms of sales this month" can be transformed into a vector sequence containing hundreds of floating-point numbers.

[0072] Keyword vectors can be sparse vector representations generated by statistically weighting keywords in the text based on term frequency-inverse document frequency or the BM25 algorithm. For example, only non-zero dimensions in the vector correspond to the positions of keywords appearing in the text, and the dimension values ​​reflect the importance of the keywords. They are usually used to characterize the literal matching features of the text without relying on semantic understanding, and can be used to supplement the deficiencies of semantic retrieval in precise keyword matching scenarios.

[0073] The semantic vector repository can be a specialized database that supports vector storage and retrieval, such as the Milvus vector database. It pre-stores vector data converted from each semantic access form and its associated semantic description information, and can be used to receive query vectors and quickly return several stored records with the highest similarity.

[0074] The semantic description information can be supplementary text that provides a textual explanation of the business meaning, field purpose, and common query scenarios of the semantic access form. For example, "Sales contract form, which records the contract number, amount, and signing date signed between the company and the customer" can be stored together with the name of the semantic access form and participate in vectorization.

[0075] The form information can be a text unit consisting of the name of the semantic access form and its corresponding semantic description information. For example, "sales contract" plus its business description can be combined into a string and exist as a record in the vector repository.

[0076] The first similarity value can be a value obtained by calculating the cosine similarity or inner product between the semantic vector obtained by converting the data query statement and the semantic vector of the form information. The higher the value, the closer the query statement and the form information are in terms of semantics.

[0077] The first ranking can be the position number of each semantic access form in the sorted sequence after sorting multiple semantic access forms according to the first similarity value from high to low. The first ranking indicates the highest semantic similarity.

[0078] The second similarity value can be a value obtained by performing BM25 relevance calculation on the keyword vector obtained by converting the data query statement and the keyword vector of the form information. For example, it can be calculated based on word frequency, document frequency and document length normalization. The higher the value, the more relevant the query statement and the form information are in terms of keyword literal matching.

[0079] The second ranking can be the position number of each semantic access form in the sorting sequence after sorting multiple semantic access forms from high to low according to the second similarity value.

[0080] In some implementations, the obtained data query statement (e.g., the natural language text "Query the top ten customers in terms of sales this month") can be converted into semantic vectors and keyword vectors, respectively. For the semantic vector, a pre-trained text embedding model (such as a general Chinese embedding model) can be invoked to map the entire query statement into a dense floating-point vector of a fixed dimension. For example, the mapped semantic vector can be a vector of dimension 768 [0.12, -0.34, ..., 0.56], which can capture the deep semantic intent of the query statement. For the keyword vector, the BM25 algorithm can be used to calculate the term frequency (TF) and inverse document frequency (IDF) of each word in the query statement, and a sparse vector can be generated based on the statistical information of all documents in the corpus. This vector has non-zero values ​​only on the keyword dimension that appears in the query statement. For example, the mapped keyword vector can be: {("this month", 2.3), ("sales", 5.1), ("customers", 3.2)}, which can represent the literal matching features of the text.

[0081] For example, a semantic vector repository can employ a database specifically designed to support mixed dense and sparse vector retrieval (such as Milvus). In the semantic vector repository, each record corresponds to a semantic access form, and the form information, composed of the name of the semantic access form and its associated semantic description information, is stored after being vectorized. The semantic description information can supplement the form's business meaning, field usage, and common query scenarios. For example, for the semantic access form "sales order," its form information can be described as a sales order table, recording each order's number, customer name, amount, order time, and order status. When the form information is entered into the database, it is also converted into a dense vector using an embedding model, and a sparse vector representation is constructed using a BM25 index to support subsequent dual-path retrieval.

[0082] For example, the semantic vector of the transformed data query statement can be compared with the dense vector of form information corresponding to each semantic access form in the semantic vector repository to calculate similarity. The similarity measure can be cosine similarity or inner product; the result is the first similarity value, ranging from 0 to 1. A higher value indicates a greater semantic similarity between the query statement and the form. For instance, the semantic similarity between the query "top ten customers in sales this month" and the "sales orders" form is 0.92, while the similarity with the "customer information" form is 0.45. This application does not limit the specific similarity calculation method.

[0083] Furthermore, all candidate semantic access forms can be sorted from highest to lowest according to their first similarity value to obtain the first ranking of each semantic access form in the semantic retrieval dimension. For example, multiple semantic access forms and their corresponding first similarity values ​​are: sales order (0.92), product information (0.78), customer information (0.45), and inventory ledger (0.30). Then the first rankings are: sales order 1st, product information 2nd, customer information 3rd, and inventory ledger 4th. The higher the ranking (the lower the ranking value), the more semantically the form matches the user query.

[0084] For example, the keyword vector (sparse representation) of the transformed data query statement can be compared with the sparse keyword vector of the form information corresponding to each semantic access form in the semantic vector repository using BM25 relevance calculation. The BM25 algorithm comprehensively considers the frequency of occurrence of the query term in the form information, the inverse document frequency, and the field length normalization factor, and outputs a non-negative second similarity value. For example, the BM25 score for the query "top ten customers in sales this month" is 12.6 in the "Sales Orders" form information, 3.2 in the "Product Information" form, and 5.8 in the "Customer Information" form. A higher second similarity value indicates a better literal match between the keywords in the query statement and the form information.

[0085] Then, the sets of identical candidate semantic access forms can be sorted from high to low according to the second similarity value to obtain the second ranking of each semantic access form in the keyword retrieval dimension. Continuing with the previous example, if the second similarity values ​​are: sales orders (12.6), customer information (5.8), product information (3.2), and inventory ledger (1.1), then the corresponding second rankings are: sales orders 1st, customer information 2nd, product information 3rd, and inventory ledger 4th.

[0086] Furthermore, the first and second rankings of each semantic access form can be combined to select one or more of the most closely matched forms as target semantic access forms. Specifically, a Reciprocal Ranking Fusion (RRF) algorithm can be used to merge and reorder the two ranking results, ultimately selecting the top N semantic access forms (e.g., Top-1 or Top-3) with the highest fusion scores as target semantic access forms. If the fusion score is significantly higher than other forms, it can be uniquely identified as a target semantic access form; if forms with similar scores exist, multiple candidates can be returned for further processing in subsequent steps.

[0087] By using the above methods, we can simultaneously capture the deep semantic intent and literal keyword features of user queries, and then perform dual-path similarity matching and independent ranking based on these features. This avoids the problems of missed and false recalls in scenarios with highly customized table names and similar semantics when using a single retrieval mode. Furthermore, it provides a two-dimensional ranking basis for subsequent use of fusion algorithms to determine the target semantic access form, significantly improving the accuracy of table name recognition in natural language queries on low-code platforms.

[0088] In some implementations, to achieve unbiased fusion between the heterogeneous search results of dense vector semantic retrieval and sparse vector keyword matching, a smoothing constant can be obtained, and a first fusion matching value and a second fusion matching value can be calculated based on the ranking of each semantic access form in the two searches. These two values ​​are then added together to obtain a comprehensive matching value. The optimal target semantic access form is then selected based on the magnitude of the comprehensive matching value, thereby achieving automatic balancing, deduplication, and confidence re-ranking of semantic intent and literal features. For example, (103.b7) may include: (103.b7.1) Obtain the smoothing constant, and determine the first fusion matching value for each semantic access form based on the first ranking and the smoothing constant for each semantic access form; (103.b7.2) Determine the second fusion matching value for each semantic access form based on the second ranking and smoothing constant corresponding to each semantic access form; (103.b7.3) Based on the first fusion matching value and the second fusion matching value corresponding to each semantic access form, obtain the comprehensive matching value corresponding to each semantic access form; (103.b7.4) Based on the size relationship between multiple comprehensive matching values ​​corresponding to multiple semantic access forms, select at least one semantic access form with the largest value as the target semantic access form.

[0089] The smoothing constant can be a preset positive integer used in the reciprocal ranking fusion algorithm to prevent the ranking from diverging and to adjust the weight of high-ranking items. For example, it can be 60. It can be used to map the rankings in different search result lists to normalized fusion matching values ​​to avoid the top-ranked item from receiving excessively high abnormal weights.

[0090] The first fusion matching value can be used to quantify the relative importance of the form in the semantic retrieval dimension; the higher the ranking, the higher the first fusion matching value.

[0091] The second fusion matching value can be used to quantify the relative importance of the form in the keyword retrieval dimension.

[0092] The overall matching value can be used as a unified ranking criterion for cross-channel search results. The higher the overall matching value, the better the overall performance of the form in both channels of search. For example, if the semantic search contribution is 0.015 and the keyword search contribution is 0.012, then the overall matching value is 0.027.

[0093] In some implementations, a first fusion matching value can be calculated for each candidate semantic access form based on its first ranking. Specifically, the single-path contribution formula in the reciprocal ranking fusion algorithm can be used: First fusion matching value = 1 / (k + first ranking). For example, if the first ranking of a semantic access form "Sales Orders" is 1 and the smoothing constant k = 60, then its first fusion matching value is 1 / (60+1) ≈ 0.01639; if the first ranking of another form "Product Information" is 3, then its first fusion matching value is 1 / (60+3) ≈ 0.01587. The higher the first ranking (the smaller the value), the higher the first fusion matching value.

[0094] Similarly, the second merge match value can be calculated based on the second ranking of each semantic access form (ranked according to the BM25 relevance of sparse keywords) and the same smoothing constant k: Second merge match value = 1 / (k + second ranking). Continuing with the previous example, if the second ranking of "Sales Orders" is 1, then its second merge match value is 1 / (60+1)≈0.01639; if the second ranking of "Product Information" is 3, then its second merge match value is 1 / (60+3)≈0.01587. If a form ranks highly in the first path but low in the second path (e.g., first ranking 1, second ranking 10), its second merge match value is only 1 / (60+10) = 0.01429, significantly lower than forms that rank highly in both paths.

[0095] Furthermore, the first and second fusion matching values ​​of each semantic access form can be added together to obtain the overall matching value of that form. The overall matching value of each semantic access form can be determined in the following way: ; in, The result set consists of two paths (including dense semantic retrieval path and sparse keyword retrieval path). For candidate semantic access forms The rank number in the current search path (starting from 1); This is a smoothing constant (e.g., 60). The formula sums the reciprocals of the two rankings, resulting in a higher overall match score for forms that perform well in both categories. For example, the overall match score for "Sales Orders" is 1 / (60+1) + 1 / (60+1) = 0.03278; for "Product Information," it's 1 / (60+3) + 1 / (60+3) = 0.03174; and for "Customer Information," if the first ranking is 3 and the second is 2, the overall match score is 1 / (60+3) + 1 / (60+2) = 0.01587 + 0.01613 = 0.03200. Therefore, forms with balanced rankings in both categories can also achieve a high overall score.

[0096] Furthermore, after calculating the comprehensive matching value of all candidate semantic access forms, they can be sorted in descending order of comprehensive matching value. Depending on business needs, the largest one (Top-1) can be selected as the sole target semantic access form, or multiple largest ones (e.g., Top-3) can be selected as candidate target semantic access forms for further filtering later (e.g., business metric recall, schema assembly). For example, in the above example, the comprehensive matching value of "Sales Orders" is the highest at 0.03278, followed by "Customer Information" at 0.03200, and "Product Information" at the lowest at 0.03174. If configured to select only one, "Sales Orders" is determined as the target semantic access form; if configured to select the first two, both "Sales Orders" and "Customer Information" are used as target semantic access forms, which can then be further decided based on the business metric recall results, or the large language model can autonomously select the most suitable table from multiple candidate tables.

[0097] For example, in addition to using a fixed smoothing constant k=60, an adaptive smoothing constant adjustment mechanism can also be adopted. Specifically, the optimal k value can be dynamically calculated based on the total number of candidate semantic access forms and the dispersion of the two ranking distributions. For instance, when the number of candidate forms is small (e.g., less than 10), a smaller k (e.g., 30) is used to amplify the ranking differences; when the number of candidate forms is large (e.g., hundreds), a larger k (e.g., 100) is used to smooth ranking fluctuations. The smoothing constant k can be dynamically determined according to the formula k=α×sqrt(N), where N is the total number of candidate semantic access forms and α is a configurable coefficient (e.g., 10). In this way, it is possible to flexibly adapt to the changes in form size of different tenants and different business domains in the low-code platform, improving the robustness of the fusion ranking.

[0098] In some implementations, in addition to the two-way retrieval of dense semantics and sparse keywords, a third-way retrieval based on collaborative filtering can be introduced. Specifically, the click frequency of the corresponding table name in historical queries can be used as the third-way ranking. Then, the third-way ranking is also incorporated into the RRF fusion formula, expanding it to... Therefore, we can leverage collective user behavior to further improve the accuracy of table name matching in high-frequency query scenarios, which is especially suitable for hot business scenarios in low-code platforms where certain forms are repeatedly queried.

[0099] By using the above methods, fusion bias caused by differences in similarity score ranges can be avoided. At the same time, automatic deduplication and confidence reordering of the two search results can be achieved, thereby providing an accurate and reliable target semantic access form for subsequent SQL generation steps.

[0100] Step 104: Using a large language model, generate the initial query statement corresponding to the data query request based on the target semantic access form.

[0101] In some implementations, in order to accurately translate natural language query intent into structured database query statements, a large language model can be used to receive prompt text containing the table structure, field definitions, business metrics, and current user context information of the target semantic access form, so as to generate an initial query statement that conforms to the syntax rules, thereby completing the conversion from business semantics to an executable query language.

[0102] Among them, the large language model can be a deep learning model pre-trained on massive text data, containing a huge number of parameters and having the ability of natural language understanding, logical reasoning and code generation. For example, it can be the GPT series model or an open-source Chinese large model.

[0103] The initial query statement can be a structured query language string generated by the large language model based on the target semantic access form and related context information, such as the original structured query statement (e.g., "SELECT SUM(amount)FROM sales_order WHERE date>= '2026-01-01'").

[0104] In some implementations, after determining the target semantic access form, an initial query statement corresponding to the data query request can be generated using a large language model. Specifically, the complete table structure of the target semantic access form (including field names, data types, and business descriptions) can be extracted from the form semantic graph. The business indicator calculation rules related to the user query (such as "sales this month" corresponding to "SUM(amount) WHERE date BETWEEN first day of this month AND end of month") can be retrieved from the indicator definition semantic library. The current system time can be obtained as the absolute benchmark for relative time conditions (such as "this month" and "last 7 days"). Then, the above information, together with the user's data query statement, the current user identifier (such as user_id), and the preset SQL writing specifications, can be concatenated into a structured prompt text and sent to the large language model.

[0105] Furthermore, the large language model can leverage its natural language understanding and code generation capabilities to output raw SQL strings that conform to the target database syntax as initial query statements. For example, if a user inputs "Query my contract amount for this quarter", the target semantic access form is "sales contract", the semantic library of the indicator definition returns "contract amount = contract amount, contract date within this quarter", the current system time is May 6, 2026 (this quarter is the second quarter), and the user identifier is "user_18826", then the initial query statement generated by the large language model is: "SELECT SUM(contract_amount) FROM sales_contract WHERE sign_date BETWEEN '2026-04-01' AND '2026-06-30' AND sales_person_id='user_18826'", which accurately reflects the user's intent.

[0106] In some implementations, an SQL template caching acceleration scheme can be introduced for frequently reused query patterns (such as sales rankings, year-on-year and month-on-month analysis). Specifically, the server classifies user data query statements into patterns, identifying common template categories such as TOP N rankings, time period summaries, and year-on-year and month-on-month comparisons. If a predefined SQL template is matched, there is no need to call the large language model in real time; only key parameters from the query (such as table name, field name, time range, sorting field, and N value) need to be extracted and filled into the template to quickly generate the initial query statement. The server can store this template and its parameterization rules in a configuration center or rule engine, and update the template library periodically based on query logs. In this way, the cost and response latency of calling the large model in high-frequency query scenarios can be significantly reduced, while ensuring the consistency and stability of the generated SQL.

[0107] By leveraging the powerful semantic understanding and code generation capabilities of large language models, we can combine user natural language queries with the table structure information of target semantic access forms to automatically generate grammatically correct initial query statements. This completes the conversion from business semantics to query language, avoiding the high barrier to entry and low efficiency of manually writing structured query statements.

[0108] In some implementations, to avoid generating semantically biased queries due to a lack of business knowledge in the large language model, the indicator calculation rules corresponding to the target semantic access form can be determined based on an indicator definition semantic library. Field description information can be obtained from the form semantic graph, and combined with the current system time to construct a prompt text containing a complete business context. This guides the large language model to generate a more accurate initial query statement that conforms to the tenant's business definition, thereby significantly improving the accuracy and usability of the generated SQL at the business semantic level. For example, step 104 may include: (104.1) Based on the preset semantic library of indicator definitions, determine the indicator calculation rules corresponding to the target semantic access form; (104.2) Obtain the field description information corresponding to the target semantic access form from the preset form semantic graph; (104.3) Obtain the current system time, and generate prompt text based on the current system time, indicator calculation rules, field description information, and target semantic access form; (104.4) Generate the initial query statement corresponding to the data query request based on the prompt text using a large language model.

[0109] The semantic library for metric definitions can be a structured knowledge base that stores semantic information such as business metric names, calculation formulas, and statistical standards. For example, it can contain a knowledge set of metric definitions such as “Monthly active users = COUNT(DISTINCT user_id) WHERE last_login_time>=1st of this month”. It can be used to retrieve the corresponding calculation rules based on the business metric terms in the user query, so that the SQL generation process can understand the meaning of the metrics for a specific tenant.

[0110] The indicator calculation rules can be a standardized description of the specific calculation logic, aggregation method, filtering conditions and time range of business indicators. For example, "This month's sales revenue is defined as the total amount of orders with a status of 'completed' in the order table and an order date within this month".

[0111] Among them, the form semantic graph can be a graph database structure used to store the association mapping between semantic access forms and their field description information, field types, relationships and other metadata.

[0112] The field description information can be a natural language description of the business meaning, data type, enumeration value range, common uses, etc. of each field in the form. For example, "the field 'amount' represents the contract amount, the unit is yuan, and the type is DECIMAL(18,2)". It is usually stored in the form semantic graph and associated with the form node. It can be used to help the large language model understand the business semantics of the field and correctly map it to the column name and conditions of SQL.

[0113] The current system time can be a real-time timestamp or date obtained from the server when executing a data query request, such as "May 6, 2026". It can be used as the calculation basis for relative time conditions (such as "this month" or "last seven days") in the query, so that the time conditions in the generated initial query statement can be accurately located to the dynamic time period.

[0114] The prompt text can be structured natural language text used to input the large language model, containing query task descriptions, table structure information, indicator definitions, field descriptions, time context, and output format constraints. For example, "Please generate an SQL statement based on the sales contract form (fields: contract number, amount, signing date) and indicator rules (sales amount this month = sum of amounts, signing date is this month)" can be used to guide the large language model to generate an initial query statement that conforms to the business logic according to the expected pattern.

[0115] In some implementations, business metrics and corresponding calculation rules related to a given target semantic access form (e.g., a sales contract) can be retrieved from a pre-defined semantic metric definition library. The semantic metric definition library can be implemented using a vector database (such as Milvus) or a graph database. Each record corresponding to a semantic access form can include the metric name (e.g., "This Month's Sales," "Quarterly Contract Amount," "Average Order Value"), the form it belongs to, the calculation logic (e.g., an SQL expression or natural language description), and a description of the statistical criteria.

[0116] Furthermore, the data query statement in the user's query can be semantically matched with the indicator name and description corresponding to the target semantic access form in the indicator library to retrieve the corresponding indicator calculation rules. For example, if a user queries "contract amount for this quarter", and the target semantic access form is "sales contracts", the calculation rule matched in the indicator definition semantic library can be: "SUM(contract_amount) WHERE sign_date BETWEEN first day of quarter AND last day of quarter AND contract_status='effective'". This rule clarifies the aggregate function, condition fields, and business status filtering, providing indicator-level constraints for subsequent SQL generation.

[0117] Furthermore, field description information corresponding to the target semantic access form can be extracted from a pre-defined form semantic graph (such as Neo4j). This field description information can be a natural language description of the business meaning, data type, common values, and relationships of each field in the form. For example, the field "contract_amount" could be described as "Contract amount, in yuan, DECIMAL(18,2) type, cannot be negative"; and the field "sign_date" could be described as "Signing date, DATE type, format YYYY-MM-DD".

[0118] Specifically, it can retrieve the full description of all fields in the target semantic access form, or it can retrieve only a subset of fields related to the keywords mentioned in the user's query (such as "amount" or "date"). For example, for the "sales contract" form, the field descriptions stored in the graph include "contract_id (contract number)," "customer_name (customer name)," "contract_amount (contract amount)," "sign_date (signing date)," and "sales_person_id (salesperson ID)," etc. These descriptions enable the large language model to accurately understand the purpose of each business field and avoid incorrect mapping.

[0119] Specifically, the current system time can be obtained (e.g., the precise timestamp "2026-05-06 10:30:00" read from the system clock) and used as the absolute reference for relative time expressions.

[0120] Subsequently, the target semantic access form name, metric calculation rules, field description information, current system time, user's original data query statement, current user identifier (such as user_id), and preset SQL writing specifications (such as using lowercase keywords, disabling SELECT) can be added. The system can use a list of explicitly specified fields to perform structured concatenation and generate a complete prompt text.

[0121] For example, the prompt text can be in template form, such as: "Please generate a DorisSQL query based on the following form and information: Form name: [Sales Contract]; Fields and descriptions: [contract_id (contract number), customer_name (customer name), contract_amount (contract amount, unit: yuan), sign_date (signing date), sales_person_id (salesperson ID)]; Metric calculation rules: [SUM(contract_amount) WHERE sign_dateBETWEEN first day of quarter AND last day of quarter AND contract_status='effective']; Current system time: [2026-05-06]; User query: [Contract amount for this quarter]; User ID: [user_18826]; Requirements: [Explicitly list fields, use lowercase, and add appropriate aliases]." This prompt text contains all the business context required for LLM to generate accurate SQL.

[0122] Furthermore, the aforementioned prompt text can be sent to a large language model (such as GPT-4 or an open-source Chinese LLaMA model). The model can then output an initial query statement that conforms to the target database syntax based on its code generation capabilities. This statement does not yet incorporate row-level access control; it only reflects the user's intent and business semantics. Continuing with the example above, the initial query statement generated by the large language model could be: "SELECT SUM(contract_amount) AS total_signed_amount FROM sales_contract WHERE sign_date BETWEEN '2026-04-01' AND '2026-06-30' AND contract_status='Effective' AND sales_person_id='user_18826'". This statement correctly uses the aggregation conditions and business status filtering in the indicator calculation rules, converting the relative time "this quarter" into an absolute date range (2026-04-01 to 2026-06-30), and adding an equivalence condition for the salesperson ID, reflecting an understanding of the user's "my". After the initial query statement is generated, the subsequent dynamic permission injection step will be carried out, and finally a target query statement that can be executed safely will be obtained.

[0123] For example, in addition to retrieving data based on a static metric definition semantic library, a dynamic evolution mechanism for metric rules based on query logs can be introduced. Specifically, user clicks, corrections, or feedback on returned results in historical queries can be analyzed periodically to identify queries that frequently cause SQL semantic errors (such as inconsistent metric definitions). The system can then trigger a metric rule optimization process: calling a large language model to infer the query-feedback pair, generating revised metric calculation rule candidates, which are then updated in the metric definition semantic library after administrator confirmation. In this way, closed-loop self-optimization of metric rules can be achieved, enabling the system to adapt to continuous changes in business definitions.

[0124] By using the above methods, before the large language model generates query statements, it is possible to integrate diverse contextual information such as business indicator calculation rules, field business meanings, and dynamic time bases into the prompt text. This significantly enhances the large language model's ability to understand tenant-specific business semantics, thereby generating more accurate initial query statements that conform to indicator definitions and field meanings. This, in turn, provides semantically correct SQL templates for subsequent permission injection and query execution steps.

[0125] Step 105: Determine the target authorization access form corresponding to the query object identifier based on the target semantic access form, and perform an access permission query on the query object identifier based on the target authorization access form to obtain the access scope of the query object identifier corresponding to the target authorization access form.

[0126] In some implementations, to prevent unauthorized access to data, the target semantic access form can be mapped back to its original encoded identifier in the database, i.e., the target authorized access form. Based on this form, a secondary permission query is performed on the query object identifier to obtain the row-level access range corresponding to the user. This provides precise permission boundary conditions for subsequent SQL injection permission subqueries, achieving dual protection from table-level filtering to row-level control.

[0127] The target authorized access form can be the original physical table identifier obtained by reverse mapping from the target semantic access form through the form semantic graph. For example, the semantic form "sales_contract" is mapped back to the physical table name "FB_001".

[0128] The access scope can be a rule description that identifies the set of data rows that the target authorized access form has viewing permissions for. For example, a user can only access rows in the "Sales Orders" table that are limited by "region='East China'" or "sales_person=current user ID". It can be returned by the permission interface in the form of a subquery.

[0129] In some implementations, after determining the target semantic access form, the reverse mapping function of the form semantic graph can be used to reverse-parse the semantic form name into the original physical table identifier in the underlying database of the low-code platform, i.e., the target authorized access form. Specifically, by using the target semantic access form as the query key, the original encoded table name (the table name of the target authorized access form) can be uniquely obtained by searching along the mapping edge in the Neo4j graph database. For example, the target semantic access form "Sales Contract" is mapped to the target authorized access form "FB_001" (physical table name) in the graph, and this identifier will be used for subsequent permission queries and SQL table replacement.

[0130] Furthermore, based on the target authorized access form (original physical table identifier "FB_001") and the query object identifier (user ID "user_18826"), the unified permission interface of the low-code SaaS platform can be invoked to obtain the row-level access scope of the user on the specified physical table. Specifically, the original encoded identifier of the target authorized access form and the user ID can be passed to the permission interface. The interface returns a structured subquery statement that limits the set of data rows that the user is allowed to access. For example, the subquery statement returned by the permission interface is: "SELECT order_id FROM sales_order WHERE region='East China Region' OR sales_person_id='user_18826'". This subquery indicates that the user can only access orders in the East China region or the order rows they are responsible for.

[0131] This subquery can then be received and temporarily stored as the current user's access scope on the target's authorized access form.

[0132] For example, in addition to obtaining row-level subqueries in real time through a separate permission interface, the row-level permission subqueries for each user-form can be pre-calculated and cached during the data synchronization phase. Specifically, when the data synchronization service module pulls metadata, it also batch-pulls all users' row-level permission rules for each form (such as rules based on roles, departments, or tags) from the permission center and preprocesses them into parameterized subquery templates (e.g., "WHERE region IN (SELECTregion FROM user_region WHERE user_id = #{userId})"). Then, the template can be directly read from the local cache, and placeholders can be dynamically populated with the current user ID to generate the row-level subquery. This avoids delays in synchronous calls to the permission interface.

[0133] The above methods enable on-demand calls to the permission interface and result retrieval, thereby providing a precise permission basis for subsequently replacing table references in the original SQL with target query statements with row-level permission subqueries, and realizing post-event row-level permission injection for natural language queries in a multi-tenant environment.

[0134] In some implementations, to quickly locate the original physical table identifier in the underlying database, thereby providing an accurate mapping basis for subsequent row-level permission queries and SQL table replacements, a pre-constructed form semantic graph can be used. The target semantic access form can be used as the query key for graph traversal retrieval to obtain the uniquely corresponding original encoded physical table identifier, i.e., the target authorized access form. This achieves low-latency, deterministic conversion from the business semantic layer to the physical storage layer. For example, step 105, "determining the target authorized access form corresponding to the query object identifier based on the target semantic access form," may include: (105.a1) Obtain the semantic graph of the form; (105.a2) Based on the target semantic access form, query the form semantic graph to obtain the target authorized access form corresponding to the query object identifier.

[0135] In some implementations, when it is necessary to obtain a preset form semantic graph, an exact match can be performed using the name of the target semantic access form as the query key and a Cypher query statement from the Neo4j graph database, such as "MATCH (s:SemanticForm {name:'Sales Contract'})-[r:MAP_TO]->(p:PhysicalForm) RETURN p.name"), to obtain the associated original authorized access form identifier along the reverse of the mapping edge, thereby completing the call to the form semantic graph.

[0136] Furthermore, a reverse retrieval can be performed in the form semantic graph using a defined target semantic access form (e.g., "sales contract") as the query condition. Specifically, a semantic node that exactly matches the target semantic access form name can be located in the graph. Then, the incoming edges of that node can be traversed to obtain one or more original authorized access form nodes associated with it, from which the original coded table name can be extracted as the target authorized access form. If a semantic form corresponds to multiple physical tables (e.g., "sales contract_2024" and "sales contract_2025" partitioned by year), the server can dynamically filter out semantically matching physical tables by combining the time conditions in the user's data query statement (e.g., "this year" and "2025") or the current system time. If automatic decision-making is not possible, all tables can be returned and marked as "multi-table candidates," which can then be merged or further disambiguated by subsequent SQL generation steps using UNION ALL. For example, if the target semantic access form is "sales contract", the corresponding target authorized access form retrieved in the Neo4j graph database is "FB_001". If the user query includes "2025", it can be further mapped to "FB_001_2025". This target authorized access form will serve as the basis for calling the permission interface and replacing SQL table references in subsequent steps.

[0137] In some implementations, to address the isolation requirements of the same semantic name corresponding to different physical tables in multi-tenant scenarios, the form semantic graph can add a tenant identity field to nodes or edges. When querying based on the target semantic access form, in addition to passing the target semantic access form name, the parsed tenant identity must also be included, retrieving only the mapping relationship matching the tenant tag. For example, tenant A and tenant B each define a custom "sales order" semantic form, but map it to the physical tables "tenant_A_sales_order" and "tenant_B_sales_order" respectively. Through tenant-isolated retrieval, it can be ensured that user queries from different tenants are routed to the correct physical table, avoiding cross-tenant data leakage.

[0138] By using the above methods, we can avoid repeatedly calling the large model for semantic translation during each query, thereby significantly improving mapping efficiency and ensuring the determinism of mapping results. This provides an accurate target authorization form identifier for subsequent calls to the permission interface to obtain the row-level access scope.

[0139] In some implementations, to avoid unauthorized data access caused by directly executing SQL without permission constraints, a permission interface can be called, passing in the query object identifier and the original encoded identifier of the target authorized access form. The interface then returns a subquery statement to limit the data row access range. Based on this subquery statement, the user's row-level access range in the current form is determined, thereby achieving dynamic and fine-grained permission information acquisition. For example, step 105, "performing an access permission query on the query object identifier based on the target authorized access form to obtain the access range corresponding to the query object identifier in the target authorized access form," may include: (105.b1) Call the permission interface and pass the query object identifier and the original encoding identifier corresponding to the target authorized access form to the permission interface; (105.b2) Receive the subquery statement returned by the authorization interface. The subquery statement is used to limit the set of data rows that the query object identifier has access rights to from the target authorization access form; (105.b3) Determine the access range based on the subquery statement.

[0140] The permission interface can be an application programming interface that provides data access permission query capabilities in a low-code SaaS platform, such as a permission service interface in the form of a RESTful API.

[0141] The original encoding identifier can be the physical table name or unique code of the target authorized access form in the underlying database, such as "FB_001".

[0142] The subquery statement can be a fragment of structured query language returned by the permission interface, such as "SELECT order_id FROM sales_order WHERE region='East China Region'" or "SELECT user_id FROM user_org WHERE org_id IN (1,2,3)". It is usually used as a WHERE condition or nested query and can be used to limit the data rows in the original query statement that can be accessed by the current user.

[0143] The data row set can be a logical set of all record rows in the target authorized access form that meet the row-level permission conditions, such as the row set corresponding to "all sales orders in East China", which is defined by the description of the subquery statement.

[0144] In some implementations, the permission service interface provided by the SaaS system can be invoked through a data query tool. When invoking, two core parameters can be passed to this interface: the first is the query object identifier, which can be a unique user ID or role ID obtained after identity resolution (i.e., the query object identifier), used to represent the entity currently initiating the query; the second is the original encoding identifier corresponding to the target authorized access form (e.g., "FB_001"). For example, in a specific application scenario, when user "Manager Zhang" initiates a query, the system determines that the target form is "East China Sales Orders" based on the intent recognition result. The data query tool will then extract the original encoding identifier "order_east_2023" corresponding to this form and, together with the user ID "user_zhang", use it as a parameter to initiate a verification request to the permission interface.

[0145] Furthermore, the data query tool can receive subquery statements returned by the aforementioned permission interface. These subquery statements are SQL fragments dynamically generated by the SaaS platform's underlying permission policy engine based on preset row-level permission rules (e.g., "Regional sales managers can only view orders within their assigned region," "Regular employees can only view data they created or participated in"). These subquery statements can be used to precisely define the data rows within the complete set of data rows of the target authorized access form that the current query object has the necessary access permissions for.

[0146] For example, formally, this subquery can be one or more WHERE clauses with logical AND or OR conditions, or an embedded SELECT statement enclosed in parentheses, such as (SELECT order_id FROM order_permissions WHERE user_id = 'user_zhang' AND region = 'east'). Logically, this statement executes before the main query and outputs a list of data row IDs or a list of specific field values ​​that conform to the permission rules, further narrowing the data scanning scope of the main query. Continuing with the previous example, the permission interface might return the following subquery for "Manager Zhang" on the "order_east_2023" table: (SELECT order_id FROM order_east_2023 WHERE sales_region = 'east'), which explicitly limits subsequent queries to only access order rows in the "East China" region.

[0147] Furthermore, after receiving the subquery statement returned by the permission interface, this subquery statement can be directly used as the logical definition of the access scope, that is, to limit the set of data rows that the main query can operate on. Specifically, when assembling the final executable SQL, the subquery statement can be embedded completely, as a derived table replacing the target table, or as a row-level constraint into the FROM or JOIN clause of the main query. For example, in a specific implementation logic, if the semantic SQL originally generated by the LLM is SELECT... If we use `FROM order_east_2023 WHERE amount>10000`, then we can logically replace the obtained permission subquery statement with the original table reference, ultimately generating SQL with security boundaries: `SELECT ...` The query `FROM (SELECT order_id FROM order_east_2023 WHERE sales_region = 'east') AS authorized_orders JOIN order_east_2023 ON authorized_orders.order_id = order_east_2023.order_id WHERE amount>10000` determines the ultimate access scope on which the query execution is based, ensuring that all returned data rows strictly conform to the tenant and user permission boundaries.

[0148] In some implementations, this can be further extended to dynamic control of column-level permissions and data masking. Specifically, the permission interface returns not only row-level subqueries but also access masks for specific sensitive fields (such as "phone number," "ID number," and "contract amount") that identify the current query object. After receiving the column-level permission metadata, the data query tool dynamically rewrites the SELECT field list of the original SQL before generating the final executable SQL. For example, if the original SQL intends to query "employee name, phone number, department," but the permission policy instructs ordinary users to only partially see the "phone number" field (e.g., masking the middle four digits), the system will automatically rewrite the original SELECT name, phone, department to SELECT name, CONCAT(LEFT(phone,3),' ',RIGHT(phone,4))AS phone,department. This approach, while ensuring row-level data isolation, further enables fine-grained de-identification access to sensitive columns, significantly enhancing data security for low-code SaaS platforms in multi-tenant, complex data permission scenarios.

[0149] By using the above methods, we can effectively avoid security vulnerabilities caused by hard-coded permission rules or assuming full table access, thereby extending permission judgment from the table level down to the row level. This provides accurate and real-time permission boundaries for injecting subqueries into the original SQL and generating the final target query statement.

[0150] Step 106: Update the initial query statement based on the access scope to obtain the target query statement, and perform a query in the preset database based on the target query statement to obtain the data query result corresponding to the data query request.

[0151] In some implementations, to ensure that the final executed SQL accurately expresses the user's query intent and strictly adheres to multi-tenant data isolation specifications, a target query statement with access control can be generated by replacing or embedding the subquery statement corresponding to the access scope in the table reference position of the initial query statement. This query is then executed in a preset analytical database to return data query results that conform to user permission boundaries and business semantics.

[0152] The target query statement can be the final executable Structured Query Language string generated by replacing the original table reference with a subquery with row-level permissions based on the initial query statement. For example, "SELECT..." Replace "FROM sales_order" with "SELECT " FROM(SELECT The command "FROM sales_order WHERE region IN (SELECT region FROM user_region WHERE user_id = 'current user') AS authorized_table" can be used to automatically restrict users to access only data rows within the authorized scope during database execution.

[0153] The data query results can be a set of data returned from a preset database after executing the target query statement, such as a table of record rows and field values ​​that meet the query conditions. This data can be returned to the front-end interactive module in a structured data format or a visual table format, and can be used to present the requested business data to the user, such as "the list of the top ten customers in terms of sales this month and their corresponding amounts".

[0154] In some implementations, after obtaining the access scope (i.e., the set of data rows defined by the aforementioned subquery statement) for limiting data row access permissions, the initial query statement can be structurally updated based on the access scope to generate a target query statement that can be safely executed.

[0155] Specifically, the initial query statement is a raw SQL string generated by the large language model based on the semantic schema. It typically directly references the physical name of the target table (e.g., order_east_2023) and does not have any row-level permission constraints attached. Therefore, to achieve permission-scoped injection, the data query tool rewrites the initial query statement using derived table substitution or inline subquery constraints: the original table reference in the FROM clause of the initial query statement is replaced with a nested structure with the access scope (i.e., the subquery statement) as the embedded view, while keeping the user's original business filtering conditions unchanged in the WHERE clause.

[0156] For example, suppose the initial query is SELECT order_id, amount FROM order_east_2023 WHERE amount>10000, and the obtained access range (subquery) is (SELECT order_id FROM order_east_2023 WHERE sales_region = 'east'). Then the initial statement can be updated to: SELECT order_id, amount FROM (SELECT order_id FROM order_east_2023 WHERE sales_region = 'east') AS authorized_orders INNER JOIN order_east_2023 ON authorized_orders.order_id= order_east_2023.order_id WHERE amount>10000.

[0157] In some implementations, a more concise EXISTS clause can also be used: SELECT order_id,amount FROM order_east_2023 WHERE amount>10000 AND order_id IN (SELECT order_id FROM order_east_2023 WHERE sales_region = 'east').

[0158] Through the above update operations, the original business query intent and permission isolation logic can be organically integrated to form a target query statement that both meets user data needs and strictly follows tenant security policies.

[0159] Furthermore, after generating the target query statement, the data query tool can submit it to a pre-defined database for execution, thereby obtaining the data query results corresponding to the data query request. It should be noted that this pre-defined database is not the original business database of the low-code platform (such as MongoDB), but an analytical database (such as Apache Doris, ClickHouse, or StarRocks) that is pre-synchronized from MongoDB in real time through a data synchronization service module.

[0160] Understandably, business data in low-code platforms is typically stored in MongoDB in document form. For complex queries involving multi-table joins, aggregation calculations, or range filtering, direct execution on MongoDB can lead to high response latency and impact online business stability. Analytical databases, employing columnar storage and massively parallel processing architectures, can efficiently execute these target queries. Therefore, this application selects an analytical database as the query execution engine. For example, after data is synchronized from MongoDB to Doris, the data query tool can submit the target query to Doris using a read-only account through a pre-configured database connection pool, setting a reasonable query timeout threshold (e.g., 30 seconds). After execution, Doris returns a structured result set (e.g., a JSON array or table) that conforms to permission constraints and data filtering conditions. The data query tool then returns this result set to the Agent module, which is ultimately presented to the user by the front-end H5 interaction module in the form of natural language summaries, tables, or visual charts. Using the previous example, if the target query returns two records after execution in Doris (e.g., order IDs 1001 and 1002, with amounts of 15,000 and 20,000 respectively), then this result serves as the final answer to the user's natural language question, "Query orders in East China with an amount greater than 10,000".

[0161] In some implementations, an adaptive rewriting strategy based on query cost awareness can also be introduced. Specifically, after obtaining the access range (subquery statement), the data query tool does not directly execute a single-mode SQL rewriting. Instead, it first performs a lightweight pre-evaluation of the complexity of the initial query statement and the expected amount of data to be returned. The evaluation parameters can include at least the estimated number of rows to be returned by the subquery within the access range. Based on the evaluation results, the system dynamically selects the optimal rewriting mode: if the estimated number of rows to be returned by the subquery within the access range is small (e.g., less than the first preset number of rows, such as 1000 rows), the IN clause or JOIN derived table method is used because its semantics are clear and the optimizer can easily generate an efficient execution plan; if the estimated number of rows to be returned by the subquery within the access range is extremely large (e.g., more than the second preset number of rows, such as 100,000 rows), the EXISTS clause method is automatically switched to because EXISTS terminates the scan early after encountering the first match, making it more suitable for large table permission filtering. In this way, without sacrificing security, the optimal execution path can be selected for different query and data characteristics, thereby significantly improving the query response speed of the data query tool in complex multi-tenant scenarios.

[0162] This application embodiment obtains a data query request and parses it to obtain the corresponding data query statement, query object identifier, and tenant identity identifier corresponding to the query object identifier. It then performs an access permission query based on the tenant identity identifier and the query object identifier to obtain multiple authorized access forms corresponding to the query object identifier. Next, it obtains multiple semantic access forms corresponding to these authorized access forms and matches the data query statement with each semantic access form to determine the corresponding target semantic access form. The name of each semantic access form is used to provide a business logic description of the name of the corresponding authorized access form. Using a large language model, it generates an initial query statement corresponding to the data query request based on the target semantic access form. Based on the target semantic access form, it determines the target authorized access form corresponding to the query object identifier and performs an access permission query on the query object identifier based on the target authorized access form to obtain the access scope of the query object identifier corresponding to the target authorized access form. Finally, it updates the initial query statement based on the access scope to obtain the target query statement and performs a query in a preset database based on the target query statement to obtain the data query result corresponding to the data query request. Therefore, by introducing semantic access forms—that is, by describing the names of authorized access forms with business logic—natural language queries can be matched with table names that have more business meaning. This avoids matching errors caused by directly matching custom or non-standard table names in low-code platforms, thus significantly improving the accuracy of target table location. On the other hand, a dual mechanism of pre-access filtering and post-access injection is constructed: first, the set of authorized forms that users are authorized to access is filtered based on tenant identity and query object identifier; then, for the determined target authorized access form, its row-level or column-level access scope is further queried, and the initial query statement is updated with this scope, ensuring that the final executed target query statement strictly adheres to the user's minimum access permissions. In summary, this application can improve the accuracy of data table queries while reducing the risk of unauthorized data access.

[0163] Please see Figure 3 This application also provides a data query device that can implement the above-described data query method. The data query device includes: The parsing module 31 is used to obtain data query requests and parse the corresponding data query statement, query object identifier, and tenant identity identifier corresponding to the query object identifier based on the data query request. Query module 32 is used to perform access permission queries based on tenant identity identifier and query object identifier, and obtain multiple authorized access forms corresponding to the query object identifier; The matching module 33 is used to obtain multiple semantic access forms corresponding to multiple authorized access forms, and to match them with multiple semantic access forms based on data query statements to determine the corresponding target semantic access form. The name of each semantic access form is used to describe the business logic of the name of the corresponding authorized access form. The generation module 34 is used to generate the initial query statement corresponding to the data query request based on the target semantic access form through a large language model; The determination module 35 is used to determine the target authorization access form corresponding to the query object identifier based on the target semantic access form, and to perform an access permission query on the query object identifier based on the target authorization access form to obtain the access scope of the query object identifier corresponding to the target authorization access form. The update module 36 is used to update the initial query statement based on the access range to obtain the target query statement, and to perform a query in the preset database based on the target query statement to obtain the data query result corresponding to the data query request.

[0164] The specific implementation of this data query device is basically the same as the specific embodiment of the data query method described above, and will not be repeated here. Subject to meeting the requirements of the embodiments of this application, the data query device may also be equipped with other functional modules to implement the data query method described above.

[0165] This application also provides a computer device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described data query method. This computer device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0166] Please see Figure 4 , Figure 4 The hardware structure of a computer device according to another embodiment is illustrated. The computer device includes: The processor 41 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 42 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 42 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 42 and is called and executed by the processor 41 using the data query method of the embodiments of this application. Input / output interface 43 is used to implement information input and output; The communication interface 44 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 45 transmits information between various components of the device (e.g., processor 41, memory 42, input / output interface 43, and communication interface 44); The processor 41, memory 42, input / output interface 43 and communication interface 44 are connected to each other within the device via bus 45.

[0167] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described data query method.

[0168] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0169] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0170] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0171] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0172] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0173] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0174] It should be understood that in this application, "at least one" and "several" refer to one or more, and "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0175] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of the units described above 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 system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0176] The units described above 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.

[0177] Furthermore, the functional units in the various embodiments of this application 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0178] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or 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 multiple 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 of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0179] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A data query method, characterized in that, The method includes: Obtain a data query request, and parse the data query request to obtain the corresponding data query statement, query object identifier, and tenant identity identifier corresponding to the query object identifier; Based on the tenant identity identifier and the query object identifier, an access permission query is performed to obtain multiple authorized access forms corresponding to the query object identifier; Obtain multiple semantic access forms corresponding to the multiple authorized access forms, and match the multiple semantic access forms with the data query statement to determine the corresponding target semantic access form. The name of each semantic access form is used to describe the business logic of the name of the corresponding authorized access form. Using a large language model, an initial query statement corresponding to the data query request is generated based on the target semantic access form; Based on the target semantic access form, determine the target authorization access form corresponding to the query object identifier, and perform an access permission query on the query object identifier based on the target authorization access form to obtain the access scope of the query object identifier corresponding to the target authorization access form; The initial query statement is updated based on the access range to obtain the target query statement, and a query is performed in a preset database based on the target query statement to obtain the data query result corresponding to the data query request.

2. The data query method according to claim 1, characterized in that, The step of obtaining the multiple semantic access forms corresponding to the multiple authorized access forms includes: Obtain a form semantic graph, wherein the form semantic graph is used to store the mapping relationship between each original access form and the corresponding semantic access form; Based on the form semantic graph, each authorized access form is queried to obtain multiple semantic access forms corresponding to multiple authorized access forms.

3. The data query method according to claim 1, characterized in that, The step of matching the data query statement with the plurality of semantic access forms to determine the corresponding target semantic access form includes: The data query statement is converted into semantic vector and keyword vector, respectively; Obtain a preset semantic vector repository, wherein the semantic vector repository stores form information consisting of semantic access forms and semantic description information corresponding to the semantic access forms; The semantic vector is matched with the form information corresponding to each semantic access form to obtain a first similarity value; Based on the first similarity value corresponding to each semantic access form, determine the first ranking of each semantic access form among the multiple semantic access forms; The keyword vector is matched with the form information corresponding to each semantic access form to obtain a second similarity value; Based on the second similarity value corresponding to each semantic access form, determine the second ranking of each semantic access form among the multiple semantic access forms; Based on the first ranking and the second ranking corresponding to each semantic access form, the corresponding target semantic access form is determined from the plurality of semantic access forms.

4. The data query method according to claim 3, characterized in that, The step of determining the corresponding target semantic access form from the plurality of semantic access forms based on the first ranking and the second ranking corresponding to each semantic access form includes: Obtain a smoothing constant, and determine a first fusion matching value for each semantic access form based on the first ranking corresponding to each semantic access form and the smoothing constant; Based on the second ranking corresponding to each semantic access form and the smoothing constant, determine the second fusion matching value corresponding to each semantic access form; Based on the first fusion matching value and the second fusion matching value corresponding to each semantic access form, the comprehensive matching value corresponding to each semantic access form is obtained; Based on the size relationship between multiple comprehensive matching values ​​corresponding to multiple semantic access forms, at least one semantic access form with the largest value is selected as the target semantic access form.

5. The data query method according to claim 1, characterized in that, The step of generating the initial query statement corresponding to the data query request based on the target semantic access form using a large language model includes: Based on a preset semantic library of indicator definitions, determine the indicator calculation rules corresponding to the target semantic access form; Obtain the field description information corresponding to the target semantic access form from the preset form semantic graph; Obtain the current system time, and generate prompt text based on the current system time, the indicator calculation rules, the field description information, and the target semantic access form; Using a large language model, an initial query statement corresponding to the data query request is generated based on the prompt text.

6. The data query method according to claim 1, characterized in that, The step of determining the target authorized access form corresponding to the query object identifier based on the target semantic access form includes: Obtain the form semantic graph; Based on the target semantic access form, a query is performed in the form semantic graph to obtain the target authorized access form corresponding to the query object identifier.

7. The data query method according to claim 1, characterized in that, The step of performing an access permission query on the query object identifier based on the target authorization access form to obtain the access scope of the query object identifier corresponding to the target authorization access form includes: Call the permission interface and pass the query object identifier and the original encoding identifier corresponding to the target authorized access form to the permission interface; Receive the sub-query statement returned by the permission interface, the sub-query statement being used to limit the set of data rows with access permissions for the query object identifier from the target authorization access form; The access range is determined based on the subquery statement.

8. A data query device, characterized in that, The device includes: The parsing module is used to obtain data query requests and parse the data query requests to obtain the corresponding data query statement, query object identifier, and tenant identity identifier corresponding to the query object identifier; The query module is used to perform access permission queries based on the tenant identity identifier and the query object identifier, and obtain multiple authorized access forms corresponding to the query object identifier; The matching module is used to obtain multiple semantic access forms corresponding to the multiple authorized access forms, and to match the multiple semantic access forms with the data query statement to determine the corresponding target semantic access form. The name of each semantic access form is used to describe the business logic of the name of the corresponding authorized access form. The generation module is used to generate the initial query statement corresponding to the data query request based on the target semantic access form using a large language model. The determination module is used to determine the target authorization access form corresponding to the query object identifier based on the target semantic access form, and to perform an access permission query on the query object identifier based on the target authorization access form to obtain the access range of the query object identifier corresponding to the target authorization access form; The update module is used to update the initial query statement based on the access range to obtain the target query statement, and to perform a query in a preset database based on the target query statement to obtain the data query result corresponding to the data query request.

9. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the data query method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the data query method according to any one of claims 1 to 7.

Images